常春藤在线电影体验2017年初，我们首先考虑创建自己的系统以将设计交付给代码，许多人谈到了这一点，甚至有人做到了。 但是，到目前为止，人们对构建跨平台设计系统的经验知之甚少，并且还没有清晰，经过验证的方法来描述将设计实现过程转换为已经工作的产品的技术和方法。 而且“代码中的组件”通常意味着截然不同的事物。
同时，该公司的员工每年增加一倍-有必要扩大设计部门的规模，并优化创建布局并将布局转移到开发的过程。 我们将所有这些乘以需要支持的平台的“动物园”，然后得到类似Babel拥挤的表象，这根本无法“正常地做”并产生收入。 平台的开发通常是并行进行的，相同的功能可能要在几个月后才能在不同的平台上进行。
每个平台的单独布局集传统上，我们从设计系统将有助于解决和提出其设计要求的问题开始。 除了创建单一的视觉语言，提高原型开发和开发的速度，提高整个产品的质量外，至关重要的是尽可能地使设计统一。 这是必要的，以便可以同时在我们所有平台上立即开发功能：Web，iOS，Android，Smart TV，tvOS，Android TV，Windows 10，xBox One，PS4，Roku-无需分别对它们进行单独处理。 而我们做到了！
设计→数据
达成产品和开发部门的主要协议后，我们坐下来选择技术堆栈并研究整个过程的细节-从布局到发布。 为了完全自动化将设计转移到开发的过程，我们使用带有布局参数的Sketch文件中的组件参数解析器直接研究了该选项。 事实证明，找到我们需要的代码段并提取我们需要的参数是一项复杂而危险的工作。 首先，设计人员在命名源代码的所有层时必须格外小心，其次，它仅适用于最简单的组件，其次，对其他人的技术和原始Sketch布局的代码结构的依赖危及整个项目的未来。 我们决定放弃这一领域的自动化。 因此，第一个人出现在设计系统团队中，在该人的入口处提交了设计布局，并在输出端-数据描述了组件的所有参数，并根据原子设计方法进行了分层排序。
问题仍然很小：在何处以及如何存储数据，如何将其传输到开发中以及如何在我们支持的所有平台上的开发中解释数据。 晚上不再变得乏味……由每个平台的设计师和团队负责人组成的工作组例行会议的结果是达成了以下协议。
我们将视觉手动解析为原子元素：字体，颜色，透明度，缩进，圆角，图标，图片和动画持续时间。 然后，我们从该按钮，输入，复选框，银行卡小部件等中收集信息。我们将非语义名称分配给任何级别的样式，但图标除外，例如城市名称，若虫的名称，口袋妖怪，汽车品牌……只有一种情况-列表不应该早些用尽，什么样式将以-结束桅杆展示他！ 例如，您不应该被语义所困扰，因此不必在“小”和“中”之间添加中间按钮。
视觉语言
开发人员不得不考虑如何存储和传输数据，以使其适合所有平台，并且设计必须设计界面元素，这些元素看起来同样不错，并且可以在整个支持的设备系列中有效地工作。
早些时候，我们设法“运行”了Windows 10应用程序中的大多数设计元素，当时这对我们来说是一个新平台，也就是说，需要从头进行渲染和开发。 通过绘制它，我们能够准备和测试大多数组件，并了解将来的Ivy设计系统中将包括哪些组件。 没有这样的沙箱，只有在已经运行的平台上进行大量迭代才能获得这样的体验，而这将花费一年多的时间。
在不同平台上重复使用相同的组件有时会减少设计系统的布局数量和数据阵列，因此设计必须解决产品设计和开发实践中未曾描述过的另一个问题-例如，如何在电视上重新使用手机和平板电脑的按钮？ 在这样的不同平台上，字体和元素的大小原则上应该是什么？
显然，有必要设计一个跨平台的模块化网格，该网格将设置每个特定平台所需的文本和元素大小。 对于网格的参考点，我们选择了要在特定屏幕上观看的电影海报的大小和数量，并在此基础上制定了构造网格列的规则，条件是一列的宽度等于海报的宽度。
现在，您需要将所有大屏幕都放到相同的布局尺寸，并将它们放到常规网格中。 Apple TV和Roku的尺寸为1920x1080，Android TV-960x540，Smart TV，具体取决于不同的供应商，并且尺寸为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属性为rounding: 8 ，Windows 10应用程序将转换为CornerRadius="8" ，网络border-radius: 8px ，Android- android:radius="8dp" ，iOS- self.layer.cornerRadius = 8.0 。
OffsetTop offsetTop: 12相同的Web客户端可以在不同情况下解释为top ， margin-top ， padding-top或transform
该描述的声明性性质还表明，如果平台在技术上无法使用任何属性或其值，则可以忽略它。 在术语方面，我们制作了一种世界语：我们从Android中获取了一些东西，从SVG中获取了一些东西，从CSS中获取了一些东西。
如果有必要在特定平台上以其他方式显示元素，我们已经实现了将相应的数据生成作为单独的JSON文件传输的功能。 例如，对于Smart TV，状态为“焦点对准”，它指示了文字在海报下的位置发生了变化，因此对于此平台，“ indent”属性值中的此组件将包含其所需的8个缩进点。 尽管这使设计系统的基础结构复杂化，但它提供了额外的自由度，使我们有机会自己管理平台的视觉“差异”，而不会成为我们创建的体系结构的人质。
象形图
数字产品中的图像学总是一个庞大而又不容易的子项目，通常有一个单独的设计师。 字形总是很多，每个字形都有几种大小和颜色，此外，平台通常需要它们以不同的格式显示。 通常，没有理由不将所有这些内容带入设计系统。
字形以矢量SVG格式加载，颜色值自动替换为变量。 客户端应用程序可以使它们随时可用-任何格式和颜色。
预览版
在带有数据的JSON之上，我们编写了一个预览组件的工具-一个JS应用程序，该应用程序通过其标记和样式生成器即时传递JSON数据，并在浏览器中显示每个组件的各种变体。 实际上，预览与平台应用程序是完全相同的客户端，并且使用相同的数据。
通过与特定组件的交互，最容易理解它的工作方式。 因此，我们没有使用Storybook之类的工具，而是进行了交互式预览-您可以触摸，悬停，单击....将新组件添加到设计系统时，它会出现在预览中，以便平台在引入新组件时可以重点关注。
该文件
根据以JSON形式传送到平台的数据，将自动生成组件文档。 描述了属性列表以及每个属性中可能的值类型。 自动生成后，可以手动澄清信息，添加文本描述。 预览和文档在每个组件级别都具有相互引用的关系，并且文档中包含的所有信息都可以通过其他JSON文件的形式提供给开发人员。
弃用者
另一个需求是能够随着时间的推移更换和升级现有组件。 设计系统已经学会了告诉开发人员哪些属性甚至整个组件无法使用，并在不再在所有平台上使用它们后立即将其删除。 在此过程中仍然有很多“体力劳动”，但我们并没有停滞不前。
客户发展
毫无疑问，在我们支持的所有平台的代码中对设计系统数据的解释成为了复杂性最广泛的阶段。 例如，如果网络上的模块化网格不是新的，则iOS和Android本地移动应用程序的开发人员在弄清楚如何使用它之前会汗流hard背。
对于iOS应用程序屏幕的布局，我们使用iviUIKit提供的两种基本机制：元素的自由布局和元素集合的布局。 我们使用VIPER，与iviUIKit的所有交互都集中在View中，而与Apple UIKit的大部分交互都集中在iviUIKit中。 元素的大小和排列是根据在本机iOS SDK常量之上工作的列和语法构造指定的，从而使它们更易于应用。 使用UICollectionView时，这尤其简化了我们的生活。 我们为布局编写了一些可自定义的布局，包括相当复杂的布局。 客户端代码最少，并且变成了声明性代码。
为了在Android项目中生成样式，我们使用Gradle将设计系统数据转换为XML格式样式。 同时，我们有几个不同级别的生成器：
- 基本的 。 解析高级生成器的原语数据。
- 资源 。 下载图片，图标和其他图形。
- 组成部分 它们是为每个组件编写的，描述了哪些属性以及如何将其转换为样式。
应用发布
在设计人员绘制了新组件或对现有组件进行了重新设计之后，这些更改将落入设计系统。 每个平台的开发人员都在完成其代码生成，以提供对更改的支持。 此后，可以在需要此组件的新功能的实现中使用它。 因此，与设计系统的交互不是实时发生的，而只是在组装新版本时发生的。 这种方法还使您可以更好地控制数据传输过程，并保证客户端开发项目中代码的性能。
总结
很快，作为设计系统，一年就成为了服务常春藤在线电影院发展的基础设施的一部分，并且可以得出一些结论：
- 这是一个庞大而又难以实施的项目，需要不断分配资源。
- 这使我们能够创建自己独特的跨平台视觉语言，从而满足在线视频服务的目标。
- 我们不再拥有外观和功能落后的平台。
预览常春藤设计系统的组件
-design.ivi.ru