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 its beta phase. 🎉 At this exciting time, the Android Developer UX team would like to invite you into our world and into the design journey of our design, Compose Preview. The journey will begin with an understanding of the challenges we face, direction formation, and prototyping and evaluation.

Context: Understand the challenge

Jetpack Compose is a next-generation UI toolkit for Android development that makes it easier and more efficient to build beautiful, high-performance Android apps. It uses the intuitive Kotlin API to automatically update the UI as the application state changes. When our team first heard about the project, we couldn’t have been more excited about the infinite possibilities of the Compose project, with its potential to bind a mix of logic and data to the UI and unlock new capabilities for developers. However, this new way of building uIs also presents new design challenges.

For classic Android views, the UI is static and created primarily through XML. This means that changes to XML are reflected almost immediately in the UI, and we can build experiences like Layout Editor based on this feature, which allows developers to visually drag and drop the Layout of their application, and the changes are automatically mapped to changes to XML. However, with Compose, each change must be compiled into Kotlin code to reflect the change, which means it takes time, slowing down the iteration and creation process.

Brainstorm ideas: Sprint design scheme

To explore how to support this new mode of developing UI code in Compose, our team held a workshop with our software engineers, developer relations engineers, and product management partners to address a design challenge: How can we leverage developers’ experience with existing tools to help them create and master the Compose UI?

Based on design thinking, we start by understanding the problem and adapting the work scenario to the problem. This process requires the team to “How can we… (How took We…). “Write your ideas within this framework, and then use affinitized to identify and refine the design issues at hand. Using our previous research as a starting point, we imagined ourselves as developers, guided the team through the different stages of the actual development process, and sketched the tools for the solution.

Compose Design Seminar

This design workshop helped us summarize several core principles that will form the basis for Compose’s path in 2020 and beyond:

  • Based on previous experience with XML build tools
  • Draw the interface around the code
  • Optimize iteration and experimentation

These principles form the basis of our product design concept. For example, Compose Preview builds an experience that will look and feel familiar to users, complementing the Compose paradigm by building layouts with lightweight, reusable composables. Design workshops also encouraged us to build a more code-centric programming environment for the REPL, giving developers more control and flexibility when previewing code — essentially providing an interactive programming environment for iteration, experimentation, and learning. We also envision new experiences that go beyond XML, such as Interactive Preview, which enables real-time interaction within the isolated sandbox environment of the IDE; Deploy Preview is used to Deploy the Preview Composable to the simulator or real machine without re-running the entire application.

Prototyping: Early validation

To test our hypothesis and design path, we started prototyping ideas from the workshop and testing them in user study cases. We run studies so that we can verify that we are going in the right direction and get feedback on future ideas and inputs. We chose an iterative approach to get feedback and folded the Preview related topics across multiple studies covering other Compose related topics.

For example, to understand the Compose Preview experience, let’s first list the questions that developers will ask:

  • How can developers use Compose Preview?
  • In what cases do developers want to preview dynamic interactions?
  • How helpful is the ability to deploy and interact with a quarantined Composable on a real machine or emulator?

We invited developers to join our Coding Session to complete some simple programming exercises in the Compose project, which was created for research purposes. This approach saves time and effort in configuring the development environment, especially since Compose is still in the developer Preview phase, and helps us focus on how developers experience using Preview and other Compose apis. Early studies do need to revolve around issues of product stability, because Preview doesn’t always work as expected. The research plan anticipates these inevitable problems while also providing very early insights.

Conduct usability research through Coding sessions

From these sessions, we found that some developers were confused by the distinction between the “Refresh” icon on the Preview toolbar and the “Refresh & Build” icon in the banner. Most developers don’t realize that “Refresh” only updates the code and doesn’t require a full Build, whereas “Refresh & Build” updates all changes through a Build.

“If Refresh and Refresh & Build want to be consistent, it’s better to put them together — I initially thought the Refresh button would just Refresh the UI and not Build the project.”

Preview Refresh & Build (before and after)

With this feedback, we decided to unify the two and improve the experience so that When a user clicks on an icon or banner, Preview determines whether a refresh or rebuild is needed based on code changes.

One of the most compelling insights from early rounds of developer research for Compose Preview is that developers feel a sense of control and increased productivity while prototyping the UI in Compose.

“Refresh mode allows me to quickly prototype the UI. Coupled with the ability to create UI using the powerful Kotlin and display instance data using the @Preview function, it’s much better than the namespace helper provided in old-fashioned XML.

We also saw the surprise and delight of developers when they discovered the feature in Preview that allows them to navigate to the corresponding code while interacting with the Composable.

