So as Art and I continue to try to export the data from our respective Voyager catalogs to create an alternative web opac, I have been trying to formulate what such a beast should look like. We have the opportunity to make the web interface look and behave in any way we want, so there are a lot of things to think about. The goal is to make the opac behave in the way non-information professionals
would expect a searching interface to work, so we're not just talking about a cosmetic makeover to the current design.
We just had a professional usability study done on our web site and services. The results were rather sobering. While not every aspect of our web presence is bad, a great deal of it is, and, worse, the bad parts are generally the most important
. Making the situation even more complicated is the fact that a lot of these awkward interfaces are not under our control (the databases, ejournals and opac). Well, not currently
under our control.
I'll skip over the part about our website (we're able to fix that pretty easily) and write about what they recommended for the catalog. The first screen they gave us was a redesigned search form. An interesting dialogue came out of that:
Usability Expert: Ok, so this is the search form...
Librarian(s): So... is this the simple search form or the advanced search?
Usability Expert: This is the search form.
And it really is as simple as that. It is a text input field that, by default, would do a keyword natural language query on the catalog, or you could add limits and filters (title, author, subject, etc.) or make a more sophisticated boolean search using the exact same form
The other screen they showed was a full record page for a journal. It was extremely well laid out, but I noticed that it had a lot of visual clues in the page
that item you were looking at was a journal
. This is another incredibly simple feature. Different types
of resources can have their own layout based on what is logical for that type of resource
. Also, we could conceivably display electronic holdings from SFX in our opac interface, so the user doesn't have to click on the SFX button (or generic 856 link) and open the SFX window to see if an issue is available electronically. We could also, at this point, give recommendations of other
resources that might be valuable (such as A&I databases that this particular journal appears in).
The usability study was extremely useful for looking at the opac through non-library eyes, but with a view focused on making things more useful.
Last week I began trying to visualize how to lay out search results. The initial design, I think, will look something like:Your search for "Ernest Hemingway" resulted in:
167 Total Items :: 102 Books :: 50 Videos :: 2 Journals :: 13 Audiobooks :: 1,072 Items from GIL Express
With each of those being tabs to view different types of resources (plus a link to our state union catalog at the end). The goal is to be somewhat A9
-ish, but I can't say I'm a huge fan of the column
I am, however, a huge fan
of the folksonomy. I definitely plan on implementing user-supplied subject headings. We want to implement a del.icio.us
style social bookmarking/citation management system here anyway (probably using unalog
), and it seems like this would fit in quite well with that. I wouldn't actually expect users to just add "tags" to things without some sort of personal gain, so if it was incorporated into a "bookbag" system, it might actually get used. Although the idea of just leaving breadcrumbs around the opac (and databases) might be useful if they don't want to clutter up their bookmark pages with a ton of items. This is something that we can play around with. Mark Leggott talks about adding folksonomic support in the University of Winnipeg's alternative opac project, as well
. Interestingly, I had no idea Mark was working on something like this (rob caSSon
, at the University of Miami, Ohio, is also working on a similar project. Miami and Winnipeg are both III sites; perhaps they should get in touch with each other).
Over the weekend (yes, I get a touch obsessed about my job), I began thinking about the utility of displaying dust jackets in the opac
. When I was designing a new books list application at Emory, it seemed "obvious" to include dust-jackets in the results. I mean, that's what Amazon does and it's user-friendly, right
? Well, while I was thinking about it this weekend, I started wondering how useful this really was. What is the purpose of showing the dust jacket? It certainly won't help the user much if they go into the stacks to find the book... we rebind everything in those boring red/green/gray/"khaki" bindings, with no indication of what the original dust jacket looked like. If anything, this seems like it might be more confusing to the user.
Something that seemed so "obviously necessary" in a modern opac 12 months ago now seems pretty frivolous and would just add unneeded clutter to what will probably already be a fairly cluttery interface.
I'm sure this design will continue evolving, but it's got to start somewhere.