起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識以內容優先的理念設計移動產品
知名Web設計師Andy Clarke最近發布了320 and up，開源快速開發模板Mobile Boilerplate的分支。這恰好和他之前媒體查詢的樣板（media queries）相反，新的樣板從較大寬度樣式下的小屏幕樣式和圖層集合開始開發，而不是開始于為小屏幕裁剪大寬度的樣式。
這絕對是利用特定寬度樣式的最好方法，在結合媒體查詢或者JavaScript 之后。但當我看到對應特定設備寬度的像素值時，我有些緊張：320*480，等等。相比之依靠一個假想的寬度，比如960個像素，這當然是一個進步。但我擔心的是，這依然只是為了匹配現在流行的顯示窗口，而簡單地堆砌顯示內容。這也是Mark所說的，“被版面局限”了的設計方法（ the “canvas in” approach ）：
“我相信，為了迎合網頁本地布局設計的需要（不考慮設備），我們不得不從版面布局出發，再考慮我們的內容創意。而我們需要的其實是反過來，內容優先來設計布局?！?/p>
如今，可能的情況是你的內容就是基于像素的（圖像或者視頻），而且它們的尺寸恰好適合特定設備顯示窗口的大小。但根據我的經驗，待處理的大多數內容仍然屬于文字類。但像素卻不是處理文字的最好單元。這也是我傾向采用基于字體大?。╡m-based）的媒體查詢的原因之一。
我的基本觀點是，媒體查詢應該服務于內容。某些站點可能適合把直線型布局應用于小屏幕，而柱狀布局應用于更大設備（比如平板電腦）的屏幕。對其他站點，即使平板電腦尺寸的屏幕，直線型布局卻更適合。這都取決于內容。
我最喜歡的關于內容優先的一個例子，是Dan 的文章type-inspired interfaces。我認為網頁設計者的一個共識是，設計都應該內容優先，但我們現在卻過于依賴類似畫布的工具，比如某些預先確定的網格類工具（predefined grids）。類似地，在框架和信息構架領域，當我們需要專注于內容時，我們經常不自覺地去首先設計菜單和導航界面。
這是最近《移動優先》作者Luke對Jared說的一段話，其中提到了他的設計原則“內容優先，之后才是導航”（“content first, navigation second”）。
Luke曾經廣為人知地對互聯網開發者宣傳移動為先（ mobile first ）的方法。這種方法用于發現推送給用戶的重要內容，的確非常適用。但不要太絕對，有時候這種方法也等同于“打印樣式表優先”（print-stylesheet first），或者某種“非桌面環境優先”（non-desktop environment first）策略。正確應用的關鍵，還是在于你是否把內容優先放在第一位（you’re thinking about the content first and foremost）：
“屏幕空間被無端占用80%時，你才被迫注意到留在屏幕上的，應該是對于你的用戶或者業務最重要的特點集合。而不是一堆界面的碎片，或者可要可不要的內容。你應該明確什么是最重要的?！?/p>
但這不是說你不能把某些不太相關卻很不錯的內容放到屏幕上。但這應該添加到可能需要某種條件來延緩加載的部分，而不是一股腦地把廚房水池一類的信息放到開始界面上。
移動頁面設計上，已經出現了一系列非常不錯的典范設計。然而，傳統桌面網頁設計卻成為了死氣沉沉和自鳴得意的代名詞。這導致的是一堆充斥著陳舊無聊內容的網站，就像 Merlin 的Flickr相冊Noise to Noise Ratio 列舉的：
“當然，這之中還是有一些非常不錯的原創性內容，雖然隱藏在一堆廣告、自助鏈接和附加新聞中?！?/p>
對，在圖中接著找。負責地說，里面“的確”存在有用的內容，不是嗎？
還有一點共識，就是移動用戶是不能糊弄的。應該盡快給這些總是匆匆忙忙的用戶所需要的內容。但它的推論不一定成立。為什么我們認為桌面用戶就更能夠忍受如此多不需要的內容呢？
不需要的頁面冗余一般看做對頁面的破壞，用戶可以利用Readability，Safari’s Reader和Instapaper等工具繞開它們。這些工具的存在，一方面是為了從多個內容來源為讀者聚合信息（free up content from having a single endpoint），另一方面也將有用內容從被濫用得令人窒息的頁面容器中解放出來。這不是新的現象，當然，在RSS出現之前我們就在瀏覽信息。但這些閱讀輔助工具也應該當做對我們的警告，或者挑戰。我們怎么能用這樣一個用戶討厭的方式來承載內容，以致于用戶不得不求助Readability或者Instapaper。
一些臃腫頁面（常常是支離破碎的設計）的設計者，在設計站點時（通常是新的站點），都有一個另外的移動版本，通常是“m.子域名”的命名方式。這個版本中，內容并不是用桌面版本中呆板、冗余、分頁的方式被呈現。我注意到用戶在用Twitter或者email等工具分享鏈接時，分享的通常是這個簡潔的m.版本。這些站點影響的廣泛擴大，簡單地說就是因為它們更加易讀，在任何平臺都是如此。
我們以前讀到過，就像我在點評（the comment）Paul對移動開發者的誤導（Paul’s misguided post on mobile design）時說的：
“在過去的壞日子里，為習慣屏幕閱讀的用戶設計獨立而平等的只提供文本閱讀的站點的確是常事。這樣的確細分了用戶，但顯然，這只是取巧的方法?，F在，我們知道習慣屏幕閱讀的用戶也應該享受和其他一樣的內容服務，前提是站點應該用正確的方式構建（有趣的是，一些站點注意到“傳統的”非屏幕閱讀用戶也傾向于更快更簡潔的站點版本，這應該能給那些仍然認為桌面和移動站點完全不同的設計者好好上一課）?！?/p>
毫無疑問，我完全不同意Jakob Nielsen的說法（the proclamation from Jakob Nielsen）：
“桌面的電腦和移動設備是完全不同的。唯一能帶給用戶良好體驗的，就是為一個產品設計兩個獨立的版本，當然，一般來說移動版本會少一些功能?！?/p>
我很困惑，不知道為什么網站既然飽受簡潔可用性方面的質疑，設計者還要另外設計一個版本，而讓不用這個版本的每個人幾乎無法忍受另一版本的臃腫混亂。要注意，我不是暗示每個用戶都得到一樣的體驗，事實上遠非如此。不過多虧漸進式增強設計（按照正確方法的響應式設計正是漸進式增強的一個完美應用），我們能提供用戶需要的內容，并在任何設備上用最好的效果顯示。
所以，這才是顯出不同的關鍵：內容優先，而不是設備。
這是一個對網頁設計來說激動人心的年代。種類不斷增長的設備，直接揭示了我們以前傳統、固定大小、內容臃腫的桌面中心設計方案有多么自以為是和南轅北轍。就像面對任何變動一樣，總會有些緊張和神經質。開發者正慌不擇路地發掘移動設備帶給我們的變革和好處：
“我應該學習Objective-C嗎？”
“我應該掌握HTML5嗎？”
“我應該學習移動App構架嗎？”
你也許正做著這樣的事。不過，千萬要記住內容策略（content strategy）的應用。
原作者： Jeremy Keith 。作者是知名web開發者，作者，工作生活于英國布萊頓。 文章寫于2011年4月27日。
來源：Web App Trend
- 目前還沒評論，等你發揮！
