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.

Options and Defaults for Showing Only Licensed Content in Ejournal Platforms

Depending on the interface and system you’re talking about and depending on the user type you’re talking about (the casual searcher who needs just one or two sources quickly or the dogged searcher who needs an expansive search set), it’s an interesting question about how to handle default search options that control whether results show all possible results or just those your library has immediate access to (via subscriptions and purchases). In time that I’ve been a librarian (since 1999), academic libraries typically offer their users:

  • a catalog that only shows the library’s collections (or maybe a union collection where materials can easily be requested and quickly delivered)
  • A&I databases that rely on link resolvers to get to full text where possible and ILL services where access is not available
  • aggregator databases that pull together full text content from lots of different publishers and may also include records where only abstracts are available
  • ejournal collections from various publishers where all or part of the collection has been subscribed to or purchased

Added to that mix are discovery services that try to bring together records from the catalog and records for articles that the library has full text access to. Commonly, those discovery services will also let the user change the search mode to find article records for which the library has no full-text access. In most cases, libraries can go into administrative options for their discovery services and aggregator databases and set default search settings that control whether search results show all content or just the content the user has full-text access to. Typically, the search interfaces give the user a way to override the defaults at the search box (sometimes at the basic search box, more often only at the advanced search box) or on the search results pages.

The search systems used by ejournal collections, though, seem to offer libraries and their users far less control over default search setting or the ability to refine search to only available content. In this post, I want to review some of the ejournal platforms (and some ebook platforms) we have at Baruch College and spotlight the ones that give librarians who administer these systems and searchers who use them a measure of control over what should appear in the search results.

Cambridge Core

Admin options: Subscribing libraries have no way in the admin options or by submission of a support request to change the default search to show only results for available content.

User options: Checkbox main search page to limit to “Only content I have access to.” Same checkbox also shown at top of facets on search results pages.

Cambridge Core search screen showing checkbox

Cambridge Core search screen showing checkbox

Emerald Insight

Admin options: No way to change default search behavior.

User options: Only the advanced search page and the search results pages offer a way to “Include” “only content I have access to.”

Emerald Insight advanced search screen showing "Include" option

Emerald Insight advanced search screen showing “Include” option

JSTOR

Admin options: I don’t recall how we set this up (maybe via a support ticket) but we were able to set defaults to only show available content.

User options: Advanced search page and search results pages let you change the “Access type” from the default “Read and download” option to “All content.”

JSTOR "access type" options on the advanced search page

JSTOR “access type” options on the advanced search page

Oxford Handbooks Online

Admin options: There isn’t a way in the admin options or by means of a support request to change the default, which shows all content.

User options: The search results page is the only way to change from the default of showing all content to just the “unlocked” content.

Oxford Handbooks Online search results page with availability options

Oxford Handbooks Online search results page with availability options

Oxford Journals

Admin options: There isn’t a way in the admin options or by means of a support request to change the default, which shows all content.

User options: No way to just see content the library has.

Oxford Reference

Admin options: Same interface as Oxford Handbooks Online (but different URL). By default, search results limited “By Availability” to “Unlocked” and “Free” content. I don’t know how this get set up (it’s not an admin option).

User options: The search results page is the only way to change from the default of showing all content to just the “unlocked” content.

Oxford Reference checkboxes to "Narrow Your Choices" "By Availability"

Oxford Reference checkboxes to “Narrow Your Choices” “By Availability”

Project MUSE

Admin options: By default, we have it set to show “Access” to “Only content I have full access to.” We had to submit a support request to get this set up.

User options: The advanced search screen and the search results page give the user the checkbox to change the default setting and show all content.

Project MUSE search screen showing "Access" option

Project MUSE search screen showing “Access” option

ScienceDirect

Admin options: There isn’t a way in the admin options or by means of a support request to change the default, which shows all content.

User options: The advanced search screen offers a checkbox to “Refine your search” to “Subscribed publications.”

ScienceDirect advanced search screen showing limiter for "subscribed publications"

ScienceDirect advanced search screen showing limiter for “subscribed publications”

SpringerLink

Admin options: There isn’t a way in the admin options or by means of a support request to change the default, which shows all content.

User options: Advanced search screen and search results page offer a checkbox where you can turn the choice to “Include Preview-Only content.”

SpringerLink option to deselect checkbox to "Include Preview-Only content"

SpringerLink option to deselect checkbox to “Include Preview-Only content”

Wiley Online Library

Admin options: There isn’t a way in the admin options or by means of a support request to change the default, which shows all content.

User options: None.

What’s Next

In my next post, I’ll summarize what I found from this quick survey of ejournal platforms and talk about the pros and cons of making all content visible.

