- Featured Columnists
Table of Contents
- Web Basics
- Publishing on the Web: Putting Files on the Server
- Web Design Process and Workflow
- Project Management
- Mark My WWWord: HTML and XHTML
- Standards Compliance
- Visual Design and the Web
- Color Theory
- Working with CSS
- How to Create CSS Menus
- How Should Web Designers Manage Layouts?
- Shining Examples of Bad Design
- Get Your Site in a Festive Mood: How to Quickly Change Styles
- Designing Mobile Web Sites
- Designing for Mobile Devices
- Books and e-Books
- Online Resources
- Meta Tags and Search
- Enhancing Web Page Interaction
- Web Graphics
- Web Page Optimization
- Overview of Servers
- Server Programming Basics
- Careers in Web Design
- Intellectual Property for Web Designers
Shining Examples of Bad Design
Last updated Oct 17, 2003.
There's nothing wrong with going against the basic rules when trying to do something different, but the problems I've discovered on various Web sites prove that sometimes instead of breaking rules, companies sacrifice common sense. Ready for the tour of Sites With Features Gone Bad?
The Case of Alphabetphobia
This form asks me to select my country. No problem, that's a frequently-asked question on forms. I click on the down arrow and find a jumble of countries listed—as shown in Figure 17—not in alphabetical order. Thank goodness, it's not a long list and that United States is two words (unless USA is used, then it's going to take serious searching to find it), so it should stick out.
Lesson: When providing a list on a form, make it easy for the user to find the answer by logically organizing it. In most cases, putting the items in alphabetical order is best. If the option is months of the year, obviously start with January and work down to December rather than starting with April.
A Form Meets Its Match
The second case is a problem of cases. The automatic form filler completes one of the email addresses, but not the second one. So I enter the second email address myself by typing "m-e" and select the only option from the "saved form information" like the example shown in Figure 18.
I enter "u" and it provides me with past entries using the letter. That's what happened here; I selected the email address from the list, which used all upper case letters, the opposite of the other email entry. When I press submit, I receive an error as shown in Figure 19. The information matches except for the format.
Lesson: When validating forms, ignore the entry's cases unless there is a reason that case matters.
The form in Figure 20 asks that you enter the phone number in XXX-XXX-XXXX format, but entering the phone number without dashes goes through. If the company requested the dashed format so that the resulting phone number is readable, the developers can massage the back-end to turn in a 10-digit phone number that's missing dashes into one with dashes on the output. Limiting formatting requirements increases the chance your user will complete the form.
More Frustrating Forms
In Figure 21, after pressing Complete Order, an error message appears: "There was an error processing your order. Please try your order again." The error in the form is a bad credit card number. But the error doesn't give a hint of which field has the problem. Good forms clearly state where the problems are and some even put a message right next to the problem field to make the error easier to find.
Figure 22 shows a good example that points out why the previous form doesn't pass inspection.
Radio buttons are used on forms to ensure users select one item from the choices given. Checkboxes allow users to pick more than one item. Yet, in Figure 23, the form asks the user to select one item by choosing the appropriate checkbox. In this scenario, radio buttons are the better option.
The Case of the Confusing Links
The items in Figure 24 are in what is obviously the navigational menu. Yet when the mouse pointer touches an item, it remains unchanged, confusing the user. It turns out that the menus do have pop-ups that appear, but too slowly. Usually, when a pointer rolls over a link, the link changes to give the user an indication that it's an active link.
Have you been to a site where you couldn't find the links? Or you thought something was a link, but it wasn't? Some Web sites have text that is black without bold or an underline and they turn out to be links. The only way someone can find these is if she moves her mouse pointer around the screen.
Figure 25 shows tabs at the top and the items above and below the tabs, which look like links. What about the rest of the page? "Shop by Brand" and "Best Sellers" have plain ol' black text with no embellishment. These are links too.
Take a look at the same site's site map (Help Center) in Figure 26. What items are links? Think they're "Customer Support" and "Shipping & Returns?" Those are the only items that are NOT links.
While some experts say all links should be blue with an underline—since that's the standard—it's not realistic to expect everyone to follow that rule when few apply the W3C.org's recommended standards. Good links stand out while headers that aren't links—which help with scanning—have to stand out without looking like a link. Typically most sites do this by making the headers black and bold.
Excuse Me! Your Markup is Showing!
With the markup and editing involved in creating Web pages, many of us have been guilty of exposed code—even The Wall Street Journal, as shown in Figure 27. In the lower-right corner, the image markup appears. Often this happens because an extra > snuck in and "ended" the tag sooner.
Avoid "your slip is showing" by testing and re-testing the pages throughout the design process—especially before moving the files into production.
Zip Codes That Don't Zip
When users living in the U.S. enter a zip code plus the four digit extended number, chances are good the form will choke. While the users may not manually enter the zip code plus four, most form fillers do. In Figure 28, the user entered zip + four and got this error message.
Many sites—especially mapping sites like the one in Figure 29—ask for either a city, state, OR a zip code. While a city can have multiple zip codes, zip codes can't have multiple cities and states. The site in Figure 30 won't take the zip code without the state, but it will take the state without the zip code. Having both provides the best results, but why not save a step and accept zip code-only entries?
That's the end of our "Sites With Features Gone Bad" tour. With all the elements involved in the Web design process, from requirements to production, catching every problem area proves challenging.
Next time you come across a site that befuddles you, send it in with a link.