资讯专栏INFORMATION COLUMN

创建可维护的设计规范(Living Style Guide)

sutaking / 726人阅读

摘要:创建可维护的设计规范为什么需要相信团队工作中,不管是前端还是设计师都有被视觉统一问题折磨过的美好经历。所以在这,我先略过视觉稿,直接来说如何创建一分灵活可维护的设计规范。

创建可维护的设计规范(Living Style Guide) 为什么需要 Style Guide

相信团队工作中,不管是前端还是设计师都有被 “视觉统一问题” 折磨过的美 (dan) 好 (teng) 经历。特别是在中大型、复杂的 web 项目中,很可能存在以下问题(你能对号入座几个呢⊙﹏⊙‖):

整个项目有上百种不同的颜色。但其中大部分颜色的 16 进制值却非常接近。原因在于,开发甚至设计师使用吸管工具提取颜色值,这很容易照成误差。

不同的开发,对组件的命名可能不一样,比如按钮,有 ‘btn’、有 ‘button’ 等等。加上第一点的问题,造成 css 中诸多长得差不多,但不能复用的代码。

不同的设计师,风格也不相同,同一个表单今天是这个样子,明天它妈都不认识了。而苦逼的开发,要重新还原设计稿。

整个站点的交互,色彩,看上去总是不那么协调。

显然,如果没有一个设计规范(Style Guide),项目会越来越难以拓展,不可维护。那么制定一个设计规范就很有必要了。

Style Guide 应该是什么样子

一个合格的设计规范,至少需要满足 3 个方面,以下我以 github 的设计规范 Primer 为示例,一个个说:

1. 色彩风格

一个具备美感的网站,并不是色彩越多样越好,我们一般需要定义网站多主色调。
重要的是,定义好色值后,就愉快的可以用 sass 之类的 css 预编译,设置变量了。 (=^ω^=)

比如 github 多主色调,是蓝色

2. 组件化

设计规范应该定义出 web 项目常用的组件:比如 按钮、 弹框、表单、侧栏、导航等等。以便复用 (关键是设计时就要复用)。

3. 使用文档

定义好设计风格和各种组件后,要做的就是让各位开发和设计童鞋按规范使用了。 使用文档必须写明色彩具体值、组件的结构、css 命名等,如果有 js 组件,也要写好 js 的 api 文档。

需要自己创建 Style Guide 吗

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 简介

Craft 是一套面向 Sketch 和 Photoshop 的插件组,帮助你简化设计流程中的自动化填充,提升工作流效率,将注意力集中在设计本身。作为一个工具套件,Craft 包含下列工具:

批量复制:快速复制重复图层,并方便调节间距、数量等。

样式库:在 Sketch 中生成一个 StyleGuide。它使一个新的页面有不同的调色板,字体,文本样式和自定义元素,您可以建立自己。与你的团队分享和同步整个库。

智能图库:支持 Dropbox,unsplash,本地文件夹,或 Web 页面上调取图片到 Sketch 画板中。

数据:带来真正的文本,图像,JSON 等内容到你的 Sketch,无需花费时间进行模拟数据。

其中的样式库功能,就可以方便的生成 Style Guide:

另外这款插件绝不是一个内容生成器那么简单。它可以帮助你摆脱「Lorem Ipsum」,使用真实的产品数据进行设计,这对设计师来说简直太重要了!具体的操作办法可以去他们的 官网 看视频教程。

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/115381.html

相关文章

  • 前端进阶之路: 前端架构设计(1)-代码核心

    摘要:可能很多人和我一样首次听到前端架构这个词第一反应是前端还有架构这一说呢在后端开发领域系统规划和可扩展性非常关键因此架构师备受重视早在开发工作启动之前他们就被邀请加入到项目中而且他们会跟客户讨论即将建成的平台的架构要求使用还什么技术栈内容类型 可能很多人和我一样, 首次听到前端架构这个词, 第一反应是: 前端还有架构这一说呢? 在后端开发领域, 系统规划和可扩展性非常关键, 因此架构师备...

    DevYK 评论0 收藏0
  • 前端进阶之路: 前端架构设计(1)-代码核心

    摘要:可能很多人和我一样首次听到前端架构这个词第一反应是前端还有架构这一说呢在后端开发领域系统规划和可扩展性非常关键因此架构师备受重视早在开发工作启动之前他们就被邀请加入到项目中而且他们会跟客户讨论即将建成的平台的架构要求使用还什么技术栈内容类型 可能很多人和我一样, 首次听到前端架构这个词, 第一反应是: 前端还有架构这一说呢? 在后端开发领域, 系统规划和可扩展性非常关键, 因此架构师备...

    baishancloud 评论0 收藏0
  • 前端进阶之路: 前端架构设计(1)-代码核心

    摘要:可能很多人和我一样首次听到前端架构这个词第一反应是前端还有架构这一说呢在后端开发领域系统规划和可扩展性非常关键因此架构师备受重视早在开发工作启动之前他们就被邀请加入到项目中而且他们会跟客户讨论即将建成的平台的架构要求使用还什么技术栈内容类型 可能很多人和我一样, 首次听到前端架构这个词, 第一反应是: 前端还有架构这一说呢? 在后端开发领域, 系统规划和可扩展性非常关键, 因此架构师备...

    YancyYe 评论0 收藏0
  • 前端进阶之路: 前端架构设计(1)-代码核心

    摘要:可能很多人和我一样首次听到前端架构这个词第一反应是前端还有架构这一说呢在后端开发领域系统规划和可扩展性非常关键因此架构师备受重视早在开发工作启动之前他们就被邀请加入到项目中而且他们会跟客户讨论即将建成的平台的架构要求使用还什么技术栈内容类型 可能很多人和我一样, 首次听到前端架构这个词, 第一反应是: 前端还有架构这一说呢? 在后端开发领域, 系统规划和可扩展性非常关键, 因此架构师备...

    rockswang 评论0 收藏0
  • 前端规范(ES6BEMOOCSSSMACSS)

    摘要:前端规范在实际开发中,由于团队成员编码习惯不一,技术层次不同,开发前定制并遵循一种代码规范能提高代码质量,增加开发效率。是定义了一种的命名规范,每个名称及其组成部分都是存在一定的含义。 前端规范 在实际开发中,由于团队成员编码习惯不一,技术层次不同,开发前定制并遵循一种代码规范能提高代码质量,增加开发效率。 Javascript Javascript规范直接参考airbnb: ES6 ...

    Object 评论0 收藏0

发表评论

0条评论

最新活动
阅读需要支付1元查看
<