快手為何惹人嫌？

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

　　一、翻滾條的立異【重構法】

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

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

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

　　翻滾條能夠理解為文檔在筆直方向上的縮略圖，滑塊能夠表明可視區域當時方位，可視區域占全體區域的份額。跟著文檔全體區域不斷增高，可視區域所占的份額越小，因此滑塊高度不斷變小。計算過IE、FF、Office等常用軟件，通?；瑝K高度到8px時就不再縮小。當滑塊高度只剩8px時，翻滾條的拖動體會就適當的差。

　　Google wave對翻滾條做了斗膽的立異。

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

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

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

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

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

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

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

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

　　mac官網： 加錨點橫向翻滾條，點擊錨點，滑塊翻滾到相應方位

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

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

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

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

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

　　

#p#分頁標題#e#



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

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


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

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

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

　　Gmail附件上載的規劃對文件上載組件做了兩次瘦身手術。

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


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

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

　　傳統的翻頁方法是“上一頁+頁碼+下一頁”，我們最了解的規劃。

　　Bing圖像查找

　　Google reader

　　看圖購

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

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


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


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

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

　　由此也延伸出一點，交互規劃師的作業責任除了架構信息，還應當操控信息的活動速度和供給量。