網站設計分析：漫談回應式設計 交互上的那些不同

仲介交易 SEO診斷 淘寶客 雲主機 技術大廳

1. 如何理解回應式設計(RWD)

學究一些，首先大家先瞭解一下回應，然後再講一下設計，回應就是我發出的請求能得到什麼樣子的回復，比如我說「你好」，你會很容易的給我回復「你好」，因為大家都是中國人，如果我說「hello」，我們這代人如果上過初中， 他也會給我說「Hello」，但是如果我給對你說「Bonjour」，那可能只有高配的人才可能知道了。 這裡面，就舉了一個例子，我的應答物件就相當於我們要講的回應式的設備，他必須能夠解析我發給他的需求。 然後咱們再講一下設計，設計的官方解釋是這樣的：

1.設下計謀。

2.根據一定要求﹐對某項工作預先制定圖樣﹑方案。

3.指搞設計工作的人。

直白的講，設計其實就是設了一個計，來完成我們的需要的工作目標。

從前面我們講的回應可以看到，回應是雙方的，是互動的過程，在這個過程中我們要考慮雙方的承受能力，比如我們總不能讓小孩子扛大包。 在咱們網頁設計方面就是咱們要考慮設備的性能，從網速、Dom-節點數量、螢幕的大小等等，如果我們從前後端結合，對小孩子給糖果，給苦力大包，那樣就做到了回應式。

但是，我下面講的回應式是狹隘的，我們只是從 Web Builder 這一層做到了回應式。

2.回應式設計中的介面設計

對於介面設計，我們以前針對桌面產品的設計可能就是一個尺寸的，每個模組的位置比較固定，但是在回應式設計中，這些東西就改變了，設計師會根據產品的需要設計多個版本的設計，在這些不同的版本中，模組A在1024的寬度下， 可能會是黑色背景，但是到了768下面可能會變成白色背景，實現了在不同寬度的不同展現。 這裡面顏色、背景、寬高等都可改變，但是有一點我們需要注意的是 DOM 節點的順序最好保持一致，因為在回應式的頁面中，我們會使用流式佈局，在固定版式通過絕對位置或者外邊距負值的方式改變DOM 順序和視覺順序的技巧， 在這裡可能並不適用。

3.針對媒體查詢的中斷點

我們知道，我們通過媒體查詢(Media Query)的方式改變網頁的佈局，我們在哪些寬度下改變佈局，也就是我們所稱作的中斷點，我們更習慣的思維是針對某些設備(比如桌面、平板電腦、手機)的資料來設置中斷點，比如 1024 對應桌面、 768對應pad、480 對應手機，但實際上，這些東西是靠不住的，因為這些螢幕尺寸會根據時代的發展不斷的變化，我們的回應不應該只針對某些設備，我們需要的是一個區間值，而不是將某一解析度對應一種設備。 中斷點肯定是需要有的，那這些中斷點是如何設置的呢?怎麼才能不是為了中斷點而中斷點呢?實際上，這些中斷點的設置都是根據內容的需要做的，當我們的內容在達到一個臨界點後，視覺效果不符合人們的審美或影響了內容獲取時，這就是我們需要的中斷點。 但是我們可能無法在視覺設計的階段就能覆蓋其尺寸區間內容所有狀況，這樣我們就需要把它和現有的設備相結合確立中斷點。

因此，個人認為不同的專案，在回應式設計中需要的中斷點是不一樣的。 我們知道在媒體查詢中有 width 和 device-width 兩個特性，因為在手持設備中多數用到的是 webkit 內核的瀏覽器，我們一般會通過 viewport 的屬性，將設備寬度賦予視窗的寬度

這樣我們就能根據設備的寬度來對某些設備做媒體查詢了。

@media screen and (max-device-width:480px){ selector{ } }

4.交互上的那些不同

在回應式設計中，我們不僅要考慮以前桌面使用者的使用習慣，也必須兼顧不同尺寸的手持設備。 比如大家在PC上習慣使用的浮層在某些小尺寸的設備上就沒法使用了，就像我們下圖中看到的。 而且一些回應區域小的連結也不方便我們使用手指來操作，因此我們可以做到「求同存異」。 比如我們根據螢幕的尺寸，來決定是否使用浮層、或者增大操作區域、或者「整齊劃一」。 比如在新浪視頻專案區別設備來使用浮層，將所有的連結的操作區域做成方便手指操作的大小。

5. 具體專案開發流程

5-1. 產品策略與資訊架構

在我們介入具體專案開發流程前，我們應該已經確認了自己產品所面向的內容消費群體，以及潛在目標使用者，比如簡單的只面向小螢幕的移動使用者群或者我們要囊括所有的顯示裝置(mobile、pad、pc等等)。

當我們確定目標使用者的內容消費習慣的同時，我們應該也對他們的訪問習慣、時段等等做一些初步分析。 這不僅僅面向一個回應式網站，這對產品定位到開發都有決策作用。

在移動博客專案前期的產品分析中我們能看到，隨著時代的前進使用者內容的消費習慣也在發生著變化。

而訂閱設備的變化是在從PC迅速的向phone、pad進化，所以我們更有必要提高行動裝置的閱讀體驗來提供面向移動使用者的回應式網站。

當我們確定了以上的群體以及習慣後我們就要針對這類群體對產品自身做架構調整了。 產品架構或者內容架構在不同使用者不同設備間影響著內容資訊的可用性和可尋性，並且回應式一定會在不同解析度不同設備上對頁面中的模組重新調整，以符合不同模組在不同設備中所符合的優先順序

5-2. 回應式產品設計

回應式設計是從產品角度來進行的設計，在這個階段我們需要產品經理、交互設計師、設計師以及工程師共同介入了。 我們需要打破傳統的思維模式去思考設計，從純粹傳統的Web向移動應用過度。 通過我們第一步明確的資訊架構，來從最小顯示幕的行動裝置做產品設計，在行動裝置中拋棄更多的使用干擾，保證核心功能的最優體驗;同時交互與設計師的介入處理如何把模組設計的更小更有彈性，並初步確定設計風格、設計框架等方案; 而工程師需要在產品經理與設計師確定的方案中進行代碼測試，充分利用不同設備獨有的特性並進行框架搭建。

5-3. 回應式開發

雖然在上一步我們提到從最小顯示幕的行動裝置做產品設計，但實際不論是設計師還是工程師都是從最複雜的桌面端開始，把表現最豐富最複雜的功能實現，做減法對結構的改動會適當的減少。

移動博客專案的前期開發其實是一個與產品、交互和設計師邊測試邊溝通邊確認不斷迴圈的過程，因為在不同的設備中內容的呈現及某些特性的支援都不同，有些是與我們的預期有出入的。

對我們頁面製作工程師而言，在只有桌面端的時候，我們面向的設計稿是單一的，但是到了回應式設計，這種情況就改變了，雖然說我們可以讓設計師根據我們產品的受眾總結的螢幕寬度中斷點給予幾個版本的設計稿， 但是這些設計稿並不能覆蓋我們使用者的所有設備情況，比如我們縮放瀏覽器的時候，從1024到320之間，包含了太多不同解析度的設備。 因此，在此開發過程中我們需要不斷的和設計師溝通在設計稿無法覆蓋情況下的特殊狀況。

在後面的文章中我們會具體介紹在新浪視頻專案和移動博客專案開發中我們踩過的坑，以及一些問題的解決方法，敬請期待......