“I just discovered this feature, and I’m really excited about it. I can click on a different view in Preview and jump right into the code that draws that view. I look forward to seeing more of these features in Jetpack Compose.”

In usability studies, we observed that developers jump to different parts of the project by clicking on different UI elements in Preview — this requires a deep understanding of the UI hierarchy in Preview. Some developers find misalignment issues when interacting with Compose Preview and code navigation. For example, clicking outside the Text Composable area in Column jumps to the line in the code editor that defines Column. We therefore enhance the Preview experience by providing a Composable outline to provide functional visibility around the Composable in the layout.

Preview code jump function

Immersive: Recording in the form of a diary

It’s much easier to create value and spark new ideas by being in the field and doing usability research in person. However, due to the limitation of time, it is difficult to dig deeply into the theme. As a result, we adjusted our approach and started using more of a remote technology that lets developers use a Compose project themselves for a few weeks. During this time, developers need to keep a diary of any workflow issues they may have on a given project or on their own. A few weeks of exploration is usually followed by an interview to get a better understanding of what’s in the developer’s diary. After a few days of exploring, we also invited a group of developers to take a look at what was going well and what could be improved via Google Meet’s Coding Session.

Use an interrogative journal to help get feedback

There is a common thread in these studies – developers use Preview to create workflows and also use it for troubleshooting/validation work. For example, developers are more likely to use Refresh mode when creating a UI, switch to Interactive mode when using gesture/interaction, and Deploy mode is most commonly used for troubleshooting and validation checks.

“I was very happy when I discovered that the long press in Interactive mode showed the animation of the stars. However, the long press after that doesn’t work – the animation doesn’t appear anymore. By deploying the Preview mode on the emulator, I was able to confirm that the animation worked properly. If Interactive mode were more stable, it would be my preferred mode for testing Interactive features and animations. Interestingly, I don’t need to use it most of the time when creating new UIs and looking at how they render.”

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

“Deploying Preview only meant that I didn’t need to associate the UI with the actual flow (with multiple interfaces and user input) in order to test a new component. This makes debugging + changing complex UIs much easier.

Put your thoughts into action

We built on that research to establish the direction to go, which helped feed developer insights into our tools and issues into our product iterations — while ensuring that we also captured emerging themes to shape our design philosophy. Here are a few examples:

Preview New user experience

We found that developers had a hard time figuring out how to get started with Preview — many of them had noticed Preview in their sample projects, but couldn’t replicate the experience in their own projects. The unintuitive design often leads to misunderstandings about what the Compose compiler supports when creating the Preview Composable. For example, we observed some developers trying to preview a Composable that accepts parameters, which is not supported by Compose. In this case, error information provided by the compiler is often ignored or omitted.

“I can’t show Split views in Preview, and it doesn’t make Preview annotations work even if I’m copying code directly from a sample project.”

This important finding brings us to the default state, where the split editor (a concept derived from Preview in the View/XML world) is always visible if the Kotlin file has not defined the Preview Composable. We believe this solution not only improves Preview awareness and discovery, but also provides a learning experience related to creating and operating Preview.

Preview Default state

Enhanced coding experience

In our research, the developers asked us the following questions:

  • How do I preview a layout on a light and dark theme background?
  • How to preview a layout with sample data?
  • How do I use Preview to determine where a particular UI element is defined in my code?
  • Is there a way for Compose to mimic the Preview experience in the View/XML world, specifically how you can quickly see visual changes due to code changes in Preview?

These questions all point to one thing — developers are looking for a quick and easy mechanism to use Preview and expect it to iterate faster.

We will continue to prototype and test new features that developers have reported back, such as the Preview Configuration Picker, which allows developers to visually configure their layouts (e.g. on different themes, devices, languages, etc.), To improve the discoverability and learnability of the @Preview API.

Preview configures the selector

Another example is Live Literals (real-time display of literal types), a solution from the engineering team that introduces real-time updates to some Composable values (such as Boolean, Char, String, Color, etc.) in the Preview panel. To optimize the speed of iterative development.

Live Literal experience

The PreviewParameterProvider is another example of how we include sample data in Preview to allow real-world context testing.

Using PreviewParameterProvider

The journey is not yet over

We hope this article gives you an idea of how we are improving Compose Preview based on your feedback. Of course, our journey doesn’t end there! We have many plans to continue improving the experience with Compose Preview and its tools. For example, extend the Live Literals functionality beyond literal types to continue optimizing the speed of iterative development.

If you encounter problems with the Compose tool, or have any ideas for new features that could improve your experience, please let us know. We are also looking for developers to participate in the User research Session, you can sign up to participate.