We like to bore our friends (use of the plural is optimistic, shurely?!) with the dictum that simple, easy-to-understand writing requires more space, not less. The example we tediously trot out is of course the entirely unreadable Brief History of Time, which necessitated an entire companion volume and an Errol Morris documentary that shed little light. We know of exactly one reader who understood and enjoyed the book, and he graduated first in physics at university. (And first in the university. Mensa hobbies: Reading astrophysics on the beach.)
Had the first volume been rewritten to be about as long as 2/3 the size of the two books combined, everyone who read it would have understood it, with the result that literally millions of people would suddenly comprehend basic astrophysics.
We gave away a miracle all because of bad writing (or, more accurately, bad editing). It took ten years before newscasters could finally get away with using a simple term like HIV without defining it. Assuming the fates dictated that the book would be a bestseller anyway (even more so if it were actually comprehensible), this single book could have done more for popular understanding of science than anything else in human history, very much including the entire Cosmos television series. And we blew it.
How does this apply to the Web?
We are told, over and over again, to write short. We at NUblog like to think we have blown that theory out of the water. The actual rules of thumb are:
Pretty simple.
And now we have yet further evidence that more is more and less is not, this time from user interfaces.
In a usability test of an optical spectrum measuring instrument, about half of the users (all of whom were instrument-using engineers) had some difficulty identifying words or numbers that were abbreviated unnecessarily, and therefore hard or impossible to identify; in general, they wanted all these words to be spelled out.
For example, many users had difficulty identifying “Sens” (the abbreviation for “Sensitivity”); rather, they expected to see the word “Sensitivity” spelled out, because the abbreviation was ambiguous – one of the users routinely does “sensing” in his work. Another user at first concluded that “Sensitivity” was not on the “Amplitude” dialog at all, because of the label “dBm Sens,” which he didn’t recognize as equivalent to “Sensitivity.”
In another part of this UI, the “Amp Setup” dialog had checkboxes labeled “Amp Meter” and “Amp Corr,” where “Amp” was the abbreviation for “amplitude.” Two users pointed out that this abbreviation could easily be confused with the terms “amperes” and “amplifier” (which are also routinely abbreviated “Amp”), and suggested completely spelling out the “Amplitude Control” feature labels. Likewise, another user was annoyed that “Wavelength” was abbreviated as “Wavelgth” in a drop-down list. [...]
Also in this test, several users misunderstood the “Other Traces OFF” command button in the “Traces” dialog. They didn’t know if it meant that the traces were already off, or that this button would turn them off; several thought that it meant that traces were off, and that if they clicked it, it would toggle to “Other traces ON.” I recommended that this ambiguity be removed by relabeling it “Turn off other traces,” which requires adding only one key word.
In Web applications, one may learn from the tooltip example (which JavaScript onMouseOver and HTML title can trigger):
Specifically, the authors compared the tooltips of Microsoft Access 2.0 with the analogous “hover bubbles” of Lotus Approach 3.0. The Microsoft tooltips are very brief – for example, the icon that is redundant with the “Form” command on the “View” menu has a tooltip that says “Form View.” In contrast, the hover bubble for one of the Lotus Approach icons says, “Go to browse to review or modify data.” Clearly, in this example, the added verbosity seems to provide a level of description that goes significantly beyond what’s offered by the Microsoft tooltip. Most importantly, the additional words seem to have helped – users found Approach easier to use than Access in terms of finding functions quickly, and understanding the icons and menus.
The lesson here seems to be: The usable minimum is larger than the absolute minimum. While there is certainly such a thing as too much, we need to stop pretending there is no such thing as too little.
Posted on 2001-08-03