During a recent snowstorm, the two largest Denver newspapers, the Rocky Mountain News and The Denver Post, gave readers free access to their respective electronic editions. As is still true of many primarily print media sources, the electronic edition of each paper is essentially a careful facsimile of the print edition, but delivered as a Web page. The decision makes sense in terms of giving users a familiar interface, but in practice this approach doesn't always work as it should.

For starters, what font size should such a display use? A font size that can capture the contents of a full-size newspaper on a 12-inch laptop screen will be illegible, but a larger font size will force the user to scroll in two directions to see all the content. Worse, the online edition has to make extra room for advertisements. I'm on a huge widescreen display, so the largest allowed size for the Rocky Mountain News came out to roughly a third of my display. Still, when I view an article, even on a fully maximized browser window, I get a left-right scrollbar for reasons unknown.

I've seen other interfaces run into similar issues, and I've come to the general conclusion that trying to imitate the functionality of a physical object on a Web page (or in any other user interface) can be more annoying than pleasant. This month, I'll look at the pitfalls of familiarity as a basis for Web design.

Familiarity breeds what?

Usability people love to harp on the value of using familiar interfaces to help users adapt to new products. While good in theory, in practice this approach sometimes does little more than breathe new life into bad ideas. Just because I've seen something before does not mean I want to see it again -- ever!

QuickTime's thumb-wheel interface to control volume, for instance, was abysmal, not because I couldn't figure out how to use it, but because using it was awkward and inconvenient. Thumb wheels are great for objects that you adjust with your hands, but they're horrible as a GUI element. QuickTime has since lost that particular element, to Apple Inc.'s credit.

Another example is the virtual keyboard. Used for input, these elements are consistently hated. The entire point of a keyboard is that you type on it. A virtual keyboard that requires you to type with a mouse is a poor substitute. Even the most untrained typist can type with more than one finger, and real fingers are much easier to aim than mice.

Back to top

Tried, true, and still ugly

On closer inspection, the familiar aspects of an interface can turn out to be limitations of the original medium: they're not actually desirable qualities, merely ones that users have learned to put up with.

For instance, printing a single newspaper article in multiple columns is an adaptation to the need to fit text readably into a wide-box format, even though people read narrow columns faster. In print, it is also most useful to get all the text for an article in one place, so you don't need to fold or move the paper too much to read it. Online, where there's less incentive to compress information, vertical scrolling is more convenient -- it rarely knocks over your coffee, for one thing. So, instead of duplicating the appearance of the offline medium, you should focus on getting the best overall effect you can, even if that means changing the look and feel of an interface.

In rare cases familiarity does justify the use of specialized input devices; for instance, it is widely agreed that driving games feel more natural using steering wheels and pedals than joysticks. The difference is that the imitation isn't virtual, it's hands-on. Few people would play a driving game that required them to drag a virtual steering wheel left and right with a mouse, let alone the parody of virtual pedals.

Back to top

Questions of scale

Among the most common problems Web developers face is the difficulty of accommodating different displays. Dave Kopel, writing about the shortcomings of the Rocky Mountain News online edition, discussed issues with displaying pictures, and with page sizing. While annoying to the user, these issues are even more of a challenge for developers. How do you ensure an image will look good on anything from a 24-inch high-resolution display to a year-old laptop? You don't, for the most part. Generally, people with high-resolution displays will just have to settle for tiny little images they can barely see; otherwise, the images are too large on smaller displays.

If images are bad, text is worse. Many sites dogmatically insist on specifying all text size in pixels, with the inevitable result that text doesn't scale up on higher resolution displays. (See Resources for some tips on getting around this.) Modern browsers often allow the user to specify font scaling, or a minimum font size. But these create new issues, and can cause carefully tuned displays in which everything is placed just so to fall to pieces when text is too large. I can think of one Web site in particular, where my search text is about twice the height of the artfully constructed backdrop image meant to encompass the field's content. A plain text field wouldn't look as flashy, but at least it would work the way it's meant to.

Back to top

Evolve, darn it!

One of the hardest lessons to learn is that Web pages have their own structure, needs, and demands. The need for a printed manual to fit in the box with the product is fairly easy to understand and implement; for one thing, the product box is the same size every time. Web pages have to handle a diverse array of representations, from PDAs to huge monitors. A common response to the complexity of online representation is to take print documents, render them as PDF files or something similar, and simply let users download them. This is better than nothing, but not great. It's one thing to offer a PDF when you're really just trying to provide an exact duplicate of a printed document; it's another thing to do it when the document in question would render just as well using HTML.

In fact, HTML offers many newbie Web designers their first chance to try working with the Web medium, rather than fighting it. While HTML does make it hard to maintain precise control over formatting, it offsets this by handling formatting for you, if you let it. Can't decide whether to use a tiny picture or a large one? Have the tiny picture be a thumbnail that links to a larger one. Or, go one step further and offer a couple of links to different versions of the picture for different sizes of display.

Back to top

In conclusion

Many elements of software and Web interfaces start out imitating the behavior of physical objects. While this sort of imitation was prudent in the earlier days of the Web, when its graphical language was undeveloped, it sometimes does more harm than good today.

Objects are engineered based on their physical qualities, including limitations that your software or Web page probably does not share. Don't just copy some familiar object's behavior or appearance; think about what it's trying to do, and how to best accomplish those goals in a different medium.

New materials and new interfaces change the options that will best suit a user's needs. Keep the impacts of your technology choices in mind when you start implementing something. And whatever you do, don't avoid using color graphics in your Web pages because you're worried about the cost of ink.

This week's action item

Compare a simple software keyboard (with individual buttons for each key) to some of the interfaces that have evolved around cell-phone keypads, such as word-guessing systems that combine user input with dictionaries. What are the strengths and weaknesses of each? Which would you rather use to write a letter? Which would you rather use to enter a product key, which has no dictionary words in it at all?

Resources

Learn

• The cranky user: Oh, the pixel pickle (Peter Seebach, developerWorks, August 2005): Next time you do page layout in pixels, try using points instead.
  
  
• The cranky user: Usability off the beaten path (Peter Seebach, developerWorks, March 2006): Consider these user-centered innovations in computer software and hardware design.
  
  
• QuickTime 4: Read a review of the user interface for the QuickTime 4.0 Player when more was wrong with it than just a jog wheel.
  
  
• Dave Kopel: Read about about his experiences with the electronic edition of the Rocky Mountain News.
  
  
• The cranky user columns: Read earlier articles in this column.
  
  
• The technology bookstore: Browse for books on these and other technical topics.
  
  
• developerWorks Web development zone: Expand your site development skills with articles and tutorials that specialize in Web technologies.
  
  
• developerWorks technical events and webcasts: Stay current with jam-packed technical sessions that shorten your learning curve, and improve the quality and results of your most difficult software projects.
  
  

Get products and technologies

• developerWorks Web development Downloads and products area: Find more free downloads.
  
  
• IBM trial software: Build your next development project with software available for download directly from developerWorks.
  
  

Discuss

• developerWorks blogs: Get involved in the developerWorks community!
  
  

About the author

Peter Seebach has been using computers for years and is gradually becoming acclimated. He still doesn't know why mice need to be cleaned so often, though.

Rate this article

Comments

Back to top

Table of contents

• Familiarity breeds what?
• Tried, true, and still ugly
• Questions of scale
• Evolve, darn it!
• In conclusion
• Resources
• About the author
• Comments