WebTV achieves a very high level of usability given its design constraints. Unfortunately, the constraints are so severe that even this great design ultimately fails to provide an optimal Web user experience.
WebTV's usability engineers have done a good job at making it very easy to install and as easy as possible to use, and WebTV's imaging engineers have done an incredible job at high-quality character rendering in an NTSC video signal. In fact, the screenshots in this column do not look as good as WebTV does when displayed on a good television set: you have to see it to believe that it's possible to achieve WebTV's level of text readability on a television screen.
The remote control has great industrial design: the main buttons can be used while the user keeps his or her gaze directed at the TV screen. The four cursor key buttons surround the "action" button and can easily be used to move the area cursor around the screen to follow hyperlinks. Also, the scroll up/down buttons and the "back" button are easy to find without looking at the remote control. It actually feels very natural to sit in a reclined posture and move through online content with the WebTV remote as the only input device.
Unfortunately, the need for a simple remote control ultimately dooms WebTV as a highly usable Web experience. No matter how well designed, it is simply too awkward to use cursor keys to move around the screen instead of using a mouse or other direct pointing device. My best description of the experience of browsing the Web with cursor keys is that it feels very much like using DOS or one of the old IBM 3270 terminals. Instead of saying " this is where I want to point", the user has to say "OK, to get over here, I first do UP, UP, and then LEFT, LEFT". In other words, instead of being a single action, pointing turns into a sequence of actions that have to be planned and monitored with a much larger degree of cognitive load than when using a mouse.
Normally, the cursor keys jump the area cursor to the next selectable area of the screen, but when an imagemap is selected, they double as directional continuous-movement controls for a pointer. Using imagemaps is particularly cumbersome since doing so requires the user to first move the area cursor to the graphic, then select the graphic with the action button, then manipulate the
x-y position of the pointer within the image with the cursor keys, and finally push the action key a second time. Compare this sequence of steps with simply moving a mouse to the desired spot and clicking the mouse button in essentially a single step.
When viewing three-column layouts it is often hard to position the area cursor in the middle column, because the left or right buttons jump the cursor to the selectable area closest to the current
y position. Thus, the cursor often jumps directly from column 1 to column 3 or from column 3 to column 1.
The remote control has a set of scroll-buttons in addition to the cursor-movement buttons. Since the cursor-buttons also scroll the screen when used to move below the last selectable item or above the first selectable item, and the scroll-buttons cause new items to be selected (the first item on the new screenful is automatically selected), users often confuse the two sets of buttons. Even after many hours of WebTV usage, I found myself sometimes pressing the wrong button. Since the button-design for the remote control is an obvious candidate for intensive usability testing, I am sure that WebTV considered this problem and has good reasons for having both sets of buttons on the remote, but I would certainly consider simplifying within-page navigation to a single set of buttons.
The wireless keyboard is supposedly a $60 option, but the system is almost useless without it: email obviously requires a keyboard, and mail is still the true killer app of the Internet. There is an on-screen keyboard that can be operated by the remote control, but it is extremely painful to tap out even short URLs by moving cursor keys up-right-left-down. On-screen keyboards work reasonably well on devices like the Newton that have a direct pointing device, but with cursor keys: forget it! The on-screen keyboard can be configured to display the characters alphabetically (ABCDEF etc.) or as a traditional typewriter keyboard (QWERTY etc. - presumably other configurations will be available in international versions). The default setting is alphabetical layout which only works for people who have never used a typewriter; of course, there are probably many such users in the WebTV target market.
The wireless keyboard is very well designed as a true laptop device. You can sit in your couch and type while resting the keyboard in your lap. The form factor, weight, and typability are all well done, but the key layout is very difficult to learn. There are special function keys for the most common WebTV commands: the basic keys from the remote control (up-down, back, home, etc.) are replicated and keys are added for functions that otherwise need indirect access through the Options command (for example, GoTo and Find). Unfortunately, all these function keys are really tiny and arranged in a seemingly random fashion around the periphery of the keyboard. It is impossible to learn where one finds which keys, so the user must perform a visual scan of the function keys every time they are used. This visual scan is very difficult given that the keys are small (i.e., tiny labels) and that the keyboard is typically in the user's lap (i.e., far away from the eyes) and in poor lighting. Make a more navigable keyboard for Version 2, please.
Typing is only possible when the keyboard focus has been explicitly assigned to a type-in field. Unless the field is the first element on the screen, this means that the user has to manually use the cursor keys to move the focus to the type-in field before typing. These extra actions should be eliminated, especially given the awkward nature of using cursor keys instead of a mouse to move around on the screen. Unless the user has explicitly moved the keyboard focus to a specific field, typing should be directed to the first type-in field on the screen as soon as the user sends character input from the keyboard. This lack of a default keyboard focus is one of the relatively few areas I have found where the interaction is insufficiently polished. Quite often, shortcuts and appropriate defaults are designed into the system to reduce the number of user actions needed to achieve a given result. Doing so is a good idea in most user interfaces but is critical for a system with indirect or hard-to-use interaction techniques (e.g., voice recognition systems, telephone-operated interfaces, and WebTV).
WebTV is the first major attempt at building an information appliance and it has definitely shown the promise of non-general purpose computers when it comes to ease of installation. In fact, the only difficulty in installing WebTV comes when connecting it to the TV through the VCR. Getting the cables and all the VCR and TV settings just right to pass the WebTV signal through to the screen is often fairly complicated. Pundits often say that consumer electronics companies know how to build products for naive users, but the people who built my VCR could definitely learn something from WebTV when it comes to ease of use.
Interestingly, many of the usability problems I have observed in informal studies of a few WebTV users turned out to hurt experienced users the most. WebTV is using its own vocabulary, which is probably a better match with novice users' expectations but causes problems for experienced users. For example, when defining a new user account, the user is asked to type the user's "Internet name". One user I tested thought that he was supposed to give his email address, so he entered his current address. In fact, the system wants to create a new userid for the user on WebTV's system, and this would have been clearer for an experienced user if it had said so. For novice users (who are presumably WebTV's design center), I do agree that "Internet name" is a better term than "userid". A further problem for my experienced user was that he could not enter the userid he wanted. He has a quite distinct userid on other email systems and naturally wanted the same on WebTV, but it was taken already. The same was true for the first several variations he tried of his name. As this example shows, naming is starting to be a problem on mass services (of course, on AOL most people get names like
John537 since they are even further along the curve) and we will need to invent better ways of creating acceptable names.
Other terminology differences include using publisher instead of site (e.g., a status message says "Contacting Publisher" instead of "looking for site" when connecting to a new site) and real error messages (e.g., The publisher couldn't find the requested page instead of 404). This non-standard vocabulary no doubt tests better with novice users but will make it more difficult for WebTV users to communicate with users of other devices.
While a page is being downloaded, a single progress bar is displayed (strange that I have to praise WebTV for having a useful progress bar, but most other Web browsers can't seem to get this basic UI element right). To further increase usability, the user is informed of the name of the "publisher" as soon as possible: the text Contacting Publisher is replaced with the site name as extracted from the page <TITLE>. Unfortunately, WebTV can't display very many characters in the progress dialog (since a large screen font is necessary for readability on a TV), so it is common for the publisher name to be given as "Welcome to Washi..." instead of "Washington Post". WebTV ought to make their server chop off any leading "Welcome to" prefix from page titles. Actually, as mentioned in my discussion of proper <TITLE> design, it is bad form to use Welcome to titles in the first place!
The email icon several times made me think that I had new messages waiting when in fact there were none. My problem was that the flag is up on the mailbox even when there is no mail (new mail is indicated by the appearance of some envelopes in the mailbox); a raised mailbox flag was used by some early Unix mail programs as the indicator of new mail. New users may not have this problem, but it may be worth revising the mail icon in an upcoming release. Also, this very American mailbox will definitely need to be replaced with another icon for international versions of the system.
WebTV correctly follows the principle of progressive disclosure to move complex and less frequently used options out of the main user interface and into secondary screens. The problem from the experienced Web user's perspective is that the definition of "complex options" includes some features that are more or less second nature to the experienced user. For example, I observed one experienced user become very frustrated when she couldn't find the URL of a page she was viewing. After many failed attempts she gave up and assumed that WebTV didn't support URLs. Only after I broke a basic rule of user testing and assured her that the feature was indeed available did she persist and eventually found the URL under the "Info" command in the Options menu.
Similarly, experienced users have also had problems finding the way to type in a URL to go to a specific page. The underlying issue is that WebTV (correctly) decided that URLs have low usability and therefore wanted to hide them from their novice users. I completely agree with the desire to simplify the user interface and hide complex features. The only problem is that the Web is currently so hard to navigate that many experienced users have learned to rely on the URLs to help them understand what is going on. In particular, the lack of URL information increases the experienced user's feeling of being lost and of viewing the Web through a very small peephole. The ideal solution would not rely on URLs but would employ other means of visualizing the structure of the information space and the user's current location. In other words, we need some combination of local and regional sitemaps with path representation and a global overview of the Web (distorted to emphasize areas of interest to the user). Unfortunately, these navigational aids (which we will hopefully see in a year or two) require a larger screen area than could reasonably be dedicated on a TV monitor. Whether it will be possible to use a combination of overlays and transparency effects with some form of rapid screen multiplexing to present some of this information to TV users remains to be seen.
With respect to feature elimination, I would have removed the user preference to sort the email list with either newest or oldest messages first. WebTV's email interface only works for people who get a very small number of messages, so they should not need to sort them. One cannot accuse WebTV of feature creep, but maybe this one feature did creep in from traditional power-user design.
WebTV has a small screen that shows a very limited amount of information compared with a traditional computer screen. This is particularly true given the need for WebTV to use large fonts because of the poor display quality of NTSC televisions and the typical viewing distance between the TV set and the user's couch.
A sample Web page as displayed on a workstation-class computer monitor (reduced to 35 percent of normal size) and on WebTV (reduced to 67 percent of normal size).
The red box on the computer display marks the part of the page that is visible on WebTV's screen.
Three problems stem from WebTV's small screen size:
Excessive scrolling is needed to move about the page, meaning that the user will often not see the entire page because of the extra effort. Scrolling is known to cause problems even on normal computer screens, and it is likely that WebTV users will have even worse problems since they will need to scroll more.
Users often get lost within a single page: there is no way of knowing how far one has scrolled down the page or what other information is on the page. In particular, it is almost impossible to get an idea of the structure of a page or to predict what else one might see further down the page. These problems also exist in large-screen browsers, but because more content can be seen at any one time and because less effort is needed to scroll about the page, the usability consequences are much less severe.
Once the user has scrolled down a page, it is a lot of work to get back to the top of the page. Essentially the only way to do so is to hold down the "scroll up" button until the system has scrolled all the way to the top, one screen at a time. There is a "scroll to top" command, but it is hidden away under the Find command and requires 6-8 button presses (depending on the prior command) on 4-5 different buttons (too many) to activate. It would be better if the system would recognize a "long" press on the "scroll up" button as a command to go all the way to the top in a single fast leap.
WebTV is the first Web user interface for which I have discovered a serious need for navigational aids within the page. See the sidebar for some of my ideas for improved within-page navigation.
Except for within-page navigation, WebTV is not much different from other Web browsers with respect to navigation. The basic problem is lack of navigation support for an understanding of larger structures, but it would not be fair to criticize WebTV for lacking features that nobody else has at this time. WebTV actually improves on the history lists in other browsers by using a "recent" screen that shows recently seen pages in miniature. Often, it is easy to pick out the relevant page from the recent screen and backtrack many steps in a single action.
A satisfying "thud" sound is played if the user tries to scroll past the bottom of the screen. In general, WebTV has instructive and pleasing sound effects as an integrated part of the user interface in great contrast with the impoverished audio in most computer user interfaces (except games).
On the "Favorites" page, bookmarked sites are shown as labeled miniatures. This is a good way of showing a small number of bookmarks and allows the user to quickly discriminate the options. The presentation of the favorites would improve if sites starting to use WebTV's convention for specifying a logo image to replace the miniature with an appropriate logo (the LOGO attribute of the BODY tag). By the way, small logo glyphs might also improve the scannability of bookmarks and favorites menus in traditional, computer-based browsers. In principle, I would prefer to have logo-specifications be part of a site management system instead of being embedded within the BODY tags of every page: we need extensions to HTTP to allow browsers and proxies to retrieve site-level information (like logos and sitemaps).
Sometimes, bookmarking a page results in a black square instead of a miniature. This seems to happen when the server has not finished downloading all the graphics on the bookmarked page but feels like a bug to me: it would often be better to produce a miniature of the parts of the page that did get downloaded. A worse usability problem is that the labels show the full <TITLE> of the bookmarked page, even when the text is very long and takes up most of the screen in the WebTV layout. I would have preferred a solution that showed only the first two lines or so of the <TITLE> and then popped up the remaining text when the user places the area cursor over the bookmark.
Find Within a Page
WebTV provides a Find command to locate a text string within the current page. Since we know from studies of traditional browsers that users frequently confuse Search (whether site-wide or Web-wide) and Find, I am sure that Find will cause problems for WebTV users too. Even so, I agree with the decision to include this feature because of the reduced text readability and the problems with understanding the structure of any given page because of the small viewport. Since the user cannot easily go to the part of a page that covers a given topic of interest, the Find feature turns out to be a very handy within-page navigation aid.
If the user tries to Find a string that is not on the page, a reasonably good error message is displayed ("Could not find the word on this page"). When Find is subsequently activated on another page, WebTV correctly prepopulates the search field with the previous search string (good defaults always save users time but are especially critical for interaction widgets that are as cumbersome to operate as WebTV's). Interestingly, the Find area still displays the error message saying that it could not find the word. The first few times this happened, I assumed that WebTV was fast enough to have searched the new page for my Find string while it animated the appearance of the Find area (a reasonable assumption for the performance of a 112-MHz, 64-bit RISC processor searching a few kilobytes of text for an exact match). Because of this conclusion, I immediately closed the Find dialog without ever searching. As it turns out, WebTV had not searched the subsequent pages and the error message was a bug. My preference for a redesign would be for WebTV to make my erroneous assumption come true and search the page for the previous search string while the Find dialog is animated, since doing so would save users having to explicitly activating a search for a string that is not found. Again, manipulating interaction widgets with the remote control is much more awkward than using a mouse, so anything that minimizes user operations should be done.
Despite Sony's best efforts at putting their logo on the remote control, there is no doubt that the user experience has a big fat WebTV brand on it. The "home page" icon on most navigation screens says WebTV, as do many parts of the user interface. Most important, most of the top-level content accessed by the user carries a WebTV logo.
My conclusion is that WebTV is one of the first cases where the Content-is-King -principle has been used to overrule the brand of the physical device in the users' hands and turn the content into the main brand. In contrast, if you are using a Sun workstation to browse Microsoft's website, you still feel like a Sun customer, and conversely if you are using a Mac to browse Sun's website, you feel like an Apple customer.
Designing for WebTV
My main recommendation is not to design explicitly for WebTV unless you are creating a service dedicated to television users. The power of the Web is cross-platform design and the ability to have your user interface reside on a server under your control from which it can be projected to any customer in the world no matter what local equipment they have. This property is destroyed if you start to design for specific hardware. What should happen is that WebTV get with it and includes stylesheet support in Version 2: once that happens, you can link all your pages to a special stylesheet that is optimized for television in addition to stylesheets for traditional computers, PDAs, etc.
If you are designing a dedicated service or if you want to set up your server to detect the user agent and provide different pages to different browsers, then WebTV's own styleguide is certainly a start. Web Review 's feature story on designing for WebTV is another source.
If you want to design for the Web as a cross-platform information system but want to be considerate of WebTV users, then follow these guidelines:
Do not use large images (more than 544 pixels wide or 376 pixels tall) unless they will still work after WebTV's automatic rescaling to the available viewport area
Reserve use of imagemaps for the absolutely necessary cases (e.g., for selecting a location on a map) and make navigation bars and other sets of buttons into discrete images
Do not include text in your images since the characters will be very difficult to read on the WebTV screen
If you need to include text in an image, use 16 point bold Helvetica or larger (or an equally readable font) - the 16 point guideline assumes that the image is small enough that it will not be rescaled
Do not use a multi-column layout. The figure shows how poorly the 3-column layout from news.com works on WebTV (even though it is one of my favorite designs on a regular computer screen)
If your design requires columns anyway, use at most two columns and make sure that they will work on a 544-pixels-wide screen
If you have a page that will scroll over more than four WebTV screenfuls, then repeat any navigation bar at the bottom of the page. I dislike this advice since extra interaction options increase the burden on the "normal" user to understand the page, but if your log files show more than, say, 5 percent WebTV users, then remember that the current WebTV design makes it hard to scroll back to the top of the page.
Split your information into a rich hypertext space with a larger number of smaller nodes (OK, I didn't follow this advice for this column which is painful to read on WebTV)
If possible, make each unit small enough to fit on a single WebTV screen to eliminate scrolling (interestingly, this advice is a return to the "card shark" model of hypertext as exemplified by HyperCard in 1987: ultimately we will need to evolve a new form of HTML to define pop-ups, overlays, partial fades, and the other interaction options that enhance card-based hypertext).
Brevity: write less text