anawishnoff commented 3 years ago

Proposal: Update design of TreeView

Summary

I'm proposing design changes to TreeView so that it visually aligns with the new ListView designs. This includes providing items with a rounded backplate in non-rest states, an accent-colored selection indicator, and a more rounded checkbox in multiple selection mode.

Rationale

As ListView is getting a design update, controls that have list functionality should align with that update.
Many controls in WinUI have rounded corners, so TreeView should follow that trend and embrace the modern, Fluent look.

Scope

Capability	Priority
TreeView items will have a rounded backplate in non-rest states.	Must
TreeView items should use a pill-shaped selection indicator in single selection mode.	Must
TreeView items should use the same rounded checkbox visual in multiple selection mode as ListView.	Must
TreeView items should align with new ListView design details overall.	Must
These changes will not affect the functionality of TreeView.	Won't

Important Notes

Design Mockups

Below: TreeView in single selection mode.

Below: TreeView in multiple selection mode.

Open Questions

Any existing TreeView use cases that would be broken by this design change?

mdtauk commented 3 years ago

Many of the other controls have moved to using Fluent UI System Icons, will the chevrons be replaced with caret symbols, to fit in with the other controls?

anawishnoff commented 3 years ago

@mdtauk Hmm, this is an interesting question/idea. I think the carets, as shown in the examples above, are usually used for scrolling or navigating purposes? At least that's where I've seen them. Chevrons are used for expanding/opening/closing items (i.e. Hierarchical NavigationView), so I think they're appropriate for TreeView as well.

jschwizer99 commented 3 years ago

@anawishnoff , I appreciate a lot the step taken to align the visual style between listview and treeview. On the current preview4 the differences are quite noticeable.

Our WinUI application will target the classical desktop market. The treeview and listview are very important design elements to reflect the complex data of the 3D application. Therefore, we strongly rely on a clear distinction between multi-selection and mouse hover. In the new proposal, the contrast between selected elements and background is very weak if the checkboxes are disabled (IsMultiSelectCheckBoxEnabled="False"). For applications targeting mainly the non-touch markets, disabling the checkbox display for the listview can be beneficial as we get display space for icons. At the moment I couldn't find an easy way to achieve the same for the treeview. Thus, an alignment of the visual style should also ensure that the layout configuration possibilities are the same. If it is possible to adjust the layout and style to match the customer's needs it would be great.

Based on the above explanation:

Allow disabling of checkbox display for multi-select for both treeview and listview (IsMultiSelectCheckBoxEnabled="False")
Support XAML based configuration of select and hover styles to match with target application and market

anawishnoff commented 3 years ago

This is great feedback @jschwizer99, thank you!

This proposal won't be covering any actual functionality changes, as mentioned above, so allowing the disabling of checkbox for multiple selection mode in TreeView won't be included in this change. However, this is definitely an interesting topic. I'd recommend opening up a separate issue for this. I agree and don't see why you can disable checkboxes with ListView, but not TreeView.

If you're looking to change the colors for selection and hover styles, you'll still be able to do that by editing the control's template and providing the colors you'd like to show. However, I do appreciate the feedback about the contrast - I'm going to take a better look into this.

Noemata commented 3 years ago

Some design choices may appear heavy handed at first (e.g. prominent selection regions), but such choices do help those that have partial visual impairment. UX design aesthetics have practical usability considerations that go beyond a given fashionable design paradigm. Does WinUI have a UX design team with appropriate UX usability credentials that include disability awareness as well as current UX design know how? Typically, a UX mockup for a specific element sits beside a bunch of other UI components so the overall look and feel can be evaluated.

anawishnoff commented 3 years ago

@Noemata Yes, we work with an awesome design team who has vast knowledge of usability as well as accessibility.

Noemata commented 3 years ago

@anawishnoff , that's cool. You might want to surface their designs here for this sort of change.

llothar commented 3 years ago

I really not happy with the simplicity of this TreeView for Desktop apps.
I have to agree with @jschwizer99 on this one.

But i already knew i have to roll out my own immediately as i start porting our app to WinUI3. I just hope that the TreeView code will soon be an open source released and we can extend it as much as they we want/need.

llothar commented 3 years ago

@anawishnoff: I also want to mention that the simple bar in single selection is NOT good. It's a tiny indicator assuming there is not any other color in the tree view, otherwise it fails to get recognized fast. Add icons or color, in rich text elements (and i hope you don't want to stop us using them) and your attention gets distracted. Giving the whole item a selection color might not be fluent design, but it is better functioning.

Also lots of business web apps now use a colored sidebar stripe for classification of items. In this case it is almost impossible to realize what and where the selection is. Ok, the classification bar could be put on the right side but thats against how our brain is trained to process information.

Please test your TreeView design with more then just single styled text strings. Because users soon want to show more.

It's minimalism gone wrong, and your praised UX team failed in the past for exactly this reason. You put one simple use case and solves them but never looking for the power cases. That together with the strict sandboxing and the waste of screen real estate was the reason why UWP failed so terrible and attracted exactly zero business application writers. Please don't repeat this.

Noemata commented 3 years ago

@anawishnoff , a clearly discernable selection region is essential beyond accessibility considerations. Windows gets used in many mission critical (hazardous) situations. Picture yourself in bright sunlight, having to figure out whether you've selected the right TreeView elements to arm an explosive detonation for a portion of a rock face in an outdoor mining operation (the sort of work some of my customers do), that should better inform some of the design choices made.

llothar commented 3 years ago

The other issue i have is that you only use two arrow indicators. But we have three states for each tree item a) collapsed b) expanded c) collapsed (because it's empty)

If you search for existing "outliners" your design team will find that there are a lot of well known solutions for this. Also imagine you want to show a file browser in the tree view with combined files and directories. Do you really want to show an ">" icon in front of each file? While technically each view item can have children, conceptionally that might be not the case.

The check box with the small low contrast "-" (for some children selected) and "v" for this item selected is also way to close in look and therefore confusing. Again, best to get fully rid of this ugly boxes. But if you have then, can you give the "-" checkbox for example a lighter blue or some other clue to recognize them more easily.

microsoft / microsoft-ui-xaml