Troubleshooting Electronic Resource Problems Reported by Students

Although my job title is user experience librarian, I help out quite a bit with managing electronic resources in my library. Over the past few years, I’ve gone down deep in the weeds countless times trying to figure out what went wrong when a user reported being unable to access an electronic resource. Some times it’s just one article, some times it’s an entire database. The possible points of failure (or confusion) for the user are many. Here’s an exhaustive list (for me, at least) of what commonly goes wrong for our users.

user names and passwords

  • entering the wrong user name and/or password (e.g., typos, misremembered logins, etc.)
  • not knowing what their user name and password is
  • not realizing that the resource requires you to create your own username and password
  • trying to access the resource by going straight to the resource via web search instead of using library’s link (that goes through some sort of authentication system)
  • user has logins for more than one institution in a consortium and uses the wrong one

authentication systems

  • trying to access the resource by going straight to the resource via web search instead of using library’s link (that goes through some sort of authentication system)
  • resource hasn’t been listed correctly in the authentication system (URL for the resource has changed)
  • resource requires some new special set up in the authentication system
  • user is from another library (that may be part of a local or state consortium) but doesn’t realize that resource is strictly limited to users at that specific library
  • authentication system is blocked by firewall/security settings on user’s computer or network

browsers

  • database requires specific browser (often Internet Explorer)
  • browser settings need to be changed to allow for specific functionality in the resource

licensing issues

  • user is now an alum and doesn’t realize off-campus access is now gone
  • license doesn’t allow walk-ins and/or alumni to use database

problems caused by the vendor

  • resource is down for all subscribing institutions
  • database is searchable but full text links no longer working
  • vendor has mistakenly shut down access for the library
  • vendor has intentionally shut down access for the library because of suspicious use or expired license
  • vendor hasn’t communicated changes in its holdings to services that rely on that information (such as knowledgebases that help libraries keep track of online journal access)
  • database has agreed to an unusual restrictive license from a publisher whose content is aggregated (e.g., EBSCO and Harvard Business Review)
  • library has cancelled subscription but forgot to remove all links to it on their website, catalog, discovery layers, knowledgebases, etc.

availability options

  • user doesn’t notice the full text links on a record
  • user unaware of interlibrary loan as a service option
  • user has found content that isn’t part of a library’s subscription in a database
  • user unaware that resource might be available elsewhere as open access (e.g., in an institutional repository, on the author’s website, etc.)
  • user has found book or periodical record in the catalog but doesn’t recognize that the resource is print only

out of date info in knowledgebases

  • library has incorrectly listed a resource as something that is subscribed to
  • journal publisher or database publisher hasn’t communicated to the knowledgebase vendor changes in holdings (I’m looking at you Gale)
  • knowledgebase vendor hasn’t yet updated their system with latest info from journal publishers or database vendors

OpenURL linking

  • database where citation-only record was first found failed to create a properly formed OpenURL
  • database that the link resolver menu sent the user to is unable to properly interpret incoming OpenURL
  • user didn’t notice link resolver option in the database (usually labeled locally as “Find it at [name of institution]”)
  • user didn’t understand what to do in the link resolver menu

URLs

  • user is trying to re-visit a URL saved from a previous session (instead of using a permalink)
  • permalink that the user got from the database results previously didn’t include URL syntax that would route it through the library’s authentication system
  • permalink that the professor put on the course website or the learning management system isn’t proxied

problems specific to ebooks

  • user expected full book could be downloaded
  • user didn’t realize complexity of getting started (such as registering for an Adobe ID)

problems specific to articles

  • user has a found a short article but mistakenly believes it’s not the whole article

Testing Embedded LibGuides Content on External Sites

At my library, we’re thinking of using LibGuides to manage our database lists for the redesigned library website. I’m just experimenting here to see how well the API from LibGuides works that lets you publish a box from a LibGuide on an external website. Currently, we use a homegrown database to manage the display of databases in A-Z and subject breakdowns on the library site. We also use LibGuides for the usual kinds of subject guides. To help my colleagues who make LibGuides feel confident that the database links they use are the latest ones, I have a privately published LibGuide that maintains a canonical set of URLs. When librarians create new LibGuides and want to link to a given database, they don’t have to copy and paste URLs; instead, they can create a link that has a URL that is mapped to the canonical one. If I have to update the canonical URL in LibGuides, then all the LibGuides that use that mapped URL will automatically get updated with the latest URL.

With no effort to customize the look of this box from my philosophy subject guide, here’s a box republished via API:

LexisNexis Academic To Release Interface Optimized for Mobile Web Browsers

