Organic Menu System


This is a brief post on a recent data visualization project that involved an organic menu.   The client wanted a prototype for an upcoming project where child nodes arced out from root nodes and all nodes ‘floated’ through space.  Clicking on a child node revealed further child nodes and they wanted to be able to navigate back and forth through the tree structure.

I pointed out arbor.js and the designer for the company indicated that it was a good start, but they wanted at least one more level of navigation and curved arcs, not straight lines between parent and child nodes.  His vision was along the lines of having a piece of metal with memory; that is, the metal would bend into a nice, smooth, curved shape, but always return to straight when tension is released at both ends.

I noted that they would also need to vary the length of the hypothetical metal connector between nodes as a fixed-length would result in too much bending when parent and child nodes were close.  These were, of course, issues beyond the background of the small internal programming team.

Given the budget this company had for a prototype, I quickly came to the conclusion that a pure physics-based approach was not realistic for me to consider.  I also believed that it was not really necessary since the only true need for physics was a spring system to control motion of the individual nodes.  Arbor already does a good job at that task.

It only took a matter of half an hour to sketch out an algorithm that used a quadratic bezier curve through three points to draw the arcs from parent to child nodes.  There is more apparent curvature when nodes are close and the arcs tend towards straight lines as the distance between nodes approaches a multiplier of the canvas width.

After an hour of coding and tweaking parameters, I had a pretty decent prototype based on a node heirarchy of hypothetic data.  It took far more time to get up to speed with Arbor and write the code to manage moving back and forth between multiple levels of information.  I even setup the JS library so that any of the nodes could be images.  Remaining nodes may take any of a number of named shapes and all are drawn and labelled dynamically.


The designer looked at the prototype and raved over the results.  Of course, I had to tell the company that it was not a physics-based solution.  I used a geometric approximation to get the prototype done within their budget constraints.  The designer, in a typical display of artist arrogance, claimed that the prototype was not acceptable since it did not use the specified physics solution.  This was AFTER his enthusiastic response to the demonstration.

Oh well, at least I got paid a small fee for the prototype.  That’s the good news.  The bad news is that I can’t release the code even though the company did not use the menu system.  I have kept it for my own purposes and may release it in a future microsite now that the company cancelled the original project.

I think the object lesson here is that we all love to over-engineer and create the most physically realistic models possible for a project.  Sometimes, it’s not the being realistic that matters so much as simply looking good and looking good within time and budget constraints.

Too bad some designers don’t get it :)

Comments are closed.