為什麼 iOS 的 Tab Bar 採用 press 觸發而非按鈕通用的 release 觸發?


所有的 tap 事件都要求越快反應越好,但 button 是觸發動作,譬如編輯和刪除,譬如說關注和取消關注,這些動作一般不可「返回」,或返回和撤銷的成本太高,需要一個防錯機制,降低後悔成本。

而 Tap Bar 僅僅是視圖的切換,頻繁操作,可返回,對事件的影響有限,改變的只是視圖(view),所以不需要像 button 那樣需要針對「防錯」和「後悔成本」作優化。

這就是兩者對 tap 事件不同處理的原因。press 觸發適用於 Tab Bar,release 觸發適用於 button.

────

不過 iOS 的 button 或者 Tab Bar 或者主屏幕的應用圖標的觸發情況和考慮因素遠沒有這麼簡單,因為上面只論述了單獨的 tap 事件,而事實上,除了 tap 事件,還會有 double tap 事件,還有 tap and hold 事件,還有 tap and drag 事件,更有甚者,是 tap this button and hold then tap another button 事件...

有兩個好玩的例子,其它回答也提到了,就是 iOS 鍵盤的 delete 鍵和 shift 鍵。前者是 press 觸發,但同時帶有 tap and hold 事件(快速刪除),後者,shift,在初始狀態(燈滅)下,是 press 事件,在手指觸碰的剎那,燈即亮起。此時若保持觸碰,即 tap and hold,可以點擊其它按鍵。但在燈亮的狀態下,shift 又變成 release 觸發... 一個按鍵前後有兩種觸發形式。

而主屏幕的應用圖標,(1) 定義了 tap and drag 事件,即翻頁; (2) 定義了 tap and hold 事件,即管理模式; (3) 在滿足前面兩種事件可執行的前提下,只能是 release 觸發。

所以我們經常會看到一種尷尬的情況發生:在主屏幕翻頁的時候,觸碰到某應用圖標,先會有選中的效果,接著拖動,選中效果消失。這樣一前一後,造成的閃爍,便是我說的尷尬,是為並非優雅的結果。(或許選中的效果並非必要?)


採用 release 還是 press 對用戶體驗整體的提升是很有限的,普通人很難意識到它們的區別。要不是在知乎看到這個問題,我也不會特意去關注。所以這裡要感謝提出這個問題的@傅屍水 同學。同時,蘋果的工程師專業素養之高亦令我敬佩。(o(︶︿︶)o 我廠的安卓手機真是 release 到底,工程師和設計師都沒這個意識)

之前的回答不經過大腦就寫了,今天手頭正好有腎5、lumia800(WP7.8) 和 GS III,

於是我花了大概半小時走查了 iOS 中 tap 事件的 press 觸發,並和另外兩台做了對比,整理如下。

三星和微軟都有對點觸事件的觸發方式有考量,但卻沒有蘋果那麼喜歡用 press 觸發。

iOS 里 press 觸發的點擊事件真的相當多。

首先我找到的 TabBar 都是 press 觸發。撥號、時間管理、天氣里的 ℉ ℃ 切換的 tab、日曆切換日周月視圖的tab……

這裡@鄭紫陽 同學說得很清楚了,tab 只是切換視圖,不需要提供反悔,又能使響應快那麼一點。不過,除了要求 tap 響應快之外,另一個需要考量的是事件觸發後手指的位置。點擊一個按鈕後,往往會發生界面跳轉,如果 press 觸發了事件,完成了界面的跳轉,而此時用戶手指依舊停留在屏幕上,那麼它很可能已經點在了跳轉界面的某個按鈕上,這會讓用戶產生一定的困惑。而且,如果軟體設計的不夠好,抬手時說不定觸發了這個按鈕(我廠手機我遇到過這種情況)所以 release 觸發的一個好處是保證事件發生時用戶的手指已經離開了屏幕。而 TabBar 的特點在於,它是固定的,發生視圖跳轉不改變 TabBar 自身,手指不離開屏幕也不會有什麼影響,可以放心使用 press。

iPhone 日曆月視圖裡,點擊某一天查看當天的日程,界面不會跳轉,選中日子的操作是 press 觸發。

也有不考量手指在新界面的位置的。秒錶應用的啟動、停止、複位、計次四個按鈕都是 press 觸發,就純粹是為了快地響應,計時更加精準。同時和真實的秒錶體驗一致。

說到對快速響應的追求,iPhone 真是不遺餘力。

物理按鍵里,音量鍵調節音量是 press 觸發。

腎5點亮屏幕響應極快,也有 Power 鍵和十個有九個壞掉了的 Home 鍵 press 觸發點亮屏幕的一份功勞。雖然GS III 也是電源鍵 press 觸發亮屏,可畢竟是安卓,明顯可感知的延時還輪不到優化按鍵觸發條件。而自稱「快得把人干到冒煙」的WP手機Lumia,本來值得與腎5一戰,卻坑在 power 鍵 release 觸發亮屏。

