知名Web設計師Andy Clarke最近發(fā)布了320 and up，開源快速開發(fā)模板Mobile Boilerplate的分支。這恰好和他之前媒體查詢的樣板（media queries）相反，新的樣板從較大寬度樣式下的小屏幕樣式和圖層集合開始開發(fā)，而不是開始于為小屏幕裁剪大寬度的樣式。

這絕對是利用特定寬度樣式的最好方法，在結(jié)合媒體查詢或者JavaScript 之后。但當我看到對應特定設備寬度的像素值時，我有些緊張：320*480，等等。相比之依靠一個假想的寬度，比如960個像素，這當然是一個進步。但我擔心的是，這依然只是為了匹配現(xiàn)在流行的顯示窗口，而簡單地堆砌顯示內(nèi)容。這也是Mark所說的，“被版面局限”了的設計方法（ the “canvas in” approach ）：

“我相信，為了迎合網(wǎng)頁本地布局設計的需要（不考慮設備），我們不得不從版面布局出發(fā)，再考慮我們的內(nèi)容創(chuàng)意。而我們需要的其實是反過來，內(nèi)容優(yōu)先來設計布局?！?/p>

如今，可能的情況是你的內(nèi)容就是基于像素的（圖像或者視頻），而且它們的尺寸恰好適合特定設備顯示窗口的大小。但根據(jù)我的經(jīng)驗，待處理的大多數(shù)內(nèi)容仍然屬于文字類。但像素卻不是處理文字的最好單元。這也是我傾向采用基于字體大?。╡m-based）的媒體查詢的原因之一。

我的基本觀點是，媒體查詢應該服務于內(nèi)容。某些站點可能適合把直線型布局應用于小屏幕，而柱狀布局應用于更大設備（比如平板電腦）的屏幕。對其他站點，即使平板電腦尺寸的屏幕，直線型布局卻更適合。這都取決于內(nèi)容。

我最喜歡的關(guān)于內(nèi)容優(yōu)先的一個例子，是Dan 的文章type-inspired interfaces。我認為網(wǎng)頁設計者的一個共識是，設計都應該內(nèi)容優(yōu)先，但我們現(xiàn)在卻過于依賴類似畫布的工具，比如某些預先確定的網(wǎng)格類工具（predefined grids）。類似地，在框架和信息構(gòu)架領域，當我們需要專注于內(nèi)容時，我們經(jīng)常不自覺地去首先設計菜單和導航界面。

這是最近《移動優(yōu)先》作者Luke對Jared說的一段話，其中提到了他的設計原則“內(nèi)容優(yōu)先，之后才是導航”（“content first, navigation second”）。

Luke曾經(jīng)廣為人知地對互聯(lián)網(wǎng)開發(fā)者宣傳移動為先（ mobile first ）的方法。這種方法用于發(fā)現(xiàn)推送給用戶的重要內(nèi)容，的確非常適用。但不要太絕對，有時候這種方法也等同于“打印樣式表優(yōu)先”（print-stylesheet first），或者某種“非桌面環(huán)境優(yōu)先”（non-desktop environment first）策略。正確應用的關(guān)鍵，還是在于你是否把內(nèi)容優(yōu)先放在第一位（you’re thinking about the content first and foremost）：

“屏幕空間被無端占用80%時，你才被迫注意到留在屏幕上的，應該是對于你的用戶或者業(yè)務最重要的特點集合。而不是一堆界面的碎片，或者可要可不要的內(nèi)容。你應該明確什么是最重要的?！?/p>

但這不是說你不能把某些不太相關(guān)卻很不錯的內(nèi)容放到屏幕上。但這應該添加到可能需要某種條件來延緩加載的部分，而不是一股腦地把廚房水池一類的信息放到開始界面上。

移動頁面設計上，已經(jīng)出現(xiàn)了一系列非常不錯的典范設計。然而，傳統(tǒng)桌面網(wǎng)頁設計卻成為了死氣沉沉和自鳴得意的代名詞。這導致的是一堆充斥著陳舊無聊內(nèi)容的網(wǎng)站，就像 Merlin 的Flickr相冊Noise to Noise Ratio 列舉的：
“當然，這之中還是有一些非常不錯的原創(chuàng)性內(nèi)容，雖然隱藏在一堆廣告、自助鏈接和附加新聞中?！?/p>

