This round, Peter takes a look at how his friend's in-house CD changer application -- with a user base of two people -- underscores the need for thorough usability testing on Web pages.
A couple of years ago, my friend Kevin announced that he was going to make a stereo component himself. It was called Juke-ola, and it was designed to be the ultimate CD changer, holding hundreds of CDs, and allowing users to conveniently browse among them using a graphical interface.
It was, of course, a plain old computer playing MP3s: Users would access and select lists of songs to play through an in-house intranet. The technology involved was fascinating, but the part that's relevant to this column was just the user interface: How could you interact with a system like this? What options did it need? Perhaps most importantly, what could possibly go wrong with an application with a user base of two people?
In this article, we will look at how even a simple Web page, with a very limited user base and complete control over the target platforms, still depends on all of the usability techniques you might apply to a larger page.
The original design for the Juke-ola interface consisted of a webpad (a portable computer with a notepad form factor and some kind of network connection, designed to run a Web browser and nothing else) connected via wireless LAN to a Web server running the interface. At the time, webpads were "just around the corner." (As of this writing, they're still in development, and it's been about two years.) So, the interface assumptions were these:
With this in mind, Kevin designed the first prototypes of the Juke-ola interface. The interface centered around building and selecting playlists; this was deemed to be a likely way that users would interact with a player, and corresponded to the way large CD changers are commonly used. The interface used straight HTML, with no frames, Java code, or JavaScript. This required a few compromises (for instance, pages had to refresh occasionally to update the "now playing" display), but was very easy to develop. Thus, all the fancy stuff that a browser might do was actually included in the CGI scripts.
Even with an audience of two, it was possible to get a surprising result. For example, one of the user interface features was a playlist -- a set of songs grouped together. These playlists could be stored for later playback. The interface for editing a playlist had two lists of songs: the whole list of available songs (generally broken down by album, so the list wasn't too huge), and the current playlist (selected by the user). Clicking on a song in the big list added that song to the playlist. Clicking on a song in the playlist removed it from that list.
This mirrored a number of common user interfaces -- but turned out to be surprising to the second user (Kevin's wife), who expected that clicking on a song would "select" it and allow for further operations -- such as playing an intro, moving the song up or down in the playlist, or deleting it from the playlist. Never forget the importance of user testing. For most systems, you need to test with users who do not know how you think the page works; these people will never become experienced users if they get frustrated on the first attempt.
Juke-ola quickly developed a reasonable basic feature set. Within a few weeks, it was possible to select songs, select albums, build playlists, or even just shuffle-play the entire collection. It was about at the level of completeness that most Web pages are at launch -- complete with occasional "404" error pages.
The webpad never materialized. So, for the first year or so of Juke-ola's existence, it was controlled from a regular desktop computer -- inconveniently, this was not located in the same part of the house as the stereo system. The computer interface was gradually adapted to its local needs; for instance, an option to burn a CD with audio tracks in a given playlist was added. But, for most of that time, the day-to-day usability of the system was compromised by the delay in the external technology.
The key lesson from this is: Don't wait for technology. If your design relies on technology that you aren't holding in your hand, your design is dependent on something beyond your control -- and you very well may not be able to make it work. This is more serious for corporations than for hobbyists. Imagine telling customers they need to wait another year and a half before they can buy from you because your page depends on technology that isn't available yet. Worse, imagine telling them a dozen times that they need to wait "just one more month." It won't work, so don't do it. Build your page based on what's real today.
This applies both to technology on your end and technology on the user's end. Don't build a page that can't be used until a new release of a database engine is available; find a way to work with the existing engine. Similarly, don't assume your users have downloaded a recent version of a browser. Millions of people are still working with older browsers, and won't upgrade any time soon.
After about two years of waiting, Kevin decided to switch to a smaller form factor (even though webpads still weren't available). His choice? The Compaq iPAQ, which he selected because there was an 802.11 wireless card available for it right then, and it came with a Web browser.
This required a redesign of much of the site's interface. The side-by-side lists of songs were impractical on a screen barely large enough to list one song title. Some features -- like burning a CD -- could simply be omitted.
Most surprisingly, though, performance became an issue. Even the slowest available desktop computer (a 90 Mhz Pentium at the time) with a browser could render the entire database in seconds. The iPAQ took a couple of minutes to render the entire album database, and about 10 minutes to render the entire list of songs. (It only takes a second or two for the data to come over the wireless LAN; the rest of the time is spent on rendering alone.)
Many other interface features became problems. The site had originally used occasional pop-up windows to manage parts of its interface. The version of Internet Explorer on the iPAQ simply ignored this; the clicks were ignored and nothing happened. So, the page had to adapt to the user not being able to open new windows, or ever having more than one window open. A simple link would have worked better than JavaScript in this case.
Browser updates have brought new sources of misery; the most recent version won't refresh a page forever, so the display of the song currently playing stops working after a few minutes.
At least 10% of the time spent on this project was devoted solely to user interface analysis, design, and enhancements -- and the user base was only two people, one of whom was writing the software. Most pages seem to get less usability analysis and work than this, yet they have larger user bases, and the users are substantially more frustrated.
In particular, it is very hard to anticipate the idiosyncrasies of a browser other than the one you're testing with, especially if it's likely to be substantially different. Users with unusual displays are becoming more common, and sites that discriminate against them will lose their business.
This month's action item: Find out how much time was allocated for usability testing and design on your Web site. Was it enough? How long would it take to make it usable on a handheld browser?
Peter Seebach has been having trouble navigating through badly designed pages since before frames and JavaScript existed. He continues to believe that, some day, pages will be designed to be usable, rather than being designed to look impressive. You can reach him at crankyuser@seebs.plethora.net.