search

flutter / devtools

Performance tools for Flutter
https://flutter.dev/docs/development/tools/devtools/
BSD 3-Clause "New" or "Revised" License
1.59k stars 327 forks source link

DevTools usability and design review #2890

Open CodemateTechAgency opened 3 years ago

CodemateTechAgency commented 3 years ago

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:

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

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.

clickables_devtool

Suggestions

Rotated text labels

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

unnamed

Suggestions

Remove unnecessary repetition of data from the Layout Explorer

Delay when changing values

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

delay_devtools

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.

Screenshot 2021-04-08 at 12 21 29

Suggestions

Enhance the details tree readability

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

Scrollbar issues in details tree

unnamed

unnamed

Buttons and icons for debug toggles

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

Screenshot 2021-04-07 at 15 36 19

Suggestions

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

Improve color contrast

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.

InMatrix commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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.

https://user-images.githubusercontent.com/1226812/114581519-a0816880-9c34-11eb-9798-155a523e6739.mp4

CodemateTechAgency commented 3 years ago

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.

Screenshot 2021-04-16 at 9 20 22

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:

e9933628-d69f-4ffc-b2ac-5c4ac51b247c

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