縱觀交互規(guī)劃開展史,即是立異的交互形式被廣為承受后變成規(guī)范,舊的交互形式不斷被篩選的前史。所以交互形式開展也是一個“物競天擇,優(yōu)勝劣汰”的進(jìn)程。
交互規(guī)劃是一個創(chuàng)造性的作業(yè),運用立異的方法美麗地處理商品疑問,是一個交互規(guī)劃師價值的表現(xiàn)。當(dāng)立異的交互規(guī)劃被用戶認(rèn)可、被業(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等常用軟件,通常滑塊高度到8px時就不再縮小。當(dāng)滑塊高度只剩8px時,翻滾條的拖動體會就適當(dāng)?shù)牟睢?br />
Google wave對翻滾條做了斗膽的立異。
1、 上下按鈕與滑塊連在一起(優(yōu)點:從滑塊到上下按鈕的鼠標(biāo)運動間隔變短;疑問:點擊上下按鈕,滑塊無法跟隨運動)
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í)氣疑問。自己認(rèn)為這個翻滾條立異是因商品需求而做的,wave一個頁面也許一起存在4個翻滾條,當(dāng)4個傳統(tǒng)翻滾條一起出如今一個頁面上效果可想而知。Wave翻滾條不管視覺仍是交互上都是很“輕”的規(guī)劃,與商品全體上還算恰當(dāng)。
====================================================
蘋果對翻滾條的改善則簡略有用:加錨點。
mac官網(wǎng): 加錨點橫向翻滾條,點擊錨點,滑塊翻滾到相應(yīng)方位
iphone音樂專輯列表:加錨點的翻滾條,輕觸字母,列表翻滾到相應(yīng)方位
加錨點的方法讓翻滾條增加了導(dǎo)航和準(zhǔn)確定位功用,變得愈加易用。
二、組合查找框的立異 【組合法】
多見的帶條件查找框是“輸入框+下拉菜單+按鈕”三個控件構(gòu)成的,適宜的控件組合能夠帶來非常好的效果。
1、【輸入框+下拉菜單】組合
新浪微博的查找框,將下拉選項融合到輸入框提示里,挑選查找規(guī)模的操作愈加便當(dāng)。
#p#分頁標(biāo)題#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、點擊“增加附件”(點擊后主動開端上載,且有上載進(jìn)度條)。去掉了輸入框和提交按鈕,只剩下一個閱覽按鈕,上載只需求一次點擊操作。
四、翻頁的立異 【代替法】
傳統(tǒng)的翻頁方法是“上一頁+頁碼+下一頁”,我們最了解的規(guī)劃。
Bing圖像查找
Google reader
看圖購
而近年鼓起的這種“無盡翻滾翻頁”的翻頁方法,即翻滾條拖動到最底部后開端加載后邊的內(nèi)容,而不再有“上一頁+頁碼+下一頁”這么的連接。
相對而言twitter、Iphone app store這么的“遞進(jìn)式翻頁”則沒那么急進(jìn),保留了一個翻頁按鈕,是介于傳統(tǒng)翻頁與無盡翻滾翻頁的一種折中方法。
這兒講到的翻頁組件立異,是用新的翻頁方法代替?zhèn)鹘y(tǒng)翻頁組件。從信息的構(gòu)造來看,傳統(tǒng)翻頁是將信息分段,而“無盡翻滾翻頁”歸于信息翻滾。這兩種方法對應(yīng)現(xiàn)實生活中的原型是:書本和電影膠片,書本把信息拆分到每頁里去翻動,電影膠片的信息則一幀幀的翻滾而過。
從信息活動速度和翻頁便當(dāng)性來看,“信息翻滾”遠(yuǎn)遠(yuǎn)大于“信息分段”。這兩種翻頁方法應(yīng)當(dāng)怎么挑選?我想這應(yīng)當(dāng)取決于用戶對后邊內(nèi)容的需求強度,像谷歌查找成果頁這種越往后信息質(zhì)量越低的場景,用戶對翻頁需求并不那么激烈。Google reader這么不是按信息質(zhì)量排序的場景,供給高速的翻頁方法是個相對必要的做法。需求留意的是,翻滾翻頁不利于內(nèi)容準(zhǔn)確定位和信息回溯。#p#分頁標(biāo)題#e#
信息活動速度對信息承受者心態(tài)有很大影響,活動速度越快信息吸收量相對越小,所以閱覽pdf文檔比閱覽紙質(zhì)書本心情煩躁,不由得去翻頁,是在“掃描”而不是“閱覽”(自己片面感觸,如有雷同純屬必然)
由此也延伸出一點,交互規(guī)劃師的作業(yè)責(zé)任除了架構(gòu)信息,還應(yīng)當(dāng)操控信息的活動速度和供給量。
|