移動應(yīng)用側(cè)邊欄交互的利與弊與解決方法

1 評論 4720 瀏覽 4 收藏 12 分鐘

現(xiàn)在我們已經(jīng)有數(shù)據(jù)說明側(cè)拉菜單(又稱漢堡包菜單)的使用,可能弊大于利。

下面是一些數(shù)據(jù):

需要注意的是,這是一件十分微妙的問題。而同樣的問題,我們也已經(jīng)在用戶測試和其他一些事情中發(fā)現(xiàn)。

我希望你們閱讀過這篇文章后能對這個問題及解決方法有所了解,并且在使用這個模式前知曉其后果。

問題

  1. 不易發(fā)現(xiàn)
  2. 更低效
  3. 與平臺原生導(dǎo)航模式?jīng)_突
  4. 并不是一目了然

不易發(fā)現(xiàn)

“不在眼中的,就不會想到?!?/p>

在這個模式的默認狀態(tài),側(cè)拉菜單和里面所有的內(nèi)容都是隱藏的。

人們需要首先需要辨別側(cè)拉菜單按鈕是可以點擊的——公司都認為應(yīng)該使用一個菜單或者工具圖標來表示,他們也確實感覺有必要這么做——但是在應(yīng)用使用時可能就不是這個情況了,因為主頁顯承載了主要的功能。

不那么有效

盡管用戶了解并看重這一特征,但是這個模式帶來了一種導(dǎo)航認知摩擦,因為它迫使人們先打開菜單,然后才能看到其中的條目。

下面是一個對比的案例。展示了如果導(dǎo)航元素一直可見的話,導(dǎo)航效果是多么迅速。

側(cè)邊欄交互的利與弊個與解決方法

和平臺原生導(dǎo)航模式?jīng)_突

除了上面那些問題,在iOS這樣的平臺上,側(cè)拉菜單與標準導(dǎo)航模式有沖突。

側(cè)邊欄交互的利與弊個與解決方法

左邊的導(dǎo)航欄按鈕需要保留一個菜單按鈕,但是我們也得讓用戶有回去的方法。設(shè)計師要么承認上圖中存在的導(dǎo)航欄內(nèi)容過載問題——甚至沒有給標題留下空間,要么迫使用戶點擊好幾次來進入下圖顯示的列表。

側(cè)邊欄交互的利與弊個與解決方法

不一目了然

側(cè)邊欄交互的利與弊個與解決方法

因為導(dǎo)航僅在用戶想要進入應(yīng)用其他部分時才可見,所以使得對特定內(nèi)容信息的呈現(xiàn)更加困難。

你可能會采用和Jawbone?UP應(yīng)用相似的做法:在側(cè)拉菜單按鈕旁邊放置一個象征消息的圖標。

這個并不實用,因為這需要你去處理更多的圖標,并且作為設(shè)計師來說可能要被迫去增加一個通用圖標,而不是弱化圖標含義。

反之,下面的選項卡欄(采自twitter),讓用戶了解通知的情境,并且直接引導(dǎo)其到達相關(guān)頁面。

側(cè)邊欄交互的利與弊個與解決方法

認知

側(cè)邊欄交互的利與弊個與解決方法

你可能有時為了節(jié)省屏幕空間而被迫使用它,但是這確實會讓人們對他們看到的東西產(chǎn)生誤導(dǎo)。當你認為用戶看到了呈現(xiàn)在他眼前的所有內(nèi)容的時候,其實我們會將注意力有一個焦點區(qū)域(而不是整個屏幕),即使屏幕尺寸很小也是一樣。

案例:消失的圖標——改變移動設(shè)備的盲目性

所以節(jié)省屏幕空間可以通過不損害導(dǎo)航或者不違背基本人機交互原則而達到目的,比如提供反饋或者展示當前狀態(tài)。

另外提醒一下:我們需要的是更新我們頭腦中對人機交互的理解。我很確信這會幫助人們在進行視覺設(shè)計時避免很多錯誤產(chǎn)生。

解決方法

側(cè)邊欄交互的利與弊個與解決方法

關(guān)于問題本身寫了很多,但是具體解決方法大家其實還不清楚。

什么時候該使用它呢?

側(cè)邊欄交互的利與弊個與解決方法

極少數(shù)情況下這種模式有用,但是一般性的原則還是盡量避免使用。

IRCCloud是一個適合這個模式的應(yīng)用——可以實現(xiàn)頻道和頻道成員之間的導(dǎo)航。

由于主屏下面沒有子頁面的層級導(dǎo)航存在,所以這可以使用,信息可以簡單地呈現(xiàn)出來。

但是即使是在這種情景下,可以看到用戶界面仍然信息過載了,應(yīng)用的信息架構(gòu)需要重新考慮了。

側(cè)邊欄交互的利與弊個與解決方法

