Features for the Next Generation of Web Browsers

by Jakob Nielsen on July 1, 1995

The future is not what it used to be, especially regarding WWW browsers. They used to come in two flavors: text and Mosaic, but now there is a profusion of choices. Netscape has shown that it is possible to dominate the Internet almost overnight, going from less than one percent to about 70% market share during the last two months of 1994. Such rapid changes may be a unique characteristic of the Internet since most other markets award more permanence and slower erosion of market share to their leaders. On the Internet, news and customer testimonials spread immediately world-wide and "shelf space" is limited only by the vendor's server capacity and connection bandwidth (indeed, Netscape would probably have spread faster if only people could get through to their FTP site!).

The only certain trend on the Internet and WWW is that there are no trends on the Internet. It changes so fast that it is impossible to predict what will happen, and new trends may bloom and die overnight. Even so, the following changes ought to happen, so hopefully they will be the next trends:

WWW browsers need the ability to handle streaming data types, such as video, and they should negotiate proper quality (e.g., frames per second) with the server depending on their experienced download bandwidth. In the future, only stupid servers will send the same file to high-end and low-end clients.

Users will need lexical-level feedback from interaction with ISMAPs. All our user studies when designing Sun's new home page showed that the most serious problem was that people did not know where to click on imagemaps. Most likely, this feedback will be similar to the highlighting of buttons in HyperCard. The Java version of Sun's home page provides one idea of how this can be done (note, you can only see the effects if you are using HotJava or some other Java-capable browser).

We have to move beyond the single-canvas model: Allow non-scrolling parts of a page (called "freeze-pane" mode in spreadsheets) to combine the best of the holy scroller and the card shark models of hypertext . For example, people with an inclination to define new non-standard HTML tags could define a <TOP> tag to make information non-scrollable and always visible in the top of the window (or, with a <BOTTOM> tag, in the bottom of the window). This technique could be used to make headerbars and footers that would not remove the user's navigation options etc. if the page was longer than the window.

Note added March 1996: Please note that the suggestion I made in July 1995 to make certain parts of a web page non-scrollable is very different from the so-called frames introduced in Netscape version 2.0: Frames have horrible usability since they break most of the navigation features in a web browser (bookmarks, backtrack, and going to a URL all stop working). Non-scrollable sections of a web page would have retained the fundamental hypertext model of web browsing: what you see (the window) is what you need to know (the unit of navigation). I want something like the banner feature that was included in HTML 3 or (added August 2000) the inline frames in HTML 4.

We also need an economic model of information use, by which I refer not to payment to the information providers (we need that too), but to optimizing the use of resources. For example, the browser should negotiate with the server to download smaller bitmaps during peak load times, or the user could instruct it to spend at most 10 seconds to load a page. The page definition should be encoded to prioritize the information and provide alternative representations of large elements to enable the client/server solution to download as the most useful information that is possible under the given restrictions. It might also be possible to have the browser prefetch information during times of no user activity. Doing so would relate to the economic model of WWW usage: how much priority are you willing to place on fast browsing? If fast browsing is worth a lot to you, you should be willing to dedicate the resources to have your computer download a lot of stuff just in case you might request it later. Some of this prefetching might happen overnight (from servers you subscribe to) and other prefetching might happen by a breadth-first traversal of the outgoing hypertext links from your current page.

Of course, we need better hotlist management with advanced user interfaces for dealing with large amounts of information. Browsers should also support readwear, interest voting, group annotations, and overview diagrams of the user's navigational history/structure, possibly using an infinitely zoomable canvas.

A quick tour of the Netscape interface indicates the availability of nine hypertext navigational mechanisms. This may seem like a lot, but the navigation chapter in a standard textbook about hypertext lists at least fifteen major hypertext mechanisms that are missing from current WWW browsers. Not all of these mechanisms should be included in all hypertext systems (featuritis is a design disease to be avoided), but more navigational features are needed in advanced WWW browsers if they are to meet users' needs in the future.

Given that one of the main design principles for WWW pages is to stay within a single screen, how come that I wrote this long a column? Well, we also found that people with a real interest in a topic would read longer texts, and the last half of this column is only intended for people who really care about hypertext on the Internet.

Share this article: Twitter | LinkedIn | Google+ | Email