Web Bloopers: 60 Common Web Design Mistakes, and How to Avoid Them (Interactive Technologies)
| < Day Day Up > |
Blooper 50: Bizarre Buttons : Click Target Smaller than It Seems
A few years ago, a company asked me to review the user interface of an intranet Web application it had developed. I did and found an interesting problem: The application had large buttons all over its pages, but those buttons accepted clicks only directly on the (small) text labels in the middle of the buttons (Figure 7.15). Clicks anywhere else on the buttons were ignored.
I explained that users would hate these buttons, and some would have trouble hitting the label. I advised the company to change the buttons to accept clicks over their entire area. The developers resisted, claiming that the toolkit they were using wouldn't let them fix the problem, and that users would "get used to it."
I doubted users would get used to it, because most other on-screen buttons they encounter-on the Web and elsewhere-allow clicking anywhere on the button. Not to mention that the small labels were much harder to hit than the buttons. I appealed to management, and eventually the bizarre buttons were fixed.
Since then, this blooper has grown increasingly common on the Web and in intranet Web applications.
For example, Continental Airlines' website has tabs at the top of its home page for navigating to the site's functional areas (Figure 7.16). As in many websites , the tab width adjusts according to the width of the visitor's browser window. However, only the text labels of the tabs respond to mouse-over and mouse-clicks.
RealEstate.com exhibits an even more misleading form of the blooper. In the Quick Find navigation bar on the left of the home page (Figure 7.17), the "buttons" change color when the cursor is over any part of them, strongly suggesting that the entire button is clickable. However, only the text labels on the buttons accept clicks.
Adding to the confusion, the links in the home page's top navigation bar don't have the blooper: They respond to clicks anywhere inside their black box. So users can click anywhere on the buttons in the top navigation bar but have to hit the text labels in the Quick Find bar. Got that? There's more: On other pages in the site, the top navigation bar does commit the blooper, by accepting clicks only exactly on the button labels (Figure 7.18). This sort of inconsistency can easily occur if each navigation bar is implemented by a different programmer, with no coordination between them.
Until RealEstate.com is purged of this blooper or at least is made consistent regarding where users can click, its visitors will have trouble remembering which navigation bar works which way.
This blooper can be seen at many other websites: Acer.com, SDExpo.com, CRLA.net, CSMonitor.com, RitzCameras.com, to name only a few. In some cases, the misleading user-interface component is simulated buttons; in others, it's simulated tabs.
Recipe for the Blooper
This blooper usually occurs in navigation bars constructed from HTML tables containing text links. This is a simple and therefore common way to construct a navigation bar. Each text link is in its own cell of the table (Figure 7.19). In navigation bars constructed this way, only the text labels are clickable.
In such a case, to have the blooper, simply do the following:
-
Make the internal table borders visible so each link is completely enclosed in a box.
-
Turn underlining off for the link labels so they won't look like regular links.
-
Optionally, make the boxes change color when the cursor moves anywhere into them.
Just follow this simple recipe, and you too will have the blooper: boxes that look like buttons but don't act like buttons.
Avoiding the Blooper
If you construct a navigation bar using an HTML table, the obvious way to avoid presenting misleading link targets is to not follow the recipe. By subverting either or both of the first two parts of the recipe, you make it clear that only the text labels are clickable. Therefore,
-
Keep the table borders invisible, or at least don't completely separate the links (Figure 7.20[A, B]).
Figure 7.20: These navigation bars don't follow the blooper recipe. A- Links not enclosed in visible table cells . B- Links not completely enclosed. C- Links enclosed but underlined as links. -
Leave underlining of the link labels turned on (Figure 7.20[C]). Better, leave them the standard blue link color.
The U.S. Internal Revenue Service website, IRS.gov, avoids the blooper by underlining the text labels and not putting each navigation-bar item in a separate boxed area (Figure 7.21). This makes clear that only the underlined textual links are clickable.
For Image Links
The aforementioned recipe is not the only way to commit this blooper. Not all navigation bars are constructed from text in tables. When Web designers want a navigation bar to look like an array of buttons, they often build it using either a table of images or an image map. In such cases, designers should follow these guidelines to ensure that the "navigation-bar buttons" behave like buttons:
The preferred way to build a button array is to arrange individual button images using stylesheets or tables. Make each button image a whole-image link by enclosing the IMG tag in a link <A> tag.
If you use an image map to present an array of buttons, [2] make the extent of each button clear and design the map so that entire buttons are mapped as links. If the buttons widen when the site visitor widens the browser window, the width of the mapped link must be a run-time calculation.
Many Web sites achieve buttons that are clickable anywhere by using one of these solutions. For example, the home page of IEEE.org, the website of the Institute of Electrical and Electronic Engineers, shows both vertical and horizontal navigation bars in which the entire area of every button is clickable (Figure 7.22).
The blooper is also avoidable in navigation bars that simulate tabs rather than buttons. An example is OfficeMax.com (Figure 7.23). Tabs on this navigation bar accept clicks anywhere in their outlined area.
[2] Image maps are not well regarded by usability experts, because they increase page-download times and hinder accessibility to blind and motor-impaired people. Nonetheless, some designers use them.
| < Day Day Up > |