本文讨论的是如何将 UED 的设计标准化体系在研发侧进行落地,以及我们对“超级 App 实现暗黑模式的最佳实践”这一问题的深度思考。
我们的目的是对 Android 和 iOS 的系统新增特性–暗黑模式进行适配。暗黑模式本质上是一个视觉模式,而视觉模式的适配对于业务复杂,页面众多的超级 App 来说一直是个工作量繁重的需求。
下面我们来看看,在设计标准化体系建立之前,优酷客户端是怎么实现视觉还原的工作的。
一、各自为战:前"设计标准化"时代的视觉还原工作
每一年,优酷 App 都会优化体验设计,对整个 App 的视觉呈现进行改版。视觉改版工作分配到各个团队的技术同学手中,有三种主要的实现方式。
第一种:
通过服务端下发视觉模式标记,客户端通过解析该标记的配置,转化成对每一个视图的代码设置。一个视图在某个视觉模式对应的代码设置在开发时就确定了。
第二种:
服务端下发一套视觉样式的 Key-Value 值,客户端预先写好视觉样式的 Key 和视图元素的对应关系,在客户端渲染时,通过这个 Key 在服务端数据中找到对应的 Value 并设置给视图元素。
第三种:
依赖于原生的资源加载器,不同的视觉模式对应不同的资源文件。
横向对比来看,方案一的设计最简单,完全取决于需求,典型的推一下走一步。方案二落地成本最高,需要对每一个视图增加响应配置的能力实现,开发的自由度最低,每个业务的开发都需要遵守相同数据协议完成相同的动作。而且它只能控制接入了这一视觉样式实现的业务,是渲染时方案,无法影响到 XML 形式的布局文件,只能在运行时才能看到效果。但是它的好处是变更成本较低,可以动态的修改服务端模版并下发到客户端页面。
对于方案三,则最符合原生开发习惯,也有最全面的开发工具支持,在编写布局文件时就能看到效果。但缺点是写完了就固定了,变更成本非常高。
为此,UED 和研发同学共同研发了优酷统一的设计标准化开发体系,携手迈进了“设计标准化”时代。
二、最简即最优 - "设计标准化"的设计原则
在确定设计标准化技术方案之前,我们还需要确定设计原则。
我们的原则是:
简单,准确,全面,具备一定的动态性的设计体系
1、简单 是因为视觉模式适配在超级 App 落地涉及的团队非常多,而大家的技术栈各有不同,极具差异性,所以希望技术方案贴近系统原生实现,清晰且简单,才能让大家容易接受,才不会和不同团队的的既有技术方案产生冲突。技术方案可以叠加但不能冲突,不然落地的时间遥遥无期。
2、准确 是因为视觉模式适配涉及的页面非常多,参与的设计和开发同学也非常多。如何统一地把控总体的效果,不在落地的过程中发生变异,就需要一个唯一且准确的标尺。这样,在开发中若出现设计或需求的修改,也能够快速响应。
3、全面 是因为视觉模式适配的页面中,不仅有 Android/IOS 这样的 native 页面,还有 Weex/H5 等动态页面,未来还可能有 Flutter,小程序这种新兴势力。所以一定要设计一个全面的技术方案。另外,我们希望我们的方案可以输出到文娱其他团队,供集团其他 BU 甚至外部公司参考。所以最终的技术方案一定是具有通用性的。
4、动态性 是考虑到可能需要服务端下发设计配置信息,或者针对不同页面做定制。
5、设计体系。在前“设计标准化”时代,设计和开发同学的工作是割裂的,通过视觉稿上的标注进行沟通。开发不对设计效果负责,设计往往都要在开发工作完成之后才能看到设计效果,然后设计再找开发修改,再 Review,形成循环。这是纵向的割裂。另外,还存在着横向的割裂,同样的设计在不同的应用场景要重复循环,而不同的设计和开发可能在最终的效果上有不同的表达形式和标注,造成 App 风格的不统一,降低用户体验。所以希望我们的技术方案能够减少这些 Gap,形成完整的设计体系。
三、"设计标准化"时代的视觉还原工作
下面,为大家介绍我们现在的方案——设计标准化体系。
我们和设计同学一起对线上的产品进行了摸底,归纳抽象出了其中具有共性的设计,站在全站的高度,共同搭建了设计产品化能力。把影响视觉风格调性的基础属性(颜色、字号、间距、圆角、尺寸)进行了统一的命名(DesignToken),设计与开发团队共同维护一套可扩展的视觉属性。视觉属性与框架布局分离,并与开发逻辑相互对应,通过集中式的 SDK 统一管理,一处替换全端生效,便于统一控制并快速修改产品风格。
在 App 视觉还原的具体工作上, 设计同学负责确定界面的色彩框架,形成设计规范,建立模式色板。而研发同学则不再像以往一样,根据视觉稿上具体的数值进行开发,改为根据 DesignToken 的语义名进行开发,而且通过多级的视觉开发代码复用,最大程度的减少具体业务组件的适配工作,将适配开发改为了页面走查,且只需要走查没有纳入或使用 DesignToken 的场景。
另外,我们考虑到语义化名字在设计和开发之间的自然流转,还修改和增强了设计开发工具。将之前直接标注数值在视觉稿上的方式,改为了输出 DesignToken 和示例代码在标注上。在不给设计同学增加标注成本的前提下,大大减少了设计和开发的沟通成本。
设计侧同学对标准化设计体系的思考,可以参看《优酷的设计标准化体系建设》,这里不再赘述。
下面,我们从开发的角度介绍一下设计标准化体系的具体实现,以及设计标准化体系上线之后,优酷是怎么实现暗黑模式的。
1、以 Android 为例,以下是我们的设计标准化整体架构图:
在代码的工程结构上,也体现了设计标准化体系的分层思想,分为了属性,控件,组件和容器四层,每一层都是基于其下一层的 DesignToken 搭建而成,层层叠加,最终构成完整的页面。
以 Android 为例,我们将 DesignToken 的设计翻译为 Android 的具体技术实现:
1)我们定义了很多基础属性:
下面是几个基础属性的例子:
2)在布局文件和代码中直接使用这些基础属性
上面就是 Android 业务代码使用公共资源库的代码示例。
2、对于 iOS 来说,我们将 DesignToken 的设计翻译为 iOS 的具体技术实现
1)我们定义了很多基础属性:
以色彩属性为例:
2)在代码中直接使用这些基础属性
得益于我们对现有设计的抽象和归纳,这些公共样式的布局文件是由专人提前开发完成,业务开发同学只要直接使用就可以了。对于实际的业务开发同学来说,他们不需要再关注设计的细节,设计和开发都是基于共同的 DesignToken 展开工作。
3)设计同学可以通过对 DesignToken 底层定义的控制,把控整个 App 设计的实现效果。
四、设计标准化体系在优酷落地的意义
设计标准化体系在优酷的最终落地,极大地提高了优酷设计和研发团队的工作效率。
1、统一管控
所有的页面都是基于统一的 DesignToken 来实现的,可以做到“一处修改,到处生效”。如果未来出现所谓的“红色模式”,“蓝色模式”,我们有信心在非常短的时间之内完成整个优酷 App 的视觉换新工作。
2、节省人力
所有的设计和开发同学都基于统一的设计语言沟通,极大地减小了交流成本。在版本迭代的末期,设计同学需要对视觉效果做微调和修改时,其作用尤为显著。
3、方便开发
现在优酷 App 中可以使用的 UI 基础属性全部属于一个受控的 DesignToken 集合,业务开发同学不需要关心和理解设计的具体细节,只需要将视觉稿翻译为 Android/iOS 原生实现即可; 不再需要反复确认设计稿细节和反复微调来还原视觉效果。
经过优酷数个版本的迭代,对比原有的开发模式,大部分设计和研发同学都感受到了设计标准化的强大威力,也认可了新的基于设计标准化的工作流。因此,优酷的设计标准化体系的持续开发一定会坚持下来,继续演进和迭代,支持更多的场景,支撑更多的大文娱业务。
究竟设计标准化体系的威力有多么强大呢?暗黑模式的落地是一个最好的 Case。有了设计标准化体系打下的良好的基础,优酷 App 的暗黑模式的开发工作总体上是很顺利的。业务开发同学反映工作量比预期的少很多,设计同学视觉走查的结果是仅仅发现了很少量的视觉问题,这也反映出设计标准化体系和暗黑模式的技术方案设计比较完善,组件标准化的覆盖率达到相当高的程度。
下面,我们分 Android、iOS、Weex&H5 三篇文章,各自介绍我们是怎样基于设计标准化体系,完成“暗黑模式”的技术支撑方案。
作者简介:
涵父,阿里文娱无线开发专家。
相关阅读:
评论