響應式 Web 設計指南「實踐篇」

不管你是奔赴戰場、跑馬拉松，仍是構建一個響應式的站點，準備工做都是關鍵。

建立一個響應式的站點意味着要考慮多樣化的設備生態系統。

若是沒有適當的準備，你將發現本身會由於缺乏必要的部分而忙裏忙外，而且站點的質量也將受到很大的影響。

 

考慮的因素

做爲任何響應式項目的第一步，都應該是肯定投資這個項目是否有意義。在你作決定以前，這裏有一些值得思考的因素。

若是其中有任何一項形成了嚴重的障礙，那麼也許你應該選擇一個非響應式的實現，至少目前來講是這樣。

 

性能

與有線網絡相比，移動網絡正遭受着顯著增長的延遲和顯著減小的帶寬。即便在小屏幕上隱藏了內容，可是標籤和CSS依然會被下載。

性能是用戶體驗中固有的一部分。若是你並不關心如何構建站點，那麼最終這將致使一個異常臃腫而緩慢的站點。

 

使用環境

你的站點的用戶體驗會根據使用環境的不一樣而不一樣。不一樣的設備能夠在不一樣的環境下完成不一樣的任務。

相反，一個可以在多種設備上表現一致的新站點能夠運行的很是好，是由於其體驗並不依賴於大量的使用環境。

 

內容協商

也許你會選擇去從新組織或者重構站點的內容。比方說有一個頁面有一個內容欄和一個邊欄，若是你將佈局變爲單獨一欄，那麼邊欄就會被擠到整個內容欄的下面。

不少時候，邊欄的內容也許遠遠要比內容欄底部的內容重要。因此若是你不從新規劃內容的順序，那麼頁面的層級劃分就會消失。

 

時間投入

相比非響應式的方法而言，響應式的方法一般都須要更多的前期時間投入。

由於你要考慮大量的具備不一樣能力的設備，還須要去觀察目前已經存在了哪些設備，以及一些特殊設備如何與之交互。

這些時間並無被浪費，在項目開始時失去的時間極可能會在維護成本中獲得彌補。

若是你有時間投身到建立一個高質量的站點中去，那麼你應該響應式地好好思考一下。

 

支持

從桌面端向下構建響應式站點，正如它在大部分狀況下所實現的那樣，會在不少移動設備上形成問題。

取而代之，若是你選擇漸進加強的方式，那麼就能夠避免這些問題。首先爲能力最弱的瀏覽器編碼，而後再使用媒介查詢來逐漸加強體驗。

首先爲能力最弱的瀏覽器構建站點是最明智的選擇，但也不能保證更流行的設備就必定比目前的設備有更強的能力。

 

廣告

響應式站點中廣告的問題，已經再也不僅僅是技術的種種限制了。

解決響應式設計中有關廣告製做和廣告銷售的問題是很是重要的一步，由於廣告商是從廣告的精準投放中獲利的。

大幅的標題欄廣告用在小屏幕設備上是註定失敗的，而響應式的方法可以確保爲每種分辨率的屏幕提供的廣告都是合適的。

 

結論

不管當前咱們的工具及心態有着怎樣的侷限，請不要忽視響應式設計的潛能。

一旦你已經認定了響應式方法對於你的項目來講是合適的，那麼你就要考慮如何來實現它。

當咱們能認真的使用它，並能將其與正確的技術結合在一塊兒時，一個響應式的方法才能夠做爲大部分站點的起點。

 

響應式設計流程

若是你往水裏扔了一顆石子兒，那它便會激起一連串擴散的漣漪，雖然撞擊點很小，但影響波及甚遠。

若是把咱們現有的工做流程比做是水，那麼響應式設計就是那顆石頭，而那一圈不斷擴散着的漣漪，影響着一同工做的方方面面。

 

可交互媒介

是時候轉變一下 「Web是一種靜態的媒介」 的觀念了。Web是靈活的、不可預測的，所以執拗地使用固定的工做流程和靜態的可交付成果並不能幫助咱們挖掘Web的潛能。

不要用那些其實並不存在的限制來約束咱們本身，咱們的工具、技術以及可交付成果應該更好地反映出Web的這一動態特性。

 

協做

傳統的網頁設計流程都是線性的，首先由設計師建立設計稿，一旦經過後便將其轉換爲幾個靜態的線框圖，最後交給開發者去實現。

而在一個響應式項目中，因爲你關注的是如何爲大量不一樣的設備服務，工做流程無疑會變得更加複雜。

你不能指望設計師能預料每一種可能出現的狀況，你也不能指望開發者能百分之百地與設計師設計的每一個交互都保持同步，所以咱們須要一種更高層次的合做。

若是在設計過程當中，設計師和開發者能一塊兒緊密地工做，那麼開發者就能指出其餘可能的情景，考慮就會更加周全。

 

溝通

從項目啓動開始，設計師和開發者就應當參與進來。

