摘要:創建可維護的設計規范為什么需要相信團隊工作中,不管是前端還是設計師都有被視覺統一問題折磨過的美好經歷。所以在這,我先略過視覺稿,直接來說如何創建一分靈活可維護的設計規范。
創建可維護的設計規范(Living Style Guide) 為什么需要 Style Guide
相信團隊工作中,不管是前端還是設計師都有被 “視覺統一問題” 折磨過的美 (dan) 好 (teng) 經歷。特別是在中大型、復雜的 web 項目中,很可能存在以下問題(你能對號入座幾個呢⊙﹏⊙‖):
Style Guide 應該是什么樣子整個項目有上百種不同的顏色。但其中大部分顏色的 16 進制值卻非常接近。原因在于,開發甚至設計師使用吸管工具提取顏色值,這很容易照成誤差。
不同的開發,對組件的命名可能不一樣,比如按鈕,有 ‘btn’、有 ‘button’ 等等。加上第一點的問題,造成 css 中諸多長得差不多,但不能復用的代碼。
不同的設計師,風格也不相同,同一個表單今天是這個樣子,明天它媽都不認識了。而苦逼的開發,要重新還原設計稿。
整個站點的交互,色彩,看上去總是不那么協調。
顯然,如果沒有一個設計規范(Style Guide),項目會越來越難以拓展,不可維護。那么制定一個設計規范就很有必要了。
一個合格的設計規范,至少需要滿足 3 個方面,以下我以 github 的設計規范 Primer 為示例,一個個說:
一個具備美感的網站,并不是色彩越多樣越好,我們一般需要定義網站多主色調。
重要的是,定義好色值后,就愉快的可以用 sass 之類的 css 預編譯,設置變量了。 (=^ω^=)
比如 github 多主色調,是藍色
設計規范應該定義出 web 項目常用的組件:比如 按鈕、 彈框、表單、側欄、導航等等。以便復用 (關鍵是設計時就要復用)。
定義好設計風格和各種組件后,要做的就是讓各位開發和設計童鞋按規范使用了。 使用文檔必須寫明色彩具體值、組件的結構、css 命名等,如果有 js 組件,也要寫好 js 的 api 文檔。
Style Guide 確實有價值,但也需要一定成本(構建成本、維護成本、推廣及學習成本)。那什么情況下需要自己創建 Style Guide?我們可以假設幾個場景:
你在一個靈活敏捷的小型創業團隊,產品迭代快,變動大。(規范跟不上變化)
你一個人或者就幾個人負責一個項目,凡事可以隨時當面溝通。(溝通成本小)
你的項目偏向展示性,內容絢麗多樣,定制化強。(組件復用性低)
簡單來說,如果創建自己的 Style Guide ,成本大于效益,那我們就沒必要大費周折搞這些了。
另外,很多時候我們可以直接用 第三方 UI 庫 (碼農福音  ̄▽ ̄),它們的文檔其實就是一份 Style Guide。而且文檔完善,考慮周全,易于學習。比如 Ant Design、Element、Angular Material 等等
到這,你還覺得有必要自己創建一份 Style Guide 的話,請繼續往下看。
創建 Living Style Guide按說設計規范應該由設計師和產品一起定制好視覺稿,前端?們再根據視覺稿書寫規范。所以在這,我先略過視覺稿,直接來說如何創建一分靈活可維護的設計規范(Living Style Guide)。
我們需要 node 環境 , 以及 kss 這個工具。kss 可以根據 css 里面的注釋,生成 Style Guide 的文檔。
簡單說下用法:
第一步,先安裝 kss
npm installl -g kss
第二步,創建一個文件夾,然后下載 kss 的 demo。
mkdir kss-demo cd kss-demo git init git clone https://github.com/kss-node/kss-node.git
安裝依賴
npm install
然后打開 demo 文件夾,我們可以看到如下結構,kss 就是根據里面的配置內容,生成 Style Guide
demo - components // 定義組件 - buttons.hbs // 編寫 html 示例結構 - buttons.less // 編寫組件樣式 - forms // 定義組件 - homepage.md // 文檔規范內容 支持 markdown - kss-config.json // 配置文件 - kss-headings.less // 規范文檔的樣式 - mixins // less 方法 - preview.png - styles.css - styles.less
我們可以用 demo 來改動下,文件夾改名為 my-style-guide (隨意) 做成我們自己想要的內容,然后
kss --source my-style-guide
kss 工具就會幫你創建一個styleguide文件夾。里面是 Style Guide 的內容了。配置跟生成出來的內容,關系如下(簡單畫畫圖,詳細內容,請下載研究)。
less(當然 css 和 sass 也可以) 里面的:
注釋 => 編譯成文檔說明
less 的樣式 => 組件的樣式(button 等)
hbs 文件里的內容 => 組件的結構 (使用了 handlebars 模板引擎)
這么一來,簡單的 Living Style Guide 就創建好啦(鼓掌)。
另外 github 上也復雜些的 kss 相關模板。
kss-node-template、 kss-node-template-such-as-github
不過真正項目里,應該如何定義色彩、風格之類的呢。這就要找設計師啦。哈哈哈。
在嘗試性使用 kss 的過程中,個人感覺有些不足之處,或者說麻煩之處。
比如 kss 生成的文檔說明,全部寫在 css 里,并且要遵循 kss 的語法,而在 css 里寫 Markdown ,也蛋疼。這增加了學習和編輯的成本。
kss 中 Style Guide 的組件結構,需要寫在另一個文件,還用了模板引擎,這樣維護起來不方便。
在和團隊童鞋探討之后,我們決定放棄使用 kss,不過他提出了個簡單版思路,有興趣的童鞋可以嘗試下:
大部分的文檔內容用 md 來編寫,組件的結構寫在該 md 文檔的 code 里,css 則跟 md 文檔同名, 這樣,工具就可以根據文件名為索引,生成對應的 html 文件,再組織這些生成的文件,拼成完整 Style Guide。
比如:components // 定義組件
|----buttons.md // 編寫 html 示例結構,和文檔
|----buttons.css // 編寫組件樣式
這樣,寫起來舒服,維護起來也舒服些。如果大家有更好的思路方案,歡迎拍磚探討!
周末大放送:
最后,給設計師童鞋們推薦個可以根據設計稿,從 Sketch 生成 Style Guide 的插件。一樣牛逼烘烘!
Craft 是一套面向 Sketch 和 Photoshop 的插件組,幫助你簡化設計流程中的自動化填充,提升工作流效率,將注意力集中在設計本身。作為一個工具套件,Craft 包含下列工具:
批量復制:快速復制重復圖層,并方便調節間距、數量等。
樣式庫:在 Sketch 中生成一個 StyleGuide。它使一個新的頁面有不同的調色板,字體,文本樣式和自定義元素,您可以建立自己。與你的團隊分享和同步整個庫。
智能圖庫:支持 Dropbox,unsplash,本地文件夾,或 Web 頁面上調取圖片到 Sketch 畫板中。
數據:帶來真正的文本,圖像,JSON 等內容到你的 Sketch,無需花費時間進行模擬數據。
其中的樣式庫功能,就可以方便的生成 Style Guide:
另外這款插件絕不是一個內容生成器那么簡單。它可以幫助你擺脫「Lorem Ipsum」,使用真實的產品數據進行設計,這對設計師來說簡直太重要了!具體的操作辦法可以去他們的 官網 看視頻教程。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/115381.html
摘要:可能很多人和我一樣首次聽到前端架構這個詞第一反應是前端還有架構這一說呢在后端開發領域系統規劃和可擴展性非常關鍵因此架構師備受重視早在開發工作啟動之前他們就被邀請加入到項目中而且他們會跟客戶討論即將建成的平臺的架構要求使用還什么技術棧內容類型 可能很多人和我一樣, 首次聽到前端架構這個詞, 第一反應是: 前端還有架構這一說呢? 在后端開發領域, 系統規劃和可擴展性非常關鍵, 因此架構師備...
摘要:可能很多人和我一樣首次聽到前端架構這個詞第一反應是前端還有架構這一說呢在后端開發領域系統規劃和可擴展性非常關鍵因此架構師備受重視早在開發工作啟動之前他們就被邀請加入到項目中而且他們會跟客戶討論即將建成的平臺的架構要求使用還什么技術棧內容類型 可能很多人和我一樣, 首次聽到前端架構這個詞, 第一反應是: 前端還有架構這一說呢? 在后端開發領域, 系統規劃和可擴展性非常關鍵, 因此架構師備...
摘要:可能很多人和我一樣首次聽到前端架構這個詞第一反應是前端還有架構這一說呢在后端開發領域系統規劃和可擴展性非常關鍵因此架構師備受重視早在開發工作啟動之前他們就被邀請加入到項目中而且他們會跟客戶討論即將建成的平臺的架構要求使用還什么技術棧內容類型 可能很多人和我一樣, 首次聽到前端架構這個詞, 第一反應是: 前端還有架構這一說呢? 在后端開發領域, 系統規劃和可擴展性非常關鍵, 因此架構師備...
摘要:前端規范在實際開發中,由于團隊成員編碼習慣不一,技術層次不同,開發前定制并遵循一種代碼規范能提高代碼質量,增加開發效率。是定義了一種的命名規范,每個名稱及其組成部分都是存在一定的含義。 前端規范 在實際開發中,由于團隊成員編碼習慣不一,技術層次不同,開發前定制并遵循一種代碼規范能提高代碼質量,增加開發效率。 Javascript Javascript規范直接參考airbnb: ES6 ...
閱讀 3518·2021-11-17 17:01
閱讀 3927·2021-11-08 13:12
閱讀 2482·2021-10-08 10:04
閱讀 695·2021-09-29 09:35
閱讀 1425·2021-09-26 10:12
閱讀 2040·2021-09-07 09:58
閱讀 1958·2019-08-30 15:55
閱讀 2139·2019-08-30 13:14