As an update to my last post (“Apps vs. Mobile Web Optimized Interfaces for Search and Discovery”), I just want to make a quick note that LexisNexis has confirmed that their forcoming new mobile interface with LexisNexis Academic will be not be a dowloadable app but instead something that is designed to work in mobile web browsers.

I hope that they’ve designed it so that it automatically detects whether you’re using a browser on a phone and then redirects you to the optimized interface. Some of the database vendors that offer mobile browser interfaces require the library to set up a unique of URLs for the mobile versions, which means the number of links you have to maintain and provide to your user has doubled. As anyone who has tried to maintain electronic resources for a library knows, keeping on top of URL changes for those resources is a major time sink, as the links are usually spread across a wide number of pages on a library website.

Apps vs. Mobile Web Optimized Interfaces for Search and Discovery

I really wish the publishing companies, scholarly societies, and database vendors that are exclusively developing apps for mobile devices would rethink their preference for apps over interfaces that are optimized to work on mobile web browsers. Ever since Apple launched its app store on iTunes, web developers have been debating whether it is preferable to do a mobile web optimized site or instead release an app. Now that the vendors that libraries rely on for databases have earnestly entered the world of mobile design, there seems to be a lack of uniformity of opinion about the best way to proceed. Some companies have only released apps:

Others have only done interfaces that are slimmed down enough to work comfortably within a mobile web browser:

Some have hedged their bets and offer both apps and mobile web interfaces:

Some notable vendors have yet to release their mobile service yet. LexisNexis Academic will have a mobile interface this summer, though I’m still not clear if it’s an app or a mobile browser interface. ProQuest’s new platform for it’s databases is supposed to have mobile browser interface, but I haven’t seen it yet (I’m not sure if it hasn’t been released yet or if it requires you to switch over to the new platform, which we haven’t yet done in my library). Having tried most of the apps and web interfaces for the products above and having thought about how my library will promote them to our students, I’ve come to the conclusion that for the moment, the mobile web experience is superior to the app one. Here are the reasons why I’m not a fan of the apps I’ve seen.

  • Apps have to be downloaded. The user who wants to find something has to first take the extra step of installing an app.
  • Apps have to be updated. I don’t know if the apps that the library vendors will provide will require as frequent updates as the other apps on my phone, but even having to do it at all is an extra annoying step for our users to periodically follow.
  • Clunky authentication. Users have to do things like fill out a form with their app and get an email back from the vendor with a special code to be entered into the app. Other apps have to be “paired” up while the user is on the library’s or college’s network.
  • Idiosyncratic authentication. It’s hard enough getting our users to enter some sort of user name/password combination for most of our databases they access via regular web browsers, but at least it is a consistent experience. With apps, we’re expecting our users to get used to a variety of authentication schemes that vary from app to app. Furthermore, each app requires you to authenticate. If you use a browser to visit library databases (on a regular browser or a web one), you authenticate once that session and use as many databases as you want without having to re-authenticate each time you try a difference resource.
  • Apps take up space. Our library has huge ecosystem of databases. Do we really expect our users will want to use up valuable screen real estate and space in the phone’s memory with all the databases they may need?
  • Eclipse other databases. It’s already challenging enough to get users to recall that there are more databases than the ones with the easy-to-recall brand names (JSTOR, LexisNexis). A user who has downloaded a database app or two is going to be less likely to recall that there may be other, possibly more relevant, database options for mobile search. If you are looking at mobile optimized web page listing all the library’s mobile-friendly databases (perhaps sorted by subject, by title, etc.), there’s a greater chance they’ll use a wider variety of databases than if they’d downloaded an app or two.
  • App names often differ from regular web versions. Why should we add to the mental burden of our users by asking them to recall that what we call IEEE Computer Society Digital Library (an ungodly name to begin with) is the same as IEEE Xplore Mobile Digital Library (the former is the regular web version and the latter is the mobile app version)? Or expect them to know that buried in the sprawling app from Gale called Access My Library are the mobile versions of Business & Company Resource Center, Gale Virtual Reference Library, and more?
  • No link resolvers. I didn’t see any link resolvers in the apps. Admittedly, it’s not clear to me whether the link resolver we use (SFX) works properly in the mobile browsers I’ve used. Assuming that link resolvers can be made to work in the browser, I like that we can recreate the ecoystem of databases and link resolution that we have on the regular web. I don’t see how that ecosystem can be easily recreated in a world of mobile apps for each database.
  • Libraries can’t customize apps. The admin options that libraries are given to tinker with the look and feel of their web-based databases are not available with the app versions of databases.
  • Vendors don’t offer apps for all mobile operating systems. Very few apps come in versions for all the major mobile operating systems: iOS (for iPhones and iPod Touches), Android, and Blackberry.
  • Developing apps is expensive. The wish list of things I would like database vendors to fix or improve is lengthy. Spending precious time and money to develop apps is not at the top of my list. The cheaper and, in my mind, better option, is to develop for mobile web browsers first, as that lets vendors get their products onto a wider range of mobile device more quickly than if they were to take the time to develop apps for each of the mobile OSes.

