Abstract 1 1 Introduction 2
Integrated Document Space Navigation Tools
Download 324.2 Kb.
|
- Navigate this page:
- 5.1The Basic Model: Data/State Sharing
- 5.2Document Space and Navigation Data
5Integrated Document Space Navigation ToolsEach document space navigation tool is designed and optimized for some specific task. It is not possible to meaningfully present all the information about documents at all the levels it might be presented at once. This is a result of the limitations of physical display devices and human perceptual abilities. While navigating, the need for information at any specific moment changes. To support navigation requires a combination of different presentations in an appropriate order. For example, it may be useful at the beginning to get an overview of a space -- to understand the structure of space. During traversal of space specific detail, obtained by zooming to some local map with more detail on objects, may be useful. A content viewer is needed to examine the content. This is a similar idea to the one in Spring, Morse, and Heo (1996) and consistent with Shneiderman's view that the user interface should provide “Overview first, zoom and filter, then details on demand” (1998). While it is possible to add many features into an application, i.e. to add a variety of document presentation tools, a user may not use these additional features. According to Albers (1997), learning new methods and options requires additional work and remembering. Users will work to optimize their cognitive resources rather than maximizing work output. 5.1The Basic Model: Data/State SharingWhat constitutes a tool is difficult to specify. Some tools have different presentations or “modes”. Some tools are generic, i.e. tools that are used by a variety of other programs. The term tool is referred to the latter type of object. Tools are modular programs that provide some special presentation, interaction and some special function. A coordinated group of tools will be called a system. Navigational tools use document-related data and a presentation or display of that data. Different tools may use the same data with different presentations or use the same presentation on different data. In terms of presentation, integration of navigation tools involves how different presentations can be viewed on a single screen or in a specific sequence. The integration will be concerned with multiple windows, graphical object combinations, and interaction schemes. At the code level, the integration of navigational tools is a matter of sharing or exchanging state data and content data between program modules. When the user is interacting with a system of navigational tools, tool state information, such as current position, will be of use in orientation when switching between tools. When the user is using a search tool, passing the search terms allows the system to provide result texts with query words highlighted in context. 5.2Document Space and Navigation DataTo this point, two types of data have been described -- document data and navigation data. One might imagine document data to be public and navigation data to be personal. One might further imagine document data to be stored remotely and navigation data to be stored locally. It is not hard to find counter examples for these cases. For example, link traversal or navigation data on a Web site might be collected to find high traffic paths. Similarly, file system data on a PC may be considered personal -- and only stored locally, etc. Below, some of the issues pertaining to document and navigation data are outlined: Local or Remote Data A document in local storage may be accessed faster than one in remote storage. Local storage access is more reliable than remote access, which depends on a network and server. At the same time, a user can use any machine to access remote data as long as that computer is connected into a network, while data stored locally is accessible only to one machine. Increasingly, it is a design assumption that system locations should be transparent for the user and application developer. At the current time, differences in response time still betray remote locations. The response time is dependent on both transmission bandwidth and delays. The delays may be from both network delay and server response time. This limits some design choices in an interface. For example, it is possible to avoid user frustration from the "HTTP file not found" error message by scanning all links on a page and removing "file not found" links before showing the page and its anchors. However, this approach would noticeably slow response time because of delays in determining link existence. There are many standard protocols related to sending document space information including HTTP, Z39.50, and NFS and AFS RPC calls. HTTP addresses document retrieval. Retrieval of sets of documents and having a server keep the state for the query to allow transmission of partial sets of records was implemented in Z39.50. Simple, fast, and robust access methods were developed in NFS and AFS. Navigation data is usually generated by a client or interface module in a distributed application. Commonly, the navigation information will stay local and be used only during a navigation session. However, navigation data such as personal bookmarks may involve all the remote machines that a user accesses. Shared or Private Data While private data may be local or remote, shared data most likely will be remote. In a multi-process environment, especially in multi-user document spaces, shared data may be changed by any of a number of users. Centralized control is needed to insure accurate data. While control is centralized, the implementation may be distributed. The key is that the control function is singular. For example, techniques for such control have been developed for distributed database systems. In client-server architectures, the server generally provides the shared data. Document space data is considered to reside on the server. The server provides mechanisms to maintain data integrity in a shared environment by various methods, including locking and versioning. Private data may be stored remotely at the server to provide availability across machines. In this case, the server needs to provide protection against unauthorized access. In a collaborative system, navigation information may be sent across program modules to other users. Many systems provide current viewpoints of several users in an interface, e.g. SASSE (Baecker, Nastos, Posner, & Mawby, 1993). In asynchronous collaborative systems, navigation information may be kept by the server to support group navigation. One of the problems with the centralized storage of navigation information is the large size of the information store that accumulates. At the same time, some information that helps the navigation process, such as a most recently visited place or most frequently visited place, are worth keeping. Processed or Raw Data It is useful to distinguish document metadata from document content. It is also true that there are differences in the representation of metadata and content. In most file systems, there is a specific command for reading file attributes and another command to read file content. In the HTTP protocol, GET will obtain the document while HEAD will retrieve information about the document. Needs for dynamic attribute data may be met by the XML standard, which will allow for the dynamic definition of the structure of a data set. At the current time, the interface still requires a priori agreement about the semantics of the metadata. For example, while file size can be treated as a simple integer, it can be also presented in kilobyte and megabyte units. Even if the simple semantics of dynamic data description can be managed, it is still problematic how a system accommodates this information. For example, HTTP uses the MIME type of a document to determine how to present a document. The presentation of a specific document type requires that the program to present the document be known. A generic scheme for presenting documents may be made available with the Common Object Request Broker Architecture (CORBA) type services. Download 324.2 Kb. Share with your friends:
|