# Path of web design modularization - 屠澤寬 Jeremiah Kevin Tu

{%hackmd D_yXRZ3kQuiR5RjV0P_kPg %}

> 網站設計跟模組化本身就是衝突的東西

很多時候程式設計師只能靠著外表憑空想像架構等
1. 工程師看問題以功能性導向為主
2. 設計師看問題以外觀配色 樣貌
3. 設計師看問題：宏觀、平衡
4. 溝通管道非常受限

公司往往會需要在工程/設計中 偏向某一邊
偏設計 -> pixel perfect

當工程師針對設計師的提出完全接受時，往往就會陷入 CSS 地獄，包含了一堆 !important 等等

使用!important hotfix會解決一時的問題但造成汙染的累積

和設計師溝通：這個設計是有問題的，告訴設計師這個無法做到

設計會出好多種版本
開發過程中一直改版
到最後的版本跟之前已經有差異

# Style Guide 設計師和工程師的共同語言
1. 定義顏色
2. 定義按鈕
3. 定義字體大小

缺點：
1. 額外多餘的作業
2. 通常會在產品完成之後才會出現
3. 太過抽象
4. 大部分是未完成狀態
5. 完稿的設計會與`設計準則`脫節

# 元件/組件化

[Atomic design](https://medium.com/uxeastmeetswest/%E7%B6%B2%E9%A0%81%E8%A8%AD%E8%A8%88-atomic-design%E7%B0%A1%E4%BB%8B%E5%8F%8A%E5%B7%A5%E4%BD%9C%E5%AF%A6%E4%BE%8B-42e666358d52)

不是設計網頁 而是設計元件
原子化 - 元件切割到最小單位
一個 input 欄位 拆解-> lable + input + button

> [name=Laura] 從設計圖來說，還蠻像 sketch symbols 的概念？
> 設計師切 symbols, 工程師切 component, 可重用 + 版控

wireframe - 網站頁面 由很多元件組成

和傳統的差異
* 傳統
1. 一頁一頁設計
2. 每頁的元件各自獨立
* Atomic design
1. 先定義元件
2. 每一個頁面去使用那些元件
* 最大不同 (Atomic design)
1. 在網站上可以直接 DEMO
2. 所有的定義檔都在網站上，且是單一網頁
3. 減少網站上重複定義的元件
4. 元件順序是大包小，越晚匯入的 css 有著更高的權限 (後面覆蓋前面的 css)

# Q&A

1. 元件引入層級可能會不一樣 要列出很多 demo 用的 module 來讓工程師知道哪種情況引入哪個層級

工程師開發前可以看 demo page 去學習如何使用元件

1. 花多久時間完善 style guide DEMO 網站

看公司策略，用現有的網站去建置，或者是因為太多的技術債，則就是砍掉重做；如果真的要推的話就是從小開始做和其他工程師取得共識。

1. 第一步將網站的顏色統一
2. 當改到按鈕的時候，就會發現真正的問題，例如有 200 多個按鈕 Style

* 大約至少需要半年時間，才略有所成

# Reference

http://vitaluikit.com/
> [name=Laura] 偷安利我們 team 的 open source style guide (css style + react component), 目前新專案用 react 寫, 換顏色客製化很方便. Demo page: https://speed-vital-react.netlify.com/
###### tags: `#FEDC2018`