This is the fifth in a series of blog posts by the Android Studio team diving into some of the details and behind the scenes of Project Marble. Beginning with the release of Android Studio 3.3, Project Marble is a multi-release and focused effort on making fundamental features of the IDE rock-solid and polished. The following post was written by Paris Hsu (Interaction Designer) on behalf of the Layout Editor team.

The Layout Editor is one of the design tools in Android Studio that enables developers to preview and build layouts across multiple devices. The Layout Editor is especially powerful when building a new layout with ConstraintLayout. We have heard from many app developers that they like the new features we introduced in the Layout Editor such as previewing layouts across different screen sizes, or sample data, which allows specifying placeholder text and images. However, we have also received strong feedback that there are several performance and error prone usability issues that make editing XML the only path forward, especially when working with ConstraintLayout, which often put developers in unintentional and awkward states in the design tool.

Thus, we set out to address these performance and usability issues during Project Marble, and today we are excited to give you an update on the progress. While this article will focus mostly on the usability issues, we want to let you know that build performance was also a focus for Project Marble. In fact, the design surface relies heavily on build speed, since on each mouse up: the XML is updated, processed by the build, and loaded into Layout Lib rendering engine — a simulation of the Android UI system running within Android Studio on the JVM. Hence, we also make sure that in all our efforts to improve usability none of the changes impacted performance. Now let us shed some light on the significant usability improvements we have made so far in Android Studio 3.5 as well as our next steps.

So what did we do?

One of the core goals we have for the Layout Editor is to provide you with the most accurate layout previews to allow for faster design iterations. With that goal in mind, we took the results from a series of recent usability studies with app developers, prioritized the issues, and after some technical investigations, we landed on the following top six areas to optimize the Layout Editor during Project Marble:

1. Constraint visualization and selection
2. Constraint creation
3. Constraint deletion
4. Visual refresh
5. Device snapping behavior
6. Dimension resources for margin

Improvement #1 — Constraint visualization and selection

Currently, there are two ways that the Constraints are visualized in the Layout Editor: (1) with arrows & anchors on the design surface and (2) with the constraint widget on the property panel, as illustrated below:

What we learned from you was that, while the current visualization helps illustrate constraint types, constraints directions, and margin values, it had one missing piece: the ability to quickly identify relationships — to see at a glance a summary of what these constraints are connected to. We found that it is especially difficult to see where the arrows point in a complex layout, where many components overlap each other.

To address this feedback, we added a Constraints Section to the Attributes panel, which lists the constraints relationships of the currently selected UI component in an easily digestible format, as illustrated below:

You can now see how many constraints you have created for this component, what components these constraints point to, as well as their constraint margins or biases.

Moreover, with this new Constraints Section, we went one step further from visualization to utilization. We thought: “What if we can also allow you to select these constraints from the list like you would select components from the component tree?”

This way, a mental mapping will be created between the constraints on the design surface and the constraints on the list, allowing you to easily find the constraints when building your layouts:

With the new selection mode, we also addressed some of the constraint deletion issues we had (more in depth in Improvement #3 below). Now when a constraint is selected on the list, you can use the Delete key to delete the constraint.

One thing to note here is that we also noticed in usability studies that many developers don’t know about the zoom controls on the design surface, and without zooming in, some of the interactions on the Layout Editor are harder to execute. We believe that the new visualization will help mitigate some of surface interactions by providing an alternative way to select constraints on the property panel. However, we do want to give a shout out to our zoom controls here: you can access them on the toolbar, or simply use the keyboard shortcut Ctrl/Cmd+ to zoom in, Ctrl/Cmd- to zoom out, and hold the Spacebar to pan:

Improvement #2 — Constraint creation

Currently, there are three ways to create constraints in the Layout Editor:

1. Dragging from the anchor of a component to the anchor of a target component
2. Dragging from the anchor of a component to the center of a target component(s)
3. Using the “+” buttons of the constraints widget on the property panel

Through usability studies, we identified several pain points in these workflows and made some improvements to them.

For interaction option #1, previously when dragging, we used the flashing green dots as an indication of whether or not you can constrain to that anchor. We decided to remove the green dots since they created visual clutter. We have gotten feedback that because the dots were flashing, it was difficult to tell, for instance, filled (constrained) and non-filled (non-constrained) anchors. Thus, we instead adopted a system that relied on user intent. Instead of flashing green dots, when dragging, we simply hide anchors that you can not constraint to, and when you drag to target components, we also give them a blue overlap if they contain constrainable anchors:

In fact, the blue overlay is especially useful when there are overlapping anchors; it helps identify the target component you are trying to constrain to:

For interaction option #2, we added ghost anchors when hovering over the options in the context menu to give a visual sense of which target component anchors the options are referring to:

It is especially useful when they are overlapping components:

Lastly for interaction option #3, we heard from app developers that they don’t use the constraint widget due to lack of trust, since there is little visual/system feedback of what happens after they interact with the widget. To address this, we want the newly added constraint section (Improvement #1) also to be a way to increase learnability of using the widget to create constraints. We see it as a way to provide immediate feedback of which constraint was added after you interact with the widget:

Improvement #3 — Constraints deletion

Previously, to delete a constraint in the Layout Editor, you clicked on the anchor of that constraint, and it would be removed.

While such constraint deletion is quick and easy, what we learned from developers is that they found it to be error prone. In a complex layout where you may have smaller components, many developers accidentally delete constraints when they are trying to select components, especially if the screen is zoomed out.

Hence, with the new ability to select constraints, we have also updated and improved the way you can delete constraints:

1. Select the constraint(s), then use the Delete key
2. Alternatively, we added a keyboard modifier for the old delete model: hold Ctrl/Cmd and hover over the anchor, and the constraints will turn red to indicate it will be deleted on click

Improvement #4 — Visual refresh

In the spirit of Project Marble, we also gave the Layout Editor a visual refresh to have a more consistent color palette:

We especially focused on cleaning up Blueprint mode, since we heard from developers that they found this outlined-only view to be very useful when it comes to making layout edits without the distraction of UI content.We updated the color saturation to be more cohesive, got rid of high contrast white lines, and added text support for components that were empty before.

Improvement #5 — Devices snapping behavior

One of the most valuable reasons to use ConstraintLayout is to ensure that your app layout looks great across multiple devices, and the Layout Editor provides an easy way for you to do that by cycling through different devices on the toolbar. We also allow custom size snapping. However, when we looked into this feature during Project Marble, we realized that our default devices list was quite old and the custom size snapping behavior was not very intuitive. Thus, we made improvements in both areas to include newer device sizes, always expose resizing handles, and improve snapping. We also added a blue overlay to indicate zones of common device sizes, from small, normal, to extra large.

Improvement #6 — Dimension resources for margin

Last but not least, we made updates to the constraint widget and default margin drop-down to allow using dimension resources for margins: We added a “@…” for both of them, and though the design is evolving, here is the current iteration:

What’s next?

Project Marble doesn’t end here! We have many plans to continue to support and improve the experience of the Layout Editor. Of course, editing layout files directly in XML is still just a click away, but we hope you see some of the useful interactions on the Layout Editor that can be a big productivity boost when creating and editing layouts in Android Studio.

If you encounter any issues while using the Layout Editor, or have an idea on new features that can improve your productivity, please file a bug. We will continue to optimize the editor’s performance, fix bugs, and incorporate your suggestions and feedback.