交互手勢全解析之描述維度
編輯導語:你有了解過交互手勢的描述維度嗎?你認為現如今交互手勢的呈現效果如何?這篇文章作者詳細講解了之前未提到的較為隱性的描述維度,感興趣的小伙伴一起來看看吧。
交互手勢的描述維度是什么?在這里我們將其簡單定義為影響一個交互手勢呈現效果的變量。
在之前的文章中,提及過的描述維度包括穩定化效果、控制方式、閾值類型、時間限制、按下次數、觸發時機,但它們的都是一些較為顯性的描述維度,確定了某個手勢的基本框架。
本文主要講解之前未提到的較為隱性的描述維度,它們同樣影響著用戶的操作體驗,包括角度與方向、反饋比率、熱區。下面將逐一介紹。
一、角度與方向
角度與方向的知識在「交互手勢全解析之位移類手勢」中簡單地討論過一些,在這里會講解地更詳細。
位移類手勢的方向一般為上下方向或左右方向,或者二者兼有之,但是想要觸發操作,手指移動方向并不需要完全垂直或水平,默認會有一個容錯角度。
當某個界面或模塊僅支持上下方向或左右方向的位移類手勢時,如下圖所示,360度會1:1均分,每個方向有180度的容錯角度,只要在角度范圍內滑動,都可以觸發相應操作,但需要注意的是在僅支持上下方向滑動時,如果完全水平方向去滑動,則不會觸發任何操作,反之亦然。
雖然說角度的容錯范圍很大,但是滑動時離預期方向的角度偏離越大,單位長度產生的有效位移距離就會變少。例如下圖中,在一個只能上下滑動的頁面,垂直上滑和偏移上滑相同距離產生的有效位移是不同的,垂直上滑的效率明顯更高。
當上下滑動和左右滑動同時存在于一個頁面或模塊時,會出現兩種情況。第一種情況是被滑動的內容除上下左右外可以往更多方向移動,例如滑動照片或地圖查看更多細節(如下圖所示),是允許用戶自由地朝任意方向滑動的。
第二種情況是,在單次操作中,只有上下或左右方向的滑動需求。360度會1:1:1:1均分,每個方向有90度的容錯角度。在這種情況,上滑時手指滑動方向只要左右偏移不超過 45° 都會被判定為上滑,如下圖所示。
對于這第二種情況,系統需要處理以下兩個問題。
問題A:如果在上下滑過程中進行左右滑動的操作,系統如何判定?
一般我們是不希望用戶在一次操作中同時進行上下滑動和左右滑動的。系統如果判定某次滑動為上下滑動,為了避免誤操作,在本次滑動結束前(滑動結束的定義:手指離開屏幕并且受控物停止移動或停止其他屬性變化),左右滑動會被完全禁用,而且左右滑動的容錯角度會臨時分配給上下滑動,如下圖所示。
例如,在iOS信息列表中,左右滑動可以喚起更多操作,上下滑動可以滾動頁面,但是一旦進入上下滑動的過程中,不松手的情況下左右滑動喚起更多操作就被完全禁用了,且左右滑動的容錯角度會臨時分配給上下滑動。
問題B:系統是如何在某一次滑動時判定我們是想要上下滑動還是左右滑動呢?
系統給予我們自然的使用體驗背后是復雜的判定過程。判定的難點有兩個,第一個難點:手指在操控屏幕時并不是一個穩定的狀態,接觸屏幕的一瞬間很容易抖動。抖動的方向也是不確定的,這個抖動需要判定為滑動嗎?如果用戶并不想滑動只是想進行點擊操作的話怎么辦?
第二個難點:手指在接觸屏幕后,接觸屏幕的手指面積是逐漸增加的,但向下的增加要比其他方向的多,如果直接識別的話會被判定為下滑,應該怎么處理?
下圖的動畫是慢速模擬手指接觸屏幕的過程。
為了解決上述的兩個難點,系統會設定一個容錯距離,用戶的滑動位移如果在這個距離內,系統就會把手勢判定為“點擊”,只有當用戶往某個方向的滑動位移達到或超過這個距離,系統才會判定為“滑動”。但是由于這個容錯距離很小,作為用戶的我們去操作時,是很難感受到這個容錯距離的存在的。
基礎規則講完了,接下來針對第二種情況介紹一些負面案例,下圖左是滑動前正常的角度分配,但是有時由于開發同學的失誤,導致容錯角度沒有均分,出現下圖右中觸發上滑和下滑的角度極小的情況,進而導致用戶在上下滑動時非常容易誤操作為左滑和右滑。
網易云音樂也曾有過類似的遺留問題,iOS 端的播放頁上滑調出評論頁極易誤操作為左右滑動黑膠切歌(下圖 A ,現已修復),安卓端的賬號側邊欄上滑瀏覽極易誤操作為左滑收起側邊欄(下圖 B )。
因此,在驗收階段,角度的容錯性檢查也是重要的一環。因此在驗收時間充裕的情況下,可以切換不同的手持方式分別體驗一次,因為有些問題只有在特定的手持方式下才容易被發現。
二、反饋比率
之前提到過施控物(施加控制的一方)和受控物(被施加控制的一方)的概念。比率是受控物的某個屬性變化與的施控物某個屬性變化的比值。為了更好地理解這個概念,在這里舉個例子。
如下圖,在網易云音樂的播放頁和微信小程序頁面邊緣右滑一個固定距離時,頁面的下降距離是不同的,網易云音樂播放頁的下降距離大約只有微信小程序頁面的一半,我們可以認為對于這個交互,網易云音樂的反饋比率是微信小程序的一半。
比率的大小并沒有絕對的優劣之分。比率越小,反饋越遲鈍,但方便精準操作。比率越大,反饋越靈敏,效率高,但不方便精準操作。由于比率的這些特性,在不同的場景中會根據需求來選用合適的比率。
在現實生活中,不同車型的轉向比就是一個較為典型的案例。汽車方向盤旋轉1圈半只能讓輪胎旋轉30度左右,而賽車、卡丁車的方向盤旋轉角度和輪胎的旋轉角度通常是一致的。
普通人使用汽車的主要目的是代步,主要訴求是舒適安全,因此選用反饋比率小的轉向比能夠提高容錯率。而對于賽車、卡丁車這一類為競技而設計的車型,駕駛員要隨時對復雜的賽道環境做出快速的操作,因此需要使用反饋比率高的轉向比提高靈敏度。
反饋比率在很多設備的交互設計中都有應用,例如我們可以設置鼠標的跟蹤速度的快慢,跟蹤速度越快,反饋比率越大,鼠標移動相同的距離可以控制光標移動更大的距離。
在觀看視頻時,對進度進行細微調整和跨度較大的調整都是用戶的常見需求,因此一般做法是采用兩種比率不同的操作方式來滿足需求。通過拖動視頻區域的熱區來進行反饋比率較小的細微調整,通過拖動進度條的熱區來進行反饋比率較大的大跨度調整。
三、熱區
熱區為手勢提供了可操作的區域,需要接觸屏幕的手勢都需要熱區才能觸發。合理的熱區布置能夠有效提高用戶體驗。
3.1 熱區大小
更大的熱區可以減少用戶瞄準所花費的時間,減少觸發失敗的概率。
熱區的大小不一定等于按鈕的大小,當某個按鈕在視覺上設計得比較小時,為了方便用戶操作,我們可以將熱區合理地設計大一些。例如下圖的App Store應用詳情頁中,視覺上按鈕雖然很小,但是點擊熱區卻設置得很大。
按鈕與熱區如果聯系感弱,就會導致用戶的疑惑。例如下面的案例,換一換的按鈕熱區過大,擴大到了標題區域,用戶如果無意間點擊標題卻更換了一批內容,就可能感到奇怪。
下面的詞典案例中,雖然播放按鈕只是右側的一個小圖標,但是頂部由單詞構成的整個區域都是可以點擊的。因為點擊單詞與發音存在強聯系,所以這樣的熱區擴大是合理的、聯系感強的。
按鈕的層級和樣式如果相同,熱區面積一般需要保持一致,并撐滿可用空間。例如常見的tab欄上的圖標。
對于高頻操作,很多App會另外設計一個隱藏手勢供用戶使用,因為手勢所能提供的熱區遠遠大于按鈕的熱區,更加便于用戶操作。例如網易云音樂的播放頁會將高頻功能都另外配備一個手勢以此來提高操作效率。下圖藍色為按鈕熱區,紅色為手勢的熱區。
3.2 熱區層級
界面會存在點擊類手勢與位移類手勢的熱區重疊的情況,此時兩者是平級的,因為手勢差異大所以互不干擾。
當界面中存在兩種點擊類手勢的熱區重疊情況或兩種位移類手勢的熱區重疊情況時,就會出現層級排序的問題。
在支付寶的一個猜漲跌的模塊中,熱區的大概分布如下圖所示。整個模塊整體有一個熱區,點擊可以進入二級頁面。看漲和看跌分別有一個熱區,點擊可以直接選擇操作,層級布置是在整體熱區的上一層。
對于位移類手勢,熱區的層級布置更為復雜。比如以豆瓣的我的頁面為例,在iOS全面屏上的橫滑熱區分布如下圖所示。
①邊緣右滑喚起側邊欄;②橫滑泳道可以看更多書影音檔案;③橫滑底部的iOS安全區可以切換應用;④其他位置右滑可以切換tab頁。
通過熱區層級的觀察,我們能夠發現一些明顯的體驗問題。
在QQ音樂的首頁,頁面可以通過橫滑切換tab,同時歌單可以通過橫滑查看更多。歌單的滑動熱區位于橫滑tab熱區的上一層。
通過觀察熱區的層級我們可以看出,歌單的橫滑熱區幾乎覆蓋了拇指的易操作區域,導致tab的橫滑手勢難以觸發。
有書的播放頁中,左邊界的全局右滑返回熱區在進度控件的上一層,但是進度滑塊由于距離頁面左邊界太近,導致滑動進度滑塊時很容易誤操作為返回上一頁。這種情況下我們可以標注一個右滑手勢禁用區域給開發工程師說明情況,將此情況避免掉即可。
3.3 啟動熱區與調整熱區
對于某些位移類手勢,在操作時熱區并不是一直保持不變的,而是分為了啟動熱區與調整熱區。當位移類手勢的起始點位于啟動熱區時,系統才會響應,后續操作過程中,手指不離開屏幕繼續進行位移操作時系統響應的區域被稱為調整熱區。
通常調整熱區會擴大到全屏,同時禁用了界面的其他全部功能,目的主要是為了保證在后續操作過程中能夠為用戶提供足夠大的熱區增加操作舒適度,其次是為了避免用戶手指一直擋住觸發區域的重要信息。
例如,iOS的控制中心中,在音量控件區域上下拖動可以調節音量大小,拖動過程中將手指移出音量控件區域繼續上下拖動仍然可以繼續調節。這樣的設計可以避免手指擋住控件造成無法直觀看清音量大小的問題。
再進行一個案例對比,QQ音樂和網易云音樂的播放條都支持左右滑動切歌,但是整體體驗上有一些差距。
在面積大小層面,QQ音樂的啟動熱區與網易云音樂的啟動熱區是基本相同的,但是QQ音樂的調整熱區是全屏,而網易云音樂的調整熱區仍然和啟動熱區一致。
這樣導致的問題是,用戶在使用網易云音樂時,如果左右滑動播放條的過程中手指無意間超出了啟動熱區就會導致本次操作無效,影響使用體驗,而QQ音樂沒有這個問題。
以上就是關于描述維度的思考總結,有興趣的朋友可以持續關注~
本文由 @Ballen成明 原創發布于人人都是產品經理,未經作者許可,禁止轉載。
題圖來自Unsplash,基于CC0協議。
真的很希望各大APP能考慮一下手滑、錯點、誤點的情況,再也不想點錯什么了
太有趣啦,交互手勢原來有這么多維度,各種容錯機制真是幸苦了開發人員
縱享絲滑的設計感,給使用者帶來很好的體驗!作者分析的好!
隱性的描述維度是之前從來沒有接觸過的領域,看了這篇文章受益匪淺,很不錯