Evaluation and Evolution:More on Rooms, Resolver &

SingleSearch at Leicester

Janet GuineaJonathan McGowan

One Year On…

• New skins • Usability testing• Guidelines and best practice• Involvement: Library staff/University

publicity• Resolver/eLink maturity• SingleSearch in progress• Rooms pilot live in October 2005

Usability Studies

• 2 usability studies: March (main study) and August

• Academic staff, postgraduate, library staff volunteers, undergraduate, foreign students:- rewards!

• Facilitator and observer

• SingleSearch tested in August study

• Feedback throughout the pilot

Usability (March)• Overall very positive• Welcomed the use of images• Eye automatically goes to top left, so make sure most important

information is located there• Too much text• Navigation not obvious, especially from home page• Some items have positive and negative feedback e.g. predefined

searches.• Non-standard University branding • Browser/accessibility issues• Many people not aware of the subject pages in their present form!• Suggestions for further resources to include being received.

March conclusions

• satisfactory level of usability, but can be enhanced by addressing certain issues

• unfamiliarity of the interface = training and experience• greater level of consistency in our Room building

required• design of the banner and terminology may need to be

revisited• tab names should be consistent between rooms where

possible• Using SingleSearch - make the nature of the search

clear to the user• accessibility - JAWS software enables users to use the

pages. Some work required

Guidelines/best practice

• Consistency – e.g. Welcome tab + image• Tab arrangement/pane names• Alphabetical versus logical debate• Skin choice• Link text standardised• Metadata: subject/description controls - keywords• Embedding websites: permission/rules• HTML guidance • Sharing content modules

August Study

• Most people impressed by Rooms

• Generally unaware of efforts to organise content alphabetically or in any other logical sequence

• SingleSearch: Usability tasks and questions must be considered carefully

Integration

• iLink implemented August 2005• Rooms referenced on each page• Search results links to SingleSearch:

SINGLE_SEARCH_URL• Search result links via ISSN to eLink: OPEN_URL• Catalogue > GoogleScholar > eLink:

SEARCH_ENGINE_URL_PT1|http://scholar.google.com/scholar?q=|

• Migration: Rooms2/EPS in summer 2006

SingleSearch – In the Beginning

• What does it do?• Who is it for?• Is SingleSearch any use in an Academic

Environment?• The potential of a configurable Metasearch

engine• The threat to librarians everywhere!!!!!!

The Plug-in Problem

• The architecture of SingleSearch• A modifiable front end supporting search modules or

‘plug-ins’• You want how many plug-ins?• Plug-ins are configured by Muse not locally• Limited configuration options• Inconsistency of changes by both MUSE and Database

providers• Authentication

The Athenian Question

• Authentication is the biggest issue• IP verification works due to resident server• Server IP for search and client IP for result

linking• Athens databases are a problem• Athens authentication is not supported• Session id cookies also present interesting

difficulties

Where we are now

• The service is live but not hugely publicised• SingleSearch does provide an exceptional resource• Much Electronic content specific to academia is available • SingleSearch does provide a metasearch service far in

advance of Mamma, Metacrawler or Dogpile• SingleSearch is no threat to subject librarians but should

be pushed as a web search starting point• Future advances overcoming authentication difficulties

and incorporating OpenURL links from the delivered results will provide a truly superb resource.

Resolver/E-Link

• Resolver is a resounding success• We have had a lot of positive feedback• It is still being pushed as an A-Z• Updates occur monthly• There are issues with some of the data provided

by the suppliers• More suppliers are providing support everyday