Tree-view pattern

[aprilma419]

Requesting for the implementation of tree-view table patterns.

In Keycloak Admin Console, we have a feature called Groups, which allows users to create groups of users to a parent group, and there could be hundreds of children groups in a parent group with approximately 5-10 levels of nesting groups. Users also can cut and paste a group to a target parent group.

The original Group feature looks like this:

The exact use cases of Groups that we'll potentially do as below:

• Move single or multiple groups to a parent group by using a one-column tree table to achieve that.
• There are normally 5-10 levels of nesting groups in a top-level parent group or even more.
• Have pagination inside a parent group to inform users about the numbers of children when there are hundreds of children.

I noticed there are tree-view table designs still work in progress, including a full table version and one-column version. So it raised a question to me of when we could get a completed version of these tree patterns, would they be done by September 2020 or there are other plans on them?

[mcarrano]

@aprilma419 The tree-table development is currently on hold as had encountered problems making this work as a table. Do you require anything other than a one-column tree? If not, we may be able to deliver that.

I'm a bit confused about this statement:

Have pagination inside a parent group to inform users about the numbers of children when there are hundreds of children.

Also are you really looking for a collapsible tree or something more like a tree drill-down? It would help if you can provide some wireframes that illustrate what you need.

cc @LHinson

[aprilma419]

@mcarrano Thanks for the answer. We've learned that it's impossible to show children level paginations in a table, so we were thinking of using a left side tree-view list to show the levels of groups. Below are the two screenshots of what we will most likely to have the Group page look like:

The way of showing each level of groups we were using is similar to what Google Drive has(like the pic below), user can choose to view children groups or detail pages at the right part of the page by clicking the group name in the list, or to drill down by clicking the arrows. To better navigate among those levels of groups, after looking through some other products, we think breadcrumbs could be a good solution.

On the top left corner of the list in my screenshot, there's a "Move to" button, which is something we still want to use the one-column tree patterns to achieve, same to Google drive's "Move to" menu.

[mcarrano]

So if I understand correctly @aprilma419 , you are looking for us to introduce a tree browser control like the one on the left, is that right? The drill-down tree is also something we've investigated for other use cases. There is an open issue here: https://github.com/patternfly/patternfly-design/issues/774 But it's true that we are missing the expandable tree in PatternFly. Do I understand correctly?

[aprilma419]

@mcarrano Yes, what exactly we want at this time is the tree browser at the left side of the page and the one-column tree pattern, so that we can implement them by Sep 2020.

[mcarrano]

@aprilma419 . We have added this to our roadmap to be available in a June-July timeframe. You can look for design updates to be posted here as we work on this.

[aprilma419]

@mcarrano Great! Look forward to the updates. Thanks!

[yih-wang]

@mcarrano Will the expandable tree browser control support some extreme cases? For example, how to display if a parent node has thousands of children nodes?

[mcarrano]

That's a good question @yih-wang . What would you expect in that situation?

[yih-wang]

@mcarrano Keycloak may have such extreme cases like a parent node has thousands of children nodes or thousands of embedded levels. Maybe an "explore from here" function would work. Users can right-click on a node to make it the new root. The following screenshot shows the case that exploring from the node "ContentPresenter". Maybe we can also add a number next to the node to indicate how many children this node has. So users can have a psychological expectation on what would happen after expanding the node.

[mcarrano]

Thanks @yih-wang I agree that we should have the option to report the number of children associated with a node. I think that "explore from here" is an interesting idea. Maybe this works as some sort of drill-down where the breadcrumb at the top shows me how many levels deep I am?

[yih-wang]

@mcarrano Yes, exactly!

[ajacobs21e]

https://github.com/patternfly/patternfly/issues/2635#issuecomment-608053401 I have a similar use case that I posted on the multi-level dropdown issue but my context is more of a tree view than a dropdown and would be used as a filter for a table. My use case would have nested items around 5 levels deep, but 10+ levels are possible. The names of each level are usually a few words long too. For those reasons doing an indented design like April's won't work. Here's my example in context (this page and the next two) https://marvelapp.com/70e251a/screen/67725428

@nlcwong has a similar use case as well.

[aprilma419]

Hi @mcarrano, a quick question on the interactions of the one-column tree pattern.

Can users click on the row(anywhere except the arrow area to drill down) to be selected for actions in a compact-sized one-column tree？Or they're only allowed to click on the Action link to do actions in a row?

