I’ve been looking at several different UI tools and programs for hierarchical information display. Some of these are almost purely graphical, others are purely textual, and others split the difference. Some links:
There are actually a lot of these types of kits and programs available. Some of these have led to secondary tools built on top of the more basic ones–there are a number of extensions to TouchGraph, for example in browsing Google searches results. The utility of these varies depending on what you’re trying to accomplish, of course; but what interests me are the advantages and disadvantages of using certain UI metaphors to grasp and navigate around information.
Take TouchGraph, for example. What I love about this toolkit is that the visual effects seem very fresh (I don’t get bored with them) and the rendering is smooth. You can do neat things like zoom or rotate the graph using sliders (not all the demo/applications written with TG support this), as well as filter out the edges to reduce visual clutter.
But TG also shows the downside of this sort of layout. I find I need to have a certain amount of empty space between nodes, and that I need to limit the number of visual edges, or else the screen becomes too cluttered for me and not very usable. This is due in part to a limiting factor–that nodes are displayed as text strings, which take up horizontal space, and edges that cross each other are too hard to see–so I find I need short text strings, few text strings, and few edges displayed at any one time to get useful information out of the visual model.
The TG-style views don’t represent hierarchies well, to my eye, even if the data source in question (say a website) has, in common use, a hierarchy in place (rooted at the home page). It’s true you can establish a “central” node with related nodes radiating outwards, but this seems to go against the grain for websites that really are organized hierarchically.
FreeMind has the advantage of displaying something more like a tree (though I think it can be made to suggest a graph), and as the nodes are laid out left-right or right-left, there is a clear way to navigate down the hierarchy through eye movement. It also suffers from the drawback of nodes-as-text, and I find that nodes with long text strings just, again, clutter up the view.
Which brings me to another point, which is the purpose of using these things. I’ve used JOE to write outlines of ideas, analysis and tasks lists. It works well for that purpose, and my old favorite, the Word outline mode, has been long ago relegated to less-favorite-son status. It is better than a text editor for that purpose because it enforces the hierarchical structure–you’re editing an outline, and the editor is only an outline editor–and the top-down layout supports longer strings as these can take up the full horizontal width of the screen without negotiating with other elements on the right or left.
But then, with JOE I can’t represent a graph–a node in the outline that has more that one parent node. With WikiPad I think I’m getting the best of both worlds, as each page in the local Wiki can be belong to either a strict tree or a graph, depending on how it’s referenced.
Still, there is something immediately captivating about these graphical views, and I can’t put my finger on exactly what that is. For one, it’s somehow more inviting–I *want* to click on links and move the nodes around. I feel I have some control over what I see and how I best want to see it. The textual approaches of JOE and WikiPad (WikiPad does have a navigator, but it’s a standard tree-style component) put my mind in some kind of box–a box in which I sometimes feel productive and sometimes feel constrained.
But there’s this problem of content. It seems that without some conventions about how to identify nodes, there’s just too much information available in the visual layouts. With Entity-Relationship Diagrams (ERDs), there are some very consistent conventions, and at the same time, there is an important constraint on the structure of the nodes in an ERD, which is that each entity (often a table in an RDBMS) has a name, then columns–so columns can be displayed in a list below the name, forming a naturally rectangular view of the node. That convention is too limiting for general-purpose information hierarchies, though.
The last problem I want to mention is just a UI problem–which is the modal behavior of all this. If you expand the window that holds the TG GoogleBrowser, for example, you can actually fit quite a bit of information on screen. The problem is what you do with it. At the end of the day, being able to navigate nodes and follow a set of links in a cool-looking graph doesn’t help me–I always want to drill-down to the content. And when I do that, then I need to pop out of the graphical mode into some other, like a browser. And that change of context back and forth I find somewhat bothersome.
I love the work people are doing with this, and at the end of the day it’s cool to see the variations in how you can play with this stuff. Check out the links above–the HyperGraph website has a neat built-in navigator applet to move around the website.
(originally posted as this JRoller entry)