创作模式库的原则

2020-05-27 08:36:30

无论你想不想使用沃霍尔,拥有一个模式库对于控制你的项目设计都是至关重要的。但并不是所有的模式库都是平等创建的。有些人在协调你的团队对你的设计系统的理解方面比其他人做得更好,而那些做这项工作的人往往遵循一套共同的原则。本文介绍了创作一个好的、有用的和一致的模式库的明确原则。它可以帮助您确保模式库保持最新、可扩展,并且确实可供您的团队使用。

每个设计系统都有自己的词汇。本术语表定义了一些适用于任何模式库、设计系统或CSS方法的通用术语。

模式库是一个网页,它充当设计系统的唯一真理来源。它定义了项目的调色板,显示了如何组合组件以及可以组合哪些排版属性。它包含可能出现在项目中的每个用户界面构建块的典型示例。构建块本身称为模式库的元素,由组件、主题和实用程序组成。

组件是用于Web项目的任何独立构建块,使用标记和CSS样式构建,并且可能具有由JavaScript驱动的任何特殊行为。组件的示例有按钮、摘要或甚至更复杂的UI对象(如模式对话框)。组件是通过模式库中的规范示例定义的。术语“组件”指的是作为整体的组件,包括该组件可能包含的任何子内容。模式库中组件的规范定义称为组件定义,实际项目中(模式库之外)相同组件的实例是组件实现。组件中本身不是组件的HTML元素称为组件子元素。就像组成根元素本身一样,它们必须完全按照模式库的规定来实现,直到最后一个像素(当然不包括内容)。

在大型的、杂乱无章的棕地项目中,期望模式库一直定义所有可能的组件是不合理的。非组件是用户界面的一部分,不遵循任何组件定义,但仍然必须遵循主题。它们可能会出现在生产项目中,但不会出现在模式库中。

该主题代表图案库的基本样式规则,如调色板、字体、排版功能以及图标。项目中的每件事都必须遵循主题规则,无论元素是不是组件实现。

实用程序是附加的样式规则,可以添加到组件以调整其外观或调整其位置。添加阴影、浮点加页边距或负责网格定位的类都是实用程序的主要示例。实用程序可以组合在一起,如果它们的样式不相互冲突的话。

创作模式库的原则遵循莫斯科的优先顺序。“必须”是硬要求,“应该”是一个建议,“可能”则相当于一个不错的要求。

首先必须设计一个供人类使用的模式库。工具必须适应人类的需求,而不是反过来。

模式库必须是活生生的Web文档,能够适应项目生命周期内不断变化的环境,并且可以很容易地添加新的组件或组件的变体。PDF和其他非交互格式不适合图案库。

模式库的设计必须考虑到扩展。其他模式库必须能够构建在任何其他模式库中的模式和组件之上。衡量这一点的一个指标是,库是否提供了扩展位置(哪些组件)的指导,以及代码示例是否具有可扩展的API。

模式库中定义的所有内容都必须具有响应性,并且模式库必须提供允许用户查看处于各种响应状态的相关元素的用户界面。

组件必须是自包含的用户界面构建块,除了样式的公共重置或规格化外,不依赖于任何外部上下文。

模式库中定义的所有组件都必须通过HTML和CSS中全面、规范的实现来定义。同一组件的多个示例上的样式不能相互冲突(不包括组件变体)。

必须使用清晰可识别的示例内容、填充文本和占位符图像来定义图案库中的组件。

组件必须以任何实现者都可以轻松重用的方式定义。组件定义不能依赖于特定的技术或框架,但可以在此基础上构建。

调色板以及可以在整个项目中使用的所有字体和排版组合必须是图案库的一部分。

主题、实用程序和组件的定义必须明确区分,并且不得在模式库中用于其他目的。例如,组件定义不能同时用作颜色或排版信息的来源。

开发人员应该能够轻松地改进和扩展模式库(例如,添加文档和注释)。

模式库在任何给定的时间点都应该尽可能全面。它应该用尽可能多的用例来表示尽可能多的组件,用尽可能多的示例来给出项目的整体状态。

应该首先表示组件的最常见变体,然后显示不太常见的变体。

模式库中的所有元素都应该被记录下来,解释如何以及何时使用它们,以及如何和何时不使用它们。

组件应该以可扩展的方式编写,以便使用模式库的开发人员可以在需要时添加新的行为。

如果组件可以包含其他组件(如容纳图像、文本、按钮的卡片组件),则应标记为容器组件;如果不能包含其他组件(如普通的基本按钮),则应标记为表示组件。

模式库应该提供开发人员工具来方便地使用组件代码,比如将组件定义的代码复制到剪贴板的按钮。

模式库的用户界面应根据其定义的组件构建,以便于更好地理解组件,并防止模式库的用户界面和组件的样式相互影响。

模式库可以定义并非由模式库服务的每个项目都使用的组件。

模式库可以设置为一个或多个代码模块,可以由实现者直接使用。

模式库可以为不仅仅定义组件的实现者提供交互式用户界面。排版操场或拖放组件编写器对任何模式库都是有用的补充。

模式库对于任何规模的团队都至关重要。好的设计根源于不一致,没有单一的设计真理来源,保持一致性几乎是不可能的。本指南可作为您的模式库的检查表,无论您的项目是否即将开始,或者您是否在维护大型遗留项目-有没有现有的模式库。通过坚持这些原则,您将创建一个实际有用的设计参考,您的人类团队和像沃霍尔这样的工具都会欣赏它。

本指南就像一个好的模式库一样,是可扩展的。如果你觉得有我们遗漏的东西(或者完全错了),请发推特给我们!