2015-11-19
2482
大屏幕上有兩個典型的區(qū)域適合放置導航：頂部和左側，但在缺少屏幕空間的手機屏幕上卻是一個有趣的挑戰(zhàn)。隨著響應式設計越來越流行，在小尺寸屏幕上處理導航的各種方法越來越值得我們關注。而手機網站導航必須在快速獲取一個網站的信息和不可見性之間取得平衡。
下面是一些處理響應式導航比較流行的技巧，由于下述幾種導航方式還沒有約定俗成的叫法，所以大家可以結合案例網站來理解他的實際用法：
頂部導航
頁腳錨
選擇菜單
切換
左側導航彈出
只有頁腳
隱藏導航
當然每一種方法都有優(yōu)點和缺點，在為你的項目選擇適合的方法時需要注意。
導航最容易實施的解決方案之一是保持它在頂部。由于這種方法容易實現，所以你可以在許多（甚至大部分）響應式網站中找到它。
容易實現——你幾乎可以保持你大屏幕網站的原樣。
無需依賴Javascript——確保最大的兼容性。
無需辛苦的重寫CSS樣式。
沒有絆倒你的代碼順序——無需赴湯蹈火的把導航列表在代碼里來回轉移。他按原始順序排列。
高度問題——移動端的高度問題。正如《盧克的書》所說，內容第一，導航第二是首選的移動網頁體驗。你想要使用戶盡可能快地獲得重要的內容。這意味著要讓導航移出用戶的視線，使他們能夠專注于頁面上的核心信息。當所有的核心內容被切斷，它會被混淆：
注釋：該網站首屏由LOGO和導航構成，點擊導航頁面切換，而導航一直保持在頂部，頁面之間的跳轉看起來并不差異，也沒有快速地揭開核心內容。
不易擴充——當你想要添加一個新的部分到你的網站，會發(fā)生什么？此刻導航整齊的排列在一行，當你的客戶說你需要把“產品和服務”添加到導航，會發(fā)生什么？或者當你需要把菜單翻譯成德文時呢？
不易點擊——填鴨式的鏈接太緊密地結合在一起，很容易導致不必要的的間接點擊。
跨設備的問題——在iPhone上文字可能看起來很棒，由于不同的設備呈現文字的方式不同，在其他平臺上看起來可能是分散的：
注釋：在小屏幕上響應導航被截斷成多行
Trent Walton個人站
http://trentwalton.com/
Ethan Marcotte個人站
http://ethanmarcotte.com/
http://andmag.se/2012/01/height-matters/ 高度問題@andmag
http://alwaystwisted.com/post.php?s=2011-02-20-dont-let-your-menu-take-over 不要讓你的菜單取代@StuRobson
這種聰明的解決方案，保持網站的導航列表在底部，而頭部包含一個簡單的錨鏈接指向頁腳導航。這種方法為其核心內容清除出了很多的空間，同時仍然能夠快速獲取導航。
易于實現——簡單的頂部錨點。導航列表在底部。這是相當容易實現的。
無需依賴Javascript——這意味著更少的測試和更好的支持。
按比例放大需要很少的CSS工作——由于有絕對或固定定位，對于移動頁腳導航到頂部變成小菜一碟。
單獨按鈕在頭部—— 一個簡單的菜單圖標或鏈接只占用很小的頭部空間，這樣可以為核心內容釋放大量的空間。
錨點跳轉讓人迷失方向——快速跳轉到該網站的頁腳可能有點讓人迷失方向。
不優(yōu)雅——這樣說似乎很奇怪，但一個不和諧的跳轉，雖然非常實用，但不是優(yōu)雅的交互使用。
內容雜志 網站（點擊頂部右側菜單錨點，頁面跳轉到底部導航）
http://contentsmagazine.com/
http://webdesign.tutsplus.com/tutorials/htmlcss-tutorials/a-simple-responsive-mobile-first-navigation/ 一個簡單的、響應式、移動首選導航
http://www.abookapart.com/products/mobile-first 《移動第一書》
對于小屏幕來說，馴服脫韁野馬的導航的一種方法是將一個鏈接列表，轉化為一個選擇菜單。這就避免了頂部導航方法提出的問題，并且這是一個節(jié)省地方的聰明方式。
釋放了大量的空間—— 一個選擇菜單絕對比水平或垂直列表，占用少得多的空間。
保持在頭部交互——而不是頁腳導航。選擇菜單保持了頭部導航功能，這符合用戶的預覽習慣。
容易辨認——選擇菜單貼有明確的標簽，顯示“導航”或“菜單”，這非常容易辨認。
使用本地控件——每個移動瀏覽器將會用各自的方式處理選擇菜單。觸摸設備將會提升導航列表的觸摸友好度。
難以控制設計風格——選擇菜單是設計風格的眼中釘。每個瀏覽器處理他們都有各自的方式，通常都是笨拙的方法。它使得網站跨瀏覽器風格看起來只有一半是一致的。因此，選擇菜單處境尷尬，并且確實玷污了一個原本看著不錯的設計。
可能令人混淆——用戶習慣于選擇菜單在下拉表單中，但我不知道他們是否會脫離上下文去理解一個表單元素。這只是一種直覺，所以這將是有趣的試驗。
處理子導航項——通過選擇菜單來處理嵌套列表可能看起來很怪異。子類別通常用破折號縮進處理，雖然這可能會讓人容易理解，但是卻也容易混淆，甚至有點難看。
依賴Javascript——對Javascript有依賴性。
Viljami Salminen 網站
http://viljamis.com/
http://tinynav.viljamis.com/ 微導航 @viljamis
http://css-tricks.com/convert-menu-to-dropdown/ 為小屏幕把菜單轉換為下拉菜單
http://coding.smashingmagazine.com/2012/02/13/progressive-and-responsive-navigation/ 進步和響應式導航
https://github.com/mattkersley/Responsive-Menu 響應式導航
切換類似于頁腳錨方法，但是沒有跳轉到頁面底部的錨，而是設定一個菜單圖標在頭部的右側，點擊滑動打開或收縮菜單。這是一個好看的方法，也比較容易實現。
固定位置——切換菜單的位置固定，不像頁腳錨突然跳轉，不會讓用戶失去方向感。
優(yōu)雅——這絕對是優(yōu)雅的方法之一。沒有尷尬的表格或頁面跳轉，只是一個平滑生動的滑動，或簡單的顯示/隱藏。
易于擴展——所以你需要做的是隱藏移動觸發(fā)和顯示導航列表，當達到適當的斷點，你就有了一個正常的大小的導航。這一切都可以通過CSS實現。
動畫的表現——在移動設備上無論是哪種類型的動畫，其結果都是多樣化的。Android對CSS動畫的表現是出了名的差,所以事情可能不會那么順暢。
依賴Javascript——同樣這種方法有點依賴Javascript去觸發(fā)切換，但極小。我有一個黑莓的測試設備，不聽任何話，但大多數瀏覽器，包括代理的瀏覽器，如Opera Mini和Dolphin Mini，能很好的處理它。
星巴克網站
http://www.starbucks.com/
移動網絡的最佳實踐
http://mobilewebbestpractices.com/
http://jasonweaver.name/lab/flexiblenavigation/ FlexNav，一個jQuery插件用于響應菜單
http://filamentgroup.com/lab/responsive_design_approach_for_navigation/ 用于導航的一種響應的設計方案，第一部分@filamentgroup
Facebook為移動端普及了左側導航，這個樣式相當獨特。通過一個菜單圖標來訪問導航，導航從左側滑出，主體內容移向右側。
釋放大量空間——當你有大量的列表項時，其他導航技術展示效果都不會太好,而這種方法提供了大量的空間來展開。我認為這就是為什么Facebook采用這種方式。
美觀——這個菜單非常復雜和先進，所以他肯定有一個令人叫絕的因素吧。
使用facebook帶來的慣性——Facebook 移動端用戶已經習慣使用這種模式，因為網頁和Facebook移動應用程序使用過這種導航。
高級——當其它方法只需要修改簡單的元素，而這個方法卻有很多需要移動的部件。正如斯蒂芬妮·里格爾指出，奧巴馬的網站導航打破了一切， 除了最尖端的設備。如果你的項目是為一個更廣泛的受眾，而你選擇了這種方法，你要非常小心。
不能很好地擴展——這種方法對于移動端是相當獨特的，不一定能輕松地擴展到大屏幕上。您需要承擔維持小型和大屏幕兩個不同的導航的風險。
令人混淆——當我第一次看到Facebook新的移動端導航時，我竟然以為它是壞了的。在右側有一點內容，這樣看上去似乎有點怪，但是這純屬個人喜好。
維基百科
http://zh.wikipedia.org
http://stephanierieger.com/a-plea-for-progressive-enhancement/ 一個逐步增強的請求
只有頁腳的導航類似于頁腳錨的方法，只是沒有頭部的錨點。它遵循內容第一，導航第二的原則，但是它要求移動用戶一直滾到頁面底部，才能在站點中導航。
釋放頭部空間——它遵循內容第一，導航第二的原則，但是...
難以發(fā)現——用戶（無論小屏幕還是大屏幕）可能很難發(fā)現底部有一個導航。
難以訪問——移動端用戶不得不滾動完整個頁面直至底部（可能很長）只是為了瀏覽網站。
梨（一個開源的Wordpress主題）
http://pea.rs/
遵循這個規(guī)則：不要因為用戶用較小的設備訪問您的網站而懲罰他們。這不是事實—
上一篇：網頁設計中的響應式布局設計
下一篇：關于響應式頁面設計
