1. Evaluation and Evolution: More on Rooms, Resolver & SingleSearch at Leicester Janet Guinea Jonathan McGowan

2. 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

3. 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

4. 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.

5. 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

6. 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

7. 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

8. 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

9. 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!!!!!!

10. 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

17. 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

18. 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.

19. 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