Compose Preview 的 UX 设计之旅

本文由来自 Android Developer UX 团队的 Preethi Srinivas (UX 研究员) 和 Paris Hsu (交互设计师) 所撰写。

Jetpack Compose 刚刚进入 测试阶段 啦！🎉 在此激动人心的时刻，Android Developer UX 团队想邀请您进入咱们的世界，走进咱们设计 Compose Preview 的设计之旅，旅程将从理解咱们面临的挑战、方向的造成，以及原型设计和评估开始。

背景: 理解挑战

Jetpack Compose 是新一代 Android 开发的 UI 工具包，它可更简单高效地构建出精美且性能卓越的 Android 应用。它使用了直观的 Kotlin API，可以作到 UI 随着应用状态的变化而自动更新。当咱们的团队第一次据说这个项目时，咱们无比期待 Compose 项目的无限可能，它具备将逻辑和数据混合绑定到 UI 的潜力，以及为开发者解锁新的能力。然而，这种新的构建 UI 方式也带来了新的设计挑战。

对于经典的 Android 视图，UI 是静态的，且主要是经过 XML 进行建立。这意味着对 XML 的更改几乎能够当即在 UI 中反映出来，咱们能够根据这种特性来构建像 Layout Editor 这样的使用体验，让开发者们经过可视化的拖放操做来编辑他们应用的布局，相应的更改也会自动映射到对 XML 的更改。然而，使用 Compose 的每一次修改，都必须编译 Kotlin 代码才能反映出变化，这就意味着须要花费时间，从而减慢了迭代和建立的过程。

集思构想: 冲刺设计方案

为了探究如何在 Compose 中支持这种开发 UI 代码的新模式，咱们团队和咱们的软件工程师、开发者关系工程师和产品管理伙伴一块儿举办了一个研讨会，以解决一个设计挑战: 咱们如何利用开发者对现有工具的使用经验来帮助他们建立和掌握 Compose UI？

咱们基于 设计思惟方法，从理解问题和调整问题的工做场景开始思考。这一过程须要团队在 "咱们能够怎样... (How Might We…)" 这一框架下写出本身的想法，而后经过亲和图法 (affinitized) 去识别和提炼这些手头的设计问题。咱们以以前的研究为出发点，将本身想象为开发者，结合实际开发过程会遇到的不一样阶段，来引导小组进行思考，并绘制出解决方案的工具草图。

Compose 设计研讨会

这一设计研讨会帮助咱们总结了几点核心原则，为 Compose Tooling 在 2020 年和以后的发展路线奠基了基础:

• 基于以往为 XML 构建工具所积累的经验为基础
• 围绕代码进行界面的绘制
• 优化迭代和实验

这些原则构成了咱们产品设计理念前进的基础。例如，Compose Preview 构建出的使用体验在外观和使用上都会让用户以为很熟悉，在此之上还补充了 Compose 的范式，经过轻量且可重复利用的 Composable 来构建布局。设计研讨会还鼓励咱们更多地以代码为中心构建出 REPL 的编程环境，使得开发者在预览代码时拥有更多的控制权和灵活性 — 这样在本质上就提供了一个支持迭代、实验和学习的交互式编程环境。咱们还设想了提供超越 XML 以外的新体验，例如 Interactive Preview (互动预览)，它能够支持在 IDE 内部被隔离的沙盒环境下的实时交互；Deploy Preview (部署预览)，用于在不从新运行整个应用的前提下，将 Preview Composable 部署到模拟器或者真机上。

原型设计: 早期验证

为了验证咱们的假设和设计路径，咱们开始对研讨会中的想法进行原型设计，并在用户研究案例中对其进行测试。咱们开设了一些研究，以即可以验证当前的方向是否正确，并获取关于将来想法和相关投入的反馈。咱们选择了一种迭代方法来获取反馈，从而在涉及其余与 Compose 相关主题的多个研究中，将与 Preview 相关的主题进行了折叠。

例如，为了解 Compose Preview 的使用体验，咱们首先列出开发者将会问出的问题:

