ITauthor

I was using a horrible application called QMAP today. It’s a program for drawing “process maps” – that is, flow charts representing a process. In my case I was editing some diagrams of our documentation processes. But please, next time, give me Visio. Please!

Think Visio is clumsy and annoying to use? Try using QMAP!

Anyhow, I had linked one diagram to another diagram as a child process, but then changed my mind and wanted to remove the link. I selected the little box that (intuitively? I think not) represents a linked diagram, and I pressed the delete key. The following message was displayed.

Now, of course, with hindsight, I should have taken my time, read the message over several times, considered its implications, thought long and hard about what I should do next and then, and only then, proceeded cautiously. Maybe I’m just too used to software that works sensibly.

Did I want to store CHILD GROUP “2” (as it so nicely called the diagram I’d actually named “Review Process”) inside the trashcan? Well, no, I did not want to store it inside the trashcan, I just wanted to remove the link on this diagram. So the answer was no. Right?

So I clicked No. Big mistake!

What this dialog box was really asking me was: “Do you want to delete this diagram?” But for some reason, the developer had kindly thought to include within this dialog box the option to delete the diagram irrevocably, without placing it in the Recycle Bin, and without bothering to offer me an “Are you sure you want to delete this?” opportunity to change my mind. One false click and a couple of hours’ work vanished into thin air.

So let’s consider some of the things that are wrong here:

a) The word “delete” is never mentioned.

b) Instead it refers to the normal deletion operation that we all know and love as “storing inside the trashcan” (“inside” mind you – not “in” or “on” or “underneath” or “nearby”, but “inside”).

b) It uses some weird nomenclature to refer to a diagram I’d already named, so it’s not clear what I’m about to “store” (or not).

c) By answering “No” to this question I am just saying I don’t want to do the thing it has offered: to store something inside the trashcan. I am not saying anything more than that. I’m just saying “No – don’t do that.” However, the software assumes that because I don’t want to do the thing it’s offered to do, I obviously do want to do this other thing: the thing it hasn’t actually mentioned, namely delete my work instantly and forever.

d) The dialog box also has two other buttons: “No to All” and “Yes to All”. However, I’d only selected one thing, so what were these “all” things. All what?

This is just the tiny, but ghastly, tip of the enormous iceberg of horrors that is QMAP usability (or lack of).

I can only hope you never encounter this application.

Something I’ve been preaching for years, to any software developer who’ll listen, is: don’t use a tree view control in the user interface if your users are not highly technical and there’s another way of allowing the user to do the thing they actually want to do (which there usually is if you put some thought into it).

So I was delighted to hear Jeff Atwood and Joel Spolsky’s views on the Stack Overflow Podcast #45:

Atwood:   … programmers love hierarchy, to a degree that they don't even understand how different they are than the public in this regard. Like they love putting everything in this little bucket, that goes in this little bucket, which is this sub-bucket of this and this, and normal people hate that. And threading is totally a manifestation of that and it drives me crazy that a lot of programmers can't see that they're like immediately like: "Oh, threading is good. I love threading. What are you talking about?" You know? They can't see it at all.

Spolsky:   Right, right.

Atwood:   It's like myopia.

Spolsky:   Yeh. I mean it's really a function of the size of the group, and one thing I've learned through years and years of usability testing is that anything that smacks of a hierarchy or a tree is not going to be understandable to the average, non-technical user.

Atwood:   Yeh.

Spolsky:   You just have to learn that: if it's a tree, or a hierarchy, like eighty per cent of the regular people are going to get confused and not quite get it.

Hierarchies are great at showing nested relationships, and they make sense to programmers, who are used to them – but most of the time the relationships don’t matter to the user. Usually the user just wants to find something and yet the tree view forces them to “drill down”, clicking down into a hierarchy that becomes increasingly complex as they click.

My request to all programmers placed in the position of having to design a user interface: avoid hierarchies unless you truly believe the end users really need the hierarchical information.