5

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?

  • A top levlel with 8K nodes is not the start of good UX in my opinion – paparazzo Aug 20 '14 at 17:00
  • It is possible that some non-specific answer is applicable. However I think that more knowledge about how this hierarchy relates to users mental model may be useful in designing the right solution. e.g. Separate page or mode for type-A / type-B may be great idea or plain dumb. Can't currently tell. – Jason A. Oct 20 '14 at 15:06
3

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.

  • How would the outcome of your query-filter look like? Let say if your filter has multiple nodes/branches/leaves to show how would you present this to the user? You've got more or less a list with maybe more nodes with branches and leaves attached to it. – myradon Aug 21 '14 at 9:38
  • @myradon Not sure I understand the question. Consider a tree with all nodes/leafs shown. Now in the query field the user types 'a'. Say it isn't flex-search, so only items starting with 'a' are considered matches. Basically, any non-match is hidden (taken away from the tree). Does this make sense? – Izhaki Aug 21 '14 at 11:10
  • What I mean as partly answered by Sruly below. If you filter the results can be leaves, nice targets entity, but it can also be a path, like 'parent > matching_node > children/sibling/whatever'. So basically that row-entry in result-list will be a snippet of your tree, in Sruly's words breadcrumbs. – myradon Aug 21 '14 at 12:34
1

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.

  • This is almost exactly the direction we have been leaning indirection we are heading in. A search box that provides a list of matches. When you click on it, you get into that node's detail page which has a breadcrumb and a list of all the child nodes + additional metadata. We're taking that idea on a spin currently. Will let you know how it pans out. – Szymon Rozga Aug 21 '14 at 12:31
1

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.

0

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;

enter image description here

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.

  • That seems a little confusing. Because to me, this looks like if you click on "blue cotton," it will omit what you searched for originally. I don't know if this will work as elegantly as planned. Did you test this out? I'm curious about your findings. – Majo0od Aug 20 '14 at 15:08
  • @Majed, frankly I didn't test it. it's an idea. – myradon Aug 21 '14 at 9:15
  • I'm curious to see how that will work in a real environment. If you get any results from this, let me know! – Majo0od Aug 21 '14 at 11:54
  • As an example of this, you could look at the command palette of Sublime Text 3 (a texteditor for developers). I'm trying to reproduce something similar because I think it's the easiest way to quickly find what you are looking for in a mountain of data without having to dig deep down :) – achedeuzot Sep 3 '14 at 21:07
0

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/.

  • It's basically a tree view of 200k nodes. Each node has between 0-1000 children. There are ten nodes with between 1000 and 8000 children. Too much data for one tree view. – Szymon Rozga Aug 20 '14 at 19:39
  • Are these nodes somehow consistent? Like you put items in a node to mimick a property like 'Action-node > Die Hard, Action-node > The A-team or House-music-node > DJ whatever, House-music-node > DJ someone' Basically you could say the parent node is a property of these items. But this only when the tree-structure works like that. So an item will reseed in probably more then 1 node. If so maybe tagging convention works. We need more context. – myradon Aug 21 '14 at 12:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.