Diagramming Tools - A call to action!

It has been bothering me for a while now, especially after each and every frustrating, multi-hour-long session: the world's diagramming tools suck. Big time.

It's really a wonder that after over two decades and countless billions of dollars being pumped into research and development, that no-one has really managed to create a diagramming tool which can match the immediacy or flexibility of pen and paper, let alone bring anything "new" to the table in terms of "enhancing human intelligence".

From my experiences with various tools which have attempted this over the years, I see a few common trends coming through time and time again:

1. A fixation on drag and drop from a toolbox as the sole means of adding content
2. Connectors which only snap to midpoints, and which need manual rewiring if the placement of shapes which they connect change
3. A "bounded" canvas size that must be specified in advance
4. Lack of sophistication of clustering tools - entities can either be grouped together or not, but we cannot easily just specify constraints to say that a cluster of entities should stay relative to another while still being able to edit them individually and adjust their proportions
5. Clunkiness of text handling ranging from excessive default padding (leading to content clipping) to adaptive font size problems (usually an overly large default font) coupled with problems clearly defining "free floating" vs "bounded" text.
6. Overly optimistic context switching, leading to frequent missteps and errors

In short, perhaps what I'm looking for is a Blender style diagramming tool. Is this because I've been brainwashed by over 7 years of extensive Blender usage and development? Maybe.

However, without this experience, could I have been able to say that there are potentially better ways out there that we haven't been exploring over these years? That in the name of "consistency", we've gotten into a trap of iterating over a dead-ended street, plodding around in the darkness while there are still so many unexplored wells of untapped interaction potential? In lectures on design, we are taught to avoid the trap of iterating on bad early designs. But yet, here we have generations of software which have just been iterating on the same basic premise defined at the dawn of interactive displays back at the PARC labs.

As claimed by usability guru Jakob Nielsen (of the Nielsen-Norman group), "we've now reached the limits of the current GUI paradigm" in this article written in 2005! That's over 6 years ago now - an eternity in computing terms. While he was making a case here for the much maligned Ribbon and in particular, the interactive preview-on-hover galleries (which incidentally I find pretty cool, though in recent times, I'm slightly re-evaluating that after having accidentally hovered over them while typing and ending up with strings of repeated characters from computer locking up while trying to preview stuff), I agree that the current system of menus and toolbars may not really be the best direction.

After all, how many people do we run into that say "I'm not good with computers". While this number should hopefully be decreasing (especially as the pervasion of social media and Apple touchscreen gadgets continue their march to rule the world) I still get this very often from people I run into. It is interesting observing people hammering away at their machines - at the checkout, at the library, in a meeting somewhere, or somewhere else completely - and watching them get confused, start swearing, or just plain jumping through obscene hoops as if performing some exotic mating ritual.

Anyways, getting back to the original topic.


Why are the problems I've mentioned such a pain to use?
1. Drag and drop from toolboxes
It is often argued that presenting a toolbox and letting users drag and drop stuff from that onto their canvas is a good idea. It makes use of recognition over recall, and combines this with direct manipulation (dragging items). This is great for novices, but is IMO harmful to the efficiency of expert/experienced users, especially in the form in which it is presented now (as a docked bar on one edge of the screen, far away from most of the content it affects).

While non-overlapping designs are preferable to those which make it a habit that everything must come up as a separate dialog that goes on top of the previous one, I'm beginning to come to the conclusion that perhaps it is actually impossible (or at best, not actually that desirable) that all forms of overlapping interaction are rejected.

Another problem I've noticed recently is the advent of the modal "accordion" toolbox design. To help users navigate the vast tool space, programmers have been grouping icons within collapsible sections. However, the thing with these collapsible sections is that they tend to be collapsed by default, and in some cases, limited so that only a single section can be open at a time. All of this is very limiting, and results in situations where people are wasting their time managing their "windowing chrome" rather than working on their content (aka: an obscene mating ritual to appease the machine again? ;).

A compromise between these evils could be as follows:
A toolbar of sorts to add content could still exist. However, it should not be docked as part of the window frame, but rather, be a transient entity, which by default could float around the bottom edge of the screen. For experienced users, spacebar could bring up this toolbar to show up wherever their cursor was, thus minimising needless mouse travel and reducing the "drag" to simply a click.

2. Connectors and snapping points
The way that connectors are implemented in most packages is that they can only snap to the midpoints of the edges of shapes. Perhaps it was thought that this could make it cleaner to manage the connection points.

In practice though, this has often lead to several classes of problems:

• When multiple connectors all connect in at the same edge, they tend to start overlapping and clumping into ugly illegible clumps. If only the would have the sense to spread themselves out around this docking point, then it is possible that they would all be able to fit nicely
• When shapes get rearranged (and they will), the connections need to adjust themselves relative to the shape so that they still connect properly. However, as things stand now, if the placement of the shapes change so that the closest edges are now on opposite sides to before, the connectors end up overlapping in unsightly ways which can only be cured by manual relinking. This sort of manual tinkering is a waste of time, but is also a natural thing for humans to want to do. Really, the computer should be adjusting the connection points by rotating these around the shape's outside contour as appropriate.

