Final Project Writeup:
(Assignment 10)
May 10 , 1999

Alison Brandt, Daniel McMahon, Katherine Falk

SIMS 213: User Interface Design and Development

Problem Overview

People with information needs requiring the use of bibliographic and other research databases often have difficulty finding and using the appropriate one. While universities make these resources available, they have trouble making them accessible. Providing an effective interface for database selection, particularly for the remote user with no human help at hand, is a significant challenge.

Library research databases are notably complex and heterogeneous: they vary in the kinds of information provided (citations, abstracts, full text, statistical data), types of sources included (articles, conference proceedings, book contents, dissertations), dates (span of years that the database has been in existence as well as span of publications dates for the materials covered), and the breadth and depth of subject matter. We have observed unclear labeling in existing systems, leading to unpredictability and usability problems. We have also seen quite a bit of inconsistency, especially in the type and degree of information provided in the descriptions of each database. Collections are rapidly growing in size and variety as publishers release new products and electronic versions of existing print products. Libraries have had to struggle to keep up with this growth, and haven't been able to take on the problem of providing a coherent integrated interface.

Solution Overview

The prototype interface we are designing attempts to address this problem by providing multiple points of access. From a single screen, one can browse the collection of resources using subject-based groupings or a more full alphabetical list. Users who know what they want to use can access it directly through a title select feature. The taxonomy and organization of the page seeks to match the mental model of the users and to accurately represent a complex body of information to assist the user with the selection process.

Tasks & Scenarios

Tasks Used for the Design Process

Using our original task analysis information, as well as our background knowledge in the (university) library domain, we developed scenarios to represent user tasks to help us during the design process. We tried to use realistic tasks, but it is important to note that we could never hope cover all types of tasks. (Users of this type of system would approach it with a nearly endless variety of information needs, which are impossible to predict.)

As we went through the design iterations, we used a series of scenarios. While they did not remain constant, there is consistency between them. In many cases, we used a large set of very short scenarios (about seven) for testing. (The various scenarios used can be found in our task analysis, low-fidelity testing, and 2nd prototype testing.)

Three Representative Scenarios

For demonstration purposes, we have distilled three scenarios that represent the range of tasks for which our interface might be used.

1. A known database search:
Armando wants to use the BIOSIS database to find articles on bovine spongioform encephalopathy (mad cow disease).

2. A search for articles on a topic, published around a particular time, in full text if available. Appropriate database turns out to be telnet-based:
Helen is writing a book on the history of women's education in the United States, and wants to find articles about Radcliffe in the 1970's, written around that time. She doesn't know what the appropriate source would be, but hopes that maybe it will include full text so she doesn't have to make photocopies.

3. A search for background materials on a broad, historical topic:
Derek is about to begin a large research project on the history of the women's suffrage movement. He doesn't know much about the topic, and so wants to start by reading an overview.

Storyboards Showing Use of the Interface

1. (Finding BIOSIS) There are three main ways for Armando to find this database.

1a. Key "bios" or "biosis" in the title select box, click "GO"->BIOSIS

And Biosis appears alone on the title search results screen.

Or:

1b. "Science & Technology"->"Biology & Zoology"->BIOSIS

1c. "All the Databases"->scroll to "B's"->BIOSIS

Armando might also use one of the resorting options before he found it (although this would not be the most efficient method.)

