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.

Tree view

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.

6 Answers 6


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.


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.

enter image description here

  • miller columns are still a tree structure, but with an extra flaw: deep trees trigger horizontal scrolling.
    – worc
    Nov 29, 2016 at 0:12

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.

  • 3000 is not a lot perhaps in terms of crucifying system performance, but it IS a lot in terms of the user efficiently being able to browse a list! Oct 25, 2011 at 0:00
  • 2
    true, but I don't think there would ever be that many displayed due to the use of the filter - it's actually a search/autocomplete system that happens to display results in tree form. Oct 25, 2011 at 0:12
  • Support the answer from @TomClarkson, I think talking to your developer and getting him to lazy load the data would help so that only the data that will appear in the screen is rendered, rendering of all the nodes would be really make the browser cringe. Oct 25, 2011 at 2:49
  • @RogerAttrill Tell that to IE8 :) (RE: performance) Oct 25, 2011 at 14:59

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

enter image description here

  • What happens with the checked items?
    – CheeseCake
    Apr 6, 2021 at 16:59

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


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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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