Speaking Geek

Text in websites and web-applications, as in desktop software, is often written in programmers' technical jargon, making it incomprehensible to the software's intended users. This is known as "speaking Geek" (Johnson, GUI Bloopers, 2000).

Geek-speak can appear anywhere there is text in a website. Sometimes it's in instructions the site provides. Sometimes it's in error messages. Let's look at examples of each.

Northwest Airlines

On its flight-search form, Northwest Airlines instructs site-users to "select the traveler(s) from the drop-down box...". "Drop down box" is a GUI toolkit term known mainly to programmers. Most of Northwest Airlines customer have no idea what "drop-down box" means. They must simply to guess what it means by examining the form and using deductive reasoning. Making users think about the UI, rather than about their own goals, is what makes this a blooper.

Elsevier

To order books from the website of Elsevier, customers must fill out of a form that asks for their Title (Dr., Mr., Mrs., Ms., etc.) and their name. If the customer attempts to proceed without specifying a Title, the site displays an error message: "Title must be a string between 1 and 20 characters." The term "text string" is a GUI programming technology term. For most Elsevier customers, a string is something one uses to tie things together, not a sequence of text characters.

This is even ignoring the problem that even if users knew what "string" means in this context, the Title setting is a menu and therefore isn't a string from the users' point of view.

Association for Computing Machinery (ACM.org)

The Association for Computing Machinery's Digital Library website provides a humorous example of speaking Geek. ACM members who subscribe to a digital library service can view tables of contents of ACM journals. If the Table of Contents for a specified issue of a journal is not available, instead of simply saying that, the Digital Library website displays an error message "No Children Found". This is Geek-speak: from the software's point of view, a Table of Contents is a hierarchy in which the article listings are child-elements. If an issue of a journal has no corresponding content-items in the data base, that means no child-elements of the journal element were found, hence the odd error message.

Avoiding the Blooper

Geek-speak must go! Web users aren't captive, so they are even more sensitive to geekisms than are users of desktop software. If anything confuses or annoys them, they can leave at any time.

How to avoid speaking Geek can be summarized as follows:

• Know your users. Interview representatives of your target user population to learn their vocabulary for the tasks your site covers. Don't expect people to learn a new vocabulary -- even just a few new terms -- to use your site. They won't, and you'll be the loser.
• Develop a site lexicon. Create a list of all the terms and their corresponding meanings that will appear in the site. Base the list on the users' tasks and vocabulary. Follow it religiously and keep it current as the site changes. Assign a team member -- preferably a technical writer -- to be the keeper and enforcer of the lexicon.
• Keep implementation terms out. This includes GUI component names like dialog box, icon, field, drop-down. It includes technical terms like proxy server, SSL encryption, and authenticate. It includes internal exception symbols and program code like array_index_out_of_range, javascript error: file.open() failed, and illegal method.
• Provide solutions for errors. Engineers like to describe the problem. Users want to know the solution. Of course describe the problem -- in terms related to what the user was doing -- but also suggest a course of action.
• Put the right people on the job. The root cause of "Geek-speak" in software and websites is a management blooper: assigning the job of writing command-names, instructions, and messages to programmers. Programmers are skilled in writing software code, not text. The writing of software text should be assigned to people who have the right training and skills: user interface designers or technical writers, preferably the latter.
• Test the text on users. The text in a website should be tried on representative users before the site is put up on the Web. One nice thing about text is that it can be tested using paper-and-pencil tests or not-yet-connected static pages -- you don't have to wait for the site to be finished. Another nice thing about text is that even if problems are discovered close to the release date, they are usually easy to fix.