The document discusses best practices for database web pages and usability testing of those pages. It provides examples of how different universities structure their database pages, including landing pages, A-Z lists, subject pages, and individual database records. It also summarizes the results of surveys on how academic libraries design these parts of their websites. Usability testing tips and examples from other libraries are also presented.
1. The Front End Design of & Usability for ERM Data Amy Fry, Electronic Resources Coordinator Bowling Green State University http://personal.bgsu.edu/~afry/
2.
3.
4.
5.
6.
7.
8.
9. Type of system Homegrown: 71.1% *Percentages are based on 114 libraries (excluding 7 national/special libraries and 4 libraries whose databases pages were behind a login) Kent State University Type of system # of libraries %* Homegrown 81 71.1% Metalib 14 12.3% Innovative 8 7% LibGuides 4 3.5% Xerxes 4 3.5% WebFeat 2 1.75% LibData 1 <1%
10. University of Missouri-Columbia Types of access # of libraries % Databases A-Z 111 97 Databases-by-subject lists 91 80 Full resource records 83 73 All three 73 64
11. Order of subject lists University of Connecticut Subject list order # of libraries % By relevance 38 41.8% By format 7 7.7% Alphabetical only 46 50.5%
12. Libraries using icons or graphics: 64 (56%) Use of icons and graphics Icon # of libraries Access restrictions 38 More information 27 Full text 9 Magnifying glass (Metalib: search in database) 5 Tutorials 4 Funding source 3 Format (audio, etc.) 3 Plus sign (Metalib: add to a set) 2 Social media 2 Metasearch 2 Logo/screenshot 2 RefWorks 1 New 1 Plus-star 1 SFX 1
16. Survey Question 9 What types of information are currently collected in your library's ERM system and to whom does that information display? Check all that apply. Answer Options In ERM? Display to public? Display to staff? formats Databases 14 8 13 Electronic journals 12 5 11 Electronic books 8 4 7 “ public” info Resource descriptions 14 7 12 License information (permissions) 14 6 13 Coverage dates 6 5 6 Resource advisories 7 5 7 Trial information 8 2 8 Tutorials/user guides 5 2 5 “ library” info Vendor/contact information 12 1 10 License information for ILL/fair use 11 4 10 Login/passwords 10 0 8 Renewal information 9 0 8 Purchase approval information 4 0 4 Payment history 4 0 4
17. a: author b: resource format c: tickler log d: subject e: description f: public note g: user support h: coverage i: incident log j: access information k: resource advisory l: usage statistics m: administration n: note o: connect button p: resource id q: not used r: local contact s: pricing and payment t: resource name u: trial or trial info v: resource type w: resource contains x: alt. resource name y: resource url z: resource mgmt tickler Resource records at BGSU
19. Fields in resource records Important Confusing Not needed Most important fields Description 14 0 1 Dates 10 1 0 Full text 7 1 0 Most confusing fields Mobile access 0 10 3 Coverage load 2 6 1 On-campus access 1 4 0 Least important fields User support 2 2 3 Mobile access 0 10 3 Local contact 4 1 2
23. change to Databases A-Z change to Databases by subject Remove search box change to Videos & Images add Film, Television & Media Studies
24. Database title Contains Notes Access for mobile devices Alternate on-campus link Tutorials & help Add a connect button Journal titles in this database Dates included View this title
25.
26.
27.
Hinweis der Redaktion
We have three goals for this part of the day: Exploring our options for our public databases webpages and taking a look at what other libraries do with them Exploring our options for full records for databases and looking at what librarians and users find important in them Talk a little bit about doing usability testing on our webpages and tips for planning successful usability projects And while this is an ERM forum, it’s important to realize that you don’t need an ERM for any of this – or, rather, whatever you use to manage this information IS your ERM.
So what do I mean when I say the front end? When discussing databases webpages, libraries often include four chief elements: a landing page, which includes access to the other three types of access
An A-Z list of databases to help people navigate to known resources
Databases-by-subject pages, which are meant to facilitate choosing a database when you don’t know what to choose, or to show what options are available in a particular field
And full records for databases, which typically contain more information about a resource than can be contained in either of the list formats. If you think about your own library’s website, you probably have at least a couple of these of these types of webpages for your databases, if not all four kinds, managed either by an ERM or other commercial software like LibGuides, or managed by homegrown software.
When we were thinking about restructuring our databases webpages, which are generated by the Innovative ERM, I decided to look at the websites of all 119 ARL libraries to see what their approaches were. I looked for the presence of all four front end webpages I just mentioned, what kind of software they were using to generate these pages, what they called the link on their home page into the pages, how they arranged their databases-by-subject lists, and whether or not they used visual elements within their records.
My approach was bolstered historically by other similar website surveys of ARL libraries and their findings.
So here’s what I learned. Most libraries are still using homegrown database-driven systems to generate their webpages for databases. This is software Kent developed several years ago. This means that most libraries are maintaining separate software for this purpose and maintaining information about their resources both here and, most likely, in other places too, whether that means an ERM, the catalog, LibGuides, etc. The reason for this is that transitioning to another system is time-consuming and staff-intensive and disruptive for patrons, but also because homegrown systems do what we want without the shortcomings of commercial software. For example, using Innovative for this purpose, we don’t have a lot of control over a lot of the elements of our public webpages, and customization of them is extremely cumbersome. However, I think we’re going to see more and more libraries getting away from the build-it approach as services like LibGuides get easier to use, or as more libraries start using open-source solutions.
Almost every ARL library – 97% - maintains an A-Z list of databases, and the vast majority also provide databases-by-subject lists. This supports the idea that we believe that our patrons are still for the most part navigating to known resources rather than searching for them. When we did usability testing on our databases webpages last winter, most of our participants used the databases portal to click through to known resources, and almost none of them thought to type the resource name into the search box on our home page, though doing so would get them that resource at the top of the results list every time. We’re now implementing a discovery layer, Summon, so it will be interesting to see if discovery layers change how users find databases, but lists are a familiar approach for now.
For libraries that have offer databases-by-subject lists, the majority are just in alphabetical order, but a surprising number of libraries are making an effort to order lists by relevance. This example is from Uconn, which also did a terrific usability study on their databases webpages that was published in 2010. They not only order subject lists by relevance, but limit the initial screen to only five resources, with the option to display all for that subject with an additional click. I have not seen any usability testing that proves this is a better approach for users, but you have to think that our patrons are really used to relevance ranking, at least in response to free-text searching online. We are not able to offer this because of the limitations of the Innovative ERM, but I wish we could.
Another thing I think users are really used to seeing are images, and I love the University of Missouri’s approach to lists, which includes a screenshot of the database search screen in its lists. A slight majority of ARL libraries use at least some images, most often to indicate access restrictions,
As we see in the University of Cincinnati’s list here.
The last point I want to make about this is – it’s OK to call our databases databases and, in fact, more ARL libraries use this term than any other in getting students to their databases pages. In our usability testing, our users did not have a problem using our databases link to get to our databases lists. I was afraid when we asked them to find articles on a subject they would use our e-journals link, but few did. Not all students may know what databases are, but it’s a term both we and their professors use to describe these resources. Students do NOT know what e-resources are.
There are a wide variety of approaches to presenting full records for databases, from Wright State’s minimal approach with descriptions, dates, and related databases, to ours at BG, which includes tutorial links, contact information, permissions, and coverage information.
Last summer we asked libraries in OhioLINK what information they included in their ERM records. Descriptions, permissions and vendor contact information were most often included, while information on purchasing, payments and tutorials for users were least frequently used. We also asked libraries what information they displayed to the public, and learned that most libraries in Ohio chiefly use ERMs as staff tools. As you can see from this listing of responses, libraries display far more of this information to staff than to users. This is probably because libraries are already using other systems for their public webpages and have implemented ERMs to manage information for staff, even though this approach duplicates work.
At Bowling Green, we include twelve of the 26 possible variable fields in our resource records in the public display, and use an additional nine fields for staff only.
Last winter we asked 15 users for their feedback on these records, asking them to look at a printout of the resource record fr Business Source Complete and circle information they thought was important, put question marks next to information they thought was confusing, and cross out information they thought was unnecessary.
Users most often circled descriptions, dates and the words full text; were most often confused by our links to alternate access (mobile and on-campus) and the coverage load information; and, though they rarely chose to cross anything out, decided links to tutorials and local contact information was the least likely to be necessary to include in the records. From this, we can conclude that Wright State’s minimal approach to record building actually covers most of the bases necessary for users, so if you were worried about not having more complete records, you shouldn’t. Descriptions and dates actually are important to users and help them decide whether or not they want to use a resource.
This was part of a usability study we did on our home page and database pages. We talked to fifteen undergraduate and graduate students. From this timeline, you can see that the entire project did not take a huge amount of time from planning to completion – we began it in December and were finished making recommendations last May. The most challenging part of our testing was actually designing the tasks we used and testing them to make sure they would give us the information we were looking for.
For this, these were our most useful sources: Steve Krug’s don’t make me think, Lehman & Nikkel, and foster and Gibbons. Foster and Gibbons is an extremely exhaustive and groundbreaking study that used a staff anthropologist to design research around students’ use of the University of Rochester Library. But a usability study does not have to be that involved in order to be effective, and, really, any time spent talking to students is useful. We took a very minimal approach that used minimal staff time, minimal technology (we used free software to record audio but did not film our sessions, use screen captures or set up a usability lab – instead, we relied chiefly on old-fashioned observation and detailed note taking), and minimal analysis – putting data into spreadsheets instead of exhaustively transcribing each session.
We did make changes to our records and webpages based on the feedback we got from students. For example, we learned that our Images and Media category was equated with media studies, not videos, so we changed that and added a category for media studies that we called film, television and media studies. We also removed the search box on this page which allowed users to search for databases by title, because we did not observe students using it for that but did observe them typing topical searches into the box and getting no results.
We revised some of the wording on our records and added a big orange connect button because some users did not recognize the hyperlinked database title as the link to get into the database and search it.
Then we did some follow-up testing by grabbing students in the main entrance to our student union and revisiting some of our tasks to see if the changes we made helped them be successful.
The testing we did was overall not difficult and very worthwhile, and you can do it too! It was easy to get funding for incentives (in our case, $20 gift certificates to Kroger or the bookstore) from our dean’s office; easy to recruit participants (we didn’t do anything complicated like Facebook or even campus newsppaer ads, which we discovered were surprisingly expensive; most of our participants came from the flyers we hung up in the library) and we didn’t fuss with too much technology, instead focusing on developing a good testing instrument and listening and observing carefully when we were with the students themselves.
We would have done some things differently – for example, I wish we had been more committed to making changes to our databases pages before we began. We were not able to make any desired changes to our databases A-Z list. However, sometimes administrators and IT staff will not realize changes are necessary until you gather the data, so this may be impossible, as well. We’ve not been able to really assess the impact of the changes we made – for example, are our students using the film category and the connect button? I would need help sifting through Google Analytics data to learn this and don’t have a plan to make this happen. Also, we haven’t done any follow-up testing since last summer, though I suspect that is on the near horizon for us, as we are currently implementing summon and will want to do testing on that this fall.