經過及早地讓設計師和開發者參與進來，能夠確保頁面與交互之間的一致性，而開發者則能夠在發現潛在問題以前，就將它們指出來。

不一樣於簡單的手手相傳，一種更具協做性的工做流程能使得設計大綱更加成功。

在設計大綱中，應該安排站點在儘量多的設備上進行測試。由於這樣能夠對設計中的任何瑕疵都予以指出，並能夠暗示你應該作出哪些調整來爲給定的設備作優化。

 

迭代

理想狀況下，每次迭代只須要作出很細微的調整，由於對於體驗的輕微調整會相對容易。

這聽起來也許很是耗時，的確是這樣，但這對於確保最終的產品可以給用戶帶來溫馨的體驗，也是相當重要的一步。

 

尊重

若是項目中設計師和開發者之間缺少彼此尊重，那麼整個過程也會失敗。

咱們會憑藉已有的一點知識走很長的一段路。尊重，正如它所表現出來的那樣，你很難將它給予那些你不瞭解的事物。

若是你是一個設計師，那麼就去花點時間在編程上，這將使你更加深刻地瞭解開發者們的工做。

一樣，做爲一名開發者則要去探索一下那些設計概念，這樣能夠幫你意識到設計遠遠不僅是漂亮的顏色和字體。

 

與客戶協做

協做不該該僅限於內部，它也一樣應該擴展到你與客戶的來往當中。讓客戶儘早地加入進來，而且從始至終都要讓他們成爲項目中的一部分。

若是在整個過程當中都能讓客戶參與進來的話，那麼大家之間的關係就會變成一種團隊合做。客戶與設計團隊之間的那堵牆便轟然倒塌了，雙方的意見均可以被對方聽到，並且每一項提出的解決方案都會有來自雙方的貢獻。

 

系統方式思考

一個站點須要有一致性，不但包括頁面與頁面之間，並且還包括設備與設備之間。

要想得到一致性，就須要以系統的方式來思考問題。經過考慮單獨的組件，能夠將它們從頁面中解耦，並迫使咱們思考這些組件應該如何一同工做。

先考慮站點中單獨的組在不一樣的環境中要如何運行，而後考慮這些組件如何能統一地建立出一種廣闊的體驗，這些對於任何響應式項目的成功都相當重要。

 

優先考慮手機

手機在爆炸式地增加：

　　隨着設備數目的激增，愈來愈多的人們開始只使用移動設備來訪問互聯網。在有些國家移動平臺已經佔據了主導地位，所以優先考慮移動平臺是頗有意義的一件事。

手機迫使你專一：

　　移動設備大都只有一個很小的屏幕，這意味着能往裏面填充的內容頗有限。優先爲手機設計能夠迫使你專一於弄清楚哪些內容是最重要的。

手機豐富的能力：

　　移動設備開始加裝愈來愈多的傳感器，雖然目前還不能從瀏覽器中訪問到，但放眼將來，咱們能夠利用這些傳感器建立出更好的體驗。

 

線框圖

若是從一開始就建立一個高保真度的原型，那麼要從完成的設計中看出以前的顏色或樣式將會變得很是困難。可是若是能從建立一個低保真度的線框圖開始，那麼一切就會變得很容易。

一般狀況下，線框圖不會包含顏色、字體或者圖片。畫線框圖的目的並非爲了演示站點佈局，而是爲了幫助肯定頁面結構，其中包括將會顯示什麼類型的內容，以及這些內容有着怎樣的優先級。

要儘量地讓你的線框圖保持簡單。線框圖的保真度越高，你遇到的阻力也就越大，線框圖的保真度越低就越容易讓人專一於頁面的結構、層次和行爲。

 

模型

是時候放棄「像素級精確控制」的那種渴望了。不完美是件好事，不完美能催生各類特質並帶來可塑性。

靜態模型存在着大量的問題，對於設計最終將會如何呈現，它只能給出很是有限的預測。

在瀏覽器裏設計可以更好地演示當用戶與頁面上的元素交互時所發生的一切，另外一個好處是可讓咱們專一於內容和結構。

對於許多設計師來講，在代碼中工做讓他們失去了創新和試驗的能力。不過在理想的工具出行以前，最重要的是學會放棄對圖像編輯軟件的依賴。

 

樣式嚮導

爲了可以對整個項目有所幫助，你須要建立視覺樣式嚮導以及相應的模式庫。

這樣作不但能夠確保站點能夠維持一個統一的視覺外觀，並且代碼也能維持統一的樣式，這在很大程度上簡化了後期的維護。

一份良好的視覺參考除了要包含站點內各個元素的樣式以外，樣式嚮導還應該提供特定的元素要在何時以及如何被使用的信息。

樣式嚮導正變得愈來愈流行，其中最爲著名的就是 Twitter 的 Bootstrap。有了這樣一份資源，即便對於新手開發者來講，快速開展工做也會成爲一件容易的事。