• 开发者该如何使用 Compose Preview？
• 在什么状况下，开发者想要预览动态交互的效果？
• 在真机或模拟器上部署隔离式 Composable 并与之交互的功能对开发者的帮助程度如何？

咱们邀请了开发者来加入咱们的 Coding Session，在一个以研究为目的而建立的 Compose 项目中完成一些简单的编程练习。这种方式节省了配置开发环境的时间和精力，尤为是 Compose 仍处于开发者预览版以前的阶段，这一方法还可以帮助咱们关注开发者在使用 Preview 和其余 Compose API 时的体验。早期的研究确实须要围绕产品稳定性的问题进行展开，由于 Preview 并不是总能按照预期正常工做。研究计划预见到了这些不可避免的问题，同时也可以提供很是早期的洞察。

经过 Coding Session 进行可用性研究

从这些 Session 中咱们发现，一些开发者会在区分 Preview 工具栏上的 "Refresh" 图标和横幅中的 "Refresh & Build" 图标时感到困惑。大多数开发者不会意识到 "Refresh" 只更新代码而不须要完整构建，而 "Refresh & Build" 则会经过构建更新所有修改。

"若是 Refresh 和 Refresh & Build 但愿保持一致，那么将它们放在一块儿会更好 — 我最初觉得 Refresh 按钮只会刷新 UI 而不会构建项目。"

预览 Refresh & Build (以前和以后)

获得该反馈以后，咱们决定将二者统一块儿来，并改进了体验，当用户点击图标或者横幅时，Preview 会根据代码变化的状况来肯定是须要进行刷新仍是从新构建。

从早期几轮开发者参与的研究中，产生了一个对于 Compose Preview 的深入体会是，开发者在 Compose 中进行 UI 原型设计时，会感觉到一种掌控感，以及工做效率的提高。

" Refresh 模式让我能够快速完成 UI 的原型设计。加上可使用功能强大的 Kotlin 建立 UI，以及利用 @Preview 函数展现实例数据，比起老式的 XML 中提供的命名空间助手要好得多。"

咱们还感觉到了开发者在发现 Preview 中同 Composable 交互时可以导航到对应的代码这一功能时，他们所感到的惊讶和喜悦。

"我才发现这个功能，很是开心，我能够在 Preview 中点击不一样的视图，直接跳转到绘制该视图的代码里。我很期待在 Jetpack Compose 中看到更多相似的功能。"

在可用性研究中，咱们观察到开发者们会经过在 Preview 中点击不一样的 UI 元素来跳转到项目的不一样地方 — 这须要人们对 Preview 中的 UI 层次结构有着较为深入的理解。一些开发者发现，当在 Compose Preview 和代码导航之间进行交互时，会有错位的问题出现。例如，在 Column 中的 Text Composable 区域以外点击，会跳转到代码编辑器中定义 Column 的那一行中去。于是咱们经过提供 Composable outline 来加强 Preview 的使用体验，以便在布局中围绕 Composable 提供功能可见性。

Preview 代码跳转功能

沉浸式: 以日记形式进行记录

相对而言，在现场亲自参与可用性研究更容易创造价值，并激发出新的想法。然而因为时间的限制，很难深刻地去对主题进行挖掘。所以，咱们调整了研究方法，开始更多使用一种远程技术，让开发者本身对某个 Compose 项目进行几周的使用。这段时间内，开发者须要写日记，记录他们在指定项目或者本身项目中关于工做流程上的一些问题。一般咱们还会在几周的探索以后，再搭配一次访谈，目的是为了更好了解开发者日记中的具体内容。在几天的探索以后，咱们还邀请了一些开发者经过 Google Meet 的 Coding Session，来观察并肯定哪些部分的工做是进展顺利的，以及一些能够被改进的地方。

经过提问式的日记来帮助反馈的获取

在这些研究中出现了一点共性 — 开发者会使用 Preview 来建立工做流程，还会利用它进行一些故障排除/验证的工做。例如，在建立 UI 时，开发者会更倾向于使用 Refresh 模式，而在使用手势/交互时，他们会切换到 Interactive 模式，至于 Deploy 模式，则最经常使用于故障排除和验证检查。

