DevTools usability and design review

[CodemateTechAgency]

Introduction

Hello! At Codemate, we’ve been doing an initial design review of the Flutter Inspector DevTools, to identify some issues and potential improvements.

Our usability and design team evaluated the DevTools from the perspective of a novice user with the key priorities of ease-of-use, intuitiveness and visual structure. The team interviewed our own Flutter developers for deeper insights and to gain a broader understanding of how developers actually use the tools in their day-to-day work. We also researched and benchmarked the Flutter DevTools against other similar development tools for web and mobile.

It’s clear how important the DevTools are to our Flutter developers, with a particular focus on the Flutter Inspector, which is where we’ve concentrated our research.

Examining the Inspector, the team found various issues concerning the clarity and intuitiveness, as well as a few bugs and glitches. The inspector presents lots of important data, which is easily lost in visual clutter. By addressing these issues and adding few quality of life improvements we could make the inspector easier to understand.

Widget Tree

Helping users find widgets

Currently the widget tree is hard to visually scan through and developers find it hard to locate widgets within the tree.

Suggestions

We could fix this by providing more visual guidance, such as color coding the circle with the letter based on:

• Different depths
• Different widgets
• Different widget families (i.e accessibility, gestures, texts)

We could also highlight the widget within the running app when the user hovers over an item in the widget tree.

Visual link between widget tree and layout explorer

There’s currently no visual link between the widget tree and layout explorer. We also feel the coloring of the Flutter Inspector might be confusing for users.

Suggestions

• Matching the colors of the layout explorer and details tree with the opened widget in the widget tree
• Other ways of color matching such as different widgets or widget families

Layout Explorer

Make the Layout Explorer less busy

The most common feedback from our developers regarding the Layout Explorer is that it’s too busy and cluttered with data. We need to evaluate what information is most important for developers to ensure they can work as efficiently as possible.

Enhance the clickable areas in Layout Explorer

It’s unclear which elements within the Layout Explorer are clickable, and which are just labels.

Suggestions

• Use a clearer dropdown design to make them stand out more.
• Ensure that the dropdowns always have a label to tell what the dropdown does. We feel the user is currently required to guess what some of the inputs do.

Rotated text labels

We feel the vertically rotated labels are difficult to read, requiring the user to tilt their head.

Suggestions

• Avoid having labels that require tilting your head to read them.
• Rearrange the layouts so that labels can be rearranged or repositioned to be easily readable.
• Consider the content that needs to be shown here
• Evaluate if showing “width x height” in the middle of the component would make more sense
• Evaluate clarifying the box constraints display.

Remove unnecessary repetition of data from the Layout Explorer

• Currently the layout explorer has a lot of the data duplication.
• We need to figure out a consistent way of displaying the area measurements so that the user can get the wanted values of a component with a quick glance.

Delay when changing values

There's a slight delay when clicking boxes/dropdowns in the Layout Explorer:

This makes the DevTools feel sluggish to use and affects the overall user experience and the quality of usage.

Details Tree

The Details Tree is a powerful tool when you really need to look into the specifics of your code. Based on the hands-on experience and feedback we received, we feel that currently you can get a bit lost in the huge amount of data displayed and no way to find or emphasize what you are looking for. Also a few scrolling issues diminish the user experience.

Suggestions

Enhance the details tree readability

• Make a clear separation between label and value with typography and coloring.

Add search/filter for details tree to find and highlight the data you’re looking for, similar to Chrome’s inspector

• Currently the “Details Tree” is quite cumbersome to find things without knowing what you’re actually looking for. By adding a simple search input for the “Details Tree” we ensure that even novice users easily find the view they’re looking for.

Scrollbar issues in details tree

• Vertical scrollbar appears in the middle of the area when selecting an item in the widget tree.

• Horizontal scrollbar stays visible even if there is no content to scroll to.
• The details tree's bottom row goes under the scrollbar, so it's hard to click that expand arrow:

Buttons and icons for debug toggles

Our developers didn’t understand what some of the debug modes did, or what their use cases are.

Suggestions

