響應(yīng)式設(shè)計的概念
響應(yīng)式設(shè)計的概念最早由Ehan Marcotte在2010年5月份的文章 <響應(yīng)式網(wǎng)頁設(shè)計>中提出。 他強調(diào)：頁面可以根據(jù)用戶的設(shè)備環(huán)境，包括系統(tǒng)，分辨率，屏幕尺寸等等因素，進行自發(fā)式調(diào)整，提供更適合當前環(huán)境的閱讀和操作體驗，對已有和未來即將出現(xiàn)的新設(shè)備有一定的適應(yīng)能力?？梢哉f響應(yīng)式設(shè)計能夠完美解決文章開頭提到的問題，小到智能手表的屏幕，大到電視顯示屏，只需要一套代碼就能夠完美兼容，實用且高效。
當我們搜索有關(guān)響應(yīng)式設(shè)計的資料時卻發(fā)現(xiàn)大多數(shù)教程都是針對前端開發(fā)工程師撰寫的，有著許多難懂的專業(yè)名詞，讓人望而卻步。
以下筆者通過案例，簡單介紹有關(guān)響應(yīng)式設(shè)計的技巧。
響應(yīng)式設(shè)計的技巧
Ehan Marcotte的文章中提到了三個概念：流動布局（Fluid grids）、媒介查詢（Media queries）和彈性圖片（Scalable images）。這些概念原本指的是實現(xiàn)響應(yīng)式的一些技術(shù)手段，從設(shè)計師的角度，我們可以簡化為以下兩點。
一、分段響應(yīng)
通過拖動瀏覽器的寬度，我們會發(fā)現(xiàn)響應(yīng)式網(wǎng)頁會隨寬度的改變自動調(diào)整布局方式。
需要注意的是，每當瀏覽器達到一個寬度節(jié)點，網(wǎng)頁布局就會相應(yīng)發(fā)生較大變化，這就是分段響應(yīng)。這里我們又需要注意兩個要點：
– 寬度節(jié)點應(yīng)該如何確定？
– 達到寬度節(jié)點時頁面布局應(yīng)該如何變化？
1.寬度節(jié)點應(yīng)該如何確定？
寬度節(jié)點來源于前文提到的媒體查詢（Media queries），是前端工程師用簡單的方法，來獲取不同設(shè)備的特征，例如設(shè)備的寬度/高度，窗口的寬度/高度，設(shè)備的手持方向，分辨率等。設(shè)計時也可以采用相同的思路，參考網(wǎng)站用戶的設(shè)備分辨率數(shù)據(jù)，比如手機尺寸、平板電腦尺寸及桌面顯示器尺寸，確保常見設(shè)備寬度能夠落入到某一設(shè)計范圍之內(nèi)。
2.達到寬度節(jié)點時頁面布局應(yīng)該如何變化？
頁面布局的變化可以簡單歸納為三點：內(nèi)容增減、布局調(diào)整、樣式調(diào)整。
內(nèi)容增減–當瀏覽器寬度較大時，有足夠的空間展示更多的頁面內(nèi)容。隨著瀏覽器寬度的減小，為了使有限的頁面不至于擁擠，就不得不對原有內(nèi)容進行部分隱藏以滿足整體布局的合理性。
布局調(diào)整–如同前文提到的，當頁面空間被壓縮時，其布局方式也需要相應(yīng)變化，最常見的就是布局的行列數(shù)發(fā)生改變。
樣式變更–頁面中的有些模塊，例如導(dǎo)航欄等不能簡單的只隱藏部分內(nèi)容來適應(yīng)瀏覽器的變化，這時就需要調(diào)整其樣式，將整個模塊變更為其他形式展現(xiàn)，以方便小尺寸設(shè)備的使用體驗。
總的來說，分段響應(yīng)就是頁面針對不同的瀏覽器寬度展示不同的布局方式。每個組件都可以根據(jù)具體使用場景應(yīng)用不同的變化類型。
二、動態(tài)布局
解決了分段響應(yīng)的規(guī)則后，接下來需要制定瀏覽器在寬度節(jié)點之間變化時，組件該如何變動，即動態(tài)布局。
這里再次搬出Ehan Marcotte的文章所提到的流動布局的概念，原特指以百分比為度量單位的布局技術(shù)實現(xiàn)方式。這里就不對如流動布局、彈性布局、流體柵格等各種概念做一一說明。筆者就此統(tǒng)為一個大的概念：在響應(yīng)式設(shè)計的布局中，不再以像素（px）作為唯一單位，而是采用百分比或者混合百分比、像素為單位，設(shè)計出更具靈活性的布局方式。
三、其他需要注意的點
首先，要注意的是什么情況下適合采用響應(yīng)式設(shè)計？一切設(shè)計的最終目的都應(yīng)該圍繞著產(chǎn)品體驗這一核心。為了做響應(yīng)式設(shè)計而做響應(yīng)式設(shè)計，往往得不償失。
其次，在搞清楚產(chǎn)品本身的核心用戶體驗之后，選取你的用戶群體所使用的硬件設(shè)備，這個時候你應(yīng)該了解每種設(shè)備所使用的場景，設(shè)備使用的環(huán)境和場景是設(shè)計的重要依據(jù)。
最后，并非所有的內(nèi)容都符合不同設(shè)備的使用場景，比如智能手表就不適合展示大量的文本內(nèi)容。你的產(chǎn)品所覆蓋的設(shè)備組當中，每種設(shè)備的使用場景不同，應(yīng)該匹配的用戶體驗也不一樣。比如移動端用戶和桌面端用戶的需求就是不同的，場景差異也很大。
以上就是關(guān)于響應(yīng)式設(shè)計的分享，希望對你有用。
]]>國外網(wǎng)站使用這種布局方式較多，經(jīng)過調(diào)研，結(jié)合嘗試后，本文梳理了響應(yīng)式設(shè)計的方法流程，記錄問題與思考，幫助以后類似的項目開展更快。
什么是響應(yīng)式布局
響應(yīng)式布局常常和自適應(yīng)布局搞混。其實通過下面的動圖我們很容易能理解兩者的區(qū)別。
△ 響應(yīng)式和自適應(yīng)的區(qū)別，來源網(wǎng)上資料
- 響應(yīng)式布局：容器大小隨窗口大小而變化。
- 自適應(yīng)布局：容器大小不隨窗口大小而變化，邊距隨窗口大小而變化。
響應(yīng)式布局優(yōu)勢
調(diào)研中我們發(fā)現(xiàn)，國外幾個內(nèi)容網(wǎng)站，YouTube、Spotify、Netflix 和Behance，都使用了「內(nèi)容墻」的設(shè)計方式，以突出內(nèi)容的豐富度。
由于這種設(shè)計通常會保持容器之間的間距不變，這就需要容器大小變化以適應(yīng)窗口大小變化了。響應(yīng)式的布局思路，很好地幫助完成內(nèi)容墻的設(shè)計。
△ 滿屏的內(nèi)容突出了內(nèi)容豐富度
響應(yīng)式布局的設(shè)計要點
在以往的開發(fā)合作中，設(shè)計提供切圖和尺寸標注給開發(fā)就行了。
而響應(yīng)式頁面中的容器大小是動態(tài)的，我們可以提供一個表格，告訴開發(fā)在不同的頁面寬度區(qū)間，對應(yīng)的布局應(yīng)該是怎么樣的。這些區(qū)間的臨界點，就是「斷點」。
我們以容器多，情況比較復(fù)雜的視頻首頁模擬一次確定斷點的流程。
△ 響應(yīng)式布局的設(shè)計思路
首先，斷點是反映頁面發(fā)生突變的情況的，如邊距開始發(fā)生變化、容器數(shù)量開始發(fā)生變化等。本例中，我們固定了側(cè)邊欄a、邊距b、間距d。據(jù)下圖公式，容易得知容器數(shù)量和容器寬度有著明確的數(shù)量關(guān)系。因此，尋找斷點，需要我們先確定容器寬度(c)。
△ 容器數(shù)量和容器寬度有著明確的數(shù)量關(guān)系
容器寬度和容器內(nèi)容相關(guān)。本例中，我們規(guī)定正常情況下容器寬度最小300px，以保證封面圖和標題文字還能被看清。當容器寬度被壓到300px時，容器數(shù)量減少一個。
有了容器的最小尺寸，那么我們可以輸出給開發(fā)的「頁面寬度-容器數(shù)量對應(yīng)表」。從下表可以讀出，瀏覽器寬度在1284-1595px之間時，側(cè)邊欄展開為288px，放3個容器，瀏覽器會自動把容器寬度算出來。
△ 頁面寬度與容器數(shù)量關(guān)系表
斷點選擇的技巧
從上面的案例我們知道，確定斷點和容器數(shù)量、容器大小有關(guān)。那么，斷點的選擇其實是體現(xiàn)了，設(shè)計師對頁面信息呈現(xiàn)方式的理解。
1. YouTube的小心機
調(diào)研的過程中，我們發(fā)現(xiàn)YouTube 選擇 1143-1966px 作為4個容器的前后斷點。這個頁面寬度區(qū)間很大，達到了824px（遠超5個容器的跨度335px）。
△ YouTube的網(wǎng)頁斷點情況
我們猜想：
- YouTube認為1行4個視頻是用戶瀏覽的最好數(shù)量；
- 他們想把這種布局覆蓋主流的(約66.25%)屏幕寬度 1280-1920px。
2. 關(guān)注高分屏的實際效果
需要特別注意的是，橫向分辨率達到3840px 的PC高分屏中，主流瀏覽器會按照2倍圖展示內(nèi)容。此外，Windows系統(tǒng)下有系統(tǒng)縮放，推薦的是1.25倍，導(dǎo)致3840px的屏幕寬度，瀏覽器認為只有1536px (3840px÷2÷1.25)。所以有時候會出現(xiàn)在分辨率很高的屏幕下，響應(yīng)式頁面展示的內(nèi)容反而更少了的情況。
寫在最后
響應(yīng)式的布局方法能很好地支持越來越流行的「內(nèi)容墻」的設(shè)計。找好斷點，設(shè)定好不同屏幕分辨率的布局策略，是響應(yīng)式設(shè)計的關(guān)鍵。
原文：騰訊GLDesign
去年上半年，我開始著手推動項目中響應(yīng)式設(shè)計的落地。以官網(wǎng)優(yōu)化需求為契機，主動去做了響應(yīng)式的頁面設(shè)計，也說服了產(chǎn)品、設(shè)計和開發(fā)的相關(guān)同事一起把它上線落實，但不幸的是，由于各種方面的原因，比如，生搬硬套的PC模塊，無差異化的設(shè)計使得移動端閱讀不佳，導(dǎo)航兼容性有限等等原因，上線幾個月后又悄然下線。我不禁反思，項目中是否應(yīng)該推行響應(yīng)式？今年年初重新啟動了全站響應(yīng)式項目，從產(chǎn)品、交互、視覺到開發(fā)，各個角色全方面參與了響應(yīng)式項目，最終門戶的頁面實現(xiàn)全面響應(yīng)式。在項目過程中有技術(shù)沉淀，也有不少的思考，也就有了以下的文字。文章的內(nèi)容圍繞四個方面，響應(yīng)式的概念，實踐方法，一些案例，以及一些看法。
概念
Ehan Marcotte 為A List Apart寫過一篇介紹型的文章 <響應(yīng)式網(wǎng)頁設(shè)計> 。文中講到響應(yīng)式的概念源自響應(yīng)式建筑設(shè)計，即房間或者空間會根據(jù)其內(nèi)部人群數(shù)量和流動而變化。
[最近一門新興的學(xué)科“響應(yīng)式建筑(responsive architecture)”開始在探討物理空間根據(jù)流動于其中的人進行響應(yīng)的方法。建筑師們通過把嵌入式機器人與可拉伸材料結(jié)合的方法，嘗試藝術(shù)裝置和可彎曲、伸縮和擴展的墻體結(jié)構(gòu)，達到根據(jù)接近人群的情況變化的效果。運動傳感器與氣候控制系統(tǒng)相結(jié)合，調(diào)整圍繞人們周圍的房間的溫度以及環(huán)境照明。已經(jīng)有公司制造了“智能玻璃技術(shù)”，當室內(nèi)人數(shù)達到一定的閥值時，它可以自動變?yōu)椴煌该鳡顟B(tài)，為人們提供更多隱私保護。]
Web響應(yīng)式設(shè)計的概念與之也非常相似。在如今技術(shù)飛快發(fā)展的時代，一向是以快論英雄，設(shè)備和分辨率日新月異，就以分類相對明晰的iPhone為例，就有多達4種的分辨率和屏幕尺寸，更別提廠商蓬勃發(fā)展的安卓機領(lǐng)域。因此，為每種設(shè)備或者特定設(shè)備分辨率制定相應(yīng)的獨立版本是非常費時費力的事情。
Web響應(yīng)式設(shè)計的理念，應(yīng)當是，頁面可以根據(jù)用戶的設(shè)備環(huán)境，包括系統(tǒng)，分辨率，屏幕尺寸等等因素，進行自發(fā)式調(diào)整，提供更適合當前環(huán)境的閱讀和操作體驗，對已有和未來即將出現(xiàn)的新設(shè)備有一定的適應(yīng)能力。
實踐
有了概念，一定要談?wù)剬崿F(xiàn)的方法。類似于響應(yīng)式建筑，Web頁面也有對應(yīng)關(guān)鍵因素。
- 可彎曲、伸縮、擴展的墻體結(jié)構(gòu)——可擴展的布局；
- 運動傳感器——MediaQuery；
- 氣候控制系統(tǒng)——柵格；
- 藝術(shù)裝置——css等等。
以上給了我寫文章的脈絡(luò)結(jié)構(gòu)靈感，于是先從最基礎(chǔ)的布局談起。
可擴展的布局
有一種流體布局的概念在早起web興起的時，就開始盛行了。它的概念是說頁面會根據(jù)瀏覽器窗口的變化進行更改，網(wǎng)站可以通過維護一套代碼，保質(zhì)一致性的設(shè)計。我這里強調(diào)的可擴展的布局也是基于這個概念，只是現(xiàn)在的方法多種多樣，因此要強調(diào)頁面布局的可擴展性。
可擴展的布局途徑有很多，比如常見的百分比布局，以及一直未成為標準的柵格布局等等。
- 框架
就從這框架來說，以一個常見的可擴展的三欄布局為例，就有數(shù)十種方法，這里拋磚引玉舉幾個例子。
方法1：
方法2：
方法3：
方法4：
方法5：
方法6：
方法7：
方法8：
方法9：
除了上述總結(jié)的幾種，還有更多更多的方法。兩欄布局同理就不贅述。
此外W3C也有一個柵格化布局（Grid Layout）的規(guī)范，這個布局是基于兩維柵格系統(tǒng)設(shè)計的，可以輕松按照我們的意愿改變頁面的設(shè)計。它與Flexbox配合效果更佳。但目前仍處于草案階段。翻看了W3C的最新草案內(nèi)容，對Grid Layout的使用方法和原理簡單介紹下。
1）定義grid：
首先在grid item外的父級容器上定義display: grid.
Values：
- grid – 定義block-level的柵格；
- inline – 定義 inline-level的柵格
2）一些相關(guān)概念：
- grid lines – 是橫向和縱向劃分grid的線，它可以一朝數(shù)字順序被指定，也可以用用戶制定的名字被指定。
- grid tracks – 指的是一個grid列或者行之前的區(qū)域，換而言之是兩個相鄰的grid lines之前的空間。下圖是第二行和第三行之間的grid tracks。
- grid cells – 一個grid cell指的是grid中最小的單位。
- grid areas – 是用來展現(xiàn)一個或多個grid item的邏輯空間。它被四條grid line包圍。
3）grid item 屬性
了解了一些基本概念后，就可以更加絨里理解相關(guān)的grid item屬性。
- grid-column-start
- grid-column-end
- grid-row-start
- grid-row-end
這四個屬性中，grid-column-start和grid-row-start指明區(qū)域起始線，grid-column-end和grid-row-end指明區(qū)域結(jié)束線。這四個屬性均有以下四個值可取。
Values：
- <line> – 可以是一個數(shù)字，代表的是 grid line
- span <number> – 該項會橫跨所提供的數(shù)字個grid tracks
- span <name> – 該項會橫跨直到碰到下一個指定名字的grid line
- auto – 自動或者默認屬性
舉個例子：
代表的區(qū)域就是：
除以上提到，grid還擁有更多的屬性，使之可以定義grid item的寬高，間隙，內(nèi)部自適應(yīng)的方式，對齊方式等等。更多屬性可以參考W3C文檔。
4）瀏覽器支持：
令人遺憾的是，瀏覽器的支持度還未盡人意，未來在UA上獲取更多支持才是Grid發(fā)展的根本。
框架搭建好，才僅僅是響應(yīng)式的開始。但是俗語有云：Well begun is half done. 響應(yīng)式從做好的布局開始。
原文鏈接: ISUX
]]>
譯前言：2015年響應(yīng)式設(shè)計趨勢的延續(xù)，也將帶來更多的爭議和思考，此文所引論據(jù)較為客觀，點出了響應(yīng)式概念的初衷和近年來跨屏設(shè)計的狀況，并提供了解決思路和可參考的具體方法，原文下的評論也有諸多爭議，有興趣可以移步一覽。
原文：http://www.smashingmagazine.com/2014/07/22/responsive-web-design-should-not-be-your-only-mobile-strategy/
作者：Maximiliano Firtman
你臉上掛著微笑心情愉悅地縮放著瀏覽器窗口時，認為網(wǎng)站達成了移動端友好體驗的目標。在探討之前我要提前推論：如果你只是把響應(yīng)式網(wǎng)頁設(shè)計定為終極目標并且是唯一的移動端方案，是在流失用戶，也許還有金錢。幸運的是我們能夠修正這些錯誤。
這篇文章的內(nèi)容將涉及移動網(wǎng)頁與響應(yīng)式設(shè)計的關(guān)系，始于如何提供靈巧的響應(yīng)式設(shè)計，及移動端的性能為何如此重要、響應(yīng)式設(shè)計何以不能視為網(wǎng)站的目標，并止于技術(shù)本身的性能爭議，以便輔助理解問題的真正所在。
2000年起，設(shè)計師和開發(fā)者就已對移動端存在的問題過分簡化，而現(xiàn)在有些人則認為響應(yīng)式網(wǎng)頁設(shè)計是一切難題的銀彈。我們需要正視的是，達到移動網(wǎng)頁的輕快體驗應(yīng)蓋過其他任何目標。向所有移動設(shè)備傳送一個快速可用并全兼容的體驗是一個挑戰(zhàn)，在實施響應(yīng)式技術(shù)時也是如此。而在一開始便關(guān)注性能將協(xié)助我們更易達成目標。
響應(yīng)式網(wǎng)頁設(shè)計非常優(yōu)秀，但它不是銀彈。如果把它當作移動端的唯一法寶，那么也許會有性能問題將對轉(zhuǎn)化率造成阻礙?，F(xiàn)約有11%的網(wǎng)站是響應(yīng)式的并且這個數(shù)字每個月都在上升，討論它的時機到了。
根據(jù)Guy Podjarny的調(diào)查，72%的響應(yīng)式網(wǎng)站統(tǒng)一傳送相同數(shù)量的字節(jié)，而不依據(jù)屏幕尺寸區(qū)分處理，甚至在使用速度較慢的移動網(wǎng)絡(luò)連接也是如此。但并非所有的用戶都會耐心等待網(wǎng)站的加載。
實際上只需對問題有基本理解，我們就可以讓損失降到到最低。
移動網(wǎng)站由來已久
我并不是說不該讓設(shè)計做到響應(yīng)式，或者建議應(yīng)該采用一個m.*的子域名。事實上，社交分享已無所不在，不區(qū)分設(shè)備讓每一個文件指向同一個URL是明智的。但這并不意味著單一的URL應(yīng)該總是傳送同一文件，或者說是所有的設(shè)備應(yīng)該加載同一個資源。
引用創(chuàng)造“響應(yīng)式網(wǎng)頁設(shè)計”術(shù)語的Ethan Marcotte的一句話：
最重要的是，響應(yīng)式網(wǎng)頁設(shè)計不是特意為移動網(wǎng)站提供的一個替代解決方案。
（譯補Ethan Marcotte原文：“我認為響應(yīng)式設(shè)計是設(shè)計哲學(xué)的一部分，也是前端開發(fā)策略的一部分。而作為后者，應(yīng)依實際項目所需評估其可行性。”）
響應(yīng)、移動、快速
移動端的性能保證與響應(yīng)式設(shè)計可以同時實現(xiàn)，只要用上一些其他技術(shù)。響應(yīng)式網(wǎng)頁設(shè)計從不意味著去制造性能問題，這也是我們無法歸罪于這項技術(shù)本身的原因，而許多人相信它能解決一切問題才是錯誤的根源。
讓設(shè)計響應(yīng)式化的重要性在于，我們需要處理從臺式機到手機的大區(qū)間viewport尺寸。但是只考慮屏幕尺寸低估了移動設(shè)備，臺式機與手機的分界線正在變得模糊，不同類型的設(shè)備也趨于提供多樣化功能。顯然我們已無法再只依賴于使用媒體查詢這一功能。
有些評論者稱之為“負責(zé)任的響應(yīng)式網(wǎng)頁設(shè)計”，雖然其他人把它叫做現(xiàn)代化的響應(yīng)式網(wǎng)頁設(shè)計。撇開兩種叫法語義上的差別，我們確實需要理解并意識到問題所在。
不存在銀彈也沒有可以一勞永逸的方案，我們能做的是使用組合技巧提升現(xiàn)有的響應(yīng)式方案并且力求性能的最優(yōu)化：
- 提供相同URL及內(nèi)容，但針對不同設(shè)備結(jié)構(gòu)不同；
- 在立項規(guī)劃階段便需遵循移動優(yōu)先原則；
- 使用display: none時進行真機測試驗證資源加載，而非依賴于桌面瀏覽器模擬；
- 在瀏覽器提供更好的解決方案（如srcset）之前，使用JavaScript分發(fā)響應(yīng)式圖片；
- 移動端初始viewport的文件內(nèi)嵌，或者優(yōu)先加載首屏內(nèi)容。
- 提供更智能的響應(yīng)式方案如：按需加載、分組響應(yīng)式、服務(wù)器端的自適應(yīng)處理。
按需加載
CSS媒體查詢無法讓設(shè)備區(qū)分加載和解析，這意味著移動端的手機會下載和解析為更大屏幕提供的CSS。再者，蜂窩網(wǎng)絡(luò)下CSS的分區(qū)渲染浪費的毫秒十分寶貴，有必要避免全依賴于此。
正如我們知道的，iPhone不會動態(tài)轉(zhuǎn)換為iPad的尺寸，采用JavaScript 的matchMedia查詢方法替代CSS媒體查詢，則能夠保證不同設(shè)備顯示內(nèi)容的統(tǒng)一性并且只加載它們各自所需要的CSS。
使用特征檢測工具可以做到更好，如Modernizr可以構(gòu)建更智能的UI和功能定義，而不是只依賴于屏幕尺寸。
分組響應(yīng)式
基于單HTML頁面為所有屏幕進行響應(yīng)式設(shè)計時，為臺式電腦和智能手機傳送同樣的HTML結(jié)構(gòu)是糟糕的，原因再次回歸到移動端的性能問題。
即使服務(wù)器端存儲同一個文件，基于設(shè)備分組也可以實現(xiàn)對終端的按需發(fā)送。舉例來說，為6英寸及更大尺寸的屏幕提供大的浮動式菜單，而為小于6英寸的屏幕提供一個小的漢堡包菜單。響應(yīng)式技術(shù)可以基于分組實現(xiàn)不同情境的適配，如橫豎屏模式的轉(zhuǎn)換、不同型號的iPhone（寬為320像素）、各式5英寸的安卓設(shè)備（寬為360像素）及平板（寬為400像素及以上）。
服務(wù)器端層面
更智能的響應(yīng)式解決方案的最后一個選項是服務(wù)器，對移動網(wǎng)頁來說服務(wù)器端進行特征檢測及定義并不新奇，市面上早有諸如WURFL和Device Atlas之類的工具庫。
把響應(yīng)式設(shè)計與服務(wù)器端組件聯(lián)合同樣也有前例，已被知曉的有響應(yīng)式設(shè)計+服務(wù)器端組件(RESS)，或被稱為自適應(yīng)設(shè)計，保障每個終端代碼簡約性的同時，提高了響應(yīng)式的速度與可用性體驗。
不幸的是，在過去幾年里這些技術(shù)沒有在社區(qū)里獲得太多的推動，只需看看有多少為開發(fā)者提供的博客或雜志將“RESS” 與“自適應(yīng)” 和“響應(yīng)式”相提并論便可一知。其一原因在于：我們是前端工程師，任何涉及后端的內(nèi)容都是個令人頭疼的難題。
一部分情況是前端設(shè)計人員可以控制的是服務(wù)器上的腳本；另一部分情況是有遠程開發(fā)團隊管理，設(shè)計師并不想在每次需要調(diào)整UI時都與他們打交道，這種情形下的心情我能夠理解。
這也是為何在大項目里頭應(yīng)該考慮新的架構(gòu)層：一種不需要動用后端，只通過前端工程師就能夠?qū)Ψ?wù)器端架構(gòu)進行操作的方式。Node.js是一種卓越的作為前后端之間流通架構(gòu)的平臺，這個架構(gòu)方式下，前端工程師可以基于內(nèi)部的流通性進行調(diào)整而不需要涉及后端架構(gòu)，從而實現(xiàn)為所有設(shè)備提供輕快的響應(yīng)式和可用性體驗。
響應(yīng)式設(shè)計、性能和技術(shù)數(shù)據(jù)
對這篇文章你可能抱有一些置疑，接下來我們將對技術(shù)細節(jié)進行重新審視以減輕你的疑慮。
響應(yīng)式設(shè)計通常會為所有設(shè)備傳送相同的HTML文件，再采取媒體查詢的方式加載不同的CSS和image文件，這一點有的人可能不太同意，但很多情況下都是如此實施的。
你也可能會認為如今移動網(wǎng)絡(luò)速度的提升已足夠?qū)崿F(xiàn)良好的體驗，畢竟4G非?？欤O(shè)備也運行得更為流暢，那么在下結(jié)論之前我們來看一些數(shù)據(jù)吧。
蜂窩連接
4G網(wǎng)絡(luò)還沒有廣泛覆蓋，而即便是全世界范圍內(nèi)都能夠使用4G網(wǎng)絡(luò)，可能也會有一些超出預(yù)期的狀況。只論US地區(qū)的4G用戶數(shù)量約為22%，而其中的40%并非隨時處于4G連接狀態(tài)，除外地區(qū)則只有不到3%的手機使用4G連接。
移動網(wǎng)絡(luò)速度受限于帶寬，3G可以達到5Mbps，4G可以達到50Mbps。但移動網(wǎng)頁體驗通常面臨的最重要的現(xiàn)狀是：消耗于接收大文件（如YouTube視頻）的帶寬越多，大批量小文件的并行下載越不順暢，并會伴有確定性的高發(fā)延遲。延遲是設(shè)備對每個數(shù)據(jù)包的首字節(jié)發(fā)起請求接收的往返時間。
蜂窩網(wǎng)絡(luò)比其他連接方式延遲更多。雖然US的家庭DSL連接延遲為20~45ms，3G網(wǎng)絡(luò)
卻可能達到150~450ms，4G網(wǎng)絡(luò)則為100~180ms。這也就意味著蜂窩連接的延遲比家庭網(wǎng)絡(luò)要高出5~10倍。
尚有其他延遲方面的問題如無線電廣播引起的變動：當手機進入休眠狀態(tài)后打開收音機頻率需要獲取更多數(shù)據(jù)而導(dǎo)致滯時；設(shè)備平均可用內(nèi)存越低也就意味著電池和CPU消耗越多。
蜂窩網(wǎng)絡(luò)下的響應(yīng)式設(shè)計
一個實例：Keynote是一家提供性能解決方案的公司，發(fā)布了2014超級碗頂尖廣告的網(wǎng)頁性能數(shù)據(jù)。這份報告里陳述：在wired或Wi-Fi連接下加載時間為1~10s區(qū)間，而在蜂窩連接下加載時間為5~60s的區(qū)間。實在難以想象超級碗上投放的廣告是需要加載整整一分鐘的網(wǎng)頁。
同樣的報告顯示有43%的網(wǎng)站提供了移動專屬版本，平均體積為862KB；50%實行響應(yīng)式方案的平均體積在3211KB（超出將近四倍）；另外7%對移動設(shè)備提供的則是桌面版，這基本可以認為響應(yīng)式網(wǎng)站比移動專屬網(wǎng)站的體積更大。
當然，響應(yīng)式網(wǎng)站可以有不一樣的表現(xiàn)，但不幸的是，這份報告之外的響應(yīng)式網(wǎng)站的表現(xiàn)也基本與超級碗廣告相似。
基于云技術(shù)的瀏覽器
如果對移動端網(wǎng)頁的性能仍存有疑慮，想想看基于云技術(shù)開發(fā)瀏覽器的廠商正為用戶做的——包括Opera Mini、基于亞洲的UC瀏覽器（根據(jù)statcounter的統(tǒng)計，其市場占有率為11%），Amazon Fire的Silk瀏覽器和目前的 Google Chrome（通過選項設(shè)置）。
這些廠商在云端壓縮所有的網(wǎng)站和資源，隨后瀏覽器下載優(yōu)化過的版本到移動端，而他們?nèi)绱俗龅睦碛墒钦J識到了性能服務(wù)于用戶的意義。
移動端的網(wǎng)頁被低估
網(wǎng)絡(luò)社區(qū)通常會低估移動瀏覽器的重要性，我曾聽到人們說現(xiàn)今的移動端網(wǎng)頁只有iOS的Safari和Android的Chrome瀏覽器，對響應(yīng)式設(shè)計，我們只需顧及320像素寬的viewport。但實際情況比這復(fù)雜得多。
如今有不下于10個瀏覽器的市場占有率超過1%，就算只需考慮iOS和Android的默認瀏覽器也并不容易。大致情形來說，在移動端瀏覽網(wǎng)頁的用戶中，iOS占50%，Android占38%，Windows Phone占3%，Opera Mini占5%（包括各類操作系統(tǒng)），剩余4%則為其他平臺。
而如今的Android平臺有64%的用戶使用自帶瀏覽器，這是一個與Google Chrome存在差異并且本身具有多個版本的瀏覽器。此外，最新的三星Galaxy中有一些設(shè)備所提供的Android瀏覽器是自定義引擎的版本。
根據(jù)viewport的尺寸，僅Android系統(tǒng)的智能手機，如今我們需要處理的像素寬度就包括320、360、400、540。那么我要建議的是，不要低估移動端的網(wǎng)頁，并去了解它那些獨一無二的特征。
1秒內(nèi)完成首屏內(nèi)容的加載
在移動設(shè)備中，我們把在1秒或是更少時間完成首屏內(nèi)容（即不需滾動直接顯示的內(nèi)容）渲染的網(wǎng)站視作是快的。我知道1秒鐘看起來十分快速——特別是考慮到至少有一半的情形是要在蜂窩網(wǎng)絡(luò)下來達到的——但這已被證實是可能的。1秒響應(yīng)可保證用戶聚焦于內(nèi)容，從而提升轉(zhuǎn)化率及減少流失。
達到1秒響應(yīng)時間，首屏內(nèi)容需要在傳輸控制協(xié)議（TCP）的單次往返時間中完成——不能忽略的是普遍的3G網(wǎng)絡(luò)幾乎存在半秒的延遲。由于TCP被稱為“慢啟動”，首次響應(yīng)不能超過14KB以避免二次打包。這意味著首屏內(nèi)容的HTML和CSS至少必須符合14KB的單次HTTP響應(yīng)。如果我們做到這個，那么也就達成了1秒加載時間的感官體驗。
這條規(guī)則并沒有被明確列出，且要視實際需要而有所調(diào)整。然而，由于移動屏幕的首屏內(nèi)容顯示通常無法達到與桌面屏幕一致的效果，使用響應(yīng)式設(shè)計達到1秒的目標是非常艱難的，但實現(xiàn)的難度是可以通過多種技術(shù)的結(jié)合降低的。
一個HTML服務(wù)所有平臺
一個典型的響應(yīng)式設(shè)計是對所有設(shè)備發(fā)送單一的HTML文件：電視、桌面、平板、智能手機及其后的所有手機。這聽起來很贊，但我們生活的世界有蜂窩網(wǎng)絡(luò)和其他的各種問題。移動設(shè)備下你的響應(yīng)式HTML可能會正確渲染，但它不夠快，本來它應(yīng)該是可以更快的，這也在影響你的轉(zhuǎn)化率。
一旦有display: none出現(xiàn)在CSS中，你的站點就會開始變慢。一個從零開始為語義設(shè)計的站點，響應(yīng)式的超載會讓一切工作幾近化為無用；一個站點的HTML里包含的40個外部JavaScript里的絕大多數(shù)jQuery插件和功能庫都是為大屏服務(wù)的，響應(yīng)式超載會讓一切崩潰。使用同一HTML，就等同于在所有設(shè)備加載同樣的外部資源。
這并不是說不能做單一的響應(yīng)式設(shè)計，只是站點不會自行進行優(yōu)化。如果你已經(jīng)留心到了性能，那么你的響應(yīng)式方案將會不同尋常。
我們來審視一番星巴克的站點，它的主頁是響應(yīng)式的并且在我們測算的三種viewport下（屏幕截圖見下）看起來都很贊。但查看結(jié)構(gòu)之后，我們發(fā)現(xiàn)所有版本都加載33個外部JavaScript文件和6個CSS文件。使用3G延遲網(wǎng)絡(luò)的移動設(shè)備需要加載到39個外部文件只為顯示這樣一個頁面么？
不同情境下的星巴克站點 (查看大圖）
你可能會認為，“啊，干嘛怪技術(shù)應(yīng)該怪實現(xiàn)”，這是對的。這篇文章并不是和響應(yīng)式網(wǎng)頁設(shè)計作對，它駁斥的是瞄準了響應(yīng)式卻實現(xiàn)得很糟糕，它駁斥的是以響應(yīng)式為目標而不顧性能，正如星巴克一般。
若你的響應(yīng)式站點存在性能問題，那根源可能是出于你所定的目標。若為響應(yīng)式設(shè)計實施規(guī)劃，也必須為性能實施規(guī)劃。
資源加載
媒體查詢有多種應(yīng)用方式，通常采用如下中的一種：
- 單獨CSS文件添加多樣的@media聲明；
- 通過link標簽的media屬性為頁面引入多樣的CSS文件。
第一種情形中，只會產(chǎn)生一個CSS文件，故所有設(shè)備都會加載全平臺的CSS，數(shù)百個無用的選擇器都會被瀏覽器轉(zhuǎn)譯和解析。
你可能會認為多樣的外部文件是更好的方式，因為瀏覽器會基于斷點加載不同的資源，這是我們在各種博客、雜志、書和培訓(xùn)課程中得到的信息。
<link rel="stylesheet" href="desktop.css" media="(min-width: 801px)"> <link rel="stylesheet" href="tablet.css" media="(min-width: 401px) and (max-width: 800px)"> <link rel="stylesheet" href="mobile.css" media="(max-width: 400px)">
好吧，你完全錯了。所有的瀏覽器會不分環(huán)境地把所有的外部CSS一并加載。下面的屏幕截圖顯示iPhone下載了所有頭部引用的CSS文件， 包括與它無關(guān)的。
為何瀏覽器會下載所有的CSS文件？現(xiàn)在假設(shè)有一個CSS文件是為豎屏提供的另一個則為橫屏提供。我們不希望瀏覽器在橫豎屏切換時飛快地切換CSS，為防止其間出現(xiàn)頁面裸奔（無CSS的裸HTML頁），我們希望的是瀏覽器提前把所有文件都加載好。而這正是你基于屏幕尺寸定義媒體查詢會發(fā)生的一切。
那么可以調(diào)整移動瀏覽器的尺寸么？目前基本上不行，但廠商正在準備推出可以像桌面瀏覽器一樣調(diào)整的移動瀏覽器，這也是瀏覽器會不顧媒體查詢的寬度匹配規(guī)則不分情境加載所有聲明的CSS的原因。
尚沒有任何移動設(shè)備具有可伸縮的viewport（目前為止），但某些情形下viewport會被重置：
- 某些瀏覽器的屏幕旋轉(zhuǎn)；
- viewport聲明被動態(tài)更改；
- onload添加了內(nèi)容導(dǎo)致偏移；
- 支持外部鏡像；
- 某些三星的安卓機同時運行多個app（多窗口模式下）。
在上述變動下瀏覽器會最優(yōu)化加載可能會需要的所有資源。而不遠的將來瀏覽器對此會更智能，但此時我們尚有問題存留：我們傳送了比實際需要超出得多的資源，從而讓用戶遭受無妄之災(zāi)。
真正的問題：以響應(yīng)式設(shè)計為目標
正如Lyza Danger Gardner在“當我們談?wù)?lsquo;響應(yīng)式’時我們在談?wù)撌裁?rdquo;里所說的，設(shè)計師為“響應(yīng)式”下的定義并不一致，從而會導(dǎo)致溝通誤差。
追本溯源來看，這個術(shù)語首次出現(xiàn)是在2010Ethan Marcotte的文章里，隨之而來是同名書籍。Ethan定義其為：以流體網(wǎng)格、彈性圖片和媒體查詢?nèi)N技術(shù)為多區(qū)間的設(shè)備屏幕提供最佳顯示體驗。
這并沒有什么不對，問題出現(xiàn)在我們只把它視之為站點效果，而沒有理解其背后更寬廣的更需要達成的目標。
當以響應(yīng)式設(shè)計效果為目標，會變得容易迷失在觀念中。你 真正試著去解決的問題是什么？響應(yīng)式化有問題么？也許沒有。但你是否把“響應(yīng)式化”理解為“兼容移動端”？如果是這樣，那你也許犯了一些錯誤。
一個站點的終極目標應(yīng)該是“服務(wù)用戶”，從而實現(xiàn)更多形式的轉(zhuǎn)化，不論是讓訪客傳播文字、提供信息還是產(chǎn)生消費。沒有高性能的站點就沒有滿意的用戶。
性能在轉(zhuǎn)化上，尤其是移動端方面的直接影響，已被多次證實。如果這是你第一次聽聞，只要隨便翻閱一本 Steve Souders關(guān)于網(wǎng)頁性能優(yōu)化的專業(yè)書就可一知詳細。
知曉目標，決定用何種工具和技術(shù)以最佳方式實現(xiàn)。這就是你分析在哪里、如何用響應(yīng)式方法時應(yīng)該做的。你使用響應(yīng)式設(shè)計——卻沒有領(lǐng)會它。
響應(yīng)式與用戶
紐約時報在幾個月前以保持“符合你的預(yù)期”為目標重新設(shè)計了網(wǎng)站，同時有上千家大型企業(yè)驕傲地推出了他們新的響應(yīng)式版的網(wǎng)站。
紐約時報以有別尋常的方式進行響應(yīng)式設(shè)計，但有一些人對它并非基于相同HTML進行適應(yīng)性布局而是采取專門的移動站點抱以不滿，甚至有一篇文章冠以“新版的紐約時報WebApp缺失響應(yīng)式設(shè)計的核心”的標題聲討。
沒有人說過響應(yīng)式設(shè)計意味著使用同一HTML去適配所有屏幕尺寸，而這顯然已被當作普遍定義。但這條規(guī)則并沒有在任何地方被明確規(guī)定，只是我們試圖簡化問題所造成的。
近幾個月內(nèi)，數(shù)家公司都在宣揚著這樣的臺詞：“我們提供了一個新的響應(yīng)式版網(wǎng)站，讓移動端轉(zhuǎn)化得到了100%的提升。”但轉(zhuǎn)化的提升確實是因為站點進行了響應(yīng)式化么？還是用戶意識到了它是響應(yīng)式的而更愿意使用？
人們轉(zhuǎn)化更多僅是因為在移動設(shè)備上得到了更快更好的體驗，而無關(guān)于采取了何種有別以往的方案（不論它是移動端版本還是桌面版本的縮影）。以此說來，響應(yīng)性沒有任何優(yōu)于采用傳統(tǒng)移動方案實現(xiàn)的特別之處，而相同設(shè)計下的獨立移動站點若輔以其他技術(shù)形成更明智的方案，也能夠達到相同的轉(zhuǎn)化甚至更佳。
結(jié)論
“用戶才不鳥你的站點用上了什么響應(yīng)式” —— Brad Frost
Brad Frost相當正確，用戶想要的是快速易用，他們并不老去調(diào)整瀏覽器窗口，也不需要理解“響應(yīng)式”的含義。
這是沉重的事實，也并非是所有網(wǎng)站都會面臨的狀況，但也好過總想著“我們做了響應(yīng)式兼容移動端沒有后顧之憂了。”某些時候，甚至不需要考慮情境地把響應(yīng)式設(shè)計稱之為“性能破壞者”也是有利的，因為這將有助于讓人們關(guān)注到性能的重要性。
紐約時報是對的：以用戶為核心，而非工具或技術(shù)，甚或是當作設(shè)計師們的狂歡。
延伸閱讀
- “遺失核心的響應(yīng)式設(shè)計”Brad Frost
- “RESS: 響應(yīng)式設(shè)計 + 服務(wù)器端組件,” Luke Wroblewski
- “當我們談?wù)?lsquo;響應(yīng)式’時我們在談?wù)撌裁?/a>” Lyza Danger Gardner, A List Apart
- “再好的運營也無法回避性能問題” Aaron Rudger, Keynote
- “二度驗證：實境下的響應(yīng)式設(shè)計性能” Guy Podjarny
- “技術(shù)本無過錯，執(zhí)行決定成敗” Tim Kadlec
- “稱之‘響應(yīng)式設(shè)計=性能破壞者’于性能有益” Tim Kadlec
響應(yīng)式設(shè)計方法對開發(fā)者非常有用，因為它使我們的內(nèi)容在各種設(shè)備上廣為傳播。不用保留幾個獨立版本的網(wǎng)站，也可以摒除諸如縮放和流式布局這些方法的弊端。
本文重點討論設(shè)計師遇到最多的3個響應(yīng)式設(shè)計問題，也會提供一些規(guī)避錯誤的策略。
縮放、流式布局與響應(yīng)式
這些術(shù)語容易造成混淆，設(shè)計師常常錯誤地交替互用。實際上，每個都是布局技巧的顯著進化過程，像技術(shù)演進那樣逐一顯現(xiàn)。
縮放布局，旨在相對縮放每一個元素。它們會隨著窗口大小變化動態(tài)縮放內(nèi)容，就這方面而言，它們是響應(yīng)式的。布局本身保持靜止，通過改變每一個元素來保持一致的表現(xiàn)。
上圖：不同分辨率下縮放布局的例子，這種設(shè)計為了統(tǒng)一犧牲了易讀性。
流式布局就不一樣，因為它們隨著窗口尺寸縮放容器元素。通過em這類相對單位可以做到這點，克服了縮小文字的問題。用戶主動縮放時，設(shè)計就被破壞了。
上圖：不同分辨率下流式布局的例子，這種設(shè)計為了易讀性犧牲了統(tǒng)一。
響應(yīng)式設(shè)計不會縮放任何東西。相反，它會根據(jù)窗口尺寸決定顯示哪些內(nèi)容。
上圖：不同分辨率下響應(yīng)式布局的例子。
災(zāi)禍1：菜單折行
如果在頁面頂部使用了導(dǎo)航欄，當頁面展現(xiàn)在小屏幕上時，響應(yīng)式設(shè)計通常會把它“掰”成更緊湊的格式，但這并非總是有效，如果顯示區(qū)域比斷點更寬，又不足以在一行顯示所有菜單項的話。結(jié)果會導(dǎo)致菜單的折行。
有些方法可以解決這個問題。其一，減少導(dǎo)航欄中橫排菜單項的數(shù)量，將它們分門別類。然后選中某類時，你可以通過下拉菜單來顯示子類。
其二，減少斷點的數(shù)值。應(yīng)該以導(dǎo)航欄開始出問題的實際數(shù)值為準，而非具體設(shè)備尺寸。
其三，不同設(shè)備使用不同方式，例如滑動抽屜。
災(zāi)禍2：使用固定寬度圖片
內(nèi)容區(qū)域通常都隨窗口尺寸變化。所以當固定寬度圖片超出顯示區(qū)域時，圖片就被裁剪了。
上圖：糟糕的固定寬度圖片例子，它太大了。于是出現(xiàn)了滾動條，內(nèi)容被推到屏幕之外。
通過給圖片設(shè)定相對單位，可以避免這個問題?；蛘呤褂弥С猪憫?yīng)式的框架（比如Bootstrap），使用響應(yīng)式圖片class名來控制（例如class="img-responsive"）。
上圖：同樣的元素，用響應(yīng)式圖片class名的方式，滾動條就不見了。
災(zāi)禍3：元素的扭曲
這有點晦澀難懂，但本質(zhì)上，布局顯示在小窗口上的時候，所有未經(jīng)處理的列都會以行的形式呈現(xiàn)。這是個問題，因為內(nèi)容的扭曲會不經(jīng)意地改變設(shè)計的層級。
上圖：列變成了行，扭曲了內(nèi)容。
解決方法顯而易見，但令人驚奇的是，仍有很多人在糾結(jié)它：只要明確地設(shè)定元素的寬度、高度、內(nèi)邊距。如果它移出所處位置，蓋住了其他元素，可以通過將它包裹在div容器中，設(shè)置外邊距，迫使它回到原本的地方。
規(guī)劃有助于避免問題
本文只討論了3種最普遍遇到的響應(yīng)式設(shè)計災(zāi)禍，還有很多其他途徑會毀了一個好的設(shè)計。預(yù)防錯誤并不難?，F(xiàn)代瀏覽器都有內(nèi)置的響應(yīng)式布局測試，好好規(guī)劃設(shè)計，多做測試。
翻譯:可樂橙
作者信息：
EMMA GRANT
Emma Grant is a professional freelance content writer from Ireland. Over the past three years she has travelled the world while running her business from her laptop. You find her at www.florencewritinggale.com More articles by Emma Grant
Material Design
2011年，Gmail郵箱的按鈕變得更加扁平化。2012年，Google引入分層的卡片設(shè)計，使用更多的空白和精心設(shè)計的層次排版結(jié)構(gòu)。經(jīng)歷了幾年的迭代和提煉，Google尋找到了一種可以貫通的理論體系，即把系統(tǒng)內(nèi)的各種設(shè)計都規(guī)范成一種變形的紙片，并套用現(xiàn)實中紙墨的物理模型進行交互，這就是2014年Google I/O大會隆重發(fā)布的Material Design。
Material Design提出了平面像素的Z軸概念，通過紙片在物理世界中形態(tài)的抽象和提煉，定義了各種信息層級和常用狀態(tài)的表達方式，并詳細講解了各個細節(jié)的處理方法，就像一本考試大綱，囊括了產(chǎn)品中常用的UI細節(jié)，甚至一些UX細節(jié)。這里并不贅述，想看詳細的Design Guide請點擊這里（要搬梯子），翻譯版的點擊這里。
如果說UX和UI的展現(xiàn)，是連接產(chǎn)品與用戶的紐帶，那么產(chǎn)品的UX以及UI應(yīng)從產(chǎn)品的核心邏輯延展并且推演而來。如果說產(chǎn)品的核心邏輯或者技術(shù)的實現(xiàn)難易會成為設(shè)計展現(xiàn)的限制，那么UX和UI應(yīng)是在各種限制下所權(quán)衡出的最優(yōu)解。而Material Design則像是架橋說明或者權(quán)衡出的通用解，對于眾多產(chǎn)品做以參考。
既然是通用大綱，那么拋開產(chǎn)品僅談設(shè)計，難免會停留于“通用”層面，而利用Material Design進行實戰(zhàn)的案例，網(wǎng)上也多是app的一些設(shè)計嘗試。恰好在近期的工作學(xué)習(xí)中，接手一個響應(yīng)式web站點的改版設(shè)計，筆者參考Material Design總結(jié)以下三點分享如何實現(xiàn)復(fù)雜響應(yīng)式站點的Material Design。
一、清晰輕量的產(chǎn)品邏輯
奧卡姆剃須刀法則同樣在產(chǎn)品架構(gòu)設(shè)計中適用，越簡單的架構(gòu)越有利于產(chǎn)品的生長。清晰輕量的產(chǎn)品邏輯，會減少用戶的負擔(dān)感，從而提高交互上的效率和愉悅感。
分析Material Design，會發(fā)現(xiàn)Google歸納了兩類復(fù)雜內(nèi)容信息的層級關(guān)系，分別是Card和Tile（List 以及其他相似定義屬于同類的內(nèi)容信息層級），其他定義多用于UI結(jié)構(gòu)及細節(jié)。其中，Google定義Card是一種多功能信息的聚合入口，信息層級應(yīng)較高，體現(xiàn)在Z軸應(yīng)高于其他信息，視覺上有陰影表現(xiàn)并加以圓角處理。而tile（或同類信息列表）則是（同類或相關(guān)）信息的模塊展現(xiàn)，信息層級應(yīng)較低，體現(xiàn)在Z軸應(yīng)略低于其他信息，視覺上應(yīng)無陰影表現(xiàn)不加圓角處理。其結(jié)果是從視覺層面讓產(chǎn)品對象更高效、更簡單，同時也更具物理世界的“真實感”。
最近接手的項目是Gekec.com的全站改版。Gekec（革客）是Geek和Maker交集，喜歡革新，喜歡技術(shù)范兒、新潮的科技消費品，喜歡自己動手創(chuàng)造產(chǎn)品，Gekec.com也就是這類人的聚集地，整個產(chǎn)品囊括電商、資訊（或h5宣傳）、拆機、以及社區(qū)討論等各種功能，改版前邏輯復(fù)雜，功能繁多。改版開始之初，筆者了解到革客群體時，便認為理性加濃重Geek味道的Google風(fēng)格或許是最適合Gekec.com的視覺體系，然而復(fù)雜的產(chǎn)品邏輯不能給用戶帶來高效的交互體驗和愉悅的使用感受，視覺上也并不能很好的通過Material Design推演并且變化，所以梳理出清晰、輕量且方便視覺統(tǒng)一的產(chǎn)品邏輯成為第一任務(wù)。
Gekec.com的產(chǎn)品全功能在此并不贅述，Product Feature全部為達成宜家式的體驗式設(shè)計，經(jīng)過梳理可以歸納成三層，首層為體驗層（多入口的首頁封面）、第二層為貨架層（包括商城模塊、拆機模塊、體驗?zāi)K）、第三層為詳細、操作層；
如上圖，輕量的產(chǎn)品結(jié)構(gòu)即可方便設(shè)計的推演。例如其中第一層可以通過H5靈活排版做產(chǎn)品全方位體驗，第二層與第三層的關(guān)系即可利用Material Card和Tile表現(xiàn)。Card表達了全部信息的聚合和入口，tile則表現(xiàn)同類信息的羅列。從card跳轉(zhuǎn)到最終頁應(yīng)有一種卡片展開的體驗。
二、適宜UI推演的響應(yīng)辦法
在產(chǎn)品邏輯清晰簡潔的基礎(chǔ)上，一套適宜Material Design變化的全尺寸響應(yīng)辦法就成為復(fù)雜響應(yīng)式網(wǎng)頁設(shè)計的核心內(nèi)容，響應(yīng)辦法能夠直接決定功能模塊的響應(yīng)邏輯以及UI的變化。實際操作中，響應(yīng)辦法的確定主要就是確定柵格和占比。
1）柵格
網(wǎng)頁柵格系統(tǒng)是從平面柵格系統(tǒng)中發(fā)展而來。對于網(wǎng)頁設(shè)計來說，柵格系統(tǒng)的使用，不僅可以讓網(wǎng)頁的信息呈現(xiàn)更加美觀易讀，更具可用性。而且，對于前端開發(fā)來說，網(wǎng)頁將更加的靈活與規(guī)范。柵格系統(tǒng)的具體含義以及使用方法在此不再贅述，感興趣的朋友可以參考淘寶UED的一些文章：
網(wǎng)頁柵格系統(tǒng)研究（1）：960的秘密
網(wǎng)頁柵格系統(tǒng)研究（4）：技術(shù)實現(xiàn)
在Gekec.com的項目中，經(jīng)歷產(chǎn)品功能模塊的梳理，筆者使用了12柵格系統(tǒng)，目的是能夠滿足2、3、4、6的頁面等分。注：具體柵格系統(tǒng)的建立應(yīng)因產(chǎn)品和設(shè)計所決定，柵格系統(tǒng)并不是萬能的，而確定的柵格系統(tǒng)可以為整個響應(yīng)式設(shè)計做規(guī)范性參考。
2）占比
A.占比
如上文說，12柵格約束網(wǎng)頁的內(nèi)容區(qū)，而網(wǎng)頁的內(nèi)容往往并不占據(jù)屏幕的全部寬度，而是在兩側(cè)留有間隙，營造空間感。由于屏幕的限制，這種空間感在移動端設(shè)備顯得更加重要，如圖，然而強加固定的margin pixel會使得12柵格占比不定，難以控制設(shè)計效果。
所以占比應(yīng)是12柵格寬度對應(yīng)屏幕的比值，即：
12柵格寬度X占比=屏幕寬（臨界點）
優(yōu)秀而巧妙的占比確定可以讓網(wǎng)頁設(shè)計呈現(xiàn)在各個主流屏幕上均是100%像素。
這里簡單解釋一下，若一個200px寬的元素在1200px寬的屏幕上，其占比為16.67%，同樣的邏輯，到1024px的屏幕上這個占比16.67%的元素即占據(jù)了170.67px，這樣的情況下，某一個物理像素?zé)o法占據(jù)100%，在完美主義的設(shè)計師眼里，是無法接受的事情。而巧妙的占比，可以讓元素在各個主流屏幕占據(jù)100%像素，完美展現(xiàn)設(shè)計意圖。
B.臨界點
臨界點（breakpoint）是指響應(yīng)式網(wǎng)頁發(fā)生布局變化的關(guān)鍵點，如“當屏幕寬度小于480px時加載…樣式，當寬度在480px- 600px之間時加載…樣式”。響應(yīng)式網(wǎng)頁理論上有無數(shù)種尺寸，我們不可能也沒有必要為每個尺寸都去做設(shè)計，需要做的是選定幾個臨界點做設(shè)計，在兩個臨界 點之間是延續(xù)上一個臨界點的布局。
臨界點確認總體目的就是為了保證頁面在手機（屏幕很小）、平板（屏幕中等）、PC（屏幕大）上加載相應(yīng)的樣式，然而經(jīng)驗較少的設(shè)計師往往會苦惱一個問題，那就是高像素的手機屏幕和低像素的平板屏幕應(yīng)如何處理。例如設(shè)計師會擔(dān)心1080p的手機加載大屏幕頁面，或者720p的平板加載小屏幕頁面。
但需要注意的是，響應(yīng)式網(wǎng)頁不同于APP的屏幕適配。網(wǎng)頁是沉浸于瀏覽器的產(chǎn)品，瀏覽器所啟動的屏幕像素才可以被認為是臨界點的參考點，為此，筆者做了一些測試，如下表，可以看出不少1080p手機在瀏覽器中僅啟動360px，而神奇的ipad無論是不是retina屏幕，無論是不是mini，均顯示1024x768px 。
從上表可以看出，許多擔(dān)心其實并不需要。綜上，在Gekec.com的項目中，筆者為達到多數(shù)主流屏幕100%像素的追求，即需達到內(nèi)容區(qū)在主流屏幕臨界點的占比可以被12等分，進而獲得12柵格，即：
12的公倍數(shù)X占比=主流屏幕尺寸
項目中經(jīng)歷了一些測試和取舍，最終確定占比為93.75%，臨界點為1280px、1024px、768px和320px。
具體為：
1280px<=screen，占比93.75%，12柵格在典型屏（1280px）寬1200px；
1024px<=screen<1280px，占比93.75%，12柵格在典型屏（1024px）寬960px；
768px<=screen<1024px，占比93.75%，12柵格在典型屏（768px）寬700px；
320px<=screen<768px，占比93.75%，12柵格在典型屏（320px）寬300px；
如上圖的占比劃分，頁面元素可以完成靈活、規(guī)范的響應(yīng)?？梢砸源俗鳛檎麄€產(chǎn)品的響應(yīng)辦法，在此基礎(chǔ)之上，可以對Material Design進行全面的推演。
三、精雕細琢的頁面細節(jié)
如果說產(chǎn)品邏輯是整個網(wǎng)站的骨架，那么精雕細琢的頁面細節(jié)則可以比喻為網(wǎng)站的氣質(zhì)靈魂。有輕量級的產(chǎn)品構(gòu)架和明確靈活的響應(yīng)式辦法后，即可通過Material Design的官方說明進行全面設(shè)計。在Material Design的說明中，已經(jīng)詳細解釋了各個狀態(tài)的約束和細節(jié)，在此并不贅述，筆者僅挑選一些典型的細節(jié)。
1）css動畫
Material Design中開篇第一章節(jié)便講述了動畫給用戶的直觀感受，說明感知一個物體有形的部分可以幫助用戶理解如何去控制它。一些細節(jié)位置的動畫能給用戶體驗上的驚喜。然而在web端實現(xiàn)動畫效果并不像app里那樣的容易，大量JS也會影響頁面加載速度甚至影響頁面其他代碼。所以筆者選擇利用CSS對頁面一些細節(jié)加以動畫效果。
A.點擊按鈕
Material Design給出了一種ripple button，抽象了人用手觸碰卡片的漣漪效果，給用戶一種全新的使用體驗，歡迎來Gekec.com點擊嘗試。
B.輸入框
簡單的Description和一條橫線，抽象了實體文字卡片的填寫過程，可以幫助用戶對輸入?yún)^(qū)域有實體化的理解，歡迎來Gekec.com點擊嘗試。
2）文字樣式
Material Design中強調(diào)“同時使用過多的字體尺寸和樣式，可以輕易的毀掉布局”，并約束了常用的基本樣式就是基于12sp、14sp、16sp、20sp的字體排版。
熟悉Android的朋友可能對sp的概念并不陌生，sp：Scale-independent pixels，它是安卓的字體單位，以160PPI屏幕為標準，當字體大小為 100%時， 1sp=1px；然而響應(yīng)式的網(wǎng)頁并不是安卓，網(wǎng)頁更需要物理像素的尺寸約束，所以筆者在所劃分的臨界點計算了一下所測試屏幕的瀏覽器PPI，如下：
iphone5: 320x568px/4英寸/PPI=162.95
榮耀6：360x640px/5英寸/PPI=146.86
ipad：1024×768/7.9英寸/PPI=131.96
ipad mini：1024×768/7.9英寸/PPI=162.03
從上面的數(shù)據(jù)可以看出，大多瀏覽器啟動像素所產(chǎn)生的PPI大約在160左右，所以某段文字在PC端約束的物理像素尺寸，直接同樣尺寸應(yīng)用于移動端時，應(yīng)該也可以產(chǎn)生不錯的體驗效果，所以設(shè)計時可以直接將Material Design的字體sp尺寸轉(zhuǎn)化為px來使用。Gekec.com的項目中，筆者只約束一套字體樣式，在方便前端開發(fā)的同時，完成了不錯的響應(yīng)式效果。
3）顏色
Material Design Guide中給出了若干明亮鮮艷的顏色，并且指定了顏色的主要展現(xiàn)和層級變化，可供設(shè)計師選擇。
在實際操作中，通過商品內(nèi)容的分類，筆者直接選擇Material Design中的顏色，作為每類商品的主要顏色，而在一些重要的操作入口，顏色應(yīng)與主要顏色有明顯區(qū)別。筆者應(yīng)用色環(huán)在Material Design Color基礎(chǔ)上，配合內(nèi)容建立整個網(wǎng)站的顏色體系：
A.主體顏色以及層次根據(jù)內(nèi)容確定，直接參考Material Design Color
B.應(yīng)用色環(huán)分析整體補色間色
將所有主體顏色步在色環(huán)上，可以分析出補色位置應(yīng)為上方紅框位置，應(yīng)用于有明顯區(qū)別的重要入口，如“加入購物車”、“砸￥1元參與”，“結(jié)算”等等；而間色位置應(yīng)為下方紅框位置，應(yīng)用于不明顯的細節(jié)變化，如文字hover，文字鏈接等；
4）間距
Material Design Guide中已經(jīng)嚴格約束了各個元素狀態(tài)下的間距，但為了滿足全站響應(yīng)式布局在主流屏幕展現(xiàn)，筆者仍然使用了8px原理對一些間距進行了調(diào)整；在很多設(shè)計師研究8px原理并進行設(shè)計的同時，筆者仍然需要強調(diào)，響應(yīng)式web的設(shè)計應(yīng)基于瀏覽器的像素尺寸，并不是基于ios和android的屏幕尺寸。具體可以參考上面已經(jīng)分享的表格進行實驗。
這里分享一些8px的文章，感興趣的同學(xué)可以看一看：
總結(jié)：
Material Design已經(jīng)給出了詳細的設(shè)計細節(jié)和原則，但不一定適合每一款產(chǎn)品，設(shè)計師需要弄清自身的產(chǎn)品是web還是app，邏輯是什么樣，才可以進行細化的設(shè)計工作；深入了解產(chǎn)品邏輯的基礎(chǔ)上，確定的一套響應(yīng)辦法和頁面細節(jié)，能夠保障設(shè)計的展現(xiàn)并帶來不錯設(shè)計效果。Material Design作為即蘋果、微軟之后最新推出的設(shè)計語言，充滿了濃郁的Google風(fēng)情，能夠給用戶提供新鮮的視覺體驗，希望有越來越多的設(shè)計師會嘗試用Material Design進行設(shè)計。
]]>