Tree: sticky checkboxes and actions buttons

[saskliutas]

Hi, I am working on replacing old tree component with the one provided by @itwin/itwinui-react and having some trouble. In old tree implementation we have horizontal scroll when tree nodes have long labels or tree is deeply expanded. To make checkboxes easier to use with horizontal scroll they are positioned sticky and are always visible on the left size of the tree e.g:

I tried to achieve this using iTwinUI Tree but could not make checkboxes sticky.

We are also showing filtering button on the right side when node is hovered. This button is also positioned sticky to make sure that it is always in the same place e.g:

I couldn't achieve this as well. It looks like this one is not working because ._iui3-tree-node-content class adds overflow: hidden. I get he behavior I want by removing it.

This the the sandbox where I tried to implement these features: https://stackblitz.com/edit/vitejs-vite-2ubrrb?file=src%2FApp.tsx. You can see that expanding deeply in the tree horizontal scrollbar appears but checkboxes and filter button does no stick.

I wanted to know if I am missing something or this it not possible to achieve at the moment? If this does not look like a good approach from UX perspective I am open to suggestions.

[Ben-Pusey-Bentley]

The filter button that you have is using the sticky position, but it is sticking to the tree node content because of overflow: hidden. Elements with the sticky position stick to whatever the nearest ancestor is with one of the special defined overflow values, and hidden is one of them. docs source Adding the sticky position to the div above the checkbox causes it to correctly become sticky, but as you can see in the bellow screenshot, doing so can break the UI when user's scroll horizontally:

I think it would probably be better to avoid this UI styling. I think it would be better to make your tree container wider if you can to avoid the checkbox and filter buttons going off screen.

You can use CSS selectors to override the styles to create this, but you should avoid using private class names like ._iui3-tree-node-content. Instead, give your checkbox a class name like checkbox and filter button a class name like filter, and then use a selector like div:has(> .checkbox) for the checkbox div or div:has(> .filter) for the div above the filter button. Again, I think it would be better to avoid making this UI, since not everything draws underneath the checkbox and filter button, but it should be creatable.

[grigasp]

Sticky positioning should not be used here at all. It feels very arbitrary and does not solve anything. Why does the checkbox and filter button get to be sticky but the expander buttons and text labels don't? Additionally, it can cause problems at high zoom percentages, since it decreases the amount of space available for non-sticky elements.

I would argue that it does solve something. In our use case the tree is generally very deep (typically at least 5 levels, but often ~10), node labels are long and the checkboxes are the core feature of the component. Because of high level of nesting and long node labels, users often need to use horizontal scroll to find what they need to reduce the whitespace on the left, but they still need to see the checkbox, because that's generally the primary reason they're drilling into the tree in the first place.

The filter button on the right should not be hidden behind a hover interaction. Hover should never be required to reveal any actions; it's very bad for accessibility and usability.

While I agree that ideally it shouldn't, I would argue that for data-intensive components some compromises need to be made. E.g. the filtering entry point could be added to a node's context menu. What @saskliutas didn't mention is that the button is displayed always when a node's filter is active - not making it sticky will effectively make it impossible to see which nodes are filtered.

[mayank99]

We're internally discussing a better solution for this; we agree that deep nesting can lead to a less-than-ideal UX.

In the meantime, can you share more details around what exactly this UI does?

• If the checkbox is the main action, then does clicking anywhere on the tree node perform any action?
• What happens on clicking the filter button (i.e. what exactly is being filtered?) How would a user know the difference between something that is filtered vs something that just has the option to be filtered?
• What happens if the label is too long to fit in the container?
• Are there any other actions that a tree-node is supposed to be perform?

[grigasp]

If the checkbox is the main action, then does clicking anywhere on the tree node perform any action?

Yes. Clicking on the node selects the entity represented by the node and sets the node as selected.

What happens on clicking the filter button (i.e. what exactly is being filtered?) How would a user know the difference between something that is filtered vs something that just has the option to be filtered?

We allow filtering children of each parent node. Clicking the filter button opens a dialog that lets you define the filter.

Filtering button states:

• Initial state (no active filter, no mouse hover) - no button is displayed.
• Mouse hover state without active filter - a button with hollow filtering icon is displayed.
• Active filter - a button with non-hollow filtering icon is displayed.

What happens if the label is too long to fit in the container?

Horizontal scrollbar shows up.

Are there any other actions that a tree-node is supposed to be perform?

Nodes may have a context menu and a double-click action. Also, we need to support advanced node selection modes - ctrl+click, shift+click.

[FlyersPh9]

Do you allow multi-select? Or can only 1 node be selected at a time?

[grigasp]

Do you allow multi-select? Or can only 1 node be selected at a time?

Yes, we allow multi-select.