Modern Alternative to Tree View for Hierarchical Data

  • There are other similar questions to this, but none of the solutions really fit my problem space. Breadcrumbs and drill-down menus are not the solution. So without further ado:

    • The design problem is a configuration panel that takes up 1/3 the application space
    • It's a desktop application (not web, not mobile)
    • Configuration groups have files which have child items that need to be seen/managed
    • There is a search feature, but no facets
    • Needs to be compatible with touch screens
    • The 1/3 width configuration panel directly affects the 2/3 width application area. The user needs to see the affects of their configuration choices live.

    Everything about the design problem suggests we need a tree view, except for touch screens. I attempted to use an accordion pattern in mockups with our development team and it didn't really work for our situation. We need to have more than one sub-group open at once.

    More requested Detail:

    • Typical depth: 4 levels
      • Config Section
      • Group
      • File
      • Record
    • Worst case real world depth: 5-6 levels (groups can have sub-groups)
    • Typical records per file: 10s
    • Worst case records per file: 100s
    • Configuration sections: 4

    NOTE: We may or may not choose to show the file level only if the user requests it. That will reduce the max depth we need to worry about, and for some configuration sections it gets in the way.

    Search will be a key part of this dialog, there really is no other way to do it. However, we don't have the real-estate for faceted search, or any obvious facets that aren't already part of the hierarchy. Breadcrumbs can be a part of the solution, but in the area where we have the most records we need neighboring groups open at the same time.

    why can't an accordion have multiple sub-groups open at once? This is the path I would go as well.

    Technically it's no longer an accordion when you do that. I can go with "expanders" in WPF speak (http://www.wpftutorial.net/Expander.html) But that also met with luke-warm responses.

    Questions: 1. It's a 3 level hierarchy (group, file, child)? 2. Roughly how many nodes in each level (order of magnitude... Tens, hundreds, thousands?)

    I can see how multiple levels of "expanders" would be met with concern. I do think the solution will have one level of expand/collapse in it though -- http://codepen.io/run-time/pen/MYPGJZ

    It's n-level, but 4 levels in most cases. Config section->group->file->child. Groups can have subgroups, but in practice it shouldn't go more than 5-6 levels overall. Some groups can have hundreds of sub-items. Total number of items depends on what the user loads, but potentially close to 10,000 items the user *can* interact with. Search will have to be an integral feature. It's the browsing structure I'm having trouble with.

    For most configuration sections: 10s of items. For a small number of config sections it will be 100s of items.

    What about a touch screen screen eliminates tree view. Why not just put configuration is it own tab?

    @Blam, without the changes in the answer below the clickable targets are too small with a traditional tree view. The area taking 2/3 of the screen is affected by the configuration going on in the panel on the right. The user needs to see how the configuration changes directly affect what they see.

    I guess I don't get the question but a tree view is just hierarchical data. Why not just have hierarchical comboboxes across the top?

    @Blam, why not write that up as a potential answer? I have Windows users, so that's not something common in Windows desktop applications. I'm having a hard time envisioning what you mean by hierarchical comboboxes, and how you would see data in neighboring nodes.

  • tohster

    tohster Correct answer

    6 years ago

    I don't like tree views, but sometimes they really are the most appropriate widget.

    Before you write the tree view off, it's worth thinking about whether it can be redesigned better for tablets.


    1. Issues with tree views

    • The drop-down icons are usually too small. They're hard to click even on desktops, let alone on tablets (see Fitt's law).
      • Idea Can we make the icons larger?
    • Deep tree hierarchies occupy a lot of horizontal space, so you get clipping or horizontal scrolling, which is frustrating for users.
      • Fortunately for you, you're intelligently budgeting 1/3rd screen space for this control so this is a bit less of an issue.
      • Idea Can we use smaller indenting and line-wrapping to preserve horizontal space budget?
    • If the tree has many nodes, it's easy for users to get disoriented while deep inside the hierarchy.
      • Idea Can we use indicators to show what level of hierarchy we're at?

    2. Design sketch

    Here's one approach which incorporates the ideas above:

    enter image description here

    • Large icons for touch friendliness
    • Icons are >2x line height, which allows you to wrap long lines once rather than have them overflow the box
    • Narrow indentation
    • Use of leading . period indicators to show level in hierarchy
    • Top toolbar for search/filter/etc

    This may or may not suit your needs, but I think it's always helpful to look at the possibility of modernizing an existing control before writing it off as antiquated.

    My last suggestion is: remember that for enterprise applications, the goal is usually to design the most effective interface, not the most beautiful one.

    tohster like the idea of improving what exists rather than coming-up with something completly new! A secondary issue: What do you think should be displayed before any selection is made?

    A lot of merit to this approach. In my case, I would display the top level configuration items completely collapsed. Also some good reminders about being effective.

    @Okavango if the tree is really up to thousands of nodes, I'd be inclined to (a) collapse all nodes into top-level; (b) slightly gray out the tree until it is interacted with, and (c) autofocus on the search box. What do you think....any ideas?

    Seems quite reasonable to me and handles emphasis smartly ! I was just thinking about making use of space prior to selection to highlight some of the configuration options. If I am not mistaken salesforce which deals with huge amount of config settings does that, though "clumsily"

    @Okavango ah I see...you mean the space on the right. That's a really interesting idea..something like this? http://i.imgur.com/L02nqMx.png

    Sorry, I wasn't clear :) The space to the right could introduce the range of possible settings in high level terms just as the link you shared suggests. Past on-boarding stage it could highlight frequently accessed functionality and perhaps even more so users don't have to use search.

    @okavango got it. I like the idea a lot... There does seem to be a prevailing attitude of "search cures all" in apps nowadays, and while that may be true for consumers, enterprise users could really benefit from more specialized settings and controls.

    Agreed! Enterprise software hold tons of data that consumer facing products can't even dream of having... They should make use of it :)

    NOTE: I'm still preparing for the design review meeting before I accept an answer or not. A couple things came up that are taking my time at the moment.

    I just briefed it to the team (man that took a while), and it was well received. It scratched the itch for the laptop/tablet environment. Part of what took so long was the fact I had to apply it to our data and there were some other features I had to include in the tree view. Those are specific to my app so it doesn't change the fact this was the best answer for what I needed.

License under CC-BY-SA with attribution


Content dated before 7/24/2021 11:53 AM