of Hypertext and Graphical User Interfaces

4 Beyond the Desktop

in Vision and Reality of Hypertext and Graphical User Interfaces

  1. Web GUI meets Desktop GUI
  2. Provisions for the Future

Today, many personal computers are connected to the Internet. Communication services like electronic mail are in everyday use, and the World Wide Web definitely has characteristics of a new medium.

Tim Berners-Lee and Robert Cailliau used the NeXT application framework to develop the first program to read and edit HTML pages in WYSIWYG mode [Gillies/Cailliau 2000, p. 190]. NCSA Mosaic by Marc Andreessen was not able to edit HTML pages, but it was available for X-Windows, Microsoft Windows and Apple Macintosh. This led to a worldwide distribution of this Web browser program. Berners-Lee’s WorldWideWeb/Nexus and Mosaic follow similar principles. The programs utilize graphical user interface elements of the WIMP environment. Web pages correspond to windows. But in the case of Mosaic, the current page is replaced by the targeted page of an activated hyperlink. The shifted meaning of ’browsing’ depicts this behavior.
None of these efforts put any work into the user experience, to try to integrate the Web as a new dimension into the desktop model. Browsers are ordinary application programs. This is true for early browsers as well as for current versions of Netscape and Microsoft Internet Explorer. But inside the browser windows a new kind of graphical user interface unfolds.

The first section of this chapter will show how the WIMP desktop model and the Web interface fall apart.

4.1 Web GUI meets Desktop GUI

The Web interface and the typical desktop interface are both graphical user interfaces. But this is nearly all that these two have in common. Some important aspects of WIMP have been discussed in section 3.3 Windows, Icons, Menus, and Pointing Device. Analyzing the Web interface on the basis of WIMP shows that the Web should not be considered as such.

Browsers use windows to display Web pages. The relation between window and Web page is in accord with the expectations of the user. The window displays a document, even if it is a remote one. The user can resize the windows, which causes the content to be recomposed. No assumption is made on the screen size of the client’s machine; therefore the maximum size of the window is unknown and the Web page aims to fit any window size. A click to a hyperlink loads the next page into the browser window. The history function keeps track of the path how the pages were reached. The path is a list of URLs. Control elements are provided to navigate forward and backward in history. If the user closes the window this information is deleted.

Icons are not used in Web interfaces. To be more specific, icons that symbolize objects with a well defined semantics are not utilized, because direct manipulation is not applicable in Web context. Response times would be too long, and the technical side still suffers under the original statelessness of the HTTP protocol. Nevertheless, icons as signs and icons as labels for command buttons and image links are frequently used.

Menus are not part of Web interfaces. A Web page currently has neither control over the standard menu bar, nor of any context menu. These menus always offer standard commands of the browser interface. Unfortunately, the current Web site cannot add custom items to the menus. A couple of examples can be found in section 2.3.4 Browser. Some Web sites misuse popup controls for navigation purposes. Popup control items are intended to make a choice, for instance a country should be selected out of a list of possible countries. Selecting commands with popup controls is in conflict with the common meaning of this item in desktop application programs.

With respect to the pointing device, hardly any difference between the desktop model and the Web can be seen. It should just be mentioned that a Fitts’ Law effect on a screen edge can not be achieved for Web interfaces (cf. 3.3.3 Menus). Browser windows are not near to any edge of the screen.

Limited use of icons and no use of menus disqualify Web interfaces from being WIMP interfaces.

The Web interface also introduces its own kind of interaction mode. For example, the dominant way to use the graphical input device is to click on a hyperlink. One click is sufficient to trigger the link. In the desktop world a single click usually selects the item. Only a double click triggers the item to open. Text selection is another field of inconsistency. A piece of text usually can be selected by a click-drag action. The same action initiated on a textual hyperlink starts a drag action of the URL.

Forgiveness is a quality of well designed user interfaces. The Macintosh interface guidelines urge the application developers to implement undo functionality wherever possible. The guideline reads [Apple 95, p. 10]:

People need to feel that they can try things without damaging the system; create safety nets for people so that they feel comfortable learning and using your product.

It is too easy to damage valuable user data with a Web browser. Stability of the product is one factor, but a simple action like closing a browser window irrevocably clears the history for that window.

This passage can only give some examples to demonstrate that even the interaction modes of Web interfaces and the conventional desktop model are in conflict with each other. The misuse of familiar control elements, like popup controls, results in a mixed up user experience. The user has always to keep in mind whether she is in Web mode or desktop mode. The user is confused. Errors are more likely under such conditions.

4.2 Provisions for the Future

