One undergraduate and one graduate student were recruited to test this new interface using an abbreviated list of tasks aimed at discovering if users could find databases that dealt with format (newspapers), two topic searches on diabetes and depression, and an exact database title search. This testing revealed that many of the problems we were seeing did not stem from heuristic problems with design, but rather user expectations of function. The intrinsic problem of the database locator did not reside in its language and layout. Rather, it failed to function because, instead of providing users with a search box for articles, it gave them a series of difficult choices. Although the testers in this “quick wins” round did do slightly better than in the first round, the gains were not significant, and we decided to focus our remaining time on addressing the significant functionality problems without implementing any of the quick fixes.
Redesign
Our goals in redesigning the interface were to present users with a simple interface that could be navigated quickly, with few mouse clicks, and with minimal decision making on the part of the user. We wanted to work from the existing platform as much as possible; adjusting features to meet user expectations, or (in cases where that was impossible) eliminating features or otherwise minimizing potential pitfalls. At the same time, we did not want to remove features that had been employed successfully, even if only by a small portion of the population. The section below details the changes made to correct those problems identified though formative evaluation.
Misunderstanding of the Keyword Search Box
It was evident after reviewing query logs and testing users that the largest problem with the database locator stemmed from the keyword search box, which was consistently employed for topic-level searches. Barring installation of a federated search system, it was obvious that a keyword search feature would not be able to meet user expectations. Because users conducted very few keyword searches for broad subject disciplines, a decision was made to reconstitute the keyword search box as a title-only search box, relegating it to a secondary, tab-accessible page that provided for access to databases by name. This page would host the title-only search box as well as the full A–Z list of database names.
Poor Ranking of Keyword Search Box Results
The keyword search box did not respond with anticipated results, even when used correctly. Typing a database title in the keyword search box, for instance, often did not bring up that database first. The old search algorithm matched partial substrings and often presented search results in a surprising relevancy order. The revised search algorithm, tailored for searching database titles, uses a left anchored, word-delimited search that ranks matches at the start of a title higher than matches within the title.
Unintuitive Subject Pull-Down Menus
The subject grouping option was the most promising method of database identification for novice users or others without knowledge of database titles in their research area. These, we surmised, constituted the largest body of users and therefore “by subject” navigation was chosen to receive prominence in the interface. The pull-down menu display for subjects was not ideal because it worked well only for users who correctly guessed where subjects would exist under the broad subject categories. It was a barrier for those who did not, for example, know whether psychology is considered a science or a social science. The team was able to emphasize and simplify subject browsing by displaying all subjects in an alphabetical list. This change was consistent with Nielsen’s heuristic “recognition rather than recall.” Subjects continued to be based primarily upon UConn’s Programs and Majors in Schools and Colleges, a model familiar to our primary user group and also one that fit on a standard-size monitor without scrolling. Several changes were made in the list of subjects to accommodate cases where licensed databases fell outside of any subject area (in several cases subjects were added for format types) and to remove subjects that had no subject-specific databases.
Overwhelming Lists of Databases
To reduce the complexity of decision making previously required in database selection, we decided to initially only present the top five or fewer “best bets” databases for the subject area, relevancy ranked. Because all subject descriptions were rewritten, the five “best bets” easily fit on one screen. A more comprehensive list of “all databases in this topic” was linked to from the “best bets” list. To further enhance navigation of databases by subject, we added a new subtopic construct that enabled specialized subsets of databases to be displayed upon request. For instance, the subject Health and Medicine provides four “best bets” databases, with a link to a comprehensive list of twenty databases. It also provides subtopics for Cancer, Consumer Health, Genetics, and Quick Clinical Information. Each subtopic profiles databases specific to the subcategory. The creation of subtopics was driven entirely by availability of databases within subject areas and the need to organize them in manageable portions.
Overly Long Database Descriptions
All iterations of the database locator include both short and long descriptions of databases. The short description is displayed on the list of databases and provides a brief introduction to the content of the database; entries include the coverage dates of the resource when known. Users can also link to a more complete description of the database on a separate page, which conveys additional information about the database, including technical details, license information, and in-depth coverage of the database itself. Initially, the database descriptions were gathered from the vendor and varied greatly in tone, length, and content. For example, the original entry for ABI/Inform read:
ABI/Inform Global: Full-text articles from 1800 journals covering business, finance, management and related functional areas. ABI/INFORM Global indexes a total of 2700 major publications. Subject coverage includes: business and management, including all functional areas.
The team felt this language was repetitive and confusing to users and developed guidelines for rewriting the brief descriptions, which follow two essential elements: The text should be short (limited to 255 characters) and focus on the content of the resource. Coverage dates and technical notes are included on the list of databases, but they are set apart from the brief description. The content should not include the name of the database again, nor should it indicate the number of journals included. Following these guidelines, the ABI/Inform brief description now reads:
ABI/Inform Global: Articles in business, finance, management, accounting, advertising, banking, insurance, marketing, public administration, real estate, and telecommunications. 1991–current (full-text); 1971–current (index & abstracts).
In the first round of testing, participants frequently said that they would not read database descriptions; in later tests, with better design and textual changes, users made no such comments. While this does not prove that more concise descriptions are better, the PERM team is confident that briefer short descriptions are an improvement in usability.
Lack of Apparent Links to Databases
A surprisingly prevalent problem uncovered during testing was the inability of undergraduates to find the “Access this Database” link on the database description page. Description pages were presented to users after selection of a specific database was made. They included information about content and licensing and, for library purposes, had a click-tracking mechanism used to record database use. Of the twenty-one tasks completed by undergraduates in testing, six failed because users could not find the link to the database from its description page. Our initial assumption was that the access point (a small button at the top of the screen reading “Access this Database”) was visually unapparent to users. However, when the “Access this Database” link was supplemented by an oversized, bright green button in the “quick fixes” design, the problem persisted. It was determined that the failure of the description pages was not as much related to their visual design, but in how users got to these pages in the first place— after selection of a specific database had already been made. Users expected to be taken from their selection into a database, not to a fuller description page. To create an experience more in line with user expectations, we implemented several changes to database lists. The first was to redirect database links to the databases themselves. A zero-second redirect allowed for continued click tracking without requiring users to interact with description pages. The need to offer longer descriptions and licensing information was accommodated by adding two links to each short description: “Details” gave an expanded description and “Terms of Use” offered database-specific license information. General licensing information was also added to the footer of any page that presented links to databases.
Additionally, as a measure to ensure successful use of the database locator, several user-assistance features were added:
- a “Not Sure Where to Start?” page (accessible by tab) that provided links to multidisciplinary databases;
- page headings;
- breadcrumbs (the trail of pages followed to reach the current page);
- links to database guides, when available, from database descriptions; and
- links to subject liaisons and subject guides from subject pages.