ThinkFlood Blog

While my blog ramblings may not show it, I have a liberal arts background. Yes, I succumbed to enough traditional schooling that I have become a slavish devotee to Strunk and White’s treatise on writing. Passive voice, bad; active voice, good. Brevity, also good (although I stumble here often). So it is not surprising that I consider clarity — clarity of writing, clarity of interface, clarity of purpose — a virtue, even a fundamental principle for living.

You may ask why this principle is not higher upon the list. How is clarity subordinate to proximity, for example? To this question I have to answer that clarity primarily benefits the novice, while proximity benefits both novice and expert. Yes, clarity is about communication, and communication matters most when two people or a person and a concept are far apart. For example, sometimes I can get away with unclear communications to my wife, because we have enough shared experience that she knows the context of my thinking and can deduce my meaning. But I have to be more careful when meeting someone for the first time, because I do not want them to have a foggy impression of my motives, morals, or movements.

Unfortunately, by opening this post with comments about writing style, I have probably led you to believe that I am mostly referring to clarity of written messages. The poster boy for this problem likely to be the following:

To a non-programmer, this error message is completely meaningless. What is 0×1003e8d? Why is there an instruction there, anyway? And who is “reading” what? To a programmer with access to a memory dump from the time of the error, this message is helpful, but without that context this message is too generic to be useful. Why allow anyone to see it, then? Heck, there isn’t even a choice of what to do — the application is crashing and burning, so wouldn’t it be clearer just to say this:

Certainly clarity covers the wording of error messages and other dialog boxes, and there is some need to improve how these read. However, in my opinion spending time writing understandable messages is somewhat misguided. Instead, what can we do to make the interface more understandable (and less error prone) without all the extra words? I see too many pop-up message boxes telling me this or that — if the interfaces themselves were clear, then there would be no need for explanation.

So, how do we make interfaces clearer? Just as much of person-to-person conversation is non-verbal visual cues, so too should much of our person-to-machine conversation use these non-verbal cues. For example, buttons should stand out so that we know they are “hot spots” for action on the screen. That is, they should have some added dimension (color, shading and highlighting, etc), and ideally should deform or change subtly when we mouse over or press them (sometimes we call this last bit “malleability”). Controls should have meaningful icons and clear descriptions. Words like “Go,” “OK,” “Done,” and “Close” do not convey much information, and so we should avoid them. Personally, I am not afraid of a button name that is three or four words long — it beats a thirty word message box to ask me whether I really know what I am doing.

I believe another way to gain clarity is to modify the interface for each specific task. There is nothing more unclear than large numbers of commands that are unrelated or unavailable to the task at hand. Once again minimalism in design — even moment to moment during program operation — will help us highlight available functionality.

I realize that I may be treading close to a classic usability no-no, something called “modality.” Modality is the idea that user actions lead to certain places (modes) in which only a limited choice of options is available. The problem with modality is that it feels limiting — we have to deal with the modal operation first (or cancel out of the mode) before we can move on to do something else. However, when I talk about tailoring the interface to the current task, I am not advocating that we disable other operations. Instead, I see the interface as more fluid than static. When I choose a certain tool or enter a certain space, the related functions and options might rearrange themselves to be more proximate to my action, perhaps reordered to show the most common choices in the most convenient places. Such reordering will attract my attention – it will become the non-verbal communication that tells me what I am most likely to do next, and it helps me find what I need.

In the end, clarity is about making things obvious — hitting the user over the head with the next likely choices. Words are an important part of this obviousness – particularly labels that identify choices – but movement and styling often leave a greater impression on the mind. The highest degree of clarity comes from the most minimalistic of indicators, so as designers we should lean toward succinctness.