Web Bloopers, Part 2: Avoiding Common Text Errors
November 17, 2004
Presented by Jeff Johnson
Arranged by Sarah Adams and Bonnie Britt
Notes by Dawn Adams
The prose on many Web sites makes most editors
cringe and wish for a virtual red pencil. While many might argue
that Internet text need not be elegant, most would agree that it
should be understandable, informative, and readable. After discussing design mistakes at our September forum, Jeff Johnson
of UI Wizards, Inc., returned
in November to discuss text bloopers on the Webcommon
writing errors and how to avoid them (see
Too Much Text
"This is the most common, most prevalent text blooper on the
Net," Johnson said. "It's a law of human behaviorpeople don't
read on the Web; let's just say they scan."
Johnson gave several examples of Web sites that suffered from
verbose passages (what he calls "happy text"), noting that the
writers had wasted their time because no one was going to wade
through that text to find relevant information. He
differentiated between information and content (e.g.,
instructions on how to fill out forms vs. news articles). People
read content (such as a Newsweek piece), but scan for
For Web sites, Johnson recommends following the advice of Steve
Krug, author of Don't Make Me Think: Get rid of half of the text,
then half of what's left. He suggests:
- Avoid long prose passages.
- Use headings, short phrases, and bullet points.
- Keep link labels under three words.
"People want to do a little and get a lot,"
Johnson said. "They want to think about buying a book, not about
the Web site."
Geek-speak is another common problem on the Web. Although the
population is becoming more and more familiar with computer and
Internet terms, there are still many people out there who have no
clue what the difference between Boolean and literal text
searches could possibly be.
"Most people don't learn things in software; they just muddle
through," Johnson said. "Tech developers say that 'they' will get
used to it; that's wrong in two senses because you don't have to
do anything on the Web and people don't get used to itthey
just ignore it."
Examples that Johnson gave included an error message "Type
mismatch" which prompted some to actually key in the word
"mismatch" into the box; the command "create database template"
which meant creating a template that could be shared over the
network; and "method not allowed" which meant that selections had
to be made in a certain order.
As editors know, words are ambiguous by nature, so it is
important to make certain that the words you choose for your site
are as clear and precise in meaning as possiblemaking up
words or redefining them only compounds the problem. Johnson
concedes that sometimes people do have to learn new concepts, but
using analogies such as "Desktop" (before inventing new words)
can greatly ease the learning process.
"Every new concept that people have to learn makes your software
and writing tasks progressively harder," he said. "As you add
concepts, the complexity goes up in a curve."
According to Johnson, it's easy to tell who is in charge of a Web
site by whether the visitors are called "users"common
terminology in the computer world. As he wryly noted, there are
only two industries in the world that refer to their customers as
To avoid geek-speak, Johnson recommends:
- Use your customer's vocabulary (study them, interview them, enlist their help).
- Develop a task-specific lexicon.
- Assign a lexicon enforcer (usually a tech writer).
- Avoid computer/software jargon.
- Exclude implementation terms (e.g., leave programming terminology out).
- Don't redefine common terms.
- Don't make up words.
- Don't use arbitrary code.
It's not just the geeks who have their own private language, but
other industries and groups as well. For example, some visitors to zBuyer.com
might not understand the distinction between "Bestsellers" and
"Movers & Shakers." On corporate Web sites, internal
corporate language can creep into their public pages; for
example, on Connectix's site, the customer support pages refer to
"fee products" vs. "free products," meaning products with
fee-based technical support vs. products with free technical
- Match the site's vocabulary to site users, not programmers,
marketing people, or CEOs.
- Construct and follow a site lexicon.
- Have writers write and maintain the text.
Inconsistent terminology is a very serious problem, says Johnson, because it is disruptive to your customers learning how to use your site. There are two basic forms of inconsistent terminology: (1) different terms for the same
concept (e.g., version and revision) and (2) the same term for
different concepts (e.g., "select" meaning "to choose" vs.
"select" meaning "to highlight").
"Computers are not supposed to add to problems or interfere with
reaching goals," Johnson said. "On a computer system or Web site
you need extreme consistency, beyond what you think is reasonablelike in airports with the signage."
Johnson says to develop a product lexicon; map terms 1:1 to concepts; and ensure that software and documentation conforms to lexicon.
The advent of the Web has made everyone a participant in the
publishing industry, but few of these newbies are aware of the
need for style guides. Inconsistent style is a barrier to clear
communication. Johnson suggested following a style guide
(adopting an existing one or creating one if need be).
Clueless Error Messages
Most people can sympathize with the frustration resulting from
error messages that don't explain how to fix the problem. This is
very common in the tech world, according to Johnson, "because
geeks love to describe the problem, while customers want to know
There are several reasons why incomprehensible error messages
appear, including that the message is posted automatically by
low-level code; that the error message contains generic wording
(catch-all error messages); or that the developers may not know
how to write clear messages.
There are, however, solutions to this. Describe the problem clearly in the user's
task vocabulary, providing particulars. Suggest a solution, explicitly if the
solution is not clear from the problem. Use a particular format for error messages
(e.g., error symbol, description of the problem and a solution).
Go to summary of Jeff Johnson's related talk:
Web Bloopers, Part 1: Avoiding Common Design Mistakes