从 UI 套件到设计系统

常春藤在线影院体验

当 2017 年初我们第一次考虑创建自己的设计到代码交付系统时，许多人已经在谈论它，有些人甚至正在这样做。 然而，迄今为止，人们对构建跨平台设计系统的经验知之甚少，也没有明确且经过验证的方法来描述将设计实现过程转变为已经运行的产品的技术和方法。 而“代码中的组件”通常意味着非常不同的事情。

与此同时，公司的员工年复一年地增加——有必要扩大设计部门的规模，并优化创建和转移开发布局的流程。 我们将所有这些乘以需要支持的平台“动物园”，我们得到了巴比伦混乱的外观，它根本无法“正常进行”并产生收入。 平台的开发通常是并行进行的，相同的功能可能会在不同的平台上发布，但会有几个月的滞后。


每个平台都有单独的布局集

传统上，我们从设计系统有助于解决的问题开始，并制定其设计要求。 除了创建统一的视觉语言、提高布局和开发速度以及提高产品的整体质量之外，尽可能统一设计也至关重要。 这是必要的，以便在我们所有的平台上同时开发功能：Web、iOS、Android、智能电视、tvOS、Android TV、Windows 10、xBox One、PS4、Roku - 无需单独处理每个平台。 我们做到了！

设计→数据

当产品和开发部门之间达成基本协议后，我们坐下来选择一个技术堆栈并制定整个流程的细节 - 从布局到发布。 为了完全自动化将设计转移到开发的过程，我们探索了直接从带有布局的 Sketch 文件解析组件参数的选项。 事实证明，找到我们需要的代码片段并提取我们需要的参数是一项复杂而危险的任务。 首先，设计者在命名源代码的所有层时必须非常小心，其次，这只适用于最简单的组件，第三，依赖他人的技术和原始Sketch布局的代码结构会危及整个Sketch布局的未来。项目。 我们决定放弃该领域的自动化。 这就是设计系统团队中第一个人的出现，其输入是设计布局，输出是描述组件所有参数并根据原子设计方法分层排序的数据。

剩下要做的唯一一件事是在哪里以及如何存储数据，如何将其传输到开发以及如何在我们支持的所有平台上的开发中解释它。 夜晚不再是慵懒的……由各平台的设计师和团队负责人组成的工作组定期召开会议，达成了以下协议。

我们手动将视觉效果解析为原子元素：字体、颜色、透明度、缩进、四舍五入、图标、图片和动画持续时间。 我们从这些按钮、输入、复选框、银行卡小部件等中收集信息。我们将非语义名称分配给任何级别的样式（图标除外），例如城市名称、仙女名称、口袋妖怪、汽车品牌...只有一个条件——清单不能排完，款式如何结束——秀必须走！ 例如，您不应该被语义迷惑，这样您就不必在“小”和“中”之间添加中间按钮。

视觉语言

开发人员必须考虑如何以适合所有平台的方式存储和传输数据，而设计人员必须设计出美观且在整个受支持设备上有效工作的界面元素。

此前，我们已经成功地“测试”了Windows 10应用程序中的大部分设计元素，当时Windows XNUMX对我们来说是一个新平台，也就是说，它需要“从头开始”渲染和开发。 通过绘制它，我们能够准备和测试大部分组件，并了解其中哪些应该包含在未来的 Eevee 设计系统中。 如果没有这样的沙箱，这样的经验只能通过在已经运行的平台上进行大量迭代来获得，而这需要一年多的时间。

在不同平台上重用相同的组件会显着减少设计系统的布局数量和数据数组，因此设计必须解决一个以前在产品设计和开发实践中没有描述过的问题 - 例如，如何：手机和平板电脑的按钮可以在电视上重复使用吗？ 那么在如此不同的平台上我们应该如何处理字体和元素的大小呢？

显然，有必要设计一个跨平台模块化网格，为每个特定平台设置我们所需的文本和元素大小。 作为网格的起点，我们选择了想要在特定屏幕上看到的电影海报的大小和数量，并基于此制定了构建网格列的规则，前提是一列的宽度相等到海报的宽度。

现在我们需要将所有大屏幕调整为相同的布局尺寸并将它们放入公共网格中。 Apple TV 和 Roku 的设计尺寸为 1920x1080，Android TV - 960x540，智能电视（取决于供应商）是相同的，但有时为 1280x720。 当应用程序渲染并显示在全高清屏幕上时，960 乘以 2，1280 乘以 1,33，并按原样输出 1920。

跳过无聊的细节，我们得出的结论是，一般来说，包括电视屏幕在内的所有屏幕，就元素及其尺寸而言，都被一种设计布局所覆盖，并且所有电视屏幕都是一般跨平台网格的特例，由五到六列组成，就像普通的平板电脑或台式机一样。 有兴趣了解详情的可以评论区留言。

适用于所有平台的单一 UI

现在，要绘制新功能，我们不需要为每个平台绘制布局，以及每个平台的适应性选项。 它足以显示一种布局及其对任何宽度的所有平台和设备的适应性：电话 - 320-599，其他所有 - 600-1280。

数据→开发

