Implications of Default Search Options in Ejournal Platforms

In my last post, I reviewed a handful of ejournal platforms (and one ebook platform) to see what default options were available that affected whether the search results would show all content or only the content the library had licensed or purchased. I also wanted to see which platforms let the user change the settings for available content. There were some platforms that I think did this the right way by letting the subscribing library choose what the default search mode would be and by also giving users the option to override that default at the search page and on the results pages. Only JSTOR and Project MUSE offer this kind of flexibility. At the other end of the spectrum of flexibility and usability were platforms where neither the library nor the user could change the default settings that were set to show all content (Wiley Online Library is like that).

There are a range of platforms in the middle where the user can change the search mode to include only licensed content. A few vendors like this have communicated by various means (on posts in the ERIL mailing list or in support tickets back to me) that users tell them they want to see all the content or that some subscribing libraries prefer it to be that way. I find it a bit galling that some vendors disdain letting their customers choose what’s best for their own community (i.e., letting the subscribing library make that decision about search defaults based on what is known about the users in that community). User preferences at a large research institution (especially the preferences of the faculty and graduate students) are unlikely to be same as those of students at a community college or a small 4-year school. If anyone is going to have an understanding of those local user preferences, it’s going to be the subscribing library, not the vendor.

It’s worth taking a moment to consider the pros and cons for making all the content visible on these platforms. If the default setting shows users everything, they can avail themselves of the link resolver in the interface to track down full text (on the off chance the library has it elsewhere). If the link resolver fails to find the full text elsewhere, it should present the user with an interlibrary loan option, which would likely satisfy many users (except those who are in too much of a rush or can’t be bothered with the process). On the other hand, link resolvers can be unreliable and fail to lead users to content that the library may actually have. Furthermore, some platforms won’t even let you integrate your link resolver into the interface or they way that they let you do that is poorly done. In the article record view on some platforms, the link resolver button or link is minimized at the expense of the publisher’s own set of buttons and options to purchase the article (one can wonder about the intentions of vendors in making some of these design decisions that prioritize purchase options). No librarian is happy when a reference interaction starts off with the user saying, “I found an article on your database and now it’s asking me to pay $55 for it.”

At this point, some of you may be wondering why I’m making such a big deal out of platforms that most users only find themselves on temporarily. Users will find a record for the article in a discovery service or in an aggregator database and then wind up on the ejournal platform after a series of clicks on a link resolver (or a direct link if they’re lucky). After the user has found the full text and acted on it (read it, downloaded it, decided it wasn’t worth bothering with, etc.), they are more likely to go back to the discovery service or the aggregator database to continue their searching. It is far less likely that a user who has gone that last mile to get to the full text would then start new searches there.

With respect to the array of database options that an academic library can display on their website via an A-Z databases page, it is not uncommon for that library to skip listing all of the ejournal platforms, especially if the number of journals they actually have on a given platform is small (ejournal holding are likely to be accessible via A-Z journals pages, link resolvers, and catalog records). So it’s not like the users are going directly to these ejournal platforms in droves to begin the search process (some exceptions to this are JSTOR and ScienceDirect, which are well known by users and commonly featured on A-Z database lists on the library website).

Despite the fact that our users may not be spending that much time on these ejournal platforms, let alone consciously deciding to go there after viewing a list of database options on a A-Z list, these platforms really should offer more customization to the user and to the subscribing library.