<listing id="xdh1b"><var id="xdh1b"><i id="xdh1b"></i></var></listing><menuitem id="xdh1b"></menuitem><var id="xdh1b"></var>
<menuitem id="xdh1b"><dl id="xdh1b"><listing id="xdh1b"></listing></dl></menuitem>
<var id="xdh1b"></var><listing id="xdh1b"></listing>
<cite id="xdh1b"></cite>
<var id="xdh1b"><strike id="xdh1b"><thead id="xdh1b"></thead></strike></var>
<var id="xdh1b"></var>
<var id="xdh1b"></var>
<menuitem id="xdh1b"></menuitem>
<var id="xdh1b"></var><cite id="xdh1b"><strike id="xdh1b"></strike></cite>
<menuitem id="xdh1b"><strike id="xdh1b"><listing id="xdh1b"></listing></strike></menuitem><del id="xdh1b"><span id="xdh1b"></span></del><var id="xdh1b"></var><var id="xdh1b"><strike id="xdh1b"><listing id="xdh1b"></listing></strike></var>
<cite id="xdh1b"></cite>

漲姿勢!側邊欄交互的優劣

meng發表于 2014/08/29
側邊導航是大多移動端應用的選擇,節省不少珍貴的屏幕空間,但是這種抽屜導航也有不少弊病,今天和大家一起看看這些側邊導航,在以后的設計中能取長補短,他為我用。

抽屜導航的大問題
  1. 不易發現
  2. 更低效
  3. 與平臺原生導航模式沖突
  4. 并不是一目了然
不易發現
“不在眼中的,就不會想到。”
在這個模式的默認狀態,側拉菜單和里面所有的內容都是隱藏的。
人們需要首先需要辨別側拉菜單按鈕是可以點擊的——公司都認為應該使用一個菜單或者工具圖標來表示,他們也確實感覺有必要這么做——但是在應用使用時可能就不是這個情況了,因為主頁顯承載了主要的功能。
不那么有效
盡管用戶了解并看重這一特征,但是這個模式帶來了一種導航認知摩擦,因為它迫使人們先打開菜單,然后才能看到其中的條目。
深聊漢堡菜單!側邊欄交互的利與弊 + 解決方法
下面是一個對比的案例。展示了如果導航元素一直可見的話,導航效果是多么迅速。
深聊漢堡菜單!側邊欄交互的利與弊 + 解決方法
和平臺原生導航模式沖突
除了上面那些問題,在iOS這樣的平臺上,側拉菜單與標準導航模式有沖突。
深聊漢堡菜單!側邊欄交互的利與弊 + 解決方法
左邊的導航欄按鈕需要保留一個菜單按鈕,但是我們也得讓用戶有回去的方法。設計師要么承認上圖中存在的導航欄內容過載問題——甚至沒有給標題留下空間,要么迫使用戶點擊好幾次來進入下圖顯示的列表。
深聊漢堡菜單!側邊欄交互的利與弊 + 解決方法
不一目了然
深聊漢堡菜單!側邊欄交互的利與弊 + 解決方法
因為導航僅在用戶想要進入應用其他部分時才可見,所以使得對特定內容信息的呈現更加困難。
你可能會采用和Jawbone UP應用相似的做法:在側拉菜單按鈕旁邊放置一個象征消息的圖標。
這個并不實用,因為這需要你去處理更多的圖標,并且作為設計師來說可能要被迫去增加一個通用圖標,而不是弱化圖標含義。
反之,下面的選項卡欄(采自twitter),讓用戶了解通知的情境,并且直接引導其到達相關頁面。
深聊漢堡菜單!側邊欄交互的利與弊 + 解決方法
認知
深聊漢堡菜單!側邊欄交互的利與弊 + 解決方法
你可能有時為了節省屏幕空間而被迫使用它,但是這確實會讓人們對他們看到的東西產生誤導。當你認為用戶看到了呈現在他眼前的所有內容的時候,其實我們會將注意力有一個焦點區域(而不是整個屏幕),即使屏幕尺寸很小也是一樣。
所以節省屏幕空間可以通過不損害導航或者不違背基本人機交互原則而達到目的,比如提供反饋或者展示當前狀態。
另外提醒一下:我們需要的是更新我們頭腦中對人機交互的理解。我很確信這會幫助人們在進行視覺設計時避免很多錯誤產生。
解決方法
深聊漢堡菜單!側邊欄交互的利與弊 + 解決方法
關于問題本身寫了很多,但是具體解決方法大家其實還不清楚。
什么時候該使用它呢?
深聊漢堡菜單!側邊欄交互的利與弊 + 解決方法
極少數情況下這種模式有用,但是一般性的原則還是盡量避免使用。
IRCCloud是一個適合這個模式的應用——可以實現頻道和頻道成員之間的導航。
由于主屏下面沒有子頁面的層級導航存在,所以這可以使用,信息可以簡單地呈現出來。
但是即使是在這種情景下,可以看到用戶界面仍然信息過載了,應用的信息架構需要重新考慮了。
深聊漢堡菜單!側邊欄交互的利與弊 + 解決方法
右側的側拉菜單展示了頻道成員內容結果只是呈現活動按鈕,而弱化展現整個頻道相關操作。反之,設計師沒有其他選擇余地,只能將頻道、網絡和賬號混合放在了一個單獨的菜單之中:
深聊漢堡菜單!側邊欄交互的利與弊 + 解決方法
接下來讓我們去看看文章的下一部分。
要是不用這種方法,我該怎么辦呢?
深聊漢堡菜單!側邊欄交互的利與弊 + 解決方法
側邊菜單會導致糟糕的信息架構,因為你只是一味將其添加進去,而沒有考慮結果——直到人們實際使用的時候才會意識到它有多糟糕。
解決方法是重新檢查你的信息架構。
深聊漢堡菜單!側邊欄交互的利與弊 + 解決方法
上面是一個如何去除側拉菜單的例子。你可以按照那些彩點來了解這兩種解決方法間元素的過渡方式。
注意點:
  1. 消息選項卡上直接顯示當前狀態
  2. 項目總是可見的且可以立刻到達
  3. 導航手勢不能沖突
