UX to view and search through large set of hierarchical data

Question

Building a web desktop site in which users have to be able to navigate through a hierarchical structure. There are two types of nodes, call them A and B. A can have children of type A or B. B are always the leaf nodes.

Right now, we have ~150k of type A and 225k of type B.

At the top level there's about 8k nodes. It just goes down from there. We absolutely need the ability to drill down into each node, search through the nodes and select/unselect nodes.

The amount of nodes are pretty crazy. If this were just a list, forcing search and limiting number of results would be my approach. The fact that we have a tree makes things a bit more difficult.

What's a good user experience model for this type of scenario?

Answer 1

Seeing as this is a UX form, it would really help knowing what the user needs are. That is, what is the nature of the nodes, and what will users try/need to do with them and why. Also, is there any additional data users may be able to filter nodes by, and is it a single level hierarchy or an unlimited one (Can A have an A child that has an A child and so on - like folders on a file system).

As a side note, one research suggests that 70 similar items is roughly the amount people will bother to visually inspect - more than that people are likely to use a search/filtering function.

Without these details it is hard to provide a comprehensive answer, but the approach for tree search goes like this:

• There's a typeahead search field.
• The query entered is matched against the leafs; unmatched items are hidden.
• After filtering, any node without children is also made invisible.

If users may search for nodes (not only leafs) that you keep the nodes that match the query.

Although not ux-related, I've recently implemented exactly such behaviour (albeit to trees that hardly ever has more than 250 items) using AngularJS and it was dead easy to do.

The last 'tip' would be to consider the physical effort involve in selecting/collapsing nodes - I can only assume that collapsing will be the more common action, so a click on a node (as well as on the collapse icon next to it) should collapse/expand the node, by that offering users large click area for such action; selecting a node can be done using a (much smaller) checkbox next to each node/leaf). If selection is more common, use node click for selection, and collapse icon for collapse.

Answer 2

Does it matter to the person searching, if a node is of type A or B? I mean – do you have to make the tree structure visible within the search? If not, I would recommend using the ux pattern "faceted search" or "faceted navigation". In my opinion this can be a helpful ux pattern especially for 'power users' that know what they're looking for – but also for people that would just like to discover what's in the archives.

Here's an excerpt "Design Patterns: Faceted Navigation" at alistapart, originally published by O’Reilly, explaining the ideas and mechanics behind the concept of faceted navigation.

And here's a working example at the website of Moritz Stefaner which lets you browse parts of the archive of the New York Times (2.6 Million pages).

And german TV station Deutsche Welle is using faceted search for their video archives over here.

Also interesting: "Filters vs. Facets: Definitions" by Nielsen Norman Group.

Answer 3

With huge trees like the one you mentioned, no matter how you display it, it will be very difficult to find what you are looking for even in a filtered tree.

I have encountered similar issues (10s of thousands of nodes and more than a million leaves) and in the end we decided that for large trees, filtering does not make sense from a UI perspective.

Instead, searching in a large tree displays a flattened list of results with, in some cases, an indication of where in the tree this node lives (sort of like breadcrumbs).

This was the only solution we could come up with that solved both the UI and technical difficulties of the situation.

Answer 4

Currently I'm in a similar situation. We both agree digging through the tree doesn't work. Does the end-user have a mental model of tree in mind when they think about the navigation? What about fuzzy searching? This what a proposed to a developer today. When you type in a input-field the system will recognize the pattern and show the correct node/property/whatever along with the value. Something like this;

You type dress and the system comes up with all kind of dresses. so you pick 'dresses - short' by tabbing or clicking and you continue your query. It looks a bit like googly markup with the colon. A power-user will know if he/she types some-nodes:value the system will popup with a usable result. And I think also implement a faceted search on (most searched) properties of entities within node type A and B.

Answer 5

You question was not clear enough for me. I will reply it as much as I can.

I believe that in this case, applying a couple of approach together is the most usable. I do that in banking systems and get positive reactions when finding complex products / transactions etc...

I would use the combination of those three

• autocomplete text area: It is important that not only the names of the items but also the headings of the tree menu are also provided. You can only guess how a person remembers something.
• detailed search area: I do not know what kind of info you are looking for but in detailed search you can select main groups, dates, possible transactions, similar elements, etc...
• a tree menu will be the main content. It can be grouped in a different way in the back end but whatever the user sees is better be how people thing / talk about it. Otherwise it is not understandable. (a shop could be called "a unit" in the back end but in front it should be called, labelled, tagged and grouped under "shops")

If I would prioritize, I would go for the tree menu. Amazon is a great example for this kind of interaction http://www.amazon.com/.