[mcarrano]

@aprilma419 Since this component does not exist yet, I'll turn this around and ask what you expect. For consistency with what we've done with similar patterns, I'd say that the user should click on the action link to trigger the action. Do you agree?

[aprilma419]

@mcarrano In our case, the users will select one of the rows and then click a confirm button below the rows to finish the task, and this whole pattern will be in a modal. It seems a bit odd to me if users click on the action link in a row to leave the modal.

However, it's fine if the pattern remains for consistency reasons, I think we can use something like a radio button to let users make the selection.

[doruskova]

@mcarrano I'm adding a mockup for a tree view with some variants. Link is here. It includes:

• default version,
• with search,
• with checkboxes,
• with chips,
• clear version without these chips that indicate a number of nodes.

More specific mocks with padding are in progress.

[ajacobs21e]

@doruskova These designs look great, I especially like how you're showing context of what's selected. However I don't think these meet my use case. The directory names in my tree could be very long (8+ words) - do you know if longer names would wrap or truncate etc? My directory could also go pretty deep, I was told 10 levels deep is a fairly common example. I think it will be unmanageable to read each level if they're long names and indenting 10+ times.

[doruskova]

@mceledonia I updated the mocks for the tree view pattern here. Let me know if it makes sense to you or if you see any issue. I just need to add a tooltip for the truncated name and change the search bar because the tree should be filtered without clicking on a search icon.

[doruskova]

@mcarrano mocks have been updated. Link here Changes: search bar, a tooltip with the full name. The badges should indicate the number of children. I hope that I understood it correctly.

[mcarrano]

This looks good @doruskova . I think that the only question is what happens to this when we shrink into a mobile viewport. Does it remain a tree or transform into something else?

[doruskova]

@mcarrano I think it should be still a tree. It's just an accordion menu, so it shouldn't transform into something else. I've added a screen for it (link here) The only thing I changed is the truncation for the mobile version because the user can't trigger a hover action to see the full name. So, I wrapped the lines for the mobile version.

[doruskova]

@mcarrano Menu with icons and specification have been added here Also, I added some examples of additional features for a future here

[doruskova]

@mcarrano I've updated the mocks with an action item on the right side. The action should be triggered on a hover. I was trying to make it as universal as possible and I think that using kebab is the most universal solution that covers most of the use-cases. But, IMHO should be possible to add any type of action (icon) on the right side depending on the use-case. Do we want to limit these actions by using just a kebab icon? Let me know what do you think. Here's the screen with possible additional features. I talked to @gdoyle1 about adding this into a template, so I would like to clarify that this behavior (with kebab+other actions) makes sense to you.

[gdoyle1]

@doruskova Awesome, that looks good to me! Allowing flexibility to put any icon button you want there makes most sense to me.

I think the only thing I was wondering is if the icon button should be shown all the time or only on hover?

[mcarrano]

This looks good @doruskova . Good question about hover. What were your thoughts?

@mcoker can you also take a look here? The general goal is to support an action in a menu item independent of selecting the item (like we do for favorites now). How much can we generalize that? Does it make sense to drop anything there like a single action or a kabob menu as shown? Or do we need to restrict this to something that's an icon button? The more flexibility the better.

[doruskova]

@mcarrano @gdoyle1 I think that the icon should be shown only on hover, because imagine that every item in the menu will have, for example, the kebab. It would be messy and look like this:

[doruskova]

@mcarrano added a placeholder icon for an action item on the right. Link here

[mcarrano]

I am going to move this to development for the basic collapsible tree pattern as described in the Marvel deck. A new issue has been opened to address the drill-down tree menu as a separate component. See #867.

Thanks for all your work on this @doruskova

[mcoker]

@mcarrano sorry for the delay

The general goal is to support an action in a menu item independent of selecting the item (like we do for favorites now)

The favorites button is a specific action button for the dropdown menu item. And it's generalized so that you can put any kind of icon in it you want. That said, it wouldn't work as a dropdown toggle currently - though it could potentially work as a dropdown if a user were to attach the upcoming context menu to it.

That said, we could extend this to general use of the plain button or plain (kebab) dropdown, by changing the way the button and dropdown components appear when placed beside a menu item. Then a user could add any plain button or plain button dropdown to the item that they want.