We briefly discuss our design for the ADL WP interface,
focusing on the issues raised above.
The major part of the WP UI is based on an HTML form, as shown in
Fig. 2 
, which
contains sections for interacting with a map browser,
a catalog, and a gazetteer,
as well as a set of control/configuration and help/glossary links.
Rather than basing this design for the UI
on a particular set of user scenarios,
it was designed around a state transition model.
Each state represents a
Web form or page, some of which include partial or complete query results.
Figure 2: Web user interface ``mockup''.
The preceding model supports standard methods for querying the catalog, such as starting with the base map or gazetteer to select an area and then querying the catalog for information within this area. However, other paths through the state model extend the functionality of the library to novel uses. For example, a user could bypass the base map and gazetteer, leaving the default area defined as the entire world, and query the catalog for air photos from 1960 to 1970. Then, based on the resulting footprints denoting the catalog entries, the user could select the region of the world corresponding to the highest density of air photos within this time interval. This allows the user to select geographical areas of interest based on the library store, rather than always starting with a given geographical area. Although past usage patterns (observed at existing map libraries) generally start with an area specification, it is difficult to know if this is due to the non-digital interface through which most geographical data are now acquired.
Within the map browser section of the main form, each base map image is dynamically generated by a Common Gateway Interface (CGI) application based on user requests. We currently use a modified version of the Xerox PARC Map Viewer [http://www.parc.xerox.com/map/]. The Map Viewer supports zooming, panning, and feature selections. We have added several new functions to the Map Viewer, including generic labeling, fast panning, and overlaying graphics objects on a map. The region of the base map which is visible in the map browser is called the display window. As explained below, this window is not necessarily the same as a query window, which consists of the Earth coordinate boundaries used to limit a query. The base map also serves as the background on which we overlay footprints of the results of various queries. The catalog section allows users to enter thematic and temporal search terms for the display and browsing of objects that are in the ADL catalog.
The UI supports the primary function of the base map and gazetteer, which is to allow the user to define spatial extents or regions for catalog searches. The user can either zoom and pan the base map to an area of interest or submit a gazetteer query with a given place name and feature type. For example, a gazetteer query with the place name set to ``Ohio'' and the feature type set to ``hydrography'' will yield a query window whose Earth coordinates bound the Ohio River, but not the state of Ohio.
By default, a gazetteer query is spatially bounded by the current display window. Thus, if the current display window shows the USA and does not contain Europe, a gazetteer query with the place name set to ``Paris'' will yield a query window around Paris, Texas and will not include Paris, France. The display window will then be changed to show an area slightly beyond the query window around Paris, Texas. If the result of a gazetteer query is several unconnected regions (all of which, by default, must lie within the original display window), we contract the display window to show the smallest bounding box that encompasses all query windows returned by the gazetteer. So, for example, if the display window is set to the entire world and one queries the gazetteer with ``Paris'', both Paris, Texas and Paris, France are returned, and our display window will be a fairly large portion of the world map, as described below.
Catalog queries are bound by the query window(s) shown in the display window, rather than by the entire display window as a whole. Since our UI allows for automatically piping the query windows resulting from the gazetteer search directly through to the catalog search, we do not, by default, enlarge the query window to include the entire display window. Using the above example, one would probably not want to include footprints of satellite images of Maine after asking the gazetteer for ``Paris''. So instead we allow for several query windows within a single display window, and thus pass to the catalog a separate query for each bounding region within the display window which was returned by the gazetteer.
After a user submits a query to the ADL query engine, the query engine converts the user query to different catalog-dependent internal query syntax (e.g. SQL, ConQuest, and Z39.50) and performs the search on local and remote catalogs. The query engine returns the search results to the UI for display as an HTML table. The format and content of this table is also user configurable. Users can then select a subset of items returned by the query to get the full metadata documentation, to project selected footprints onto the base map, to view ``browse'' or ``thumbnail'' images (see below), or to down-load data objects.
The search result set contains a set of metadata information for each data item (library holding) that matches the user query. The metadata contains both text and images. In particular, two types of metadata, footprints and GIF browse graphics, can be displayed as images in an HTML document. A browse graphic is a low-resolution image of a data item, similar to the abstract of a textual article.
Frequently many more search results are returned from a catalog query than can be shown intelligibly on a relatively small display map. When footprints of multiple data items are displayed on the same map, it is difficult to distinguish which footprint is associated with which item. We are currently experimenting with many heuristic approaches and visual aids (such as clustering and labeling) to find a reasonable way of displaying footprints.
In particular, a heuristic is required for deciding which footprints returned by a query are to be displayed on the base map. This selection criteria must be configurable by the user, who may want the decision to be based on chronological order, total area covered, or other attributes. Our current default heuristic is based on the footprint weighting, where is the percentage of the query window that is covered by the footprint and is the percentage of the footprint that is contained in the query window. Thus, if the query window is defined by, say, California, less weight is given to world maps and maps of Santa Barbara than is given to, say, a map of the California/Nevada area.
Some of the ``best'' footprints are often those that lie just outside, but very close to, the query window. Thus within the UI and corresponding CGI's, we maintain two sets of bounding coordinates. The first set defines the display window, and the second set keeps track of one or more query windows, as previously discussed with the ``Paris'' example. Once we know the coordinates of the query windows returned by the gazetteer, the dimensions of the display window are calculated such that approximately 75% of the visible area envelopes the query windows. This allows footprints that contain the query windows to be displayed in the display window. The user can change the ratio of the two areas.
The query form is dynamically generated based on user preferences and selections. The initial UI presents a set of default query forms and parameter settings suitable for the general user community. Experienced users can click on a configuration button to invoke the CGI script ``Query Form Generator'' (QFG). The QFG creates a query form configuration page with which users can customize the query form to fit their particular needs. The QFG lets a user choose a set of attributes, logical operators, and heuristics to be used within the query form.
The Alexandria WWW system maintains all user configuration parameters, query statements, and current query result sets with a combination of client side and server side state parameters. On the client side, ``hidden'' form variables within the HTML document and the actual URL are used to keep track of state information. Part of the URL contains a ``cookie'' which is a unique session identifier. Thus every request coming from a particular user is associated with session information stored in a server-side session database. Upon request, this session information can be written out as hidden variables to an HTML document, allowing a user to save all customization and history parameters to a local file. This page can be opened later to return a user to their previous state. Keeping limited session information allows a user to re-use their customized query/display environment without reconfiguration, and browse through a result set without a redundant database search. Maintaining user state also allows progressive delivery of large data objects. In particular, network traffic is reduced by displaying wavelet browse images and using multi-step image enhancement.
Displaying vector or wavelet data is another important
issue in our implementation. It is unlikely that any existing
publicly-available Web browser will support vector or wavelet
data types in the near future. This problem can be solved by
helper-applications (either stand-alone or with
NCSA Mosaic Common Client Interface (CCI)), or by programmable browsers
such as HotJava. Due to HotJava's
current availability only on SUN Solaris and Windows NT, we have
decided to develop helper-applications for vector and
wavelet data display. The helper-application approach
creates a minor distribution problem and a major porting and support
problem, since every ADL client site must install our
programs in order to view vector and wavelet data
contained in the ADL catalog. We are therefore tracking
the availability of systems such as HotJava.