What can be done to bridge the gap between the desktop environment and the Web? The sections 2.3 Provisions for the Future of the World Wide Web (p. 44) and 3.4 Provisions for the Future of the Desktop Model (p. 86) show remarkable similarities. The structural problems of the Web seem to have direct counterparts in the field of desktop interfaces, and vice versa. The main three areas are: reliable and efficient identification of documents, the demand for new concepts for groups of documents, and the reign of technical solutions.
Documents on a local desktop and Web pages have in principle the same structure. They are files that contain content that matters to the user. Of course, file formats are arbitrary. Different application programs use proprietary formats. This challenge for the application-centric model has been tackled for the Web. HTML is standard for Web pages. The format is platform independent and can be edited with any text editor, although WYSIWYG editing is more comfortable for the user. Data of arbitrary type can be encoded in XML structures. The Extensible Markup Language (XML) is a subset of the Standard Generalized Markup Language (SGML). Applications of XML are powerful enough to express any data structure in an open and flexible manner. XML files share platform independence with HTML files.

The robust identification of document files is unsolved for both domains. They suffer from weak concepts to identify entities of content. Hyperlinks between Web pages can break because the URL of the target page might change. Retrieval of documents fails, because the rational behind the file name turns out to be totally unintelligible. The documents are lost in the hierarchy of folders.

New methods are needed to reliably resolve documents – on local file servers as well as on remote Web servers. Tim Berners-Lee calls it the concept of location independence and explains [Berners-Lee 99, p. 159],

the appearance of the information and the tools one uses to access it should be independent of where the information is stored […]. Whether they are hypertext pages or folders, both valid genres of information management, they should look and feel the same wherever they physically happen to be. Filenames should disappear; they should become merely another form of URI. Then people should cease to be aware of URIs, seeing only hypertext links. The technology should be transparent, so we interact with it intuitively.

It is not desirable that everything looks like a Web site – especially not under the current usability flaws of the Web. The point here is that a layer has to be installed that is responsible for the reliable access to any document. It serves as an abstraction of documents from their storage. The user interface follows thereafter. Tools that scale from the personal desktop environment to the world-wide information space give access to a seamless field of data. Consistency in user experience between the extremes is the most important factor.

The second correspondence is the lack of flexible concepts to group documents. Once we have the layer of abstraction between files and documents, once we have a technical difference between directories and folders, new powerful concepts can be implemented for different kinds of relations between objects. In Cleaning up the User Interface [Berners-Lee 97] Tim Berners-Lee proposes a new conception for folders. They should evolve into a new type of hypertext document. Placing a document into a folder would just establish a special kind of relationship between the document and the folder-document. That means that a folder would be represented by an XML data file. The membership of a document to a folder can then expressed as a hyperlink from the folder’s XML data to the document.
The design and application of those new folders is independent from the technical implementation. Section 2.3.2 Groups of Nodes (p. 44) recapitulates the purpose of groups for hypertext nodes. Sequences and clusters represent guided tours and, for instance, Web sites as a whole. The corresponding section in the chapter on graphical user interfaces 3.4.1 Filing (p. 87) outlines some concepts for extended folder functionalities. Aggregation of hypertext nodes and grouping of conventional desktop documents should become the same.

Limitations on the technical side gave preference to the application-centered design model. The document-centered approach, although beneficial for the user, did not succeed. Applications for the Internet face a similar situation, because they have to follow the protocol first. Therefore Tim Berners-Lee argues for protocol independence [Berners-Lee 99, p. 160],

The next step would be protocol independence. Right now, every time I write something with a computer, I have to choose whether to open the “electronic mail” application or the “net news” application or the “Web editor” application. The mail, news, and Web systems use different protocols between computers, and effectively, I am being asked to select which protocol to use. The computer should figure this out by itself.

The user should have full sovereignty on her documents. She should be free to do anything she likes, whether it is editing, high quality printing, sending the document to a friend, publishing it on the Web, or filing it at several places at the same time. It should be easy to put the document in context. Robust hyperlinks to and from any part of the document should be possible. Also vague relations like Tognazzini’s piles or spatial proximity should be supported by new grouping concepts. It does not matter, where the resources actually reside. Web pages and local documents can be intermixed without any restrictions. Surfing the Web and accessing files on a local hard drive should have the same user experience. Larry Tesler’s idea of modelessness has to be applied to the two dogmatic competing modes Web and Desktop.

 For a free PDF version of Vision and Reality of Hypertext and Graphical User Interfaces (122 pages), send an e-mail to:   I’ll usually respond within 12 hours. [privacy policy]

à propos