幾種常見的響應式導航設計模式優劣分析 by HiBonie

大屏幕上有兩個典型的區域適合放置導航:頂部和左側,桃園網頁設計,但在缺少屏幕空間的手機屏幕上卻是一個有趣的挑戰。隨著響應式設計越來越流行,在小呎寸屏幕上處理導航的各種方法越來越值得我們關注,rwd網頁設計。而手機網站導航必須在快速獲取一個網站的信息和不可見性之間取得平衡。

下面是一些處理響應式導航比較流行的技巧,由於下述幾種導航方式還沒有約定俗成的叫法,所以大家可以結合案例網站來理解他的實際用法:

1.頂部導航

2.頁腳錨

3.選擇菜單

4.切換

5.左側導航彈出

6.只有頁腳

7.隱藏導航

當然每一種方法都有優點和缺點,在為你的項目選擇適合的方法時需要注意。

1.頂部導航或者說“什麼也不做”的方法

導航最容易實施的解決方案之一是保持它在頂部。由於這種方法容易實現,所以你可以在許多(甚至大部分)響應式網站中找到它,SEO優化

【優點】

· 容易實現 ——你幾乎可以保持你大屏幕網站的原樣,台北網頁設計

·無需依賴Javas cript——確保最大的兼容性。

·,
響應式網頁設計;無需辛瘔的重寫CSS樣式。

·沒有絆倒你的代碼順序——無需赴湯蹈火的把導航列表在代碼裏來回轉移。他按原始順序排列。

【缺點】

· 高度問題 ——移動端的高度問題。正如《盧克的書》所說,內容第一,導航第二是首選的移動網頁體驗。你想要使用戶儘可能快地獲得重要的內容。這意味著要讓導航移出用戶的視線,使他們能夠專注於頁面上的核心信息。當所有的核心內容被切斷,它會被混淆:

注釋:該網站首屏由LOGO和導航搆成,點擊導航頁面切換,而導航一直保持在頂部,頁面之間的跳轉看起來並不差異,也沒有快速地揭開核心內容。

·不易擴充——當你想要添加一個新的部分到你的網站,會發生什麼?此刻導航整齊的排列在一行,當你的客戶說你需要把“產品和服務”添加到導航,會發生什麼?或者當你需要把菜單繙譯成德文時呢?

·不易點擊——填鴨式的鏈接太緊密地結合在一起,很容易導緻不必要的的間接點擊。

·跨設備的問題——在iPhone上文字可能看起來很棒,由於不同的設備呈現文字的方式不同,在其他平台上看起來可能是分散的:

注釋:在小屏幕上響應導航被截斷成多行

【外部參考案例】

·Ethan Marcotte個人站:

【資源】

· 高度問題@andmag 

· 不要讓你的菜單取代@StuRobson

2.頁腳錨

這種聰明的解決方案,保持網站的導航列表在底部,而頭部包含一個簡單的錨鏈接指向頁腳導航。這種方法為其核心內容清除出了很多的空間,同時仍然能夠快速獲取導航。

【優點】

·易於實現——簡單的頂部錨點。導航列表在底部。這是相當容易實現的。

·無需依賴Javas cript——這意味著更少的測試和更好的支持。

·按比例放大需要很少的CSS工作——由於有絕對或固定定位,對於移動頁腳導航到頂部變成小菜一碟。

·單獨按鈕在頭部—— 一個簡單的菜單圖標或鏈接只佔用很小的頭部空間,這樣可以為核心內容釋放大量的空間。

【缺點】

·錨點跳轉讓人迷失方向——快速跳轉到該網站的頁腳可能有點讓人迷失方向。

·不優雅——這樣說似乎很奇怪,但一個不和諧的跳轉,雖然非常實用,但不是優雅的交互使用。

【外部參考案例】

·內容雜志 網站(點擊頂部右側菜單錨點,頁面跳轉到底部導航):

【資源】

· 一個簡單的、響應式、移動首選導航

· 《移動第一書》

3.選擇菜單

對於小屏幕來說,馴服脫韁野馬的導航的一種方法是將一個鏈接列表,轉化為一個選擇菜單。這就避免了頂部導航方法提出的問題,並且這是一個節省地方的聰明方式。

【優點】

·釋放了大量的空間—— 一個選擇菜單絕對比水平或垂直列表,佔用少得多的空間。

·保持在頭部交互——而不是頁腳導航。選擇菜單保持了頭部導航功能,這符合用戶的預覽習慣。

·,台中網頁設計;容易辨認——選擇菜單貼有明確的標簽,顯示“導航”或“菜單”,這非常容易辨認。

·使用本地控件——每個移動瀏覽器將會用各自的方式處理選擇菜單。觸摸設備將會提升導航列表的觸摸友好度。

【缺點】

·難以控制設計風格——選擇菜單是設計風格的眼中釘。每個瀏覽器處理他們都有各自的方式,通常都是笨拙的方法。它使得網站跨瀏覽器風格看起來只有一半是一緻的。因此,選擇菜單處境尷尬,並且確實玷汙了一個原本看著不錯的設計。

·可能令人混淆——用戶習慣於選擇菜單在下拉表單中,但我不知道他們是否會脫離上下文去理解一個表單元素。這只是一種直覺,所以這將是有趣的試驗。