我想蘋果恨不得採用電源鍵 press 來觸發關閉屏幕,不過關閉屏幕恰恰是 release 。這是因為電源鍵定義了長按事件(長按關機),如果一按就關屏,就沒辦法看到長按事件觸發後彈出的關機選項了。

一般情況下,定義了長按(Press hold)事件的按鈕就不適合用 press 觸發,可也有例外

撥號盤0~9*#都是 press 觸發,結合點擊時嘟嘟嘟的響聲,很有座機撥號的感覺。

其中 0 * # 定義了長按事件,用來輸入 + P W , 這裡 press 觸發就不與長按事件衝突。

最後說說輸入法的軟鍵盤。

大小寫切換按鈕、字母符號切換按鈕和多語言切換按鈕這仨用 press 觸發比較好理解,原因基本等同 TabBar 。

令我費解的是,退格鍵也是 press 觸發!難道蘋果自知其輸入法不牢靠,乾脆提供用戶啪啪啪刪除錯字的爽快感?WP的輸入法也有很多按鈕用的 press 觸發,可沒包含退格。

最後的最後,可以考慮用 press 觸發的自我小結:

` 如果迫切追求操作的快速響應 (如秒錶的按鈕、power點亮屏幕)

` 如果該按鈕比較容易點中,點擊後依舊留在原處且不用考慮防錯(撥號盤數字鍵 、TabBar 、輸入法的各種切換按鈕……)

` 留意是否有長按/雙擊/拖動事件,如果有,留意是否會產生衝突

--------------- update 4.15 ,以上 ------------------

------- 4.12 未經大腦的原答案-------

除了Tab不需要提供反悔的原因。 還有一個原因是對現實的隱喻。

按鈕有兩種,一種按一下不會彈起來,比如老式的錄放音機,電熱水壺的加熱按鈕等; 還有一種按下去會彈起來,常見的如電梯樓層按鈕。

對於前者,現實中都是press觸發,後者在現實世界也是press 觸發(就算改為release也無法反悔,沒有意義),電子世界才是release觸發。

蘋果的tab, 隱喻第一種鈕,點擊後GUI表現上也是一個按下去的效果,整個點擊過程是normal-pressed; 而採用release觸發的鈕,點擊過程是normal-pressed-normal,或者彈起後變為激活狀態。可以看安卓的tab ,沒有隱喻不會彈起的按鈕,激活的tab GUI表現也不是?被按下去?的效果,所以依舊採用了release觸發。


@徐盛超 已經說的很清楚了。

我再從開發者的角度補充一點。

對於蘋果屏幕多點觸碰來說,如果tabbar的各個tab採用release觸發的話,在用戶同時按住兩個tab或者快速在tab之間切換時會出現crash現象。

因此,一般互斥的操作之間使用Press,來減少兩個動作衝突的可能;不需要互斥執行的操作,一般選擇Release方式。類似於資料庫中元操作的概念。

舉個栗子,如果一個頁面中有兩個不相關的button,那麼它們是可以被獨立地分別用兩個手指點擊並執行的,所以可以使用release方式。但如果一個頁面中兩個button的操作是相關的,比如都會對同一個頁面進行操作,或者對某一個數據進行操作,就應該使用press,而不是release,以避免衝突。

另外,

1、在鍵盤中大寫鍵其實可以在按住的同時輸入其他字元,所打出的字元在此時全部大寫。鬆開即變回小寫。相當於shift鍵。

2、在鍵盤中如果touch一個字母的同時,touch另一個字母,前一個字母就會自動被打到屏幕上去。這也是對於多點觸控多個任務之間同步與非同步執行的一種處理。

3、在鍵盤中,delete鍵採用Press的方式,是為了避免輸入與刪除同時操作文本框而產生的衝突。


使用release時,release outside可以取消。

誤操作代價高的,比如navigation bar上的按鈕(會觸發push動畫來切換界面,耗時長;而tabbar切換界面無動畫),或者一般的button,用release inside觸發,可以避免用戶誤操作(因為還沒release前用戶發現誤操作了,可以移動到outside取消)。

誤操作代價小的,可直接press觸發。


一般按鈕Press的時候會有狀態改變以指示被按下(類似於滑鼠操作的hover),

Tab還需要有一個狀態來指示當前頁面,

那麼如果使用Release觸發,就需要為一個Tab Button設計三種狀態(如果只有兩種,用戶感覺按下去了沒有反應,和死機差不多)。

並且Tab又不是會導致數據改寫的操作,可以撤銷,沒有風險。


推薦閱讀:

為什麼網站登錄窗口要在另一個網址?
ARVR的界面適合延續現在手機的扁平化界面設計嗎?
中文字體會不會與簡潔的 iOS 7 的扁平設計格格不入?
什麼是『設計思維』(Design thinking)?
圓形屏幕上的界面和交互設計有什麼特點,有哪些典型?

TAG:iOS開發 | 交互設計 | 用戶體驗設計 | TabBar |