Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

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) :

>Contract1
  >Group1
    >Article1
    >Article2
    >Article3
    >Article4
    ...
  >Group2
  >Group3
  ------------
  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 ?

share|improve this question
    
Would the user know what they were looking for? Could you apply some search filters? –  Captain Nov 18 '11 at 16:14
    
What's the use case? –  Jimmy Breck-McKye Nov 18 '11 at 17:08
add comment

4 Answers

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

share|improve this answer
add comment

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

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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