BAEF :: Forum Index: Web Text Bloopers and How to Avoid Them

November 17, 2004
Presented by Jeff Johnson
Organized 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 intelligible, informative, and readable. Jeff Johnson of UI Wizards, Inc., speaker for the September BAEF forum, returned for the November forum to speak on text bloopers on the Web—common writing errors and how to avoid them (see master checklist).

Too Much Text

"This is the most common, most prevalent text blooper on the Net," Johnson said. "It's a law of human behavior—people 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 information.

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 gave the following pointers:

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."

Speaking Geek

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 it—they 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 possible—making 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 "users."

Johnson made the following recommendations for avoiding geek-speak:

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 codes.

Insider Jargon

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 support.

Johnson suggests:

Match the site's vocabulary to the users of the site, not the programmers', marketing people's, or CEO's.
Construct and follow a site lexicon.
Have writers write and maintain the text.

Inconsistent Terminology

Inconsistent terminology is a very serious problem, according to Johnson, because it is disruptive to your customers actually 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 reasonable—like in airports with the signage."

Johnson gives the following guidelines:

Develop a product lexicon.
Map terms 1:1 to concepts.
Ensure that software and documentation conforms to lexicon.

Inconsistent Style

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 the solution."

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 problem, solution).