当然，尽管我们希望实现完全统一的设计，但每个平台都有自己独特的功能。 尽管 Web 和 Smart TV 都使用 ReactJS + TypeScript 堆栈，但 Smart TV 应用程序在旧版 WebKit 和 Presto 客户端上运行，因此无法与 Web 共享样式。 电子邮件通讯完全被迫使用表格布局。 与此同时，没有一个非 html 平台使用或计划使用 React Native 或其任何类似物，因为担心性能下降，因为我们有太多的自定义布局、具有复杂更新逻辑的集合、图像和视频。 因此，提供现成的 CSS 样式或 React 组件的常见方案并不适合我们。 因此，我们决定以 JSON 格式传输数据，以抽象声明的形式描述值。

所以财产 rounding: 8 Windows 10 应用程序转换为 CornerRadius="8"，网络- border-radius: 8px， 安卓 - android:radius="8dp", iOS - self.layer.cornerRadius = 8.0.
财产 offsetTop: 12 同一 Web 客户端在不同情况下可以解释为 top, margin-top, padding-top или transform

描述的声明性还意味着，如果平台在技术上无法使用某个属性或其值，则可以忽略它。 在术语方面，我们做了一种世界语：有些取自Android，有些取自SVG，有些取自CSS。

如果在特定平台上您需要以不同方式显示元素，我们已经实现了以单独的 JSON 文件的形式传输相应数据生成的功能。 例如，智能电视的“焦点对准”状态指示海报下方文本位置的变化，这意味着对于该平台，“缩进”属性值中的该组件将包含其所需的 8 个缩进点。 尽管这使设计系统的基础设施变得复杂，但它提供了额外的自由度，使我们有机会自己管理平台的视觉“差异”，而不是受制于我们创建的架构。

象形图

数字产品中的图像始终是一个庞大且不是最简单的子项目，通常需要单独的设计师。 字形总是有很多，每个字形都有多种尺寸和颜色，平台通常需要不同的格式。 总的来说，没有理由不将所有这些都纳入设计系统中。

字形以 SVG 矢量格式加载，颜色值自动替换为变量。 客户端应用程序可以接收它们以供使用 - 任何格式和颜色。

预览

在 JSON 数据之上，我们编写了一个用于预览组件的工具 - 一个 JS 应用程序，它通过其标记和样式生成器动态传递 JSON 数据，并在浏览器中显示每个组件的各种变体。 本质上，预览版与平台应用程序是完全相同的客户端，并且使用相同的数据。

了解特定组件如何工作的最简单方法是与其交互。 因此，我们没有使用Storybook之类的工具，而是做了一个交互式预览——你可以触摸、指向、单击……当向设计系统添加新组件时，它会出现在预览中，以便平台在使用时有需要关注的内容。实施它。

Документация

根据以 JSON 形式提供给平台的数据，自动生成组件的文档。 描述了属性列表以及每个属性中可能的值类型。 自动生成后，可以手动澄清信息并添加文字描述。 预览和文档在每个组件级别相互交叉引用，并且文档中包含的所有信息都可以附加 JSON 文件的形式提供给开发人员。

弃用者

另一个必要条件是能够随着时间的推移更换和更新现有组件。 设计系统已经学会告诉开发人员哪些属性甚至整个组件不能使用，并在所有平台上不再使用它们时立即将其删除。 这个过程中还有很多“体力”劳动，但我们并没有停滞不前。

客户开发

毫无疑问，最复杂的阶段是在我们支持的所有平台的代码中解释设计系统数据。 例如，如果网络上的模块化网格并不是什么新鲜事，那么 iOS 和 Android 原生移动应用程序的开发人员就会努力工作，然后才弄清楚如何使用它。

为了布局 iOS 应用程序屏幕，我们使用 iviUIKit 提供的两种基本机制：元素的自由布局和元素集合的布局。 我们使用VIPER，所有与iviUIKit的交互都集中在View中，而与Apple UIKit的大部分交互都集中在iviUIKit中。 元素的大小和排列是根据在本机 iOS SDK 约束之上工作的列和语法结构来指定的，使它们更加实用。 这尤其简化了我们使用 UICollectionView 时的生活。 我们已经为布局编写了几个自定义包装器，包括相当复杂的包装器。 客户端代码最少，并且它变成了声明性的。

为了在Android项目中生成样式，我们使用Gradle，将设计系统数据转换为XML格式的样式。 同时，我们拥有多个不同级别的生成器：

• 基本的。 解析更高级别生成器的原语数据。
• 资源。 下载图片、图标和其他图形。
• 成分。 它们是为每个组件编写的，描述了哪些属性以及如何将它们转换为样式。

应用发布

设计人员绘制新组件或重新设计现有组件后，这些更改将被输入到设计系统中。 每个平台的开发人员正在微调他们的代码生成以支持这些变化。 之后，它可以用于需要该组件的新功能的实现。 因此，与设计系统的交互不是实时发生的，而是仅在组装新版本时发生。 这种方法还可以更好地控制数据传输过程，并确保客户端开发项目中的代码功能。

结果

设计系统成为支持Ivy在线影院发展的基础设施的一部分已经一年了，我们已经可以得出一些结论：

• 这是一个庞大而复杂的项目，需要持续的专用资源。
• 这使我们能够创建自己独特的跨平台视觉语言，以满足在线视频服务的目标。
• 我们不再拥有视觉和功能上落后的平台。

Ivy设计系统组件预览—— 设计.ivi.ru

来源： habr.com