右側(cè)的側(cè)拉菜單展示了頻道成員內(nèi)容結(jié)果只是呈現(xiàn)活動按鈕,而弱化展現(xiàn)整個頻道相關(guān)操作。反之,設(shè)計師沒有其他選擇余地,只能將頻道、網(wǎng)絡(luò)和賬號混合放在了一個單獨的菜單之中:

側(cè)邊欄交互的利與弊個與解決方法

接下來讓我們?nèi)タ纯次恼碌南乱徊糠帧?/p>

要是不用這種方法,我該怎么辦呢?

側(cè)邊欄交互的利與弊個與解決方法

側(cè)邊菜單會導(dǎo)致糟糕的信息架構(gòu),因為你只是一味將其添加進去,而沒有考慮結(jié)果——直到人們實際使用的時候才會意識到它有多糟糕。

解決方法是重新檢查你的信息架構(gòu)。

側(cè)邊欄交互的利與弊個與解決方法

上面是一個如何去除側(cè)拉菜單的例子。你可以按照那些彩點來了解這兩種解決方法間元素的過渡方式。

注意點:

  1. 消息選項卡上直接顯示當前狀態(tài)
  2. 項目總是可見的且可以立刻到達
  3. 導(dǎo)航手勢不能沖突

側(cè)邊欄交互的利與弊個與解決方法

就這些固定的問題而言,我們也能夠通過滾動方向來隱藏導(dǎo)航條從而節(jié)省屏幕的垂直空間,F(xiàn)acebook和Safari都應(yīng)用了這種方式。固定的標簽欄能夠清晰的告訴用戶當前所處的位置,這樣我們就無需只依靠導(dǎo)航欄來確定了。

如果你想要更簡單,那么一個工具欄就足夠了。關(guān)鍵是不要隱藏導(dǎo)航,而是允許直接操作,不要和現(xiàn)有的導(dǎo)航手勢沖突,并且在相關(guān)圖標上提供反饋。

對于網(wǎng)站來說,我覺的最好的解決辦法還是重新審視信息架構(gòu),而不是直接挪用iOS設(shè)計模式。下面一個只在網(wǎng)頁頂部展示導(dǎo)航的設(shè)計就很不錯。作為網(wǎng)站導(dǎo)航來說它足夠明顯,人們可以去向下滾動,然后立即看到呈現(xiàn)的可用選項。

網(wǎng)站長圖在此:lmjabreu.com

同樣的,優(yōu)化移動端網(wǎng)站體驗還有一個秘訣:依據(jù)以下小竅門移除網(wǎng)頁300毫秒的點擊延遲,或添加觸控事件,具體論述看這里:updates.html5rocks?(自備梯子)

如何拓展?

我這里給的例子是基于iOS平臺的,并且是在你使用標簽欄或工具欄的情境下。

但是標簽欄內(nèi)如何容納超過5個標簽?zāi)兀?/p>

這不是理想的情境,這時可能需要重新考慮一下應(yīng)用的信息架構(gòu)了。但是如果你必須得有5個以上的標簽,普通的模式是使用最后一個標簽提供更多的選項,很不幸,這很像一個菜單。

側(cè)邊欄交互的利與弊個與解決方法

你也可以使用一個滾動工具條,參見Rookie。這能避免使用側(cè)拉菜單的問題,但是需要承擔輕微高一些的導(dǎo)航認知摩擦,因為系統(tǒng)在區(qū)分用戶點擊和滑動意圖時錯誤率會提升。

側(cè)邊欄交互的利與弊個與解決方法

記住,與導(dǎo)航相比,第二種解決方法的操作更加合理。

Rookie的采取的方法涉及的工具欄不確定狀態(tài)下的滾動后駐留,在完成諸如裁剪、旋轉(zhuǎn)等其中一項任務(wù)后就會隱藏表示任務(wù)已完成。

工具欄隱藏并在下一次出現(xiàn)前復(fù)位的方法可以防止不確定狀態(tài)的粘滯。

結(jié)論

所以你已經(jīng)讀了關(guān)于側(cè)拉菜單模式的問題,并且在這里提供了iOS環(huán)境中的解決方法。

希望這是清楚和有用的,如果你有任何想法,你可以在twitter上聯(lián)系我@lmjabreu。

【更新】在本文的反饋是驚人的!Twitter上有超過2萬4千名讀者訪問并留下了更多的評論。我使用Storify整理了一些評論出來。似乎Android平臺上也有更多問題要探討,尤其是想出一套適用于Web端的導(dǎo)航模式——這個目的驅(qū)動下的圖標有著極大的差別。

原文地址:lmjabreu

譯文地址:daichuanqing

譯者:張哲遠

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 個人覺帶還是五個標簽更好,從用戶體驗來看,多個標簽滑動的話可能會比較繁瑣。并在做項目的時候,給用戶體驗的時候,五個標簽用戶標示可以第一眼知道有這個東西,多個標簽滑動的話,還不是很適應(yīng)。更樓主開始說的側(cè)邊框一樣不要第一眼辨認。

    來自廣東 回復(fù)