Alternative UI patterns for a large, shallow tree

Question

In our app, AdminUsers can be associated to Editions, which are part of a Course.

A Course would be something like Ruby 101, and an Edition would be French - Online or English - Classroom. So an AdminUser could be associated with the online programming related Editions, and another could handle the French Editions.

We tried implementing this configuration using a tree, where the first level is the Course, and the second level is the Edition. As expected, you can check off a Course, and all the Editions get checked off, or you can check a single Edition. Great.

The problem comes in when there are 500 Courses with 6 Editions each. The tree becomes unwieldy and slow (due simply to the volume), even with a filter and other selection options. Even changing the tree structure (more levels or something) wouldn't change the speed problem because there are still a few thousand nodes.

Is there an alternative pattern for displaying this type of data/association with this much data? The main use case is the client wants to select all based on some criteria ("all english classroom Editions"), but also specific individual ones for those silly Editions.

Maybe just a list with an autocomplete way to add ones? But then if they have access to lots of Editions, the list is huge again. Maybe we can't avoid that.

None of us are very proficient with U[XI] related things, so we're sort of running out of ideas.

Answer 1

Is this really a tree? It seems more like a grid of data.

If the set of possible 'editions' is small--sounds like it is six--then why show them as a tree?

Show them as a table, with:

1. one row per product, and one column per edition.
2. Present a checkbox or other control if that edition is available for that product, or a blank cell if it isn't.
3. If you have 'related' editions (e.g. French/Online and French/Classroom), have a split "French" column with Online and Classroom checkboxes within it.
4. Consider letting the user filter out columns they don't care about.

Yes, large tables (or fake tables using CSS) can be slow too, but not as slow as most tree implementations.

Answer 2

The root of your problems lie in the use of a tree to browse a large amount of data. It simply is not a good vehicle for browsing and selecting large volumes.

Consider instead using (as a foundation structure) something like Miller Columns which split the structure into adjacent columns as used most excellently in the Mac OS X Finder since version 10.0.

For more information, see Finder on Wikipedia; a video on YouTube of the Windows UltraExplorer or this very quick demo at 1m:13s into a video about Finder Basics from Apple.

Answer 3

I think the design you have looks reasonably usable if the filter works well and you can fix the performance.

The performance issue shouldn't be too hard to fix technically, though you probably won't be able to use your existing tree component. I suspect it is creating all the visual elements up front then hiding them.

That is the simplest approach for a small list, but there is a lot of overhead on those elements. For a large list you are better off using a simple in memory structure for the complete data and only creating the visual elements after the complete list has been filtered to a much shorter list.

12,000 html elements with styles, images and event handlers is a lot, especially for IE. 3000 small objects in an array is nothing.

Answer 4

I was thinking exactly at the same things 2 days ago. I came up with that solution: A mix of iPod drilldown menu + checkbox list

Answer 5

Might sound strange, but maybe the problem is that fixed hierarchy. I understand that hierarchy in the physical world is in the given direction, but what would happen if you have a drop down that can say "organize by course" or "organize by editions" (sort, group, whatever). It might help you jump around change the point of veiw when needed, and switch back. That in combination with filters and select all might work... though it sounds complicating even when i read what i wrote...

Answer 6

Why not just use a search/filter box without showing any options by default? Use autocomplete so that the user has some idea of what to type in and then also dynamically load the appropriate options in a tree at the same time. Basically, use the same pattern as Google's Instant Search.

Then, if a user needs to make multiple selections across different categories, keep the trees for their selected items on the screen and do the dynamic loading beneath them. You could make an animation of moving the checked trees to the top (above the search input) or to the side so the user knows that they haven't been lost. Or, as an alternative, just briefly highlight their backgrounds and use a notification that says 'Selections Saved'.