縱觀交互規(guī)劃開展史，即是立異的交互形式被廣為承受后變成規(guī)范，舊的交互形式不斷被篩選的前史。所以交互形式開展也是一個“物競天擇，優(yōu)勝劣汰”的進程。
　　交互規(guī)劃是一個創(chuàng)造性的作業(yè)，運用立異的方法美麗地處理商品疑問，是一個交互規(guī)劃師價值的表現(xiàn)。當(dāng)立異的交互規(guī)劃被用戶認可、被業(yè)界同行學(xué)習(xí)，更是一種無窮的工作滿足感。這種立異紛歧定是驚天地泣鬼神的革命性規(guī)劃，一個小小的交互組件的立異就能夠讓商品體會增色不少。

　　一、翻滾條的立異【重構(gòu)法】

　　我們先來回想一下閱覽PDF文檔的兩種翻滾方法：1、手型東西拖動 2、翻滾條。

　　要翻看后邊的信息，用手型東西向上拖動，用翻滾條則是向下拖動，兩種操作方法的原理是什么呢?

　　把文檔分紅可視區(qū)域A和全體區(qū)域B。翻滾條滑塊對應(yīng)的是文檔的可視區(qū)域A。因此翻滾條拖動的是可視區(qū)域A，而手型東西拖動的是全體區(qū)域B，兩種操作方法拖動的主體紛歧樣，所以方向恰好相反。

　　翻滾條能夠理解為文檔在筆直方向上的縮略圖，滑塊能夠表明可視區(qū)域當(dāng)時方位，可視區(qū)域占全體區(qū)域的份額。跟著文檔全體區(qū)域不斷增高，可視區(qū)域所占的份額越小，因此滑塊高度不斷變小。計算過IE、FF、Office等常用軟件，通�；瑝K高度到8px時就不再縮小。當(dāng)滑塊高度只剩8px時，翻滾條的拖動體會就適當(dāng)?shù)牟睢?br />
　　Google wave對翻滾條做了斗膽的立異。

　　1、 上下按鈕與滑塊連在一起(優(yōu)點：從滑塊到上下按鈕的鼠標運動間隔變短;疑問：點擊上下按鈕，滑塊無法跟隨運動)

　　2、 翻滾條的滑塊高度固定不變(優(yōu)點：處理了滑塊極小的疑問;疑問：無法表明可視區(qū)域的份額)

　　這兩處修正優(yōu)化了傳統(tǒng)翻滾條的疑問，卻導(dǎo)致翻滾條基本特點(“方位”與“份額”)疑問。為處理導(dǎo)致的新疑問，谷歌 wave的翻滾條引入了兩個新元素：

　　1、 半透明灰色塊 (點擊上下按鈕，滑塊無法跟隨運動，則半透明灰色塊運動——處理方位疑問)

　　2、 停止條 (wave內(nèi)容不斷增多，停止條方位不斷向下，用來表明內(nèi)容全體高度——處理份額疑問。惋惜這個停止條視覺效果讓人以為是可拖動的，簡略導(dǎo)致疑問。)

　　Google Wave花了這么大心思立異翻滾條，也面臨著翻滾條復(fù)雜化后導(dǎo)致的用戶習(xí)氣疑問。自己認為這個翻滾條立異是因商品需求而做的，wave一個頁面也許一起存在4個翻滾條，當(dāng)4個傳統(tǒng)翻滾條一起出如今一個頁面上效果可想而知。Wave翻滾條不管視覺仍是交互上都是很“輕”的規(guī)劃，與商品全體上還算恰當(dāng)。

　　====================================================

　　蘋果對翻滾條的改善則簡略有用：加錨點。

　　mac官網(wǎng)： 加錨點橫向翻滾條，點擊錨點，滑塊翻滾到相應(yīng)方位

　　iphone音樂專輯列表：加錨點的翻滾條，輕觸字母，列表翻滾到相應(yīng)方位

　　加錨點的方法讓翻滾條增加了導(dǎo)航和準確定位功用，變得愈加易用。

　　二、組合查找框的立異 【組合法】

　　多見的帶條件查找框是“輸入框+下拉菜單+按鈕”三個控件構(gòu)成的，適宜的控件組合能夠帶來非常好的效果。

