Jump to Sidebar Content | Jump to Main Page Content

Begin site navigation:
End site navigation.
Begin left menu:
Topics

Pages

 
Search
 
Links
 
Subscribe
 
End of left menu.
Begin main content:
Blog
Archive for November 2007
« Previous Entries | Next Entries »

Top 10 Web 2.0 Usability Design Mistakes

Thursday, November 8, 2007 8:20 pm

Today was World Usability Day, the one official day of the year to celebrate user-centered design in all mediums, including Web sites. The annual event is sponsored by the Usability Professionals’ Association. In its honor, I thought I’d list some common features that impact the usability of “Web 2.0” sites, which include blogs, social networks, and other highly interactive sites.

screen image
www.worldusabilityday.org

Right now, the Web design profession is in turmoil. Many designers are casting off standards and guidelines that served the industry well for nearly a decade and declaring new sets of rules that are untested and unsubstantiated. The usability profession as a whole is lagging behind, and published usability studies on most of the new design elements are few and far between.

Part of this trend comes from the next generation of designers who are exploring design techniques that they think are new, even if they aren’t. Part of it comes from designers who feel restrained by industry rules. But the biggest push may be coming from a creed among emerging developers who believe that function trumps form.

It will be interesting to see where the industry goes and if the next wave will be an uprising of good design. I’d love to see designers and developers begin reining in some of the most egregious features, and here’s my list of the biggest problem areas (in no specific order):

Unmoderated Communities

If you threw a party without any rules and invited anyone, it’s a good bet that the police would show up at your door pretty quickly. If you are offering blog comments or social networking features on your Web site, you’re the host…you’re providing a social space, and that comes with some responsibility. It’s important to keep your readers on track, and exerting some editorial control over user interactions is critical for maintaining the integrity of your site. Pay attention to the content that users are adding to your site and step in when necessary if things get out of control.

Excessively Long Page Lengths

Long pages are becoming more and more popular, which bucks the trend of typical usability guidelines. In his July 2006 article, Screen Resolution and Page Layout, usability guru Jakob Nielsen suggests, “When you design, you should consider how much users can see if they scroll only a screen-full or two.”

Generally, I think there’s some leeway to extend past that for a few screens. The primary measure of page length should be its content. Longer pages help facilitate uninterrupted reading and are more convenient to download and print. However, it’s important to strike a balance between a lengthy article and the need for pagination, particularly for reader comments.

Here are two gross violators:

  • A great article by Smashing Magazine, but it’s about 83 screens long and it includes 45 high-bandwidth images.
  • CNN’s political tracker comes in at about 62 screen lengths.

Inappropriate Font Sizes

Pages should reflect a hierarchy, with the most important content at the top. The visual design should follow suit, which means that font sizes should be appropriate for the divisions and subdivisions within your site’s structure.

Fonts that are too large can be disarming to your readers. I think they have the same emotional impact as using ALL CAPS, and I feel as if I’m being shouted at. Small fonts, on the other hand, significantly impact readability.

screen image
Example of super big-font, image-based navigation

Web designers shouldn’t put the onus on readers to adjust their own text sizes. Scale your fonts properly with CSS and test the display in multiple browsers and screen resolutions. Watch out for inherited properties. As an arbitrary rule of thumb, try not to go over about a 24-point heading font, and don’t go below the equivalent of a 10-point font for page text or an 8-point font for caption text (however, that’s really pushing it.) In between, try to find a pleasing middle ground.

Auto-Loading Video

There’s nothing worse than clicking on a link and waiting for a page to load and wondering what’s taking so long…and then finding out that it’s automatically loading a video clip that you don’t want to watch anyway. Don’t take away user control and don’t permit video and other multimedia to play without user interaction. Let visitors to your site “opt-in” by actively clicking a Play button, rather than “opting-out” by clicking a Stop button.

Snap and Other Mouseover Pop-ups

Snap is a plug-in tool that touts itself as “a way of making your links interactive by displaying previews of websites, video, RSS feeds and audio as the readers mouse hovers over them.” It’s also an advertising and revenue-generating service.

Snap and similar JavaScript/AJAX-based mouseover effects produce a pop-up window without active user input – as soon as you hover near a link or icon, the pop-up appears. The pop-ups are unexpected because there isn’t anything to alert the user that the pop-up will be triggered. Some blogs use link decorations, such as a double underline, to indicate their presence…but how is this common knowledge for most users?

screen image
Example of a Snap Shots preview

Pop-ups can present a usability problem for many users, not just those using assistive technology devices. Mouseover pop-ups are particularly disruptive: they are distracting, they can obscure page text, their content doesn’t always scale with different text sizes or screen resolutions, and they contradict accessibility guidelines. Loading additional multimedia in this manner can also significantly slow page loading.

Forcing this kind functionality on a user is a hostile design feature because they have absolutely no control – either from in-page or browser tools.

Uncontained AJAX

AJAX enables developers to automatically load portions of page content after user interaction without directing the user to a new page or requiring a page refresh. It’s primarily used for more responsive interactivity within Web applications where data needs to be exchanged between the server and the client.

Some developers are using AJAX to integrate Tool Tips and contextual information within Web applications, such as having a Help link that produces a pop-up box containing instructions on how to fill out a form.

