做 VALSE 2016 網站的時候，沒有設計師的參與。在這種情境下要做出網站，只好考慮從功能性出發寫網站，而在這個過程中，開始思考前端工程師的工作起點到底是不是設計稿，并以此看到了可能可以 讓前端工程師脫離設計師直接寫網站 的可能性： 從功能性出發的網頁構建 。

優勢在于快速建站。前端工程師可以脫離設計師直接接觸甲方，根據功能需求直接寫代碼構成功能模塊組合之后建站。

劣勢在于裝飾性的缺失。雖然實現功能性之后能做一些裝飾性的工作加以彌補，但是這樣的設計缺乏整體考慮。算是速度與設計質量之間的角力。

核心有三點：模塊化（跟響應式直接相關）、功能優先（原型線框圖？）、一致性（字體、LOGO、前端自然模塊（navooter））。

有沒有網站不需要設計？

大概在去年9月的時候，接了一個做 VALSE 會議網站的項目。項目的 deadline 是“盡快完成”。在這樣緊迫的情況下出現了一個問題：找不到設計師。被逼無奈只能硬頭皮上了，一把甲方的需求弄清楚，就開始寫代碼。具體的做法就是：需要10個頁面？好，那我就寫個 10 標簽的導航。需要會議新聞？那我就寫個新聞的塊兒出來。需要會議位置？那我就添加一個地圖插件指向會議地址。需要注冊頁面？那就寫表單咯。就這樣一塊兒一塊兒地寫，最后形成了 VALSE 2016 的網站 。同樣的理念，還做出來了另外一個會議的網站： SIDAS 2016 。

現在回頭想起來，覺得有這樣幾個問題：

• 站在使用者的角度看，這樣一個以功能性為重的 會議 網站，設計是必須的嗎？

• 站在網站前端的角度看，前端工程師的工作的起點真的是設計稿嗎？

第一個問題我覺得是能肯定的，設計對于一個會議網站來說絕對不是必須的環節。直至今天，很多國際會議都難說有設計過： ECCV 2016 。

第二個問題，前端工程師的工作起點我認為不是設計稿，而是功能性。當拿到一份設計稿的時候，我第一時間能看到的是圖漂不漂亮，但是這并不足以讓我寫出來一個網站，我需要快速讀懂設計師想說的意思：“這一塊是導航欄，這一塊是 banner，這一塊是頁腳”。并以此用上相應的語義化標簽：“nav、footer、article”。所以設計稿給我們傳達的絕對不只有這個東西長什么樣子，更有 這是個 什么東西，換句話說，是告訴我們這個東西的 功能 。

說到這里好像我是自相矛盾：明明說不認為設計稿是起點，但是前面說的話都是在說設計稿。那我們從設計師的角度來看，他們的工作起點是什么？是甲方的需求，是這個東西要實現些什么。那他們的工作是什么？是把抽象的需求，具化成產品功能，并用圖片來描述產品功能，方便前端實現。對于一個前端工程師來說，如果你只知道設計稿漂亮，而不能理解設計師想要傳達的具化后的功能性的話，那你永遠不會用語義化標簽。因此，前端工程師的工程起點是功能性。

進一步想，如果一個前端工程師跨過設計師具化需求為功能這個過程，直接接觸需求，結果會怎樣？腦洞開大一點：做出來的是一個長得像線框圖原型的網站......（感覺這里有個莫名的笑點）

回到之前我遇到的問題：沒有設計師，只有前端工程師的話，怎樣做出來一個還能看的網站？

我覺得是 從功能性出發的網頁構建 ：用 模塊化 的方式，依照 功能性優先 的原則先寫出來一個原型圖一樣的網站，最后再通過一些保持 一致性 的技巧讓使用者認為這是一個網站的多個頁面，而非多個網站（又一個奇怪的笑點）。

通過這段描述會發現，從功能性出發的網頁構建的優勢在于快速建站，前端工程師可以脫離設計師直接接觸甲方。劣勢在于裝飾性的缺失。雖然實現功能性之后能做一些保持一致性的裝飾性工作加以彌補，但是這樣的設計缺乏整體考慮，算是速度與設計質量之間的角力。

