A UX journey of Compose Preview
The following post was written by Preethi Srinivas (UX researcher) and Paris Hsu (Interaction designer) on the Android Developer UX team.
Jetpack Compose just hit Beta! 🎉 In this exciting time, the Android Developer UX team would like to invite you into our world and walk you through our journey so far of how we have approached designing Preview for Compose. This began with understanding the challenge and forming a direction, and continued with prototyping and evaluation.
Context: understanding the challenge
Jetpack Compose is the next-generation modern UI toolkit for Android development, which aims to make crafting beautiful, performant Android apps simpler and faster. It leverages intuitive Kotlin APIs so that as app state changes, your UI automatically updates. When our team first heard about the project, we were super-excited about the possibilities for Compose, the potential of enabling mixing of logic and binding data to UI, and unlocking new use cases for developers. However, this new way of building UI introduced new design challenges.
With classic Android views, the UI is static and created primarily in XML. This meant that we could reflect changes almost immediately and create experiences such as the Layout Editor, where developers could edit their app layout via visual drag and drop, and see the corresponding edits reflected in auto-generated XML code. With Compose, however, every time a modification is made, we have to compile the Kotlin code for changes to be reflected, and that takes time, which slows down the iteration and creation process.
Ideation: sprinting to a design solution
To discover ways of supporting this new model of developing UI code in Compose, our team hosted a workshop with our Software Engineering, Developer Relations Engineering, and Product Management partners to address a design challenge: How might we assist developers in creating and manipulating Compose UI by leveraging their existing experience with current tools?
Using the Design Thinking method, we started by understanding and aligning on the problem space. This process required the team to write down ideas in the “How Might We…” framework, which were later affinitized to help identify and refine the design problem at hand. We used prior research as a springboard to guide group thinking and sketching of tooling solutions at various points in developer journeys.
The design workshop helped synthesize core principles that laid the foundation for the Compose Tooling roadmap for 2020 and beyond:
- Build upon previous lessons learned in building tooling for XML
- Embrace code as the canvas
- Optimize for iteration and experimentation
These principles formed the basis for our design philosophy moving forward. For instance, Compose Preview builds on an experience that is familiar in look and feel but complements Compose’s paradigm for constructing layouts through small, reusable Composables. The design workshop also encouraged us to lean more into a code-centric, REPL experience, allowing developers to have much more control and flexibility when previewing code — essentially providing for an interactive programming environment that supported iteration, experimentation, and learning. We also ideated new experiences beyond those offered in the XML world, such as the Interactive Preview for supporting live interactions isolated in a sandbox environment inside the IDE, and Deploy Preview, for deploying a Preview Composable to an emulator or physical device without having to run an entire application.
Prototype: early pulse checks
To validate our assumptions and design approach, we started prototyping our ideas from the design workshop and testing them in user research studies. We set up research so that we could validate current direction and obtain feedback on future ideas or investments. We chose an iterative approach to capturing feedback, thus opportunistically folding in topics related to Preview in multiple research studies that addressed other Compose-related topics.
As an example, to understand the Preview experience, we started by asking questions developers would ask:
- How does one use Compose Preview?
- In what context would one want to preview a dynamic interaction?
- How useful is it for one to deploy and interact with an isolated Composable on a physical device or Emulator?
We invited developers to join coding sessions to complete simple programming exercises in a Compose project that was created for research purposes. This approach saved time and effort with setting up the development environment, especially when Compose was in a pre-Developer Preview stage, and helped us focus on developers’ experience when working with Preview and other Compose APIs. Early research did require work around product stability issues, with Preview not always working as intended. The research plan anticipated these unavoidable issues, while still enabling very early insights to be obtained.
From these sessions, some developers expressed confusion when differentiating between the “Refresh” icon on Preview toolbar and “Refresh & Build’’ in the banner. Most did not recognize that the “Refresh” icon will only update code changes that do not need a full build while the banner will update all changes through a build.
“If Refresh and Build and Refresh intend to be the same, it would be nice if they are together — I initially thought the refresh button would just refresh the UI and doesn’t build the project.”
This feedback led us to align both and improve the experience so that when a user clicks on the icon or the banner — Preview looks at the changes to determine whether a refresh or a rebuild is needed to reflect the change.
A key insight on Compose Preview from several rounds of early research included developers associating increased productivity and feelings of being in control when prototyping UI in Compose.
“The Refresh mode lets me rapidly prototype UIs. Having the full power of Kotlin available for creating UI as well as the example data of @Preview functions is much better than the XML namespace helpers in the old XML way.”
We also heard developers experience surprise and subsequently delight on being able to navigate to a specific point in code when interacting with the Composables in Preview.
“I found out about this just now and am delighted, I can click on different views in the Preview, and jump directly to the code responsible for drawing that. I’d love to see more of these ideas applied to Jetpack Compose”
In usability studies, we observed developers navigating to different parts of their project in the code editor by clicking through different UI elements in the Preview — this required one to have a deeper understanding of the UI hierarchy. Some developers found the experience to be buggy when there was a misalignment between interactions in Compose Preview and code navigation. For instance, clicking outside the target area of a Text Composable in a Column could navigate one to the line in the code editor where the Column is defined. This led us to enhance the Preview experience by including Composable outlines to offer a visual affordance around Composables in a layout.
Immersion: keeping a diary
Live, in-person usability studies are relatively lightweight to conduct, valuable, and sparked new ideas. However, it was hard to dig deeper into topics due to time constraints. Hence, we pivoted on our research approach and began leaning more towards a remote technique that allowed developers to work on a Compose project in their own time for a few weeks. During this time, developers kept a diary including a set of questions to document their workflow as they worked either on an assigned project or a project of their own. We typically paired this with an interview conversation after a few weeks of exploration with the intent of better understanding specific entries in developer diaries. We also invited some developers for coding sessions over Google Meet after a few days of exploration to watch and identify moments when things worked well and experiences that could be improved.
A consistent theme emerged in these studies — developers were using Preview to support both creation and troubleshooting/validation workflows. For instance, while creating UI, developers leaned more on Refresh mode, while they switched over to using Interactive mode when working with gestures/interactions, and Deploy mode was most often used for troubleshooting or validation checks.
“I was so happy when I discovered the interactive mode could show the animation of a star on long press. But, on the subsequent long presses, the interactive mode didn’t work — the animation didn’t show anymore. By deploying the preview mode on an emulator, I saw that the animation did in fact work. If interactive mode gets more stable, it would be my go-to mode for testing interactive stuff + animations. Interestingly, I didn’t need to use it most of the time when creating new UIs and looking at how they got rendered.”
In addition, we heard from some developers the importance of being able to extract and focus implementation on a single Composable before thinking about the entire layout.
“Deploying just the Preview means I don’t need to hook that UI to an actual flow (with multiple screens and user input) just to test a new component. This makes debugging + changing complex UIs much easier.”
Turning insights into actions
We grounded our direction in research, which helped us feed insights and questions from developers back into iterating on our tools — all while ensuring we also captured emerging themes to mold our design philosophy. Below are a few examples:
Preview for newcomers
We observed developers experiencing difficulties discovering the entry point to creating a Preview — many noticed Preview in sample projects, but were unable to replicate a similar experience in their own project. Unintuitive design often led to misunderstanding of what is and is not supported by Compose compiler when creating a Preview Composable. For instance, we observed some developers attempting to preview a Composable that accepted parameters — a functionality that is not supported by Compose. In this situation, the error message offered by the compiler was often missed or overlooked.
“I couldn’t work out how to show the split view with a Preview, I am unable to make Preview annotation work even if I copied over code from a sample project.”
This important insight led us to introduce a default state, wherein, a split editor (borrowed from the Preview in View/XML world) is always visible with an empty state if a Kotlin file did not already have a Preview Composable defined. We believe this solution will not only improve the awareness and discoverability of Preview, but also offer a learning experience associated with creating and manipulating Previews.
Accelerating the coding experience
In research studies, developers asked us::
- How can I Preview a layout in both light and dark themes?
- How can I Preview a layout with sample data?
- How can I leverage Preview to identify where in my code I have defined a particular UI element?
- Is there a way for Compose to mimic the preview experiences from the View/XML world, particularly, with being able to rapidly see a visual change in Preview with a code change?
These questions spoke to an overarching theme — developers were looking for a quick and easy mechanism for manipulating a Preview, and expected quicker iterations.
We continue to prototype and test new features that emerged from developer feedback such as this — the Preview Configuration Picker, for example, will allow developers to configure their layout visually (e.g., in different themes, devices, language, etc.), to increase discoverability and learnability of the @Preview API.
Another example is Live literals — our engineering team’s solution to optimize speed for iterative development by introducing real time updates to some Composable values (e.g., Boolean, Char, String, Color, etc.) in the Preview panel.
PreviewParameterProvider is one more where we incorporated sample data into Preview to allow real-context testing.
The journey continues…
We hope this article has shed some light on the behind-the-scenes of how your feedback influenced improvements to Compose Preview. Of course, the journey doesn’t end here! We have many plans to continue to support and improve the experience of the Compose Preview and tooling, in general. For example, extending Live Literals to beyond literals type for more speed and quick iteration feedback loop.
As always, if you encounter any issues while using Compose tools, or have an idea for new feature(s) that can improve your experience, please file a bug here. We are also looking for developers to participate in user research sessions — sign up here to participate in a research study.