3. Bounded Canvas Size
Most of the time when making diagrams, I don't know how much space I'm going to need. On paper, I'm limited by the physical limitations of how big that piece of paper is (before having to grab and tack on another). That's why I turn to the digital domain, where there are practically no such physical limitations. Diagram can't fit? Oh well, let's just add some more virtual space in that corner.

In a way, wordprocessors and spreadsheets got this problem right many years ago. They give you effectively infinite space to play around with (infinite pages, though not necessarily page sizes for wordprocessors, and just a grid of cells with no page limit markings for spreadsheets). You just concentrate on how much content you need to produce and fit, and then worry about getting that within some set of physical boundaries as needed later on.

It took me a while to realise this problem with Inkscape. Whenever I'd tried to make diagrams, I'd always be faced with the problem: should I put this thing in the corner and start working down, or should it be more central? It was not until later on (actually a few weeks back) when trying to design some icons where I knew that I had a size limit to work to (48x48) that Inkscape started to shine. All of a sudden, the page limit made sense and was even helpful, and the rest of the workflow made sense. Wrong tool for the wrong task.

This is an example of where I think that computing tools can be truly better than pen and paper, but is an example of where we've squandered that chance.

4. Clustering tools
Tools to group related entities are absolutely essential. Sometimes it is necessary to group entities together and to lock them in that arrangement to prevent accidental modification of the details, since that group of entities is a related "whole".

However, there are times when you need to tweak parts of these entities within the bounds of the larger group. Realistically, you don't really want to go through ungrouping them just to get access to and tweak these small simple things. But most tools require you to ungroup, tweak, then regroup (I know I've been guilty of implementing these myself, but ideally we should move away from having this sort of limitation).

Perhaps then we've just been attacking this from the wrong angle. Instead of having a "group" which then becomes a single abstract entity in its own right, perhaps all we really need in some cases are parenting or relatedness constraints which aim to keep the entities related together whenever they move, but aren't strict about absolute encapsulation.

Attention should also be drawn to the hierarchical organisation of data. It may in fact be non-obvious to users that newly created objects are made the children of the last selected object, but that such organisational issues will actually end up causing grief down the track when certain operations result in totally unexpected results due to the hidden linkage.

5. Text management is absymal
When drawing things by hand, we're often limited by not being able to adapt our handwriting size that readily in advance to knowing that all the words we'd like to fit within a box will actually fit. This is a limitation of the medium, but is something which surely a computer can solve, since again, content can be modified retrospectively. Hence, if the content can't fit in a box with a given font size, then we know that we can just downsize the font until it will fit. Or perhaps expand the box to fit the content instead.

But not all computer packages are made equal, and some add excessive padding to their shapes and textboxes, which means that they cannot fit any text at all below a certain size. While padding is nice, I'd like to see some more adaptive behaviour here: padding IMO is not so much about absolute padding values, but more of a relative/proportional value that is applied just so that unsightly visual collisions don't take place (anyone who's used a few particularly suspect GUI toolkits will know what I'm talking abut).

Furthermore, it can often be difficult to set up "free floating" blobs of text, maybe lining up alongside some entities, and have them stay relative to those points, but without encountering any combination of font-size, padding madness, or alignment woes in the process.

6. Overly optimistic context switching
One moment you're trying to select and tweak the handles of and object. The next, you've managed to select the whole of another five objects on the side. Two clicks later, you've just dislodged a few of the handles of one of those five objects.

As much as this may not be a popular thing for people to hear, IMO there is a case to be made about the excessive overloading of selection and manipulation of selections on to the same mouse button. While perhaps not immediately clear, it is something that can and does result in a clearer conceptual model for interaction where there's no ambiguity on the possible interpretations of a command. This in turn simplifies things.

What can we do about this?
I'm aware that there was an attempt at this general sort of thing in the past, with "DTP Blender" (a heavily modified fork which has long since died off, and which tried to present these sorts of diagramming 2D tools with a Blender-styled interaction paradigm).

Perhaps that method was a bit extreme, and may not necessarily be the best approach in terms of long-term maintainability. But at the time, that's all there was that would have the necessary levels of flexibility.
However, this is now 2011 (and soon 2012), the second decade of the 21st century. Surely we can do better.

With the recent bpy changes in 2.5, we now have a credible "addons" system that has tighter integration with the rest of the system. With a few additional tweaks, even more powerful things can take place.

I've been thinking over this idea for a while now while bashing away at one or other misbehaving 2D tool, and think that perhaps it's finally time we had another crack at this problem.

Bring on the z-depth layered 2D goodness!