·處理子導航項——通過選擇菜單來處理嵌套列表可能看起來很怪異。子類別通常用破折號縮進處理,雖然這可能會讓人容易理解,但是卻也容易混淆,甚至有點難看。

·依賴Javas cript——對Javas cript有依賴性。

【外部參考案例】

·Viljami Salminen 網站:

【資源】

· 微導航  @viljamis

· 為小屏幕把菜單轉換為下拉菜單

· 進步和響應式導航

· https://github.com/mattkersley/Responsive-Menu 響應式導航

4.切換

切換類似於頁腳錨方法,但是沒有跳轉到頁面底部的錨,而是設定一個菜單圖標在頭部的右側,點擊滑動打開或收縮菜單。這是一個好看的方法,也比較容易實現。

【優點】

·固定位置——切換菜單的位置固定,不像頁腳錨突然跳轉,不會讓用戶失去方向感。

·優雅——這絕對是優雅的方法之一。沒有尷尬的表格或頁面跳轉,民宿訂房系統,只是一個平滑生動的滑動,或簡單的顯示/隱藏。

·易於擴展——所以你需要做的是隱藏移動觸發和顯示導航列表,當達到適當的斷點,你就有了一個正常的大小的導航。這一切都可以通過CSS實現。

【缺點】

·動畫的表現——在移動設備上無論是哪種類型的動畫,其結果都是多樣化的。Android對CSS動畫的表現是出了名的差,所以事情可能不會那麼順暢。

·依賴Javas cript——同樣這種方法有點依賴Javas cript去觸發切換,但極小。我有一個黑莓的測試設備,不聽任何話,但大多數瀏覽器,包括代理的瀏覽器,如Opera Mini和Dolphin Mini,能很好的處理它。

【外部參考案例】

·星巴克網站:

·移動網絡的最佳實踐:

【資源】

· FlexNav ,一個jQuery插件用於響應菜單

· 用於導航的一種響應的設計方案,第一部分@filamentgroup

5.左側導航彈出

Facebook為移動端普及了左側導航,這個樣式相當獨特。通過一個菜單圖標來訪問導航,導航從左側滑出,主體內容移向右側。

【優點】

·釋放大量空間——當你有大量的列表項時,其他導航技術展示效果都不會太好,而這種方法提供了大量的空間來展開。我認為這就是為什麼Facebook採用這種方式。

·美觀——這個菜單非常復雜和先進,所以他肯定有一個令人叫絕的因素吧。

·使用facebook帶來的慣性——Facebook ,網路開店;移動端用戶已經習慣使用這種模式,因為網頁和Facebook移動應用程序使用過這種導航。

【缺點】

·高級——當其它方法只需要修改簡單的元素,而這個方法卻有很多需要移動的部件。正如斯蒂芬妮·裏格爾指出,奧巴馬的網站導航打破了一切, 除了最尖端的設備。如果你的項目是為一個更廣氾的受眾,而你選擇了這種方法,你要非常小心。

·不能很好地擴展——這種方法對於移動端是相當獨特的,不一定能輕松地擴展到大屏幕上。您需要承擔維持小型和大屏幕兩個不同的導航的風險。

·令人混淆——當我第一次看到Facebook新的移動端導航時,我竟然以為它是壞了的。在右側有一點內容,這樣看上去似乎有點怪,但是這純屬個人喜好。

【外部參考案例】

·維基百科:

【資源】

· 一個逐步增強的請求

6.只有頁腳

只有頁腳的導航類似於頁腳錨的方法,只是沒有頭部的錨點。它遵循內容第一,導航第二的原則,但是它要求移動用戶一直滾到頁面底部,才能在站點中導航。

【優點】

·釋放頭部空間——它遵循內容第一,導航第二的原則,但是…

【缺點】

·,RWD自適應式網頁設計;難以發現——用戶(無論小屏幕還是大屏幕)可能很難發現底部有一個導航。

·難以訪問——移動端用戶不得不滾動完整個頁面直至底部(可能很長)只是為了瀏覽網站。

【外部參考案例】

·梨(一個開源的Wordpress主題):

7.隱藏導航

遵循這個規則:不要因為用戶用較小的設備訪問您的網站而懲罰他們,高雄網頁設計。這不是事實——移動用戶不希望或者不需要某些信息。移動用戶會做任何PC端用戶會做的事情,只要提供一個可用的方法。

【優點】

· 清除了充足的空間 ——通過為小屏幕移除導航,可以釋放大量的空間!但是,這是有代價的……

【缺點】

·為移動用戶移除內容或功能——隱藏鏈接和內容是不好的。響應的倡導者們說,響應式設計消除了許多內容差異和體驗噩夢,這來自獨立的移動網站,但如果一個響應式網站為移動用戶隱藏內容,就不太好了。

·難以維持——為小屏幕和大屏幕設的兩個獨立的導航,變成了維護網站時的一種負擔。

【外部參考案例】

·“真實的工作”網站:

【資源】

· 媒介查詢及優點測試

【總結】

最後,手機導航應該是這樣一個很好的朋友:當你需要他時,他會給你足夠的空間。而一個壞的朋友,是當你需要找人傾訴時他卻不在(導航消失或很難找到),或是他們總是很討厭的在你周圍,佔用你的空間。尋找導航和移動屏幕空間之間的平衡是一門藝術。