Compose Preview's UX design journey

This article was written by Preethi Srinivas (UX researcher) and Paris Hsu (interaction designer) from the Android Developer UX team.

Jetpack Compose has just entered the testing phase ! 🎉 At this exciting moment, the Android Developer UX team would like to invite you to enter our world and walk into our design journey of Compose Preview. The journey will start with understanding the challenges we face, the formation of directions, and prototyping and evaluation .

Background: Understanding the Challenge

Jetpack Compose is a new generation of Android development UI toolkit, which can build beautiful and high-performance Android applications more simply and efficiently. It uses the intuitive Kotlin API, which can automatically update the UI as the application state changes. When our team first heard about this project, we looked forward to the infinite possibilities of the Compose project, which has the potential to bind logic and data to the UI, and unlock new capabilities for developers. However, this new way of building UI also brings new design challenges.

For classic Android views, the UI is static and is mainly created through XML. This means that changes to XML can be reflected in the UI almost immediately. Based on this feature, we can build Layout Editor , allowing developers to edit the layout of their applications through visual drag-and-drop operations , The corresponding changes will also be automatically mapped to the changes to the XML. However, every time you use Compose, you must compile the Kotlin code to reflect the change, which means it takes time, which slows down the iteration and creation process.

Brainstorming Ideas: Sprint Design Plan

In order to explore how to support this new model of UI code development in Compose, our team and our software engineers, developer relations engineers and product management partners held a seminar to solve a design challenge: How do we use development Do they have experience in using existing tools to help them create and master Compose UI?

Based on the design thinking method , we start thinking from the work scenario of understanding the problem and adjusting the problem. This process requires the team how can we... (How Might We…) ", and then use the affinity graph method ( affinitized ) to identify and refine these at hand Design issues. We took the previous research as the starting point, imagined ourselves as a developer, combined with the different stages encountered in the actual development process, to guide the group to think, and draw the tool sketch of the solution.

Compose Design Workshop

This design seminar helped us summarize a few core principles and laid the foundation for Compose Tooling's development path in 2020 and beyond:

• Based on previous experience accumulated for XML building tools
• Draw the interface around the code
• Optimization iterations and experiments

These principles form the basis for the advancement of our product design concept. For example, the user experience built by Compose Preview will make users feel familiar in appearance and use. On top of this, Compose's paradigm is added, and the layout is constructed through the lightweight and reusable Composable. The design seminar also encouraged us to build the REPL programming environment more code-centric, so that developers have more control and flexibility when previewing the code—this essentially provides a support for iteration, An interactive programming environment for experimentation and learning. We also envisage to provide new experiences beyond XML, such as Interactive Preview (interactive preview), which can support real-time interaction in a sandbox environment isolated inside the IDE; Deploy Preview (deployment preview), for Under the premise of running the entire application, deploy Preview Composable to the emulator or real machine.

prototype design: early verification

In order to verify our hypothesis and design path, we began to prototype the ideas in the seminar and test them in user research cases. We set up some studies so that we can verify whether the current direction is correct and get feedback on future ideas and related inputs. We chose an iterative approach to obtain feedback, and thus folded the topics related to Preview in multiple studies involving other topics related to Compose.

For example, in order to understand the experience of using Compose Preview, we first list the questions that developers will ask:

• How should developers use Compose Preview?
• Under what circumstances do developers want to preview the effects of dynamic interactions?
• How helpful is the function of deploying and interacting with isolated Composable on a real machine or simulator to developers?

We invited developers to join our Coding Session and complete some simple programming exercises in a Compose project created for research purposes. This method saves the time and effort of configuring the development environment, especially Compose is still in the stage before the developer preview. This method can also help us pay attention to the developer's experience when using Preview and other Compose APIs. Early research really needs to be carried out around the issue of product stability, because Preview does not always work as expected. The research plan anticipates these inevitable problems and can also provide very early insights.

Usability research through Coding Session

From these sessions, we found that some developers are confused when distinguishing the "Refresh" icon on the Preview toolbar from the "Refresh & Build" icon on the banner. Most developers will not realize that "Refresh" only updates the code and does not require a complete build, while "Refresh & Build" will update all changes through the build.

"If Refresh and Refresh & Build want to be consistent, it would be better to put them together — I initially thought that the Refresh button would only refresh the UI and not build the project."

Preview Refresh & Build (before and after)

After getting this feedback, we decided to unify the two and improve the experience. When the user clicks on the icon or the banner, Preview will determine whether it needs to be refreshed or rebuilt according to the code changes.

From the early rounds of research involving developers, I have a deep understanding of Compose Preview that developers will feel a sense of control and work efficiency when prototyping UI in Compose.

" Refresh mode allows me to quickly complete the UI prototyping. In addition, I can use the powerful Kotlin to create the UI, and use the @Preview function to display instance data, which is much better than the namespace helper provided in the old XML. "

We also felt the surprise and joy that developers felt when they discovered that they were able to navigate to the corresponding code when interacting with Composable in Preview.

