While I’m here….
We had another fight at work yesterday, and again I was the odd one out (which I guess technically also means I was the troublemaker).
We’re trying to get the interface for our federated search engine set up.
I’m going to assume, rightly or wrongly, that most of you don’t know what a “federated search engine” is. You know how libraries subscribe to all sorts of specialty databases that index the scholarly literature and sometimes provide the full text of articles? A federated search engine is a front-end that will search several of those proprietary databases at once.
The federated-search product we’ve bought allows two different types of point-of-entry. The first type, which we’re calling Basic Search and which we’re probably making the default screen, allows the librarians to predefine sets of resources from which the user can choose. These Quick Sets have the advantage of making sure that the user searches at least a few (probably) relevant resources, but they are by their nature limited. There’s an additional problem in that the Basic Search screen will only support about fifteen Quick Sets without forcing the user to scroll down. This means we’re having to lump all of the engineering resources into a single Quick Set, which really isn’t great.
We’re calling the second type of point-of-entry the Advanced Search. This screen allows us a lot more flexibility, as we can define broad subject areas and then break them down into more specialized sets of resources. We can, therefore, offer an Engineering subject area and then allow the user to select a Mechanical, Civil, Environmental, or what-have-you subset. Once a subject and subset are chosen, the user is then presented with a list of appropriate databases which can be checked for inclusion into the search.
Now, I’ve been wise enough not to say this to my colleagues, but the Advanced Search is a UI nightmare. There are (at least) two search boxes at the top of the screen, and each search box has a drop-down menu allowing the user to specify which field (Author, Title, Subject, plain keyword, etc.) is being searched for that box’s search string. This may sound complicated when described, but it’s really a pretty standard interface; the search boxes/drop-downs aren’t the problem.
Beneath those search boxes are three boxes from hell. Two smaller boxes are stacked in a column occupying about 1/6 of the screen’s width, and the third very large box matches the stacked boxes in height and extends across the rest of the horizontal screenspace. In the left-hand column, the top box contains the subject areas; once a subject is chosen, the related sub-topics appear in the bottom box. Once a subtopic is chosen, the related databases appear in the big box. Once those appear, the user must choose which ones he or she wants to search, as none are selected by default. In all of these boxes, the number of options exceeds the allotted screen space, so scrolling must be performed within each box.
In using the Advanced Search, then, the user must make make selections in three different areas of the screen before being able to execute a search. This is an ugly, confusing, frustrating interface, and it cannot be simplified further without sacrificing functionality.
Now, I haven’t told my colleagues that this is an ugly, confusing, frustrating interface. I honestly believe they wouldn’t see what is ugly, confusing, and frustrating about it. One of them is in fact actively campaigning for this to be the default interface, and the third is on the fence.
This wasn’t what the argument yesterday was about, though, at least not directly. This argument was a bit more philosophical.
One colleague, the one who wants the Advanced Search interface to be the default, thinks the Quick Set interface is not only insufficient but actively dangerous. She thinks the lazy searchers will come to rely on the predefined, inherently limited Quick Sets and so will miss out on material that might reside in a more specialized database that is excluded from the subject-generalized Quick Sets.
My position, as articulated, is that the people who will be using the federated search will be either advanced searchers who will click through to the Advanced Search option if their needs aren’t met by the Basic Search or are people who would otherwise be happy with whatever they found on Google Scholar (or, more likely, plain ol’ Google). Even if the Quick Set results aren’t the best results possible, they are better than nothing.
Left unspoken was the fact, or at least position strongly suggested by the literature on information-seeking behavior, that even the most advanced users are rarely interested in finding the best possible information but instead are looking for the first pieces of information that suit their immediate needs. I think I might have ended up with a black eye if I’d interjected that into the discussion.
So here are the two positions, really: She feels that we must not inculcate habits of laziness in people who will at some point need to perform at a level beyond what the Quick Sets can support. I feel that if we deliver a product we must design something that will be usable by a typical patron. She thinks I’m pandering to the greatest common factor, I think she’s letting the best be the enemy of the good. At base, our contentions are on orthogonal planes of consideration, her being concerned with quality and me being concerned with usefulness.
So, what do you guys think? Keep in mind that I tried to represent her position fairly, but I still probably presented mine more sympathetically.