• Provide clearer access to documentation about what problem each debug toggle is useful for solving. This could be achieved via explanatory tooltips with links to further documentation.
• Update iconography to be consistent (style and use of color).
• Consistent use of margins and paddings everywhere (buttons, icons, list, etc).
• Ensure that the buttons have tooltips when they’re shrunken down into an icon. Currently some of the buttons are missing their tooltips when shrunken down in size.
• Increase the contrast on selected view mode toggle buttons (repaint rainbow etc).
• The grouping of the toggle buttons feels pretty random. The context of the toggle buttons is too obscure at the moment. We could easily improve this by labelling the groups for example.

Explore trying out different values in the details tree

We suggest exploring the possibility to be able to try different values for widgets from the details tree as well. Similar to Flutter's experimental HotUI feature or Chrome’s CSS editor. This would allow users to quickly experiment with, for instance, changing font sizes or colors from within the DevTools.

General look and feel

Content area standardization

• Make the content areas similar in structure. Include content area specific actions inside the area borders (refresh, tabs, expand collapse, etc).
• Contain the action within the context of their use to make the top area of the DevTools a bit more structured.

Improve color contrast

• Currently the DevTools has some color contrast issues all around (widget tree icons, light mode, tabs). We could define a more suitable color palette.
• This applies to both light and dark modes.

Accessibility

We couldn’t access the DevTools via the VoiceOver screen reader on macOS, despite other Flutter websites correctly working with it. We feel this should be a priority to fix, in order to make the DevTools accessible to visually impaired users.

Flutter Web issues

We are aware that these are Flutter Web issues, but they are worth mentioning here, since they greatly affect the usability of the DevTools.

