手把手教你玩儿转UI— Sketch 组件库

北京/学生/8年前/12850浏览

版权

通过组件库来更加轻松高效的完成设计工作，这只是“受益”的一方面；要实现这份“轻松高效”，组件库本身必须足够“合理”，包括合理的架构、合理的复用性与灵活性、合理的扩展性等等，而这些都需要自己在整理和维护的过程中不断思考和学习 - 你可能需要借鉴市面上那些UIKit的组织方式，去学着采用 Sketch 不断提供的一个个强大的新功能，基于自己团队特定产品现有的设计方案去提取原子、分子、模块、页面级别的设计模式，并对扩展性进行充分的预估，等等 - 所有这些，对于自己而言都是丰盛的学习与提升。如果说组件库本身是“鱼”，那么制作组件库的过程便是“渔”。我需要“鱼”，也需要懂得如何更好的“渔”。

当然，至于如今的这个“WireframeKit for Sketch (iOS)”，包括文件的组织方式、元素的命名规则、对于组件灵活性与扩展性的标准制定以及相应的制作方法、同时适配中英文需求的细节处理方式等等，甚至包括几乎无人问津的条款声明，都需要反复试错和雕琢，最终达成一种最优的、平衡的状态，以实现具有真正实用性、高效性的目标。

关于组件库的组织方式

在工作中自用的组件库，形式上只是 Sketch 文件当中一个名为“Library”的Page，所有的颜色、样式、文字风格定义，以及组件及模块、界面模式等都集中在这个页面当中。

如此的形式自有它的好处，例如“便携”，即每次新建 Sketch 文件时可以将这个 Page 当中的全部Artboard复制过去，如此便完成了 Library 的“导入”；市面上很多知名的组件库、模板也是采用类似的单页形式。不过对于这次的“WireframeKit for Sketch (iOS)”来说，状况或多或少有些不同。

综合以上这些考虑，最终，将 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，无需任何手动命名的过程。