Interfaces and database-specific features

I've been concerned for a while about how many of our search interfaces handle (or do not handle) the special features of specific databases. For example, I was helping someone with ERIC the other day, and needed to limit the search by educational level. I went to look for the list of mandatory educational level descriptors, and ultimately had to go to our printed ERIC thesaurus to find them listed in a comprehensible fashion. Just to see if there was any good way of figuring this out online, I tried typing “secondary education” (one of those mandatory educational level descriptors) into the online thesaurus in the three versions we have access to see if it would note the hierarchy of these descriptors. Interestingly, “junior high schools,” “high schools,” and “high school equivalency programs,” the narrower terms for “secondary eduation” in the list of the mandatory educational level descriptors, show up only under the list of “related terms”. The scope note for the term “secondary education” does say “Also appears in the list of mandatory educational level Descriptors,” but I couldn’t find such a list in our online versions. And I’m not sure what a user without extensive knowledge of the database structure would make of such a message.

This all seems pretty arcane, and I wonder if there is any way to make this structure clear to most users; through the interface. After all, limiting by educational level is something one often wants to do in this database. Currently, I wonder if they would even suspect that there might be a systematic way to do this. How can we get vendors to build in these special, database-specific features into their interfaces, in ways that make it obvious what is going on, especially when the feature is so important, as it is in this case? Will the development of faceted interfaces help?

4 Replies to “Interfaces and database-specific features”

  1. I share your concern. I’m wondering whether the trend towards the one-box search of multiple target databases, and the commonly voiced belief that “people” just want to find “something quickly” has led to a situation where the ability to support more refined search techniques gets lost. My feeling is that different people have different kinds of information needs, and librarians should advocate not only for users seeking simplicity, but also for those with more sophisticated information needs.

  2. This is one of the classic dichotomies of reference service: quick and easy or slow and sophisticated. If we only had one kind of user, the choice would be simple. However, we need t oserve both types of searchers. Designing systems for only one style makes it difficult for those who need more (or less). Publishers and vendors have a tough time gauging the level of their products for this very reason.
    This same problem carries over to the reference transaction itself. Some users want a quick answer and some want a comprehensive search. Some want us to find it for them and some want to learn to do teh research themselves. It is the reference librarian's job to figure out which user wants which style — and to respond to those requests appropriately.

  3. I completely agree with the concerns expressed in the original post as well as Cindy and Dave's comments. It should be a no-brainer that database providers and vendors should offer at least two, if not three, levels of search options to accommodate the varying needs of library users and those of us who serve them. There are those who worry that sophisticated search options, utilizing the rich metadata characteristic of “traditional” databases such as ERIC, may cease to exist if present trends toward keyword searching in simple, Google-style boxes cause providers to conclude that more advanced options are no longer needed.
    See Jeffrey Beall's article on “Search Fatigue” in American Libraries, March 2007, pp. 46-50, which seems quite relevant to this post. His concern about Gresham's Law–the bad driving out the good–is, I think, well placed. As Beall says, we must “explain to searchers the great value of metadata and metadata-enabled search engines. Perhaps by doing this we can save metadata-enabled searching from the extinction to which it is now heading” (p. 50). Indeed. If that extinction were to happen, the implications for the exhaustive yet precise information access needed by scholars, advanced students, and certain other users, would be profound.

  4. I wonder if this is only a matter of serving the advanced user. Certain features (such as limiting to a specific educational level in ERIC) are pretty basic to the way people use these databases. I suppose the novice user could enter (and doubtless does enter) some phrase such as “high school students” instead of using the mandatory descriptors that are in place to perform this function, and will probably get some random articles, but is this really the way we want to serve our users?

Leave a Reply

Your email address will not be published. Required fields are marked *