• Scrolling in feels generally sluggish and does not match platform behaviour (Web: scrolling behaviour on Mac does not match platform flutter#75850).
• Moving DevTools window from laptop screen to another monitor causes it to zoom to x2 for a while (might be related Flutter web crashes when moving between two screens with different pixelRatio flutter#56050 and textScaleFactor not working on web when text scale change in Browser/System Level flutter#52061).

[InMatrix]

Thank you so much for filing this issue! I'm impressed by how comprehensive and organized it is. Please see my initial comments on the problems you noted inline below. Hope these help us start a discussion and identify a starter project for our collaboration. Cc: @jacob314 @kenzieschmoll @csells @devoncarew

The team interviewed our own Flutter developers for deeper insights and to gain a broader understanding of how developers actually use the tools in their day-to-day work.

I really appreciate that you did this. It's advantageous that you could combine your design capability and experience using Flutter.

Currently the widget tree is hard to visually scan through and developers find it hard to locate widgets within the tree.

Agreed. I think we can do a better job distinguishing different families of widgets based on the functionalities they provide (e.g., layout, decorative, information container, animation, etc). The Widget catalog provides a starting point for such a taxonomy.

Another idea we could explore is to match the visual salience of a widget in the tree with its size on the screen. For example, if there are two Text widgets, one for a small label and another for a paragraph of text. The two widgets should ideally be represented differently in the widget tree in a way that the developer can tell which one is which at a glance. The necessary sizing data might be already available from the widgets' corresponding renderObjects.

Matching the colors of the layout explorer and details tree with the opened widget in the widget tree

I can see the mismatch now you mentioned that. Some tweaks of the colors could be useful.

The most common feedback from our developers regarding the Layout Explorer is that it’s too busy and cluttered with data.

Yes, agreed. I'd be interested in any ideas to convert text into visual representations or disclose certain options progressively. We might also consider converting some menu-based operations into direct manipulation on the layout diagram.

It’s unclear which elements within the Layout Explorer are clickable, and which are just labels.

+1. This seems relatively easy to fix.

We feel the vertically rotated labels are difficult to read, requiring the user to tilt their head.

I'd be interested in seeing some examples of UIs that handle this problem well. Would you share some pointers or preliminary thoughts?

Currently the layout explorer has a lot of the data duplication.

Could you elaborate on the data duplication you were seeing?

There's a slight delay when clicking boxes/dropdowns in the Layout Explorer.

This might be due to the fact that an actual hot reload needs to be performed to reflect the change. Maybe a progress indicator can be added to let the user know what's going on before the diagram is refreshed. Cc: @jacob314

Details Tree

I agree with the suggestions. However, our current thinking is to move the most frequently used information from the Details Tree to Layout Explorer and represent it as visually as possible. In the future, the Details Tree might be reserved for debugging edge cases or advanced users. So I'd wait until we've made more progress on the Layout Explorer.

Buttons and icons for debug toggles

Yes, tooltips or click feedback needs to be provided to better explain what these buttons do. The information is available on this page: https://flutter.dev/docs/development/tools/devtools/inspector. We could also explore an onboarding flow to introduce the features in the inspector page.

Explore trying out different values in the details tree

This is something we want to do in the long run, but it's likely to require a lot of engineering effort to make it work well. So it's probably not a good candidate for our starter project here.

Contain the action within the context of their use to make the top area of the DevTools a bit more structured.

I'd love to hear more about this suggestion. Could you point out an action that you'd like to relocate?

Improve color contrast
Accessibility

Yes to both. I think we have technical debt on accessibility, and improving color contrast would be the first step to address it. Fully supporting VoiceOver might be more challenging, we'd love to learn similar tools such as Chrome DevTools have supported it.

[jacob314]

This might be due to the fact that an actual hot reload needs to be performed to reflect the change. Maybe a progress indicator can be added to let the user know what's going on before the diagram is refreshed. Cc: @jacob314

Good news is we don't actually perform a hot reload for this case so we can make it much faster. We should profile where the operations to change flex properties are sluggish. It should be extremely fast as we are just changing properties on a render object and then triggering a layout and paint. I suspect we are doing something foolish on the DevTools side updating the UI after the property change.

Here is the implementation is in inspector_polyfill_script.dart

Future<Map<String, dynamic>> setFlexProperties(
      Map<String, String> parameters) {
    final String id = parameters['id'] as String;
    final MainAxisAlignment mainAxisAlignment = toEnumEntry<MainAxisAlignment>(
      MainAxisAlignment.values,
      parameters['mainAxisAlignment'] as String,
    );
    final CrossAxisAlignment crossAxisAlignment =
        toEnumEntry<CrossAxisAlignment>(
      CrossAxisAlignment.values,
      parameters['crossAxisAlignment'] as String,
    );
    final dynamic object = WidgetInspectorService.instance.toObject(id);
    bool succeed = false;
    if (object != null) {
      final render = object.renderObject;
      if (render is RenderFlex) {
        render.mainAxisAlignment = mainAxisAlignment;
        render.crossAxisAlignment = crossAxisAlignment;
        render.markNeedsLayout();
        render.markNeedsPaint();
        succeed = true;
      }
    }
    return Future.value(<String, Object>{'result': succeed});
  }

[jacob314]

One other idea for the inspector tree is to highlight widgets defined in your local project (in this demo in blue) and then optionally only expand other widgets when the build method for the selected widget is selected. This makes the structure of the user's own app clearer from the summary tree and better matches the mental model of going one build method at a time from browsing source code.
Here is a demo of what this could look like.

inspector_tree_animation_video.mp4

[CodemateTechAgency]

Currently the layout explorer has a lot of the data duplication.

Could you elaborate on the data duplication you were seeing?

Well, the word unconstrained is repeated many times. Not a problem per se, seeing it is important information, but now all that info is scattered around the box. So it is not just about duplication, but also about the space it takes.

We feel the vertically rotated labels are difficult to read, requiring the user to tilt their head.

I'd be interested in seeing some examples of UIs that handle this problem well. Would you share some pointers or preliminary thoughts?

This comes back to the same point as above. It is not just about rotated labels/values, but about the amount of data presented there.

Here’s an initial design idea for the Flutter Inspector:

Contain the action within the context of their use to make the top area of the DevTools a bit more structured.

I'd love to hear more about this suggestion. Could you point out an action that you'd like to relocate?

With the current label of “Refresh Widget Tree”, I’d move that within the boundaries of the widget tree. If it basically refreshes everything, then it could be where it currently is, but maybe change the label then.

For layout inspector / details tree, I’d contain the tab (and expand/collapse actions) within the boundaries to separate them visually from the upper button group

Also, maybe move the “Select Widget Mode” button along the button group with the other actions affecting the live preview. Remove the grouping of the overlays (or include them all in a same toggle group).

Improve color contrast
Accessibility

Yes to both. I think we have technical debt on accessibility, and improving color contrast would be the first step to address it. Fully supporting VoiceOver might be more challenging, we'd love to learn similar tools such as Chrome DevTools have supported it.

Chrome DevTools does support VoiceOver, but not especially well. We agree it would be a huge challenge to support screen readers on the DevTools