深聊漢堡菜單!側邊欄交互的利與弊 + 解決方法
就這些固定的問題而言,我們也能夠通過滾動方向來隱藏導航條從而節省屏幕的垂直空間,Facebook和Safari都應用了這種方式。固定的標簽欄能夠清晰的告訴用戶當前所處的位置,這樣我們就無需只依靠導航欄來確定了。
如果你想要更簡單,那么一個工具欄就足夠了。關鍵是不要隱藏導航,而是允許直接操作,不要和現有的導航手勢沖突,并且在相關圖標上提供反饋。
對于網站來說,我覺的最好的解決辦法還是重新審視信息架構,而不是直接挪用iOS設計模式。下面一個只在網頁頂部展示導航的設計就很不錯。作為網站導航來說它足夠明顯,人們可以去向下滾動,然后立即看到呈現的可用選項。
如何拓展?
我這里給的例子是基于iOS平臺的,并且是在你使用標簽欄或工具欄的情境下。
但是標簽欄內如何容納超過5個標簽呢?
這不是理想的情境,這時可能需要重新考慮一下應用的信息架構了。但是如果你必須得有5個以上的標簽,普通的模式是使用最后一個標簽提供更多的選項,很不幸,這很像一個菜單。
15
你也可以使用一個滾動工具條,參見Rookie。這能避免使用側拉菜單的問題,但是需要承擔輕微高一些的導航認知摩擦,因為系統在區分用戶點擊和滑動意圖時錯誤率會提升。
16
記住,與導航相比,第二種解決方法的操作更加合理。
Rookie的采取的方法涉及的工具欄不確定狀態下的滾動后駐留,在完成諸如裁剪、旋轉等其中一項任務后就會隱藏表示任務已完成。
工具欄隱藏并在下一次出現前復位的方法可以防止不確定狀態的粘滯。
©2010-2014 秦皇島易博網絡科技有限公司 我們專注于微信開發 | 網站建設 冀ICP備12004938號-3