7

This is my first post here. Hopefully the description will come across as clear.

What I'd like to do in an application I'm working on is to present a form of hierarchy with a potentially great number of elements (n x 1000). The user will have the possibility of moving elements around in the hierarchy and an element could exist in more than one location.

At the moment I've opted for a tree (a JTree in Java) sat on the left with a edit panel to the right. However, I figure this might encounter issues when there are many elements. Only the elements being manipulated or selected need to be visible. The top elements could be considered as fixed categories but the path of nodes below that are potentially endless.

What other ways could I use to present this information?

James P.
  • 171
  • 5
  • How many levels deep is the hierarchy? – JohnGB Sep 08 '11 at 01:32
  • It depends on how a user structures their data. The original intent is to make a sort of organizer for documents on the subject of world wars (I'm into history). They'd be organized into layers depending on their importance and the events they're relevant too. I'd say around 15 levels. – James P. Sep 08 '11 at 01:44

3 Answers3

4

If the same object can be on multiple locations in the same tree, then you don’t have a hierarchy. At the very least, you have multiple hierarchies. Or perhaps you have some many-to-many relationships.

In any case, I think you need to think more about your data model. You probably need to break down the hierarchical scheme into several orthogonal dimensions. You might be thinking that campaigns are nested in theatres of combat, but it might make more sense for geographic location and events to be separate hierarchies –especially when you have an event that spans more than one theatre.

Some dimensions may be simple categorical, others ordinal (rank), others hierarchical (a series of nested categories), and others can lists (multiple separate category selections, where each selection may itself be hierarchical). Each imply different a user interface design, and, furthermore, you’ll probably have a different design for entering the dimension values for an object than for retrieving an object based on its dimension values.

For example, you can have one dimension be the importance of the document (e.g., on a 5-point ordinal scale), and another being a list of relevant events. For dimension-value entry, this implies the UI shows the document details necessary for determining the dimension values, and has radio buttons for setting the importance. The user can select from a list or tree of all events one or more events of relevance which appear in a separate Relevant Events list (like entering email address to the To line).

Or maybe you want to rate the document’s importance for each relevant event. That implies that the Relevant Events list is a table with radio buttons or drop downs to enter the importance for each event.

In summary you may want to think more along the lines of a relational database, rather trying to force-fit the data into a single hierarchy. Studying the UIs for various databases can give you ideas on how to handle your case.

Michael Zuschlag
  • 37,870
  • 4
  • 57
  • 105
  • 1
    +1 for thinking through the data model and, in particular, deciding which dimensions your users may want to organize on. Even if you did have a pure tree, a 15-level tree is not easily consumable in any UI. Also, with datasets that big, especially in a scholarly context, users likely want to slice and dice to home in on interesting patterns - outliers, commonality, turning points, etc. – peteorpeter Jan 12 '12 at 20:39
2

Maybe some combination Zoomooz.js and InfoVis.

See How to display the hierarchical data for more details.

Community
  • 1
igor
  • 2,533
  • 1
  • 22
  • 27
1

Potentially as part of a UI, but perhaps more importantly to potentially help you understand your data better, you may want to play with some visualizations of the relationships you are interested in.

I'd recommend starting with some network graphs, because in many respects the network graph is the Swiss-army-knife of visualizations.

  • Display relationships between any number of entity types
  • Combine the display of 1 to n relationship types
  • Hiearchies work, but aren't required

(gephi is an awesome tool for playing with network graphs. yEd is also worth noting for it's wider variety of layout techniques including orthagonal, radial, etc.)

As @Michael Zuschlag points out, many other aspects/dimensions may be interesting and useful to explore this data - geography might be interesting, or individual military leaders. You might add those categories as nodes in an uber-graph and link them to your events appropriately, or create separate graphs based on each "dimension".

It's a great way to explore highly interrelated data, and in order to build the graph you are forced to become acquainted with the data.

A few Moritz Stefaner projects come to mind as well that might be of interest to you: relation browser and content landscape.

Lastly, if you are finding you have a huge tangle of many-to-many relationships of interest, you might consider storing information in a graph database.

peteorpeter
  • 3,239
  • 1
  • 20
  • 23