2. (Women's education) If Helen knows about the ERIC database, which covers Education topics published beginning in 1966, she might proceed much as Armando did in the above example. If she did not, she might do some browsing around. Examples:

2a. Retrieve the "Social Sciences" list...

...scroll to "Education" and select "ERIC"

Or:

2b. "All the Databases"->"sort by subject"->scroll to "Education"->ERIC

Other databases in the current data set that might be appropriate (although less so) would be Contemporary Women's Issues, Current Contents, maybe others.

3. (Women's suffrage) If Derek has experience doing similar projects, or if he has received good advice from his professor or a librarian, he will do the most efficient thing, which would be to go to an online encyclopedia.

3a. Select "All general reference resources" (or "Encyclopedias") ...

...and scroll down to the encyclopedia of choice (Britannica in this case).

Or:

3b. "Encyclopedias"->Britannica (or Cambridge or Columbia)

3c. Another way (which would be less efficient but would lead to more in-depth information) would be to choose "Pathfinder" and search for a library book on the topic. A less productive method, although proved in testing to be equally likely, is that he would click on "Social Sciences", look for something there, and perhaps become frustrated. That said, if he happened to choose one of the full text multidisciplinary databases (which are not in our data set yet), he might find something useful fairly easily.

Design Evolution

How Our Interface Changed, Initial Sketches through Final Prototype

Paper Prototype

	Original version of the front screen. The top bar is provides basic navigation within the site, as well as links to help and password-only services. The main window is divided into two primary categories. Under "Catalogs and Reference" are links to university catalogs; general reference materials (encyclopedias, dictionaries, etc.; and guides. "Online Research" has links to electronic databases in the categories "Arts & Humanities" , "Social Sciences", Science & Technology" and "All the Databases". An additional set, "Top Ten" was originally part of this version. At the bottom is a search box to allow users to search for a database by subject keyword.
	The revised front screen, with distracting colors removed. There is also a link to an "Advanced Search" feature.
	Advanced search screen. This screen was designed to allow the user to search for databases by keyword (based on subject descriptors), by dates covered, and by type of content (full text, abstracts, or just citations). We abandoned this model, because it proved to be incompatible with user expectations and behavior.
	Search results screen. Results are arranged in the order of "UC Only" indicator, database title (with links to the web and/or telnet versions underneath), subject description, coverage dates, original publication format, and scope (citations, abstracts, fulltext)

Working Prototype: Version 1

The front screen. As a result of feedback from users during the low-fidelity prototype testing, we eliminated the "Top Ten Databases" link because it was confusing. The navigation bar has been simplified and now contains only links to "Library Home", "Catalog", "Help", and "Contact Us". (The Login feature was also confusing, and couldn't be easily implemented at this time in any case) The layout of information is otherwise very similar to what it was in the paper prototype. An important exception is the search box, which now only provides search for a database by name, not subject. There is also a link to display only databases containing fulltext.
The original list of electronic reference resources. This page was not generated by us; we linked to it within our navigation frame. It is a long list of resources, each described with a paragraph.
List of reference resources. We created our own list of references and added them to the database. This list is substantially shorter than the library's own; much was culled. The layout is the same as for the database results pages (see below), with the exception of the date column. Reference titles are in alphabetic order.
Listing of Social Science databases. The links in the green bar at the top of the page are not operational at this point. We discarded the "UC Only" indicator, since it didn't seem to be useful. Results are now arranged in the order of "Full Text" indicator, "Name" (which links directly to the resource), "Short Description", "Dates", and "Full Description and Instructions".
Successful search result screen. In this case, this was a search for the ERIC database. The column layout is identical to that of the normal database listing screen.

Working Prototype: Version 2

	Front screen. As a result of the evaluators' comments from the heuristic walkthrough, we modified this screen to emphasize the library contents while de-emphasizing information about the library itself. This approximately one-third/two-thirds column layout puts links to library hours, locations, contect information, etc. on the left. All research links, including catalogs, are now on the right. The search box remains, but we rewrote the instructions slightly to simplify them.
	Reference resources screen. The green bar on the left has been modified to indicate that all reference materials contain fulltext. The empty "years covered" column still appears, however.
	Alphabetic listing of Arts and Humanities. This is the default format for results listings. Note the "See instructions" link in red under the database name; this appears wherever a resource is particularly difficult to use or is available by telnet only.
	Subject-sorted results screen for Arts and Humanities. Clicking on the "sort by subject" link in the green bar brings up this screen. Multidisciplinary databases always appear at the top, and are followed by subject categories in alphabetical order.
	Search error screen. This appears when the user types an entry into the search box on the front screen that doesn't match any of the database names. It shows what the user typed in and explains the problem, followed by a list of search tips. At the bottom of the page is a link back to the home page and to the list of all databases arranged in alphabetical order.
	Description/Instructions screen. The top block of text replicates the layout of the results screen. The "Contains" field normally indicates the types of materials in the resource, it appears here in error and has been removed in subsequent iterations. "Description" includes more details about the electronic research. The "Available via Telnet" section includes instructions and a link to the resource.The "Back to database list" link at the bottom takes the user back to the results screen via a dynamically generated reference.
	Fulltext screen. This screen appears as a result of clicking on the "show fulltext sources only" link in the green bar. It's a short list, and generates an error if clicked on in the "Arts and Humanities" listing.

Working Prototype: Version 3 (Final)

The front screen. Some further refinements were made to the front page. The spacing was changed to delineate chunks of text while keeping the page vertically compact, so a minimum of scrolling is necessary. The word "journal" was added to the description of research databases to increase user understanding of the databases' scope. Finally, the picture of the Campanile was added.
List of all databases. Significant changes here include changes to color including switching the blue and green columns. This was done to make the "Descriptions/Instructions" links on the right side more readable and eye-catching. Icons were added, including the fulltext icon shown here. The default "all databases" page remains in alphabetical sort order.
List of all databases by subject. Clicking on the "sort by subject" link at the top redisplays the entire list of results, but grouped into subject disciplines with headings marking these. "Multidisciplinary" databases, those that cover many topics and therefore have broader interest, appear at the top. (The following subject disciplines appear in alphabetical order.) A header including internal links to these sections appears at the top. A usability problem that we recognize, but cannot address at this time, is the fact that some of the subject headers don't actually link to anything on the page. However, in time, the system would be expanded to include databases from these areas as well, and this problem would vanish.
List of reference resources. The reference sources section was "weeded" and rearranged to highlight broadly useful tools. The rearranging included moving the encyclopedias to the top, (above dictionaries and almanacs), and placing Encyclopedia Britannica at the top of this section.
Listing of Science databases. In the "Arts & Humanities", "Social Sciences" and "Science & Technology" lists, the databases appear in the discipline-grouped sort order. At the top are the internal links to the sections, including "Multidisciplinary", "Biology & Zoology", "Engineering & Computer Science", etc. The added telnet icon can also be seen on this page.
Description/Instructions screen. The color was changed on this page to match the list pages, with blue on the left. Otherwise, this page was not changed in this version.
Catalogs page. In this version of the prototype, the pages that are linked to from the top-framed menu were added. This included a catalogs page, containing links and descriptions of the Berkeley and University of California catalogs, as well as other local and national catalogs.
Contact Us page. This page allows the user to send an email message to a librarian. Many libraries provide this service, to make librarians more accessible to users. Librarians could help users with the database selection process, for example, if the user was unsure about where to begin their search.

Major Changes From Our Initial Design

De-emphasizing "search" in favor of "browse": Initially, we wanted to provide some simple keyword/topic searching of the database descriptions. However, people consistently interpreted this feature as allowing search of the database contents. So we discarded the advanced search page entirely, and, while we left a search box on the bottom of the main page, we tried to clearly label it as a way to find a resource by title only.

Reorganization of the front page: we originally divided up the collections, putting reference materials, catalogs, and periodicals on the left, and the databases on the right. It became clear over the course of this project that this arbitrary division didn't make sense. We have placed a list of library-related links (hours, guides, etc.) on the left, but the main library content is available on the right, which fills two thirds of the screen. This seems to be a more task-oriented layout.

Information and navigation design: We created layers of information, presented to the user well thought out chucks. In an effort to simplify the list pages, make them more scannable and less overwhelming, we introduced the "description/instructions" pages. We introduced graphical elements to help with conveying information. We added flexibility of information display through sorting options.

Better error prevention: We rewrote our error messages to give better information to the user. An unsuccessful title search leads to a page of hints, with a link to a more detailed help system. In addition, the help link at the top of every page brings up a small window to the help system which is large enough to read, but small enough not to completely get in the user's way.

Changes Based on Pilot User Testing

1. Resource listings default to sorting by subject rather than alphabetical order
2. Added the word "Journals" to the front page
3. Reorganized the "References" page so that encyclopedias are at the top of the page
4. Added search tips for the title-searching box
5. Reworked the fulltext sort and display functions
Added internal links to major categories on retrieval pages (references and subject sorts)
6. Replaced "FT", "Telnet-See instructions" and "See instructions" with color icons

Usefulness of the Various Evaluation Techniques

The initial, paper-based evaluation was far more useful than we expected; despite the abstract nature of the testing materials, we were able to rule out implementing a time-consuming and probably useless feature (advanced search). Our testers were very good at sharing their thought processes and search methods with us.

The heuristic evaluation occurred when our project was more fully developed, and the comments were in reaction to an actual system, rather than to our vaguely defined paper prototype. As such, they were far more concrete. There were some issues that came up, such as how to deal with problems that didn't neatly fit into the 10 heuristic violations, and how to give and interpret severity ratings. However, we did get several valuable pieces of advice at this stage, especially regarding the error messages and the layout of the front page.

The user prototype evaluation was in some ways the most ideal; it was our chance to have our system evaluated by the kind of people who would use it. In practice, it is difficult to select the exactly right evaluators, especially with such a small pool of testers. However, the exercise of observing people actually use the system was extremely valuable. While it didn't yield any major changes in direction (and this was probably a good thing), it did give us the clues we needed to make the system that much more usable. At this stage, we decided to implement icons and significantly refine the resource listing displays.

All of these methods were valuable. The low-fidelity testing helped us to identify changes to be made to the design of the functionality of the site, the heuristic evaluation helped us to make a fundamental layout reorganization, and the pilot test helped us to fine-tune the interface. Upon this reflection, it seems that the low-fidelity testing was the most valuable, as it was here that we were able to catch the most grievous errors. However, it seems to us that this is not necessarily a reflection on the technique, but rather the fact that it was early in our design process. The size of the errors found seems to correlate with the stages of our project development; they became smaller as we got further along.

With this in mind, the method that we were happiest with in terms of its value for improving usability was user testing using scenarios, because it best replicated actual use of the system. This testing process could be repeated over and over, continually refining the interface.

Final Interface

Description of Final User Interface Design

Our interface consists of a few main components, with some variations:

The front page: Like all pages in this site but the help section, this is a frame-based layout. The blue bar at the top is for basic navigation links: "Library Home", "Catalogs", "Help" and "Contact Us". The main frame is divided into a one-third/two-thirds column format. The left side dedicated to basic library-related information (hours, locations, guides, etc.) The right side is the initial interface to our site's functionality: Except for the links to Pathfinder and Melvyl, each link is actually a "canned" query to the flat-file database of electronic resources. At the bottom is a simple form to allow people to locate a database by typing in its name.

The database listing pages: These consist of dynamically generated pages in a columnar layout, with one record per line. The leftmost blue column contains icons indicating the presence of fulltext where available, the next white column holds the title of the resource, the yellow column has a short description, the white column after it has the years covered by the database, and the blue-green column on the far right has links to the full description and instructions. The navigation bar at the top of the page has an additional feature: resorting options for the results, with the currently active option highlighted in red. The user can click on the resorting options at the top of the page, the description/instructions link, or the title of the resource itself to get to it.

The individual resource description pages: The row at the top of the page echoes the layout of the columns on the listing pages, with the same information and links (except for the description/instructions column, of course) Underneath is a paragraph summarizing the resource, with links to instructions where available, and to the resource itself.

The catalogs page: This page provides links to the major UC catalogs, as well as to other catalogs that campus library users would be likely to find useful.

The help page: This section not fully functional (the links don't actually go anywhere); however, it does represent the kind of user-sensitive help we would like to implement. The topics are both contextual (related to the search task at hand) and general (related to general issues around using the library). It is designed to be prominent but not obtrusive, and can be dismissed with a click.

The contact page: This page provides users a way to ask a question or otherwise get in touch with someone at the library.

Description of Functionality

Chart of script flow. Resources are sorted and displayed by display type ($scope) subject headings ($list), and title ($title). The user can choose to view all resources or a subset of them in alphabetical or subject order; subsets are "soc", "sci", "art", "refs" (and the refs subsets) or "fulltext". Any query that does not match the contents of the database leads to one of two error pages.

This is an actual working system. (Some of the features which are not as central to our system are not fully implemented or are not under our control, like the library information links on the left side of the front page, and the help system.) When you click on one of the resource headings on the right side of the front page, the link is actually a canned query to a flat-file database. Similarly, the "sort by subject"/"sort A-Z" links, as well as the "description/instruction" links on each of the pages are links to the database. Although there are dozens of records, there are only a few static web pages—the rest are created on the fly.

What We Left Out and Why

There were some design ideas that came up during the process that we particularly liked, but that we did not include in the prototype because it was not feasible to do so within the time available.

These included alphabetical "jump" lists; other possible methods to browse resources such as pull-down menus; additional modifications to the top navigation bar; additional categorization of resources; and integration of other resources such as electronic journals.

In addition, there are some larger trends and issues that we are aware of, but did not address in this prototype. Most notably, cross-database searching is on the horizon, and quickly becoming a reality. Any web-based interface to library resources will need to incorporate this feature. Nevertheless, we feel that the need to help users to select specialized tools will remain. This is discussed more fully in link to paper for 290.)

We used only a minimum number of "Wizard of Oz" techniques, since Dan was able to program a substantial amount of the back-end functionality. Some aspects of the interface, most notably the help system, are obviously quite skeletal and not fully functional.

Tools We Used

We generally worked with production software, rather than prototyping tools. We used Dreamweaver for the initial design and layout of all web pages, and used these as the basis for the pages generated by the CGI scripts. Graphics were created in Photoshop and Illustrator. The logo was adapted from a photograph we took of Doe library. The scripting to search the flat-file database and to generate the results pages was done with a basic Perl module called Sprite.

The fact that we were working with tools we had used in previous projects was a big help, as did the fact that each of us had expertise in different software, allowing us to divide up our tasks evenly and integrate the components of the project fairly smoothly.

Problems with the tools included the fact that the Sprite scripts and flat file databases are a very limited solution. Sprite's documentation is poor and maintenance is difficult. In addition, script performance is slow on the SIMS CGI server, Portent. The lag for processing and page rendering is between five and fifteen seconds. (Our database began with five fields per record, and grew to 19. Sprite can handle up to 2000 records, so the slow performance of our prototype is unrelated to the number of fields per record, or records in the database, at this scale.)

This system would be insufficient to power a production model of this site, but it was good enough for prototyping purposes. For a real-world system, an Oracle or Sybase database, with some scripting in Perl or another CGI language, would be preferable.

Roles of Group Members

Most of our work was done as a group, although there was some specialization.

Group work:

• Overall design issues
• All user testing
• Report writing and HTML conversions

Back to Final Project Cover Page

Back to I-LIDS Home Page