useit.com Alertbox Sept. 1998 Does Internet=Web?

Jakob Nielsen's Alertbox for September 20, 1998:

Does Internet = Web ?

My simple definitions are that

• The Internet allows any computer in the world to exchange data with any other computer in the world. As a result, a client program on one computer can access a server on a another computer.
• The Web is a hypertext system that runs over the Internet as one of its services. As a result, users can sit at any computer and browse documents that live anywhere in the world; furthermore, these documents can link to documents from any other place in the world.

Viewing the Web as a hypertext means that it needs navigation support features and that users will come to rely on consistent use of these navigation features to move around in hyperspace. In other words, there is a specific user interface that is optimal for the hypertext problem of navigating a huge information space to find and read information. Not that we are anywhere close to an optimal hypertext interface in today's Web browsers, but they do have some features like Back and bookmarks that users quickly learn to rely on.

It is unlikely that the user interface that is optimal for browsing hypertext will also be optimal for every other thing people want to do with computers. Thus, if the Web becomes a single, universal interface to all Internet services, we will either end up with a sub-optimal hypertext interface for the browsing tasks or get a sub-optimal user interface for all the non-browsing tasks.

Email is a good example: it was the first killer app for the Internet and requires a rather different user interface than Web browsing. There are services to access email through a Web browser, but they have a distinctly second-class feel relative to the use of a smoothly designed email interface like Eudora or Outlook.

The same is true for other popular Internet services like home banking and airline reservations: optimized stand-alone applications deliver a superior user experience to that derived from shoehorning the same features into a Web browser.

Obviously, these stand-alone applications need to be Internet-enabled and they must have ways of dealing with firewalls, encryption, and other practical issues in Internet access. Quite likely, the long-term solution is for operating systems to include a much richer layer of Internet services than the current simple IP transport.

Stand-alone applications have some downsides:

• They must be downloaded before they can be used. Once downloaded, they can provide much faster response times than a Web browser, since they only need to exchange minimal data with the server (whereas Web interfaces must download page layouts and behavior specifications along with every set of data). Thus, stand-alone applications only make sense for tasks that must be done repeatedly. For a once-only task, it is better to start immediately and then suffer a more awkward user interface and slower response times for each step.
• They must be reimplemented for any new computer platform that becomes sufficiently popular. This need not be a huge hardship, since some newer programming and scripting languages are cross-platform. Even so, each new platform has its own requirements, and it is obviously not possible to port an application from a desktop computer to a palm-sized computer without having to redesign its user interface. Even if the code is portable, the design is not, so some reimplementation is inevitable. For an application that is used extensively, the optimal user experience derived from this redesign will be well worth the effort, but for a rarely used application the cost may be prohibitive, meaning that it will either only be available on the most widely used platforms or that it will be restricted to an awkward Web-like interface.
• Administration and upgrades are often mentioned as downsides to specialized applications, but it should be possible to have component software that could upgrade itself as needed (without requiring a full download every time 10% of the code change) and that could be administered remotely (if the user grants that privilege).

Some interactions are sufficiently document-like in nature that they should not be considered applications. If the user's main interaction consists of browsing information, then a hypertext-like user interface may be fine. CarPoint's pricing calculator is a good example of using an integrated OCX control to achieve some functionality on a Web page while keeping it within the hypertext paradigm. Who cares that it's running code as long as it doesn't feel like it.

By clicking options on and off, a CarPoint user can determine the price of different car configurations.

Clicking checkboxes in the CarPoint Auto-Pricer has no effect outside the Web page: the user is not buying the car, but simply browsing the options. Yet it is clearly a good idea to recalculate the price to reflect the currently chosen options. The price calculator is a content feature and not a functionality feature: this is why it works to embed it on a Web page. My preferred design for a car price interface would have been even more firmly based on hypertext: include links from each of the options to secondary pages with an explanation and a review of each option.

The problems start once we need functionality features that include state transitions and multiple views. One of the most common usability problems on the Web these days is when the Back button breaks because the previous page is no longer a valid view of the data on the server. Some sites put big warnings on their pages: DO NOT TOUCH THE BACK BUTTON. This doesn't work. The Back button is so ingrained in users' habits that they reach for it all the time, no matter what you say. Remember that any individual website is an insignificant speck of dust in the universe of the Web: you cannot override habits formed while browsing hundreds of other sites.

I think it is time to recognize that the Web cannot be all things and still retain a good user interface. Let's reserve the Web for what it's good for: browsing hypertext (including dynamic content that does not have complex functionality). And let's start building Internet-enabled client-server applications that provide optimized user interfaces on the client. The Web may still have limited roles in support of these advanced applications:

• navigating to the service and finding it in the first place
• help and supplementary information
• a secondary interface with limited or awkward features for short-term use at a computer that does not have the specialized client software installed

See Also: List of other Alertbox columns