"当我发如今 Interactive 模式下长按能够显示星星的动画时，我很是的开心。可是，以后的长按操做就无论用了 — 动画不再出现了。经过在模拟器上部署 Preview 模式，我能确认动画是能够正常工做的。若是 Interactive 模式可以更加稳定的话，它将会成为我测试交互性功能和动画的首选模式。有趣的是，在建立新的 UI 并查看它们的渲染方式时，我大部分时间都不须要使用它。"

此外，咱们从一些开发者那里获得反馈，在考虑整个布局以前，可以提取并集中实现一个单独的 Composable 的重要性。

"只部署 Preview 意味着我不须要为了测试一个新的组件，而把 UI 关联到实际的流程中 (包含多个界面和用户输入)。这样使得调试 + 改变复杂 UI 变得更加容易。"

将想法付诸于行动

咱们在研究的基础之上确立了要前进的方向，这有助于将开发人员对咱们工具的看法和遇到的问题反馈到咱们的产品迭代中 — 同时能确保咱们也可以捕获到新兴的主题来塑造咱们的设计理念。如下是几个示例:

Preview 新用户的使用体验

咱们发现开发者在探索如何开始建立 Preview 时会有困难 — 不少人在示例项目中留意到了 Preview，可是在本身的项目中就不可以复刻出相似的使用体验。不直观的设计每每致使在建立 Preview Composable 时，对 Compose 编译器到底支持什么功能而产生误解。例如，咱们观察到一些开发者试图预览一个接受参数的 Composable，而这一功能 Compose 是不支持的。在这种状况下，编译器提供的错误信息每每会被忽略或遗漏。

"我没法在 Preview 中显示 Split 视图，即便我是直接从一个示例项目中复制过来的代码，它也没法让 Preview 注解正常工做。"

这一重要的发现使咱们引入了默认状态，若是 Kotlin 文件还没有定义 Preview Composable，那么拆分编辑器 (这一律念源于 View/XML 世界中的 Preview) 则始终处于可见状态。咱们相信该解决方案不只能够提升对 Preview 的认知和发现能力，还能够提供建立和操做 Preview 相关的学习经验。

Preview 默认状态

加强编码体验

在调查研究中，开发者问了咱们这样几个问题:

• 如何在浅色和深色主题背景中预览一个布局？
• 如何利用样本数据预览一个布局？
• 我如何利用 Preview 来肯定个人代码中在哪定义了某个特定的 UI 元素？
• 有没有一种方法可让 Compose 模仿 View/XML 世界中的 Preview 使用体验，特别是在 Preview 中如何快速查看由于代码变化产生的视觉变化？

这些问题都指向了一点 — 开发者正在寻找一种快速简单的机制来操做 Preview，并指望它能更快地进行迭代。

咱们将继续对开发者反馈的新功能进行原型设计和测试，例如 Preview Configuration Picker (Preview 配置选择器)，它容许开发者可视化地配置他们的布局 (例如在不一样的主题、设备、语言等)，以提升 @Preview API 的可发现性和可学习性。

Preview 配置选择器

另外一个例子是 Live literals (实时显示字面量类型)，这是来自工程团队的解决方案，经过在 Preview 面板中对一些 Composable 值 (例如 Boolean、Char、String、Color 等) 引入实时更新，来优化迭代开发的速度。

Live Literal 的实际体验

PreviewParameterProvider 是咱们将样本数据归入 Preview 中来容许真实上下文测试的又一例子。

使用 PreviewParameterProvider

旅程仍未结束

咱们但愿这篇文章能让您了解咱们是如何根据您的反馈来改进 Compose Preview 的。固然，咱们的旅程并无就此结束！咱们还有不少继续改善 Compose Preview 及其工具使用体验的计划。例如，将 Live Literals 功能扩展到字面量类型以外，以继续优化迭代开发的速度。

若是您在使用 Compose 工具时遇到问题，或者是有任何能够改善使用体验的新功能的想法，请 告诉咱们。咱们也在寻找开发者参与到用户研究 Session 中，您能够 注册 参与。