Translation Instructions:
Android Studio Project Marble: Layout Editor
Original address:Medium.com/androiddeve…
Originally written by Paris Hsu
This is the fifth in a series of blog posts from the Android Studio team that delve into some of the details and behind-the-scenes of Project Marble. Starting with the release of Android Studio 3.3, Project Marble is a multi-release focused on making the basic functionality of the IDE more reliable and elegant. The following post was written by Paris Hsu (Interaction Designer) on behalf of the layout editorial team.
The Layout Editor is one of the design tools in Android Studio that allows developers to preview and build layouts across multiple devices. The layout editor is especially powerful when building a new layout with ConstraintLayout. We’ve heard from many application developers that they like the new features we’ve introduced in the layout editor, such as previewing layouts or sample data of different screen sizes so that placeholder text and images can be specified. However, we have also received strong feedback that there are some performance and error-prone usability issues that make editing XML the only way forward, especially when using ConstraintLayout, which often leaves developers in an unconscious and awkward position within design tools.
So we set out to address these performance and availability issues during Project Marble, and today we’re happy to update you on our progress. While this article will focus on usability, we want you to understand that building performance is also a focus of Project Marble. In practice, the design interface is heavily dependent on build speed, because with each mouse: the XML is updated, processed by the build, and loaded into the Layout Lib rendering engine – which emulates the Android UI system running in Android Studio on the JVM. As a result, we also made sure that in all our efforts to improve availability, no changes affected performance. Now let’s take a closer look at the major usability improvements we’ve made so far in Android Studio 3.5 and our next steps.
So what did we do?
One of the core goals we set for the layout editor was to give you the most accurate preview of your layout for faster design iterations. With this goal in mind, we took the results from a recent series of usability studies by application developers, prioritized the issues, and after some technical investigation, we implemented the following six optimized layout editors during Project Marble:
- Constraint visualization and selection
- Constraints to create
- Constraints to delete
- Visual refresh
- Device capture behavior
- Dimension resources for a dimension
Improvement # 1 – Constraint visualization and selection
Currently, the limitations that exist are visualized in the layout editor in two ways:
(1) Arrows & anchors used on the design surface
(2) With the constraint component on the property panel, as shown below:
What we learned from you is that while the current visualization is helpful in illustrating constraint types, constraint directions, and edge values, it has a missing piece: the ability to quickly identify relationships – to see the summary of these constraint connections at a glance. We found it particularly difficult to see where the arrows point to a complex layout, with many components overlapping one another.
To address this feedback, we added a Constraints Section to the Attributes panel that lists the Constraints of the previously selected UI component in an easy-to-understand format, as follows:
You can now see how many constraints have been created for this component, which components the constraints point to, and their constraint margins or deviations.
In addition, with this new Constraints Section, we take a step further from visualization to usage. We thought, “What if we also allowed you to select these constraints from a list, just like components from a component tree?”
This creates a mental mapping between the constraints on the design surface and the constraints on the list, allowing you to easily find the constraints when building the layout:
With the new selection mode, we also solved some of the constraint deletion issues we encountered (more on that in Improvement # 3 below). Now, when selecting a constraint on a list, you can use the Delete key to remove the constraint.
Improvement # 2 – Constraint creation
Currently, there are three ways to create constraints in the layout editor:
- Drag from the component’s anchor point to the target component’s anchor point
- Drag from the component’s anchor point to the center of the target component
- Use the “+” button on the properties panel to constrain the widget
Through the usability study, we identified several difficulties in these workflows and made some improvements.
For interaction option # 1, we used the flashing green dot as an indication of whether you could constrain to the anchor point while dragging earlier. We decided to remove the green dots because they created visual clutter. The feedback we get is that, due to point flicker, it’s hard to say, for example, fill (constrained) and non-fill (unconstrained) anchors. Therefore, we use a system that relies on user intent. When you drag, we just hide the anchors that you can’t constrain, instead of flashing green dots, and when you drag to the target components, we also give them a blue overlay if they contain the anchors that can be restrained:
In fact, the blue overlay is particularly useful when there are overlapping anchor points; It helps to identify the target component that you are trying to constrain:
For interactive option # 2, we added a ghost anchor when hovering over an option in the context menu to visually see which component anchor the option points to:
Finally, for interaction option # 3, we’ve heard from application developers that they don’t use constraint widgets due to a lack of trust, because they have little visual/system feedback on what happens after they interact with the widget. To solve this problem, we hope that the newly added constraint section (improvement # 1) will also improve the learnability of creating constraints using widgets. We see this as a way to provide immediate feedback on which constraints you interact with the widget:
Improvement # 3 – Constraint removal
Previously, to remove a constraint in the layout editor, click the anchor point of the constraint and it will be removed.
While this constraint removal is quick and easy, what we’ve learned from developers is that they find it error-prone. In complex layouts that may contain smaller components, many developers accidentally remove constraints when trying to select components, especially when the screen shrinks.
So, we also updated and improved the way we remove constraints by selecting new capabilities for constraints:
- Select the constraint, then use the Delete key
- Alternatively, we added a keyboard modifier to the old delete model: Hold down Ctrl/Cmd and hover over the anchor and the constraint will turn red, indicating that it will be deleted when clicked
Improvement # 4 – Visual refresh
In the spirit of Project Marble, we’ve also provided visual refreshes to the layout editor for a more consistent color palette:
We were particularly focused on cleaning up the Blueprint pattern because we heard from developers that they found this contour-only view useful in making layout edits without distracting the UI content. We updated color saturation to be more cohesive, got rid of high-contrast white lines, and added text support to previously empty components.
Improved # 5 – Device capture behavior
One of the most valuable reasons to use ConstraintLayout is to ensure that your application layout looks great on multiple devices, and the layout editor gives you an easy way to do that by looping through different devices on the toolbar. We also allow custom size capture. However, when we looked at this feature during Project Marble, we realized that our default device list was pretty old and the custom size capture behavior wasn’t very intuitive. As a result, we made improvements in both areas to include updated device sizes, always displaying resized handles, and improved capture. We also added a blue overlay map to indicate areas of common device sizes, from small, regular to very large.
Improved # 6 – Dimension resources for margin
Last but not least, we updated the constraint widget and the default margin drop-down to allow the use of dimensional resources as margins: we added “@…” to them. While the design is evolving, this is the current iteration:
What’s next?
The project doesn’t end there! We have many plans to continue to support and improve the layout editor experience. Of course, editing layout files directly with XML is still just a click away, but we expect you to see some useful interactions in the layout editor that can increase productivity when creating and editing layouts in Android Studio.
If you have any problems using the layout editor or are aware of new features that could improve your productivity, submit an error message. We will continue to optimize the editor’s performance, fix bugs, and incorporate your suggestions and feedback.