Polishing things off (for now)

In order to finish up this project, at least for a first phase, which is all this is, we need to tidy up the UI. This consists of two things: first of all, adding in some CSS; secondly to add actions on the tab buttons so that clicking on the tab labels will cause the associated tab to be shown; and thirdly to clean up the error handling so that the error tab only appears (and is automatically selected) when there are errors.

It turns out that in order to do all of this, we need to restructure the HTML somewhat and break apart the tab titles and the tab bodies. This adds more complexity all over the place, but none of it is really interesting. For those scoring at home, it is this change that the ensureTabs method depends on.

In fact, none of this work is interesting, so feel free to dig in if you want to, it's really just essential to making it look acceptable.

Future Work

What isn't in the future? This really is just a question of scratching the surface of what can be done. To progress, this tool really needs to be used in anger, with the intent of drawing diagrams that mean something. Earlier in this blog, I have drawn some diagrams by hand, but I'm not going to draw those again just to test this tool out. But next time this blog calls for diagrams, you can be sure I'm going to dig this tool out. It will also be interesting to see how I go about incorporating such a diagram into the blog (I could experiment with that here using the samples, but I'm not going to).

Among other things that still need to be done:

• No complex connectors have yet been addressed, and these obviously come up all the time in real diagrams.
• In spite of the claims I may have implied for my algorithm, I think there are quite a few cases where it will be necessary to move nodes after they have been placed.
• So far we only have "nodes" and "edges". I would like to have a much richer semantic description of the diagrams I want to draw, but I'm not really sure what that would look like until I try it (but would have a domain-specific vocabulary of things like "server", "queue", "notification", "processing", "store" for a cloud-based software system). In addition to improving the clarity of the diagram description, I would expect this to provide information to the layout algorithm.
• I definitely want to be able to handle very large diagrams - let's say 200 nodes - and be able to expand and compress them by having the tool offer an "overview" or "schematic" of a whole system with just (say) five nodes, each of which can be expanded to a subsystem of more nodes. Obviously, this would be hierarchical. The most important point would be that the actual truth of all the diagrams is only presented once and the other diagrams are just defined in terms of what is included or left out.
• It seems to me that in certain cases, there needs to be the ability for humans to "override" the layout decisions, for example to indicate that certain nodes should be aligned horizontally or vertically, or that a node should be deflected slightly from its normal place, or that two nodes should have more space between them. On the other hand, I consider all such things "hacks" and wonder what semantic information is missing from the diagram that they are necessary.
• There should be a mechanism for adding comments to diagrams so that users can collaborate on a diagram, and probably connections to sharing tools such as github and Google Docs.

Interested? Get in touch and let's see what we can do.