|< Day Day Up >|
A very common blooper that greatly degrades people's ability to learn and use websites and Web-based applications is using different terms for the same concept in different places. It is about the best way possible to confuse people with text.
DigiGuide.com includes a page that answers frequently asked questions. The common name for such a page is "FAQ." On the Customer Support home page, that's what they call it (Figure 6.25[A]). But on the FAQ page itself, it's called a "Knowledgebase" containing "Common Questions" in various categories (Figure 6.25[B]). Visitors to this site can't be sure whether these terms refer to the same thing or not.
Some websites even use different terms for a single concept on the same page. Erlbaum.com lets customers find and order books. On the Book Search page, the function was until recently labeled both "search" and "query" (Figure 6.26).
ZBuyer.com provides two adjacent sets of search controls, each with its own button to start the search (Figure 6.27). One of the start buttons is labeled "Search," but the other is labeled "Go." There is no apparent reason for this difference, other than perhaps that the two sets of controls were added by different programmers.
Caroline Jarrett, an authority on user interface and forms design, suggests this design rule for terminology in software and websites:
Same name, same thing; different name, different thing. ( Jarrett, 2003 )
This means that terms in websites (and desktop software) should map one-to-one onto concepts. Strictly. Never use the same term for different concepts, and never use different terms for the same concept.
I'm beginning to repeat myself , but the best way to avoid using inconsistent terms for concepts is to create a site lexicon and enforce it. Enforcing it means assigning someone the job of enforcer. Although that word conjures up images of burly men carrying violin cases, it's better if the enforcer is friendly and well liked . Here's one side of a phone conversation between the designated lexicon enforcer and a programmer:
Hey, Sally, it's Phil. Got a minute? On your pages in our customer-service website, you use the term "bug report" for when customers submit a problem. But our agreed-upon term for that is "action request," remember? That's what we call them everywhere else in the site. It's also what's in the site lexicon. Where's the lexicon? At the project's intranet website. So can you please change "bug report" to "action request" on all your pages? We're running some usability tests on Thursday, so I'm hoping you can make these changes by Wednesday. You will? Great, thank you!
Had DigiGuide's development team created and used a website lexicon, it might have been more evident that the FAQ page should be titled "Frequently Asked Questions." The repeated term "Common Questions" on topic subheadings , instead of being changed to Frequently Asked Questions, could simply be dropped.
Similarly, use of a site lexicon could fix the Erlbaum.com search page (see Figure 6.26) by changing the "query help" link to "Search help" or just plain "Help."
Reconciling the zBuyer.com search controls (see Figure 6.27) is a bit more complicated. A site lexicon would help ensure that both buttons had the same label, but in this case I would suggest simply removing the upper Search box and button. The default value of the lower control's category menu makes it equivalent to the upper control, so two sets of controls aren't needed.
|< Day Day Up >|