There’s also an emerging trend whereby AJAX is being used to call up entire pages within pages. In these cases, a user clicks on a link expecting to go to a new page and, instead, the new page appears immediately below or to the side of the original link. The visual effect is somewhat similar to using a frameset.

One example of this is the Webby Awards entry form. When a user clicks one of the categories, a lengthy online form magically appears on the same page right below the icons.

Most of the time AJAX seems to be used just for a “cool factor” without respect for the user experience as developers try to simulate the desktop experience within the Web browser. Its use brings several disadvantages, particularly because it is a JavaScript-based client-side scripting method. Intended results can vary among different browsers, or even be entirely inaccessible.

This doesn’t mean that AJAX shouldn’t be used. However, it’s the way in which it’s used that matters. Pop-up boxes and many other effects are more decorative than functional: they should not obscure nearby content and control tools such as a Close button or link and scroll bars should be provided. Avoid mouseover pop-ups (see above) and always provide text or another indicator to alert the user that the pop-up will occur.

Always test broadly and implement lightly. AJAX-based content is often inaccessible to people using assistive devices or alternate input devices such as keyboards. Unless you are absolutely confident that critical functionality is still entirely accessible in non-JavaScript user environments, you should provide alternate means to access the content.

Mysterious Icons

Placing an icon on your Web site without telling users what it is means that you believe your readers are inherently psychic. Do them a favor and save them from having to guess. Good examples:

screen image
Good – Facebook
screen image
Better – LinkedIn

Image-Based Authentication

CAPTCHA and similar tools provide a way to authenticate that data being submitted through an online form is being done by a human and not a computerized script or spammer. The term is trademarked by Carnegie Mellon University.

Typically, one or two distorted images containing random words, letters or numbers are presented to the user. If the user can successfully read the phrases and enter the text into a form field, then the form can be processed.

Because CAPTCHAs are typically image based, they can be problematic for people with even slightly impaired vision, and impossible to read by people who are blind and using assistive technologies such as screen readers. The images do not scale under screen magnification or lower screen resolutions, and they can be difficult to decipher on small-screen mobile devices.

screen image
Can you read these?

To counter some of the accessibility problems, Carnegie Mellon has modified the product into reCAPTCHA, but unfortunately it still misses the mark. It now offers a small button that users can select to receive an alternate audio version of the phrases, and they suggest that this is a way to conform to Section 508 accessibility standards.

screen image
ReCAPTCHA’s tiny icons

A Wikipedia entry for CAPTCHA states that, “most sites choose to use an audio and visual CAPTCHA as a way of balancing accessibility and security. Often, email support is used to manually provide access to users who are unable to solve a CAPTCHA.”

In theory, this works…but in practice, it fails. Providing an alternate means around an inaccessible feature should be considered a last resort. It would be difficult for most users who are struggling with the application to see the small audio button. Additionally, many people using assistive technologies rely on keyboard input; the buttons require a mouse click and they are not accessible via natural tab order.

Oftentimes a CAPTCHA is placed within inaccessible page designs, at the very bottom of extremely long pages, or within overly complicated Web applications. The tool adds yet another layer of complexity. Its primary purpose is to prevent automated spam, not user authentication. CAPTCHA should be avoided in favor of other methods of form validation to achieve this goal.

Navigation Without Architecture

Tagging, lists of links, category listings, user ratings and other Web 2.0 additions offer intriguing new ways of categorizing and arranging content. But their decentralized nature can also lead to unorganized and unreliable methods for finding information.

With folksonomy, or tag clouds, Web designers and members of the online communities they build collaboratively choose keywords to identify and index content. Ideally, this makes content easier to find because there is a shared vocabulary. However, as these tag clouds grow, it can actually be more difficult to find items because of multiple synonyms and duplicate listings.

screen image
Flickr tags
screen image
Technorati tags
screen image
Example of a tag cloud

A big benefit of folksonomy for large social networking Web sites is that the community can self-promote their hot topics, which enables other members to access that same information faster.

The inherent usability problem isn’t with folksonomy itself. Rather, that folksonomy and other strategies that rely on the “wisdom of the crowd” are sometimes used as substitutes for traditional page navigation. Similar to a marketplace without any signage, this can result in unnecessary trial and error by users to locate information. Combining these strategies with standard menus and structured site maps can significantly improve findability.

Assuming That XHTML+CSS=Accessible

There is a common assumption among many Web designers, open source communities, and developers of content management systems that a Web site is accessible if it is built using XHTML and CSS. This isn’t true.

Designing products that follow XHTML and CSS guidelines issued by the World Wide Web Consortium (W3C) definitely create a solid foundation for an accessible Web site. But just because a Web site contains valid code does not mean that it is built with accessibility in mind.

There are many ways your content can defeat your goals. Low-contrast color combinations, multimedia without captions or transcripts, poorly-structured content, convoluted navigation, and high-bandwidth graphics are just a few.

Incorporating design guidelines from the W3C’s Web Accessibility Initiative can greatly enhance the universality of your products. By designing with accessibility in mind, you’re making an effort to really include as many different user environments as possible. Give it a shot, and you’ll be rewarded with higher user satisfaction.

End of main content.