next up previous
Next: A Prototype Link Lens Up: Improving Web Usability with Previous: The Link

Functional Implications

The possible improvements outlined above are more than cosmetic and raise additional functional requirements of the underlying system.

If the link is to be able to provide the user with meta-data, this information must either be provided by the referencing document's author, or be downloaded from the referenced document's server. The former approach has been applied in some specialised hypermedia publications [2]. However, our goal is to make meta-data available for a wider range of documents, and this is only achievable by following the download approach. To avoid this creating its own delays, two requirements must be met. First, the meta-data must be accessible to the client without downloading the whole document. Second, some kind of meta-data pre-loading or transclusion strategy is required so that it is available in a timely way to the user.

The HTTP protocol already supports client access of document parts through the HTTP-EQUIV directive. This allows authors to specify document tags which can be downloaded separately from the rest of the document and so HTTP already has the necessary hooks to meet the first requirement. The second requirement can be met by appropriate client side enhancements. There are a number of possible meta-data pre-load strategies. For example:

All the above pre-load strategies are assumed to operate automatically. It would be sensible, however, to allow user control over pre-loading, e.g., setting it on or off, and determining thresholds where appropriate. Yet another approach would be to give control of pre-loading to the referenced document's site. For example:

The accurate determination of download scope relies on knowing channel and site QoS. Obtaining real-time channel QoS data is problematic given current communication protocol limitations. The Hypertext Transfer Protocol (HTTP) is layered on top of the Transmission Control Protocol (TCP), which itself is layered on top of the Internet Protocol (IP). The latter does not support any QoS functions and so TCP cannot make any assumptions about factors such as latency or bandwidth. The only channel QoS related notion supported by IP is distance as measured by the number of `hops' between the sender and receiver [3]. Support for QoS is planned as part of an enhanced HTTP protocol [10], but in the meantime we must look to other solutions.

There are now several companies offering Web server QoS data on-line. Such data typically includes the number of hits per day, the average latency, and the numbers of broken links. However, we have decided to use a different approach which, though less accurate, does not assume the availability of site QoS servers. The link lens utilises the performance of the meta-data pre-load cycle to calculate channel and site QoS for each link. In the limit case where link pre-loading has not been completed before the user wants to have access to it, the link can simply be assigned a low QoS, leaving the user to draw his or her own conclusions.

Figure 7: The prototype link lens.

next up previous
Next: A Prototype Link Lens Up: Improving Web Usability with Previous: The Link
Rob Procter