本文由来自 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 中，您能够 注册 参加。