"I just discovered this feature and I am very happy. I can click on a different view in Preview and jump directly to the code that draws that view. I am looking forward to seeing more similar features in Jetpack Compose."

In usability research, we have observed that developers will jump to different parts of the project by clicking on different UI elements in Preview-this requires people to have a deeper understanding of the UI hierarchy in Preview. Some developers have found that when interacting between Compose Preview and code navigation, there will be misalignment issues. For example, clicking outside the Text Composable area in Column will jump to the line where Column is defined in the code editor. Therefore, we enhance the preview experience by providing Composable outline to provide functional visibility around Composable in the layout.

Preview code jump function

Immersive: Record in the form of a diary

In contrast, it is easier to create value and stimulate new ideas by personally participating in usability research on the spot. However, due to time constraints, it is difficult to dig deeper into the subject. Therefore, we adjusted our research methods and began to use a remote technology more, allowing developers to use a certain Compose project for several weeks. During this time, developers need to write a diary to record some of their work process problems in the designated project or their own projects. Usually we will also match an interview after a few weeks of exploration, in order to better understand the specific content of the developer's diary. After several days of exploration, we also invited some developers through the Coding Session of Google Meet to observe and determine which parts of the work are progressing smoothly, as well as some areas that can be improved.

Help get feedback through a question-style diary

There is a little commonality in these studies-the developer will use Preview to create the workflow, and will also use it for some troubleshooting/verification work. For example, when creating a UI, developers will be more inclined to use the Refresh mode, and when using gestures/interactions, they will switch to the Interactive mode. As for the Deploy mode, it is most commonly used for troubleshooting and verification checks.

"When I found out that long-pressing in Interactive mode can display the animation of stars, I was very happy. However, the subsequent long-pressing operations no longer work — the animation no longer appears. By deploying Preview mode on the simulator, I can confirm that the animation works properly. If the Interactive mode can be more stable, it will become my preferred mode for testing interactivity and animation. The interesting thing is that when creating a new UI and checking how they are rendered, I don’t need to use it most of the time."

In addition, we have received feedback from some developers, before considering the entire layout, to be able to extract and focus on the importance of a single Composable.

"Only deploying Preview means that I don't need to associate the UI with the actual process (including multiple interfaces and user input) in order to test a new component. This makes debugging + changing complex UI easier."

Put ideas into action

We have established the direction we want to move forward on the basis of research, which helps to feed the developers’ insights and problems encountered by our tools into our product iterations — at the same time ensuring that we can also capture emerging themes To shape our design philosophy. Here are a few examples:

Preview New user experience

We found that developers have difficulty exploring how to start creating Preview — many people have noticed Preview in the sample project, but they cannot replicate a similar experience in their own projects. Unintuitive design often leads to misunderstandings about what functions the Compose compiler supports when creating Preview Composable. For example, we have observed that some developers try to preview a Composable that accepts parameters, and this feature is not supported by Compose. In this case, the error information provided by the compiler is often ignored or omitted.

"I can't display the Split view in Preview. Even if I copied the code directly from a sample project, it cannot make the Preview annotation work."

This important discovery led us to introduce the default state. If the Kotlin file has not yet defined Preview Composable, then the split editor (this concept is derived from Preview in the View/XML world) is always visible. We believe that this solution can not only improve the awareness and discovery capabilities of Preview, but also provide a learning experience related to the creation and operation of Preview.

Preview default state

Enhanced coding experience

In the investigation and research, the developer asked us several questions:

• How to preview a layout in light and dark theme backgrounds?
• How to preview a layout using sample data?
• How can I use Preview to determine where a specific UI element is defined in my code?
• Is there a way for Compose to imitate the Preview experience in the View/XML world, especially how to quickly view the visual changes caused by code changes in Preview?

These questions all point to one point-developers are looking for a fast and simple mechanism to operate Preview, and expect it to iterate faster.

We will continue to prototype and test the new features that developers feedback, such as Preview Configuration Picker (Preview Configuration Picker), which allows developers to visually configure their layout (for example, in different themes, devices, languages, etc.), To improve the discoverability and learnability of @Preview API.

Preview configuration selector

Another example is Live literals (real-time display literal type) , which is a solution from the engineering team, by introducing real-time updates to some Composable values (such as Boolean, Char, String, Color, etc.) in the Preview panel. Optimize the speed of iterative development.

The actual experience of Live Literal

PreviewParameterProvider is another example where we include sample data in Preview to allow real context testing.

Use PreviewParameterProvider

journey is not over yet

We hope this article gave you an idea of how we improved Compose Preview based on your feedback. Of course, our journey does not end here! We have many plans to continue to improve the experience of using Compose Preview and its tools. For example, the Live Literals is extended beyond the literal type to continue to optimize the speed of iterative development.

If you experience problems using Compose tool, or is there anything that can improve the experience of the new features ideas, please tell us . We are also looking for developers to participate in the user research Session, you can registered participate.