模塊化

根據甲方需求，細分成功能之后，每個功能其實就是一個 div 標簽（或者其他語義化標簽）。

以會議網站為例子，其實已經有一套固定的范式，從會議需要幾個頁面，每個頁面需要放什么東西，每一年的需求其實是一樣的，從需求到功能這個過程已經被以前的網站做過了，這個時候前端要做的事情就是根據以前的功能模塊去粗取精，然后開始 coding。

一個功能模塊就是一個 div 的做法其實是自然的。響應式設計開始成為趨勢之后，網頁的設計變得同質化，長得都跟 Boxify 大同小異。

為了方便做響應式，大部分響應式模板都少有左右排版，大多是從上至下的排版。這其實給前端工程師按照需求寫網站帶來便利：新增的模塊直接添加就可以，不需要考慮過于復雜的重排問題。Boxify 是一個很典型的響應式網站，每個橫條色塊承擔起一個單一功能。

對于前端工程師來說，接到需求的第一步是明確和細化需求。細化后的需求對應起一定的功能，最后根據這些功能從上至下一塊兒一塊兒寫。

功能性優先

按照上一步做，呈現出來的很可能是難看的，因為不帶有設計，出來的頁面會簡潔到可怕。就我自己來說，每次到這種時候都會覺得蛋疼，因為審美的天性不允許自己寫出來這么丑的頁面。但是為了快速實現需求，從始至終都應該堅信自己是在做正確的事情，更直白一點，功能性對我們來說是最重要的，再丑也要堅持把功能實現了再說。

保持一致性

保持一致性是站在用戶角度思考得來的需求。

完成了功能性的網站是一個 可用 的網站，但是并不代表用戶 愿意用 。拋開會議網站這種不管我做多丑你都得用的情況，其他情況下的網站設計中，美觀是一個要素。

當一個網站的 10 個頁面都按照上面功能性優先的原則完成之后，得到的是丑丑的線框圖。然而，遵循一些很簡單的一致性，就能輕易地讓用戶產生“這 10 個頁面是一個網站里面的”這樣的想法。同時在保持一致性的過程中，也對網站進行了一定的美化。

對于一個網站下的多個頁面來說，它們天然就具有一致性：

• 一樣的 nav 導航欄和footer

• 一致的網站的主要配色

• 一致的特殊字體

實際上，只要做到這三點，網站的大部分元素都會按照這三點更新一遍。而更新之后的網站距離丑又遠了一步。

以 SIDAS 2016 網站為例。

• 一樣的 nav 導航欄和footer：nav 統一采用 Bootstrap 默認的響應式 nav。左側放上會議名稱作為 LOGO（因為會議沒有 LOGO 啊 ?_?）右側是導航的幾個頁面。footer 根據需求需要放上導航鏈接、其他會議鏈接、會議主辦人員聯系方式和社交管道，因此做成 4 個 div，豎放。




• 一致的網站的主要配色：#f60c3e

• 一致的特殊字體：使用 dosis light 免費字體作為網站主要內容（如標題和會議介紹內容）的字體；其他字體優先使用 helvetica。

除了這三點之外，還有很多細節可以美觀和優化。例如為了節省版面，將幾個較少內容的模塊合并起來；長頁面添加回到頂部按鈕；hover 動效等等。

從功能性出發的網頁構建，將功能性放在裝飾性前，對于需求急迫的項目來說可能是一種解決方案。應用這種構建方法，已經成功地做成了 VALSE 和 SIDAS 兩個案例。對于那些沒有設計師幫助的前端工程師和想嘗試拋棄掉設計師做一個項目的前端工程師，不妨嘗試一下。

作者署名：Hongyang Wang

版權聲明：自由轉載-非商用-非衍生-保持署名 | Creative Commons BY-NC-ND 3.0

當前標題：前端開發工程師眼中網站設計的功能性
文章網址：http://vcdvsql.cn/news39/104089.html

網站建設、網絡推廣公司-創新互聯，是專注品牌與效果的網站制作，網絡營銷seo公司；服務項目有網站設計等

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