内容简介：我在制作 Sketch 组件库时学到了一些东西
日常工作当中，每完成一轮迭代，或多或少都会做一些设计小结，譬如回顾一些典型方案背后的思路、权衡与决策的过程等等，同时也可以作为备忘与学习笔记。
工作是这样，个人项目亦应如此。最近在 Beforweb Store 上架的 线框稿风格 Sketch 组件库（WireframeKit for Sketch） ，从开工到完成，似乎也有将近两个月的样子了，期间零零散散的利用日常工作之外的时间一点点的制作和打磨，回头看来也是一件让自己很有成就感的事。在制作过程中，不止一次想到在完工之后要记录些什么，因为感到真的有在过去的基础上学到了一些新的、重要的东西。
那么现在就来做这件事情。在本文中，我将向各位介绍我在制作 WireframeKit for Sketch 的过程中所学到的一些东西，包括制作和维护组件库的意义，组件库的组织方式，色彩、样式及文字风格的定义策略，全局化命名规则的制定，以及相关插件的使用。
为什么要制作和维护组件库
制作这套 WireframeKit 的想法并非偶然。在工作中，本就会花额外的时间去制作和维护自己的组件库，每次进入新的迭代周期都会将这套东西作为基础模板；同样，每结束一个周期，也会将期间最为典型的、最具复用性的组件或样式定义抽取出来加入到库中。这件事做久了，库渐渐饱满起来了，自己也就越发能够从中受益，譬如对于日常工作项目当中的很多需求，都可以比较轻松的拖拖组件或进行少量的改动便能快速完成。
通过组件库来更加轻松高效的完成设计工作，这只是“受益”的一方面；要实现这份“轻松高效”，组件库本身必须足够“合理”，包括合理的架构、合理的复用性与灵活性、合理的扩展性等等，而这些都需要自己在整理和维护的过程中不断思考和学习 - 你可能需要借鉴市面上那些UIKit的组织方式，去学着采用 Sketch 不断提供的一个个强大的新功能，基于自己团队特定产品现有的设计方案去提取原子、分子、模块、页面级别的设计模式，并对扩展性进行充分的预估，等等 - 所有这些，对于自己而言都是丰盛的学习与提升。如果说组件库本身是“鱼”，那么制作组件库的过程便是“渔”。我需要“鱼”，也需要懂得如何更好的“渔” - 这就是我保持制作和维护组件库的原因。
当然，至于如今的这套“WireframeKit for Sketch (iOS)”，则有更多挑战在其中。对于私下自制自用的资源，总会有所妥协和容错；一旦面向各位同行进行公开，被更多人拿去掂量和使用，则必须在各方面尽可能做到完美，包括文件的组织方式、元素的命名规则、对于组件灵活性与扩展性的标准制定以及相应的制作方法、同时适配中英文需求的细节处理方式等等，甚至包括几乎无人问津的条款声明，都需要反复试错和雕琢， 最终达成一种最优的、平衡的状态，以实现具有真正实用性、高效性的目标 。
关于组件库的组织方式
我在工作中自用的组件库，形式上只是 Sketch 文件当中一个名为“Library”的Page，所有的颜色、样式、文字风格定义，以及组件及模块、界面模式等都集中在这个页面当中。
如此的形式自有它的好处，例如“便携”，即每次新建 Sketch 文件时可以将这个 Page 当中的全部Artboard复制过去，如此便完成了 Library 的“导入”；市面上很多知名的组件库、模板也是采用类似的单页形式。不过对于这次的“WireframeKit for Sketch (iOS)”来说，状况或多或少有些不同。
第一次尝试对外产出，最需考虑的问题之一就是普遍适用性，即抛开任何特定类型的产品设计模式，只专注在自己和多数移动端设计师最为熟悉的 iOS 系统模式上面。系统级的 设计模式 归纳起来自然有其复杂性，至少在分子层面上确保整个库的架构清晰、条理分明还是有必要的。
另一方面，虽然市面上一些知名UIKit采用着单页形式来组织所有类型的元素，但我个人并不认为这些库在实战当中会很好用，况且多数都是高度还原系统界面，无论组件颗粒度还是配色风格都不适于交互设计师或产品同学拿来直接用于线框原型的制作。
综合以上这些考虑，最终，我的 WireframeKit 文件被划分为了9个 Page，具体结构层次如下：
- Styles （样式）：提供12种颜色定义，52种样式定义及468种文字风格定义。
- Components - Bars （组件 - 栏）：提供 Navigation Bar、Tool Bar 等5大类、共计19种典型组件。
- Components - Table Views （组件 -列表视图）：提供 Cell、Section Header 等5大类、共计24种典型组件。
- Components - Views （组件 -视图）：提供 Alert、Action Shee t等4大类、共计16种典型组件。
- Components - Controls （组件 -控件）：提供 Segmented Control、Slider 等8大类、共计29种典型组件。
- Components - Icons （组件 -图标）：提供58个常用图标或灰稿图标占位符。
- Screens （典型界面范例）：针对两款设备规格提供12个完整界面范例。
- License （版本信息及使用条款）
- Symbols （所有组件的原始 Symbols）
由于页面较多，难以通过在不同的 Sketch 文件之间手动复制 Artboard 实现组件库的完整套用，所以我会在 WireframeKit 的使用说明中特别强调“ 你可以将该组件库保存为模板（‘Save as Template’），并基于该模板来创建你的新项目（‘New From Template’） ”。
关于样式定义
既然叫做“组件库”，核心价值势必由组件所承载，无论是原子级别的控件（Controls）、图标（Icons），还是分子级别的栏（Bars）、Table Views（列表视图）等等。然而正如我在 WireframeKit 的使用说明当中所说，“ 命名合理、架构清晰的样式库是所有组件定义的基石 ”。制作组件库、模板，或更为庞大的设计系统（“Design System”），首先也是最为首要的，便是全面、精细、便于维护和扩展的样式定义。
我个人习惯于将“样式定义”分为三个方面在 Sketch 当中依次进行，包括：
- 颜色 ：Colors，基础色盘。
- 样式 ：Sketch 的 Shared Styles 体系。
- 文字风格 ：Sketch 的 Text Styles 体系。
颜色（Colors）
颜色是构成信息层级与对比度的基础设计要素之一。对于界面设计而言，这条基本法则不仅适用于高保真视觉层面， 对于以线框和灰稿风格为主的交互设计来说亦是如此 。
和很多朋友一样，我也经历过“满屏 Axure 默认黑框”的粗糙阶段，又曾在一段时间里沉迷于通过很淡的灰色来绘制清爽淡雅的线框稿。然而随着时间的推移，经验有所积累，认知有所提升，终于还是认识到了对于交互设计师而言，颜色的使用绝非儿戏 - 通过不同的灰色来构建界面整体与局部信息的对比度，使内容的层次和节奏一目了然，帮助其他职能的协作人员轻松快捷的理解交互设计意图，这是交互设计师的基本职责之一 。
针对特定产品的具体情况，我在日常工作中的组件库用到了10种以上的灰色；这次的 WireframeKit 大致也是如此，针对 iOS 的特定情况，提供了12种颜色定义，包括7种灰色，以及纯黑、白，半透明黑、白等。
其中归属深色范围的灰色包括 Grey0 至 Grey4，深度逐渐降低；归属浅色范围的灰色包括 Light0 与 Light1，同样由深至浅。这种通过“Grey”、“Light”及数字对灰色进行命名的规则在全局保持统一，可以进一步用于样式（Shared Styles）与文字风格（Text Styles）的命名组成。然而与后两者不同的是，“颜色”并非 Sketch 功能体系当中的一部分，不存在一个可以管理和复用的所谓“Colors”模块，于是自己创建和维护一套基础色盘并在全局范围内保持命名及使用方式的一致就变得非常重要了。
将 WireframeKit 保存为模板（Save as Template），并以此为基础创建新文件后（New From Template），Sketch 系统色盘当中的“Document Colors”区块便会列出 WireframeKit 预设的配色，当你需要为文字或图形元素取色时，这里用起来还算便捷，只是在绝大多数时候仍然建议使用 WireframeKit 预设的 Text Styles 或 Shared Styles，保持全部颜色的集约式管理。
样式（Shared Styles）
经过对日常工作组件库的梳理归纳，在这次的 WireframeKit for Sketch 当中，我将全部52种样式（Shared Styles）划分为3大类，以便运用到各类典型的组件制作当中：
- 实色填充 ：命名形式为“ Fill-颜色名称 ”，例如“Fill-Black”、“Fill-Grey4”、“Fill-White-Overlay”等。
- 空心描边 ：命名形式为“ Border-颜色名称 ”，例如“Border-Grey0”、“Border-Light1”、“Border-White”等。
- 实色填充及多方向描边 ：命名形式为“ Fill-颜色名称-Border-颜色名称 ”，例如“Fill-Light0-Border-Grey4”、“Fill-Light1-BorderBtm-Grey4”、“Fill-White-BorderLeftRight-Grey4”等。
其中，“实色填充”与“空心描边”均与12种颜色定义一一对应，最常用的使用场景包括绘制图片占位符、头像占位符等实色形状，界面背景或半透明遮罩，空心按钮或布局容器等等。“实色填充及多方向描边”则因为包含了多个方向边框的定义而相对复杂一些，主要用于各类栏（Bars）和 Table View Cells 的构建，譬如你可以通过“Fill-White-Transparent-BorderBtm-Grey4”来实现带有下边框的 Table View Cells 样式。
至于这类单一边框或分隔线样式的制作方式，其实也是很有意思的话题。我习惯于通过“Inner Shadows”属性来实现，例如要为一个矩形元素添加下边框，则可将其“Inner Shadows”按照下图所示进行设置：
同理，要实现左、右边框的样式，则可以：
为什么不通过 Line 对象来实现边框或分隔线？其实没所谓，某些状况下也会便捷，只是在调整 Line 自身或容器整体尺寸时会出现一些问题，不如直接在容器身上做样式来的更加灵活稳妥。如果有朝一日 Sketch 可以提供多个方向的边框设置功能，那也无需再如此麻烦了。
文字风格（Text Styles）
定义文字风格（Text Styles）是整个样式定义工作当中最为困难，或是说最为麻烦的过程。
WireframeKit for Sketch 提供了468种文字风格定义，每一种都包含6个方面的属性设置。其中4项为显性属性，文字风格的命名规则便基于此，即“ 对齐方式-字体重量-颜色名称-字号 ”，譬如最为常用的“Left-Regular-Grey1-17”风格，所代表的就是左对齐、常规重量、颜色为Grey1的17号文字。
对齐方式分为左、中、右，字体重量包括 Regular 和 Semibold，颜色选用了 Grey0 至 Grey4 以及 White，字号从10到28共13种 - 排列组合下来就达到了三位数的量级。
当然，所有这些文字风格当中，只有较少一部分会被高频使用，但从整体角度讲， 我更倾向于在初期花费足够多的时间去构建这样一套高度统一的、足以应对绝大多数使用情景的样式定义，尽可能避免后期使用时在基础样式层面发生变更需求 。
而隐性属性则包括文字的行高与字间距。这两项属性不会呈现在命名当中，但在进行预设时也着实考验耐性。通常情况下，对于每个字号的文字，即便在这两个属性上只采用 Sketch 的默认设置，也不会出现很大问题，最多是字间距的微小差别；然而一旦涉及到多行内容，或是，我们最为关心的中文内容，问题便会显露出来 - 行高的设置会对文字在纵向的显示位置造成明显的影响，布局精准的英文范例内容一旦被更换为中文，纵向位置关系会产生严重问题。参考了来自 Apple 官方、Facebook 及其他第三方作者提供的 UIKit 资源，我为每个字号设置了特定的行高与字间距，尽可能还原出系统原生的样式属性。
是否真的有必要在线框稿当中如此精准的控制文字各个方面的属性、以实现高度还原？我个人始终相信答案是肯定的， 特别是在移动端，针对小规格屏幕及复杂的使用情境，对于文字样式、内容尺寸与布局的高度敏感性是交互设计师应该具备的特质 。
关于命名方式与插件的使用
前文当中不止一次提到命名方式与规则的问题，这同样是此次制作组件库的过程中印象最为深刻的环节之一。
无论对于颜色、样式、文字风格的定义，还是元件模板（Symbols）、图标、范例界面的制作与组织， 统一、通用、灵活的命名规则都是贯穿始终的基线 。关于样式定义当中的命名问题，前面已经聊过，不再重述，现在主要来看 Symbols 方面。
正如在“关于组件库的组织方式”当中所介绍的，这次的 WireframeKit for Sketch 所提供的 Symbols 会按照“栏（Bars）”、“列表视图（Table Views）”、“视图（Views）”、“控件（Controls）”等分为若干类，其中每一类又包含若干子类，譬如“栏”当中的 Navigation Bar、Tool Bar、Tab Bar等等，而每一个子类又是由若干典型 Symbols 所构成。
如此层次分明的架构对于 Symbols 的命名自然有着严格的要求，一方面要使制作过程更加井然有序、条理清晰，一方面更要确保最终产出的组件库文件真正便于索引和使用。为了体现结构层次，我第一次在 Symbols 命名当中使用了“/”符号来分隔类别，譬如“Bars / Navigation Bar / Hierarchical”、“Table Views / Cell / Avatar - Summary - Edit Mode”等等。
Sketch 可以自动识别“/”符号，并以此作为类别分隔标志来逐层组织 Symbols，最终形成完整的目录结构，正如你在 WireframeKit 文件的 Symbols下拉面板当中所看到的：
只要你在使用时知道自己需要怎样的组件，便能很轻松的逐层索引。
而说到插件，并非要罗列“我的20款常用 Sketch 插件”一类。之所以与命名方式的话题合并在一起，是因为以上聊到的这些命名规则的最终确定并非一帆风顺，无论 Text Styles 还是 Symbols，在整理命名时都经历过多轮的批量试错与修改；这些过程离不开一些重要插件的辅助，否则工作量将大到无法承受；下面做以简要介绍，有类似痛点的朋友不妨尝试。
Rename It
用于对选中的图层、组或 Symbols 进行批量重命名。功能只针对这些对象在左侧图层列表当中的名称，而不涉及具体内容。
该插件提供两种批量操作机制，包括“Rename Selected Layers”和“Find & Replace Layer Names”，前者可以自由制定批量命名的具体规则，后者则用于查找特定字符并替换。
Find And Replace
用于批量替换文本对象当中的实际文字内容（而非前一款 Rename It 插件那样针对图层列表当中的对象名称），设置项也算丰富实用；在尝试命名规则的过程中，我会通过这款插件批量修改样式定义当中所呈现的文字风格名称。
Styles Generator
可以同时用于自动化生成 Shared Styles 与 Text Styles。确定了命名规则，完成了初始的样式或字体属性设置，接下来怎样批量生成 Styles？选中所有范例对象，执行该插件提供的“Generate Shared Styles”，Sketch 便能根据你所选中的对象的图层名称来自动生成对应的 Styles，无需任何手动命名的过程。
小结
大约就是这样，关于这次在制作 WireframeKit for Sketch 组件库的过程中所想到的、学到的、深入理解到的。
我们聊了制作和维护组件库的意义、组件库的组织方式、样式定义、命名方式与插件的使用，共四大方面；虽然不会细化到具体的操作层面，但作为小结和学习笔记已经足够；希望同时也能为各位带来一定的学习和参考价值。
最后还是要向购买了 WireframeKit 并鼓励和支持着我的朋友们表示感谢，我接下来还会继续尝试其他类型的 Sketch 组件库；尚未了解 WireframeKit 的朋友不妨参考之前的简介，或通过下方二维码到 Beforweb Store 直接逛逛看。
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
Linux内核完全剖析
赵炯 / 机械工业出版社 / 2006-1 / 79.00元
本书对早期Linux操作系统内核全部代友文件进行了详细的剖析，旨在让读者在尽量短的时间内对Linux的工作机理获得全面而深刻的理解，为进一步学习和研究Linux系统打下坚实的基础。虽然选择的版本较低，但该内核已能够正常编译运行，并且其中已包括了Linux工作原理的精髓。书中首先以Linux源代码版本的变迁为主线，简要介绍了Lin-ux系统的发展历史，同时着重说明了各个内核版本之间的主要区别和改进方......一起来看看 《Linux内核完全剖析》 这本书的介绍吧!