對，在圖中接著找。負責地說，里面“的確”存在有用的內(nèi)容，不是嗎？

還有一點共識，就是移動用戶是不能糊弄的。應該盡快給這些總是匆匆忙忙的用戶所需要的內(nèi)容。但它的推論不一定成立。為什么我們認為桌面用戶就更能夠忍受如此多不需要的內(nèi)容呢？

不需要的頁面冗余一般看做對頁面的破壞，用戶可以利用Readability，Safari’s Reader和Instapaper等工具繞開它們。這些工具的存在，一方面是為了從多個內(nèi)容來源為讀者聚合信息（free up content from having a single endpoint），另一方面也將有用內(nèi)容從被濫用得令人窒息的頁面容器中解放出來。這不是新的現(xiàn)象，當然，在RSS出現(xiàn)之前我們就在瀏覽信息。但這些閱讀輔助工具也應該當做對我們的警告，或者挑戰(zhàn)。我們怎么能用這樣一個用戶討厭的方式來承載內(nèi)容，以致于用戶不得不求助Readability或者Instapaper。

一些臃腫頁面（常常是支離破碎的設計）的設計者，在設計站點時（通常是新的站點），都有一個另外的移動版本，通常是“m.子域名”的命名方式。這個版本中，內(nèi)容并不是用桌面版本中呆板、冗余、分頁的方式被呈現(xiàn)。我注意到用戶在用Twitter或者email等工具分享鏈接時，分享的通常是這個簡潔的m.版本。這些站點影響的廣泛擴大，簡單地說就是因為它們更加易讀，在任何平臺都是如此。

我們以前讀到過，就像我在點評（the comment）Paul對移動開發(fā)者的誤導（Paul’s misguided post on mobile design）時說的：

“在過去的壞日子里，為習慣屏幕閱讀的用戶設計獨立而平等的只提供文本閱讀的站點的確是常事。這樣的確細分了用戶，但顯然，這只是取巧的方法?，F(xiàn)在，我們知道習慣屏幕閱讀的用戶也應該享受和其他一樣的內(nèi)容服務，前提是站點應該用正確的方式構(gòu)建（有趣的是，一些站點注意到“傳統(tǒng)的”非屏幕閱讀用戶也傾向于更快更簡潔的站點版本，這應該能給那些仍然認為桌面和移動站點完全不同的設計者好好上一課）。”

毫無疑問，我完全不同意Jakob Nielsen的說法（the proclamation from Jakob Nielsen）：

“桌面的電腦和移動設備是完全不同的。唯一能帶給用戶良好體驗的，就是為一個產(chǎn)品設計兩個獨立的版本，當然，一般來說移動版本會少一些功能?！?/p>

我很困惑，不知道為什么網(wǎng)站既然飽受簡潔可用性方面的質(zhì)疑，設計者還要另外設計一個版本，而讓不用這個版本的每個人幾乎無法忍受另一版本的臃腫混亂。要注意，我不是暗示每個用戶都得到一樣的體驗，事實上遠非如此。不過多虧漸進式增強設計（按照正確方法的響應式設計正是漸進式增強的一個完美應用），我們能提供用戶需要的內(nèi)容，并在任何設備上用最好的效果顯示。
所以，這才是顯出不同的關(guān)鍵：內(nèi)容優(yōu)先，而不是設備。

這是一個對網(wǎng)頁設計來說激動人心的年代。種類不斷增長的設備，直接揭示了我們以前傳統(tǒng)、固定大小、內(nèi)容臃腫的桌面中心設計方案有多么自以為是和南轅北轍。就像面對任何變動一樣，總會有些緊張和神經(jīng)質(zhì)。開發(fā)者正慌不擇路地發(fā)掘移動設備帶給我們的變革和好處：

“我應該學習Objective-C嗎？”

“我應該掌握HTML5嗎？”

“我應該學習移動App構(gòu)架嗎？”

你也許正做著這樣的事。不過，千萬要記住內(nèi)容策略（content strategy）的應用。

原作者： Jeremy Keith 。作者是知名web開發(fā)者，作者，工作生活于英國布萊頓。 文章寫于2011年4月27日。

來源：Web App Trend