I recognize that the vendors, publishers, and scholarly societies are just dipping their toes into the world of mobile services. I hope, though, that they don’t get carried away with apps and can recognize the limitations that those apps have right now.

H.W. Wilson Gets Swallowed Up

I was saddened to hear yesterday on the Against the Grain blog that EBSCO would be acquiring H.W. Wilson. While I have no doubt that Wilson was ailing financially for a while and wasn’t exactly winning any love for its interface, I do have fond feelings for the company for two reasons. First, one of the few things that I recall about my elementary school library from the early 1970s was being introduced to the Readers’ Guide to Periodical Literature. Second, while in library school at the Pratt Institute in the last 1990s, I went on a tour of the Wilson offices up in the Bronx. A a burgeoning library geek, I was thrilled to see cubicle farms where staff were actively indexing journals and magazines as we walked by. Even better, though, was the on-site printing plant that Wilson still maintained and was in operation when we visited.

Fewer database vendors means to me less competition and less innovation, bad news for those of us in the library world. Here’s the text of the email that went just went out moments ago to Wilson customers about the acquisition by EBSCO:

A New Future for H.W. Wilson

Dear Customers:

We have exciting news to share.  As you know, it has always been our goal to provide the best products and services to our customers, and we are dedicated to supporting the library community as a whole.  We will continue to uphold these objectives, and will do so together with EBSCO as we move forward. 

Effective May 31, 2011, Wilson has merged with EBSCO Publishing.  We have maintained a strong partnership with EBSCO through the years, and this joining marks an exciting new beginning that will be immensely positive for Wilson customers.  With more than 150 years of combined experience serving libraries and research needs, the strengths of both companies will come together to provide greater products and services – enabling us to take the Wilson databases to unprecedented heights, and together enhance the EBSCO databases as well.  As Wilson databases are added to the EBSCOhost platform, customers will be encouraged to transition to EBSCOhost, and you will begin to see the results of the combined effort of Wilson and EBSCO.

This partnership will enable huge strides for our companies in serving our customers, and helping you to support your end users.  We thank you for your business and loyalty through the years.  We look forward to serving your needs for years to come.

For questions that we anticipate will be frequently asked, please visit:  http://support.epnet.com/knowledge_base/detail.php?id=5482

Sincerely,

 

 


Deborah Loeding
Vice President, Sales & Marketing

 

Naming Conventions for Databases

One of the things I struggle with when thinking about the library website is how to name the databases and other online resources that we subscribe to at my library. My general principle is to have the database name on the library website match the way that the database names itself. In general, this means leaving the platform/vendor name out of the name we use on the library website. Rather than say “EBSCOhost Academic Search Complete” or “Academic Search Complete (EBSCOhost),” it makes more sense to just list it as “Academic Search Complete.”

I get that including the platform/vendor name as part of the naming system you use on the website may help those users who can’t quite remember the exact name of the database they were supposed to use or that they used once before. By offering the vendor or platform name (EBSCOhost, ProQuest, WilsonWeb, etc.) as well as the specific database name, we’re giving our users  more details that may trigger recognition. On the other hand, I’m more concerned that students be able to indicate the database name correctly in any citations that they include in a bibliography. In general, the style guides seem to suggest that you just use the database name. Many of the databases will generate citations for sources that you find, and those citations usually leave off the vendor or platform name.

This week, I noticed that a database we’ve listed as “Westlaw Campus” is probably more correctly referred to as “Campus Resarch.” Before I recommend to my colleagues that we rename the database on our site, I’m curious about how other libraries list that database on their library sites. If you’ve got 30 seconds, it would be great if you could indicate on this poll in Doodle how your library handles the naming of this database. I’ll do a post later where I summarize the results.

Librarians vs. Google: Fighting the Web Giant’s Book Deal – TIME

The library community recalls with horror the pricing fiasco that occurred when industry consolidation left academic journals in the hands of five publishing companies. The firms hiked subscription prices 227% over a 14-year period, between 1986 and 2002, forcing cash-strapped libraries to drop many subscriptions, according to Van Orsdel. “The chance of the price being driven up in a similar way (in the Google deal) is really very real,” he says.

I like the quote here from Lee Van Orsdel, who is the dean of university libraries at Grand Valley State University (MI).