　　1、【輸入框+下拉菜單】組合
　　新浪微博的查找框，將下拉選項融合到輸入框提示里，挑選查找規(guī)模的操作愈加便當(dāng)。

　　

#p#分頁標題#e#



　　Google reader這么的帶輸入操作的下拉菜單，讓下拉菜單愈加易用。(這種控件組合在word、photoshop等軟件里很多見，如字體挑選控件)

　　2、【按鈕+下拉菜單】組合


　　豆瓣與Flickr的查找按鈕后邊加了一個下拉箭頭，按鈕與下拉挑選操作合二為一 (flickr這個規(guī)劃與它網(wǎng)站主導(dǎo)航條體會共同，豆瓣用這種規(guī)劃在其整站看來則略顯突兀)
　　三、文件上載組件的立異 【瘦身法】

　　規(guī)范的文件上載組件是由“輸入框(偽)+閱覽按鈕+提交按鈕”構(gòu)成。之說以稱之為“偽輸入框”是由于它首要承當(dāng)顯示文件途徑的效果，所以Firefox下點擊這個輸入框是開端文件挑選操作，chrome更是把偽輸入框改造成了按鈕，復(fù)原控件最初始的效果。

　　運用規(guī)范文件上載組件常常會呈現(xiàn)兩個提交按鈕，最常常的誤操作即是：選完文件后，直接點擊“保存頭像設(shè)置”，所以杯具了。

　　Gmail附件上載的規(guī)劃對文件上載組件做了兩次瘦身手術(shù)。

　　曩昔的gmail附件上載過程是：1、點擊“增加附件”(點擊后呈現(xiàn)一個不帶提交按鈕的上載組件)，2、挑選文件(選完后主動開端上載)。去掉了那個提交按鈕。


　　如今的gmail附件上載過程是：1、點擊“增加附件”(點擊后主動開端上載，且有上載進度條)。去掉了輸入框和提交按鈕，只剩下一個閱覽按鈕，上載只需求一次點擊操作。

　　四、翻頁的立異 【代替法】

　　傳統(tǒng)的翻頁方法是“上一頁+頁碼+下一頁”，我們最了解的規(guī)劃。

　　Bing圖像查找

　　Google reader

　　看圖購

　　而近年鼓起的這種“無盡翻滾翻頁”的翻頁方法，即翻滾條拖動到最底部后開端加載后邊的內(nèi)容，而不再有“上一頁+頁碼+下一頁”這么的連接。

　　相對而言twitter、Iphone app store這么的“遞進式翻頁”則沒那么急進，保留了一個翻頁按鈕，是介于傳統(tǒng)翻頁與無盡翻滾翻頁的一種折中方法。


　　這兒講到的翻頁組件立異，是用新的翻頁方法代替?zhèn)鹘y(tǒng)翻頁組件。從信息的構(gòu)造來看，傳統(tǒng)翻頁是將信息分段，而“無盡翻滾翻頁”歸于信息翻滾。這兩種方法對應(yīng)現(xiàn)實生活中的原型是：書本和電影膠片，書本把信息拆分到每頁里去翻動，電影膠片的信息則一幀幀的翻滾而過。


　　從信息活動速度和翻頁便當(dāng)性來看，“信息翻滾”遠遠大于“信息分段”。這兩種翻頁方法應(yīng)當(dāng)怎么挑選?我想這應(yīng)當(dāng)取決于用戶對后邊內(nèi)容的需求強度，像谷歌查找成果頁這種越往后信息質(zhì)量越低的場景，用戶對翻頁需求并不那么激烈。Google reader這么不是按信息質(zhì)量排序的場景，供給高速的翻頁方法是個相對必要的做法。需求留意的是，翻滾翻頁不利于內(nèi)容準確定位和信息回溯。#p#分頁標題#e#

　　信息活動速度對信息承受者心態(tài)有很大影響，活動速度越快信息吸收量相對越小，所以閱覽pdf文檔比閱覽紙質(zhì)書本心情煩躁，不由得去翻頁，是在“掃描”而不是“閱覽”(自己片面感觸，如有雷同純屬必然)

　　由此也延伸出一點，交互規(guī)劃師的作業(yè)責(zé)任除了架構(gòu)信息，還應(yīng)當(dāng)操控信息的活動速度和供給量。