都說2013年將是響應式設計爆發的一年。一淘設計團隊在去年一淘首頁改版時初步嘗試了響應式,最近在一淘「玩客」項目中有了更加深刻地應用,第一次在複雜產品中實現了全站響應式。中間積累了一些經驗也踩了很多坑,因而就有了這個響應式設計三部曲,此係列文章包含理念篇、知識篇和流程篇。前端
響應式網頁不像傳統網頁只需考慮一種狀態,不是交付一套設計稿就完事兒了,它給設計、前端和開發團隊之間的協做模式帶來新的挑戰。在一個複雜產品全 面響應式的項目裏,交互每一個階段該產出什麼?交互與視覺如何協做?前端什麼時候介入?哪些事情讓後端開發來作更合理?經歷「玩客」初版後,咱們獲得了一些答 案。後端
響應式設計之因此叫響應式「設計」而不叫響應式「技術」,是由於它是一項設計先行的工做。須要設計先明確好響應方式再實現出來,不能出一套設計稿後 等着前端看狀況把它變成響應式網頁。因此整個流程最初從交互階段開始,分紅6個主要步驟,視覺、前端、開發等角色根據狀況儘早介入。
架構
Step1:信息架構,肯定內容策略。框架
根據產品定位和用戶分析,交互設計師肯定站點信息架構。(信息架構呈現方式有不少種,這不是本文重點,不詳述)。工具
這時候能夠明確這個產品有多少頁面,每一個頁面包含多少內容,內容優先級是什麼。不少產品包含N多頁面,每一個頁面一一考慮響應式設計容易形成混亂且成 本巨大。因此下一步重要工做是分析頁面類型把頁面歸類。以玩客爲例,能夠把10多個頁面分紅三類:列表類頁面、詳情類頁面、操做類頁面。佈局
Step2:移動框架性能
先說下爲何第二步要先設計移動框架。移動優先是移動互聯網浪潮下應運而生的理念,由Luke Wroblewski最先提出。移動優先並非指移動更重要,響應式設計理念裏設備是同等重要的。它是指優先設計手機端的體驗,有三個緣由:測試
從移動開始作設計對習慣了PC環境的設計師多是一種挑戰,思考方式工做習慣都被迫作出改變。但這種改變必須去適應,由於用戶習慣在改變。優化
回正題,上一步已經把頁面歸類並肯定每一個頁面內容優先級,如今接着分析每種類型頁面的導航、主體內容等框架結構,最終得出一份框架結構表。從玩客框 架結構看出,全局導航是全部頁面公共的,局部導航只有列表類頁面纔有,詳情類頁面都有一個「頁面主人」信息,而關聯導航不是每一個頁面都有。設計
接着開始設計手機端「超細長頁面」的框架(由於手機上通常是單列布局,因此頁面又細又長)。這一步開始把信息結構設計成最粗放的框架,能夠在白板或 紙面上完成。要實現的關鍵目標是:把這個頁面最須要呈現給用戶的內容放在最重要的位置,要符合手機上的閱讀和操做習慣,儘可能利用手機設備的特性。
Step3:響應式框架
根據手機端的框架拓展出平板和PC端框架。這是複雜產品實現響應式設計的關鍵步驟,它是讓衆多頁面有條理地響應起來的基礎。第一件事情是肯定響應式 模式,即從手機到平板到PC,導航怎麼變化,頁面佈局用哪一種響應方式,根據內容優先級如何調整模塊順序,等等。玩客在PC端以三欄佈局爲主,左邊欄做爲局 部導航或者主人信息區,中間欄始終是頁面主體信息,當頁面須要關聯導航時統一放在右邊欄。
到如今這個階段全部頁面的響應式開始有規則可循,下一步工做就是繼續細化規則,把框架精確到具體尺寸。具體說來就是制定流體柵格系統。流體柵格系統是基於百分比的柵格佈局工具,具體的制定方法會在另一個篇章【知識篇】中詳細介紹。
響應式是一種設計理念與前端技術緊密結合的新興形態,鼓勵儘早進行跨職能溝通協做。交互肯定響應式框架和柵格系統後,其餘角色就能夠同步開展工做 了。前端開始介入完成柵格和框架搭建,產出頁面基礎框架。視覺同步開始探索和定義視覺風格探索,制定視覺框架,產出風格關鍵詞、產品配色方案。整個過程需 要幾個角色不斷討論肯定。
Step4:模塊設計
按照移動優先的原則應該先進行移動端的模塊細節設計,不過咱們選擇了從PC端開始設計細節。由於PC端開發可以充分暴露業務複雜度,項目團隊的設 計、開發、測試在PC環境下擁有成熟的工具和流程,從PC開始讓開發過程更順暢。因此我的認爲移動優先是肯定內容策略時應該遵循的理念,細節設計和開發過 程是否要移動優先,取決於產品定位和項目團隊狀況。
響應式框架肯定了頁面結構和響應模式,模塊設計這個過程開始完善全部信息排版和交互形式,這是交互設計師最熟練也是最耗時的工做。這個過程與傳統流程沒太大區別,只是內心要不斷提醒本身,這個模塊不是隻爲這個設備設計,它在其它設備下會出問題嗎?
交互肯定頁面模塊細節後能夠抽取出產品用到的控件、組件和公共模塊,如今視覺和前端開始作一件有別於傳統流程的事情。視覺根據前期定義的風格設計控組件和公共模塊的視覺效果,把它們拼成一個模擬的頁面,咱們稱之爲風格拼貼稿。前端再把風格拼貼稿裏的控組件和公共模塊實現出來,統一維護一套組件規範代碼。
傳統的作法每每是頁面視覺定稿後設計師開始整理視覺規範標註給前端。風格拼貼稿是將這個工做盡量提早,並變成一個設計協做利器。它的好處是:
一、一個頁面的視覺效果其實是由一堆控組件和公共模塊組成,用真實的控組件和公共模塊拼貼的模擬頁面已經能夠呈現出產品的視覺風格。把一個產品10多個頁面的視覺稿所有完成定稿是很是費時費力的事情,產出一份風格拼貼稿則輕鬆得多。因此它是一個高效的設計工具。
二、複雜產品老是涉及多個設計師和前端並行工做,儘早地把控組件和公共模塊抽取出來統一管理,是保證視覺風格一致性的有效方法。避免不一樣設計師同時 設計同一個控組件或公共模塊,減小重複開發形成的浪費。也大大下降後期更新和維護頁面的成本,好比當須要修改「關注」按鈕時只需改一個就能全站生效。
Step5:響應式模塊設計
PC端頁面模塊細節和風格拼貼稿完成後,剩下工做是拓展出平板和手機端的完整設計稿,前端產出所有響應式頁面代碼。進行響應式模塊設計時最須要關注的仍然是讓操做符合設備習慣,充分利用設備特性。
至此,一個全站響應式產品的頁面就陸續出來了。不少人認爲響應式設計維護成本高的理由是一個頁面要同時設計多套設計稿。玩客此次經驗告訴咱們,肯定一套設計稿和柵格系統後再拓展出其它設備下的設計方案,工做量遠比想象中的低。
Step6:測試&討論&優化,提交開發
離大功告成還差最後一步,在真實設備下測試頁面效果,項目團隊討論並持續優化。
在提交開發以前須要儘早明確服務端響應(RESS) 的策略。服務端與客戶端結合是目前解決響應式頁面性能問題的最合理方案。哪些大圖片在移動設備下只需輸出小尺寸圖片?哪些內容在什麼設備下是不須要開發輸 出的?哪些能夠減小輸出的數據數量?與開發團隊協做的響應式能夠有效控制頁面文件大小,避免頁面成爲移動設備上燒用戶流量的罪魁禍首。
測試經過後提交頁面進入開發環節。咱們從可用性和可訪問性兩方面總結了一份響應式頁面測試checklist,測試要點包括但不限於如下內容。歡迎補充。
結語
以上流程是咱們團隊作完一個全站響應式項目後集體總結得出,無論你是對響應式感興趣、正在作響應式,仍是即將開始作響應式,但願對你有所幫助。
轉載自: http://ued.taobao.org/blog/2013/05/%E5%A4%8D%E6%9D%82%E4%BA%A7%E5%93%81%E7%9A%84%E5%93%8D%E5%BA%94%E5%BC%8F%E8%AE%BE%E8%AE%A1%E3%80%90%E6%B5%81%E7%A8%8B%E7%AF%87%E3%80%91/