Compose Preview 的 UX 設計之旅

時間 2021-05-07

標籤 android 編程框架編輯器 ide 函數工具 oop 佈局性能欄目 Android 简体版

原文原文鏈接

本文由來自 Android Developer UX 團隊的 Preethi Srinivas (UX 研究員) 和 Paris Hsu (交互設計師) 所撰寫。android

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？ide

咱們基於設計思惟方法，從理解問題和調整問題的工做場景開始思考。這一過程須要團隊在 "咱們能夠怎樣... (How Might We…)" 這一框架下寫出本身的想法，而後經過親和圖法 (affinitized) 去識別和提煉這些手頭的設計問題。咱們以以前的研究爲出發點，將本身想象爲開發者，結合實際開發過程會遇到的不一樣階段，來引導小組進行思考，並繪製出解決方案的工具草圖。函數

Compose 設計研討會

這一設計研討會幫助咱們總結了幾點核心原則，爲 Compose Tooling 在 2020 年和以後的發展路線奠基了基礎:工具

基於以往爲 XML 構建工具所積累的經驗爲基礎
圍繞代碼進行界面的繪製
優化迭代和實驗

這些原則構成了咱們產品設計理念前進的基礎。例如，Compose Preview 構建出的使用體驗在外觀和使用上都會讓用戶以爲很熟悉，在此之上還補充了 Compose 的範式，經過輕量且可重複利用的 Composable 來構建佈局。設計研討會還鼓勵咱們更多地以代碼爲中心構建出 REPL 的編程環境，使得開發者在預覽代碼時擁有更多的控制權和靈活性 — 這樣在本質上就提供了一個支持迭代、實驗和學習的交互式編程環境。咱們還設想了提供超越 XML 以外的新體驗，例如 Interactive Preview (互動預覽)，它能夠支持在 IDE 內部被隔離的沙盒環境下的實時交互；Deploy Preview (部署預覽)，用於在不從新運行整個應用的前提下，將 Preview Composable 部署到模擬器或者真機上。oop

原型設計: 早期驗證

爲了驗證咱們的假設和設計路徑，咱們開始對研討會中的想法進行原型設計，並在用戶研究案例中對其進行測試。咱們開設了一些研究，以即可以驗證當前的方向是否正確，並獲取關於將來想法和相關投入的反饋。咱們選擇了一種迭代方法來獲取反饋，從而在涉及其餘與 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 的可發現性和可學習性。