I have a hierarchical structure such as the following :

every user has some contracts associated to him, every contract has some groups associated to him, and every group has some articles.

I represent this visually using a TreeView (with checkboxes such as in http://www.codeproject.com/KB/WPF/TreeViewWithCheckBoxes.aspx) in WPF :

(every user clicked on displays this structure in a TreeView) :

  Add Button
  Remove Button

Using the precedent screen, the user can Add further Articles or Contracts or Groups to his account just by checking on them and clicking Add button or remove them by clicking Remove Button.

the problem is that there are tens of thousands of articles in every Group and I don't want to bring them all in memory at once, for it would slow things down.

Can you think of any better way of handling this ?

  • Would the user know what they were looking for? Could you apply some search filters?
    – Wander
    Nov 18, 2011 at 16:14
  • What's the use case? Nov 18, 2011 at 17:08

4 Answers 4


Personally I would suggest not using a tree but using something like Miller columns. You'd have Contracts in the left column, Groups in the second column and Articles in the third column.

You could add a fourth column which gives information about a selected article - for the given group and contract. Maybe you need a leftmost column for users too. You could manage the logic for multiple selection depending on your requirements.

Underneath each column you can have a button for Add / Remove based in your selections and selection path.

That's just an alternative suggestion to using the tree...

But what really concerns me is the fact that you have tens of thousands of articles in each group, and that's the real usability issue in this scenario.

It doesn't matter whether you use a tree or a list, or miller columns - that amount of information in a single group is not manageable by the user. Not without adding a way of further ordering and chunking of the information - eg by alphabetical order, date, size, location, or other relationship or characteristic that means something in your scenario.

That degree of chunking (ie many levels of branching) simply doesn't work in a tree - not from a perspective of findability, browsability, memorability - or any other ability.

It's simply so unevenly distributed towards the leaves of the tree that the trunk and the branches can't take it's own weight, let alone allowing the monkey to find the fruit!

enter image description here


You can use a mixture of tree and list, to reduce the hierarchical structure. Buttons for adding or removing are depent on the selection (contract, group, article).

Reducing the tree


While the other answers will help with the interface, I think using meta data to help manage such a large amount of information would certainly help those approaches. Since I don't know exactly what the common denominators are with your data, I can't relay anything specifically, but I'd take a look at your information and see what you can do as far as grouping and arrangement by meta data.


It depends on the use case for viewing.

There is no universal pattern for this or any other problem. Different kinds of interfaces will make the data more manageable at the cost of inhibiting different kinds of workflows. For instance, treeviews are good when you need to instantly see the distribution of child elements amongst sibling items. Miller columns ('panes') work well when the groups of children for each parent are somehow parallel or analogous to one another. Showing data in individual forms with breadcrumbs representing 'paths' to that point are useful when the data in the form is the main focus, the path subsidiary.

I just can't help you without more information.

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.