The Link

To provide the user with appropriate information about the link, it is necessary to identify an abstraction -- or perhaps a layered set of abstractions -- that can explain its behaviour [8]. Our chosen link abstraction has two elements. The first is the channel, a communication resource which connects two (or more) computers together, and allows information to flow between them in either direction. If we restrict our notion of channel to the overall connection between the browser client and the document server, we have a concept that is synonymous with the communication associated with a download. The other element of our link abstraction is the site, a resource for despatching documents provided by the server. A channel and a site can now be associated with a link, and their properties can be presented to the user as affordances for understanding link behaviour.

The key property of a link is its QoS. Definitions of link QoS for multimedia applications cite several contributing factors [10]. For the Web user, however, the key QoS criteria is time. In simple terms, what the user wants to know before initiating a download is the delay before the download is completed. For the link, this can be defined as a function of site and channel latencies and channel bandwidth. Latencies reflect server and network congestion causing competition for these resources.

A full link time affordance, however, must also provide the user with information about the task in progress. The concept of time affordance is informed by users' subjective desire for closure, the knowledge that a system task has been successfully completed. Until this is evident, users will tend to monitor the task, assessing its progress and preparing contingency plans should they determine that it has failed. Lack of adequate time affordances may mislead users, for example, causing them to terminate the task prematurely.

According to Conn, a complete time affordance should meet eight requirements, representing information about distinct task properties [4]. We confine ourselves here to those where the link user interface is particularly deficient, and discuss ways in which an enhanced link might satisfy them. Some of the solutions we propose raise functional requirements which are addressed later.

Acceptance:

Acknowledgement that the task has been correctly specified and is executable. Arguably, this is essentially a null requirement for browsers if the task `specification' is defined syntactically as simply the act of pointing at any visible anchor. However, in so-called direct manipulation interfaces, syntactically acceptable action specifications have an implied semantic correctness [24]. For example, a document's visibility is proof of its existence. In the case of an anchor, however, this relationship between visibility and existence may not hold.

Improved satisfying of acceptance requirements could be achieved by server and document status information being available when the user is in the act of specifying the download task. This is the most timely moment to provide this information and resolves the inconsistency between visibility and existence.

Scope:

Measures of task scale, including predicted delay before completion. This requirement is not satisfied by the information provided through the link user interface. It may be partially satisfied by contextual information provided by the author of the referencing document, such as the referenced document's size.

Download scope is a function of the referenced document size and the link QoS. Satisfying scope requirements implies that these factors can be determined in advance of the download being initiated, In practice, however, only the document size can be accurately determined in this way -- given suitable functional extensions.

Link QoS figures should take into account the effects of caching. Caches were introduced to exploit locality in users' document downloading behaviour. For example, there may be a cache on the user's (client) machine and a cache on a local proxy serving a number of users. If a document has been previously retrieved it could be available on these caches. A cached document will almost always download more quickly than the copy on its server.

Progress:

Clear feedback as execution of the task proceeds, including its rate of progress. This requirement we consider is only partially satisfied. Although a progress indicator is maintained during the download, it is often difficult to relate the information it provides of the task state to its subsequent behaviour. One reason for this is that a document which may seem to the user to be a single entity may actually be composed of many embedded parts (e.g., images) each of which will trigger its own download process. The order of these embedded downloads is non-deterministic. In most browsers the progress display area is time-multiplexed between these separate downloads, making it impossible for the user to maintain a coherent picture of the overall download progress [17].

An example of an improved link time affordance is shown in Figure 6. The graph shows site QoS information and the predicted download scope. Download progress is indicated by animation of the document media content display in Figure 5. There is also a map display (accessible via the Location tab) which shows the channel as a physical connection between the user's client and the document server. Its colour is used to represent predicted channel QoS (ranging from blue for poor to red for good).