Electronic Outages

What Broke, Who Broke It, and How to Track It

Jennifer Wright

Jennifer Wright (jennywri@umich.edu) is an Information Resources Assistant at the Hatcher Graduate Library, University of Michigan.

Manuscript submitted June 26, 2015; returned to author for revision August 25, 2015; revised manuscript submitted October 24, 2015; returned to author for minor revisions December 23, 2015; revised manuscript submitted January 22, 2015; accepted for publication February 5, 2016.

As electronic books and electronic journals have become more prevalent, so too do the number of electronic resources outages related to those resources. This paper, distilled from a presentation delivered at the 2015 American Library Association Midwinter Meeting, describes the implementation of a new tracking system for electronic resources outages at the University of Michigan (UM). It elaborates on the decisions that went into building the system and the insights gleaned from analyzing a year’s worth of outages. It is hoped that such data might better inform decisions related to electronic resources at UM, and that its collection might inspire similar data-driving tracking elsewhere.

The landscape of electronic resources available to institutions is large, and ever-growing. As the number of resources increase, so do the kinds of technologies used to access those resource and the number of things that can go wrong with that technology.

After years of relying on email and anecdotal information to track electronic outages, the University of Michigan’s (UM) Library’s Electronic Access Unit (EAU) took a more concerted approach in 2013, working with the collaboration of their paraprofessional colleagues in the Electronic Acquisitions Unit and the Electronic Cataloging Unit. Managed by an electronic resources librarian, the paraprofessional staff in EAU developed an outage framework for the FootPrints ticketing system, which enables the team to track when electronic resources (e-resources) fail and under what conditions, with far greater precision than was previously possible. Additionally, FootPrints’ extensive reporting capabilities enable more detailed analysis of e-resources outages and their causes, which analysis we hope to use to inform future purchasing decisions.

This study examines outages that occurred between June 2013 and June 2014. EAU sought to determine patterns based on outage type and vendor. The team also sought to highlight areas where it might improve the ticketing system to better capture types of outages missed in the initial implementation. Although Footprints was implemented spring 2013, this study begins in June of that year to allow for time to become familiar with the system.

Literature Review

Libraries are aware of the problems endemic in electronic resources e-resources (e-resources), particularly journals. Donlan notes that “even when e-journals are part of an aggregation (a standard package of titles as opposed to an individual menu of titles from one provider) ) there can be problems with establishing correct holdings data. Content providers drop journals or lose them to competitors, so the end date for a journal run must be established in the link resolver’s knowledge base for the OpenURL to ‘know’ where a particular issue is available.”1 Such issues are hardly minutiae of concern only to staff member on the backend of the system, for as Donlan notes, “Nothing is more frustrating to a user than to click a full-text icon that leads to ‘web page not found’ or ‘sorry, no full-text was found for your article.’”2 These problems have a direct and measurable impact on user experience, and the failure of those resources to perform reflects poorly on the library and the institution.

This effect is understood on the user’s end only in the most basic terms, irrespective of the various workarounds devised to offer content. As Trainor and Price observed, “Put another way, users generally do not care whether the item is in the library’s collection: they clicked the resolver button because they want to know whether the item is immediately accessible to them.”3 This points to the nature of the end user’s problem (“Do I have access?”), which differ greatly from the complexities seen by staff attempting to troubleshoot the issue. While troubleshooters may ask where in the chain of communication between publisher, content provider, link resolver, and institution the access failed, the user ultimately has a different view of things. It is good to be reminded that despite the time and energy we devote to these troubleshooting efforts, the end result is still a struggle to answer a yes-or-no question.

In their survey of e-resources librarians, Rathmel et al. point to the difficulty not only in managing the relationships between libraries and vendors, but in managing relationships between different divisions of the library. Tools public services librarians have been utilizing for years as part of their reference work can be applied successfully to technical services interactions. According to Rathmel et al., “Customer relations management (CRM) and ticketing systems, both underused according to the survey, are one of the ways reference desks have managed handoffs, tracked statistics on common questions and resolutions, and gathered user feedback.”4 Though typically thought of in its outward-facing functions, CRM when harnessed internally within the library can greatly help communication between the many parties called upon over the course of outage resolution. At Oakland University, though BMC’s FootPrints product was under consideration, ultimately staff went with a combination of Trello and Zapier’s CRM software to improve internal communication on e-resource outages, and they saw that Trello’s label system was useful in tracking trends in reported errors.5 In their implementation of CRM software, Borchert noticed a marked increase in the expedience with which troubleshooters could organize reports of electronic outages (and, more useful still for long-term reporting, the ability to search and sort logs of previous outages greatly increased.)6 In a presentation about the same implementation, Borchert and Graves received “lively discussion from attendees” on the topic of harnessing the power of CRM software internally to better keep disparate parts of the library aware of each other’s efforts to solve the complex issues attendant upon e-resources. Borchert and Graves reported that “one audience member pondered why electronic resource management systems or integrated library systems were not providing this service. Another wondered if this expectation of integrated library systems was valid and whether libraries would be able to wait for vendor development in this area.”7 While the first question may remain unanswered, the answer to the second, in the intervening decade between 2006 when it was asked and now, appears to be “no.” Libraries are done waiting.

In addition to CRM, cross-training or an introduction to other units’ workflows may also assist in improving internal communication, as Malinowski observed at California State University, Fullerton (CSUF). At CSUF, “acquisitions staff met with staff responsible for managing the SFX server to discuss e-journal problem solving. As part of this discussion, the SFX staff developed an understanding of acquisitions workflows; this effort created a common understanding of answers to questions such as ‘why is it taking so long to get vendors to respond?’”8 Without exposure to the realities of acquisitions work (including the sometimes slow pace of library-vendor communications), troubleshooters might not understand why answers are so slow in coming.

Various organizations have attempted to wade into the shifting morass of electronic access and create best practices which should decrease the amount of failed access attempts. The Counting Online Usage of Networked Electronic Resources (COUNTER) initiative, for example, has attempted to leverage journal usage statistics to inform libraries’ acquisition decisions, but is unable to account for the kind of discovery services most in vogue now. The International Federation of Library Associations and Institutions (IFLA) notes that “the availability of quality statistical data is important in understanding how well resources are used and how cost effective they are compared to other products. This is particularly important in supporting renewal and de-selection decisions.”9 However, “index-based discovery services may or may not directly embed full-text content, and therefore a number of the prescribed reports that deal with full text are not relevant.”10 With better data about how e-resources are or are not being used (for example, turn-away statistics), acquisitions specialists would be better able to avoid purchasing the kind of resources whose performance and stability turns out to be substandard. However, while prescribing best practices is useful to vendors already committed to or in the midst of change, they are guidelines given in the fervent hope that vendors might take notice of them and act accordingly. Without repercussions for a failure to abide by these guidelines, vendors are able to ignore them.

The implementation of the OpenURL standard maintains a great influence over whether users access content. OpenURL linking, when supported by (for example) abstracting and indexing services, allows for the construction of links to full-text content that is subscribed to by the institution utilizing the OpenURL. Using bibliographic metadata to form, “OpenURLs are then sent to link resolvers run by individual institutions with which users are affiliated, which check the bibliographic information about the located resource against a local database of licensed and open access resource. The user is then presented with a list of options for how to access different versions of the resource in print and in licensed databases.”11 In seeking to map the degree to which different levels of error affected students’ willingness to search out content despite outages encountered, Mann and Sutton examined what they termed “severe system error” and found that “failure to display an OpenURL link for some item types (e.g., gray literature) and refusing to accept the OpenURL link were serious problems which overpowered multiple students during the usability tests. . . . System errors add additional complexity to student interactions with e-resources—perhaps just enough complexity to overwhelm them.”12 While data suggested that users are willing to determine metadata differences like mismatched titles or journal issues with a quick Google search, encountering severe system errors like error codes, blank screens, and absent links may cause students to cease a search completely. The level of error is so great that users assume the desired content lies behind an insurmountable barrier of system malfunction. Such studies highlight the need both for explanatory error messages and for always providing “a way out” rather than resolving to a blank screen with no link to alternative paths to content.

Various examples exist of scholarly institutions’ attempts to manage the response to e-resources outages. At Illinois State University, librarians polled both public and technical services staff and found a need both for increased cross-training between these two groups, and for public services staff to be more included in the conversations around electronic access. Foster and Williams note that “much of the literature that emphasizes the importance of collaboration rarely mentioned public services staff and limited their participation in electronic resources management to traditional roles. The public services interest in this study indicates that an important group of potential collaborators has been frequently overlooked.”13 Such studies exemplify the notion that e-resources outage resolution is a team effort extending across all branches of the library that come into contact with these resources. At Colorado State University, staff have been able to leverage LibGuides to expose some of the technical knowledge unique to those who acquire and maintain e-resources to all staff. They even go so far as to provide audience-specific e-resource LibGuides, stating that, “e-books might present a challenge for help desk staff who neither work with e-books regularly nor are familiar with the general routines of ER access. A separate, abbreviated e-books guide was designed to directly target the library information desk environment with wording tailored for library staff and students working at the information desk rather than a general audience.”14 Texas A&M University has found screencasting to be of assistance in troubleshooting the errors of remote colleagues and documenting a problem for vendors.15

Lacking from existing research on this topic is a detailed examination, not just into how careful documentation of e-resources troubleshooting is done, but into what the results of such troubleshooting tracking show about the quality of vendor products. Such analysis might prove useful both in present and future negotiations for better services from the vendors libraries deal with on a daily basis. It is this absence that the author seeks to address in this study.

Selecting a Tracking System

In 2012, an internal analysis of library workflows at the University of Michigan (UM) Library revealed challenges in library communication. As a result, each unit looked more carefully at their methods of communication, including the EAU outages team. The use of electronic resources had been on the rise, creating new access problems and new needs for staff who can troubleshoot. While this helped to justify the hiring of two additional team members, the problem of communication remained, and in seeking to address it, the FootPrints ticketing system came up as an option.

Widely implemented across various units in the UM library system, FootPrints processes incoming emails to set an email address into ticket form in an online, browser-based workspace. All team members can access this workspace, which can be customized to track everything from ticket arrival time, status and description to time spent on a ticket. Tickets can be transferred across workspaces to other teams (such as acquisitions, cataloging and public services), and the fact that each of these teams were already using FootPrints as a ticketing system made its implementation all the more attractive to EAU.

Previous communication occurred primarily via emails, resulting in pertinent information becoming siloed in individuals’ email boxes if respondents neglected to “reply all” in their correspondence. This increased the amount of time needed to address issues, as members of the troubleshooting team sought to determine who knew what about which outage. This situation was further complicated when the person who had received the pertinent information was out of the office. While we considered other ticketing systems including Trello and Jira, the ease of transferring tickets between units, the availability of a programmer who was familiar with FootPrints and how to customize it, and the fact that the library had already purchased it drove the team’s decision to use FootPrints.

Because of the high degree of customization the product offers, EAU customized dropdown menus, enabled time tracking, and provided free-text fields as necessary. The team established a group email address to forward emails received into the FootPrints system, where the newly formed tickets would await troubleshooting by one of the four members of EAU. The aim is to respond within 24 hours to any incident, with the exception of weekends. All team members receive notifications any time the group email address receives an outage report.

In addition to the group email, other units can cross-copy tickets into our FootPrints workspace, and by far the unit contributing the most of these kinds of outages is the Ask a Librarian reference service, which on average send about half of their problems per month to EAU. The issues referred from Ask a Librarian into our workspace tend to be complicated technical issues that cannot be solved by changing a search method or ensuring that a user has logged into the system before attempting to access resources.

Outage Types

A dropdown menu in Footprints provides a controlled vocabulary, eliminating the possibility of typographical errors or variants in naming when assigning an outage type. FootPrints allows for the classification of outages, which EAU has separated into the following twelve categories:

• Bundled Content: When several articles are bundled into a single document, making it difficult for both link resolvers and patrons to recognize that their desired content is inside
• Configuration: Including but not limited to concurrent user limit errors, missing IP ranges, improperly formatted SICI (Serial Item and Contribution Identifier) errors, poor site navigation, reset passwords
• Proxy: Where off-campus or wireless access through EZ Proxy is not working
• Violation/Breach: The amount and speed of accessed content exceeds limits set by the vendor and access is cut off as a precaution
• Holdings: Coverage in our catalog or knowledgebase does not match the vendor’s coverage
• Metadata: Where incorrect metadata (author last name, volume/issue number, etc.) is causing linkage to break down
• OpenURL: Where the link resolver’s linking syntax is insufficient for the resource and is failing to reach the article
• Scheduled Maintenance: Where the vendor has informed us of upcoming maintenance (this can also occur on our end)
• Target Content Lacking: The article, e-book, volume or issue is not available on the vendor’s site
• Target Site Down: Vendor’s site is down
• Subscription: Where vendor does not recognize that we have a subscription to their product, likely due to renewal, licensing, or payment changes
• Other

Another option is to leave the problem type blank. Upon review, EAU determined that this typically occurred during a time crunch, when the troubleshooter filled out the form in a rush to attend to the surge of outages. Since the description field in Footprints contained a log of both the initial report and all the subsequent updates and final resolutions to these outages, the team felt comfortable assigning problem types retroactively, based on the wealth of information available on each outage and preserved in the ticket. In the future, EAU will take greater care to ensure that the Problem Type field is always populated with an outage type before a ticket is closed.

Problem and Resolution

To minimize the possibility of typographical errors muddling statistics, the “Who Caused Problem” and “Who Resolved Problem” fields are populated by dropdown menus, which contain the following options:

• Acquisitions
• Cataloging
• ER (Electronic Resources) Staff
• Knowledgebase Vendor
• Link Resolver Vendor
• Metadata Vendor
• Selector
• Subscription Agent
• User
• Vendor
• Web Systems

The system distinguishes between Knowledgebase Vendor, Link Resolver Vendor, and Metadata Vendor (the vendor of the discovery service’s metadata), even though at present the same company (ProQuest) is used for all three services. This distinction assists both in knowing which part of the company to contact in case of future issues (repeat issues can be resolved faster if the team is able to point to previous occurrences and how they were resolved), and in maintaining a separation of functions in case the same company is not always in charge of all three services.

When the team attributes the cause of the problem to “Vendor,” the intent is to indicate the content provider. For example, if a user discovered an issue of a journal missing from ProQuest Research Library, and the cause of the “Target Content Lacking” outage was determined to be the vendor’s fault, the “Who Caused Problem” field would be populated with “Vendor,” and the “Vendor” field would be populated with ProQuest.

EAU lacked serviceable statistics regarding vendors before implementation of FootPrints, and relied on anecdotal memory to determine which vendors to add as dropdown menu options. The list in the following graphs does not encompass all of the vendors, but instead the large, easily recognizable names associated with enough outages at the time of implementation to warrant addition to the list. Using a dropdown list made choosing the correct version of a vendor name a more efficient process. The team knew it could not account for all possible vendors, however, even if it were not trying to keep the dropdown menu items to a manageable number on a single computer screen without scrolling. The team added the option of “Other” in the Vendor field, with a free-text entry box to enter other vendor names. While the option for free-text potentially raises the possibility of discrepancies in naming between individual troubleshooters (one troubleshooter may list American Medical Association, for example, and another may put AMA), EAU has discussed a controlled vocabulary and ensured that the same name is being used across troubleshooters for the same entity.

Life Cycle of an Electronic Resource Outage

To better grasp the troubleshooting workflow, the life cycle of a possible e-resource outage from beginning to end is illustrated. On Tuesday evening, a patron attempts to access an article in EBSCO’s Omnifile Full-text Select via the library’s OpenURL link resolver. The page the link resolves to is an EBSCOhost error page that states “No Results Found.” The patron clicks the “Full-Text Not Working? Please let us know!” link below the 360 Link OpenURL button. This provides a Qualtrics form (www.qualtrics.com) for users to specify the problem (see figure 1). Users can also enter their email address for follow-up from reference staff, and any notes they wish to add to the report. Once submitted, this form generates a ticket in FootPrints’ Ask a Librarian workspace, where a reference staff member seeks to re-create the outage. The staff member is able to re-create the error, suggesting that it was not a temporary glitch or user error. When the reference staff member can confirm that the problem is of a technical nature not noted in the catalog as a known issue, he forward it to EAU.

On Wednesday morning, the EAU staff member who handles that week’s outage rotation looks at the outage, which is now in FootPrints’ Electronic Outages workspace. The staff member drills down to the journal-level in the Omnifile Full-Text Select database on EBSCO and successfully locates the article in question. The staff member then tabs back and forth between the 360 Link page detailing the information searched upon unsuccessfully by ProQuest’s link resolver, and the page containing EBSCO’s metadata on the article. She identifies what she believes to be the problem: ProQuest calls the issue of the journal “7–8,” whereas EBSCO calls it “7/8.” Suspecting that this is causing the error, she opens up a ticket with ProQuest’s Summon team, requesting that they change their metadata to match EBSCO’s since that is how the article can be successfully reached on EBSCO. Later that day, a member of ProQuest’s support team responds, indicating that ProQuest is unable to make this change since it would cause sites successfully using that metadata to link out from 360 Link to then fail in making that transfer. ProQuest suggests that the EAU staff member contact EBSCO, which the staff member then does.

EBSCO responds on Thursday, requesting screenshots of the error message, which the EAU staff member provides. EBSCO notes that the link resolver in use is not an EBSCO product, and that they cannot see what ProQuest is doing to cause the linking to fail. When the EAU staff member points again to the discrepancy in the metadata between the two companies, EBSCO responds that they cannot change their metadata for the same reason as ProQuest. Because of this impasse, the outage is marked as “can’t resolve,” with the problem type listed as “metadata.” The outage is closed—all the vendor correspondence having been copied and pasted into FootPrints, allowing reference staff, whose Ask a Librarian ticket was linked to the Outages ticket, to see the resolution. The data are preserved in the event that it can be used to provide examples to vendors of products in need of improvement. Public services staff see EAU’s updates in their own FootPrints workspace, which is linked to the troubleshooting workspace. By this point, public services have typically suggested Interlibrary Loan or other alternative routes of access to the patron. If there was a specific request for an update, the Ask a Librarian staff member will inform the patron of EAU’s findings.

Findings

During the period studied, EAU received 1,586 tickets. Of those, the percentage breakdown by outage type is shown in figure 2, with most of the outage falling into the Configuration, Metadata, Holdings and OpenURL categories. Compare this to the breakdown of outages determined to have been caused by the vendor (47 percent of total outages; see figure 3), where the numbers are slightly different. Here, a greater number of outages appear to fall into the Configuration, Target Content Lacking, and Subscription categories.

The reason for this discrepancy may be that most of the issues that fell into the Configuration category tend to involve information provided to the vendor that the vendor subsequently misplaced—for example, IP ranges, which the library sends vendors when we acquire resources. When vendors change platform or initiate site redesigns, full IP ranges are not always transferred, and EAU may need to remind the vendors of the full range the library has provided to them. The same holds true for “Target Content Lacking.” If a vendor advertises that they can provide a given article, journal issue or e-book, and that content is missing, EAU populates the “Who Caused Problem” field with “Vendor.”

Subscription issues may also be attributed to vendors who failed to register the library’s active subscriptions to their content. When EAU provides a paper trail indicating that the library has paid for content, and when the resolution of the issue involves telling this to various customer help representatives, it is easy to attribute this problem to the vendor. The library had a subscription, the vendor failed to recognize it, but when they did, access was restored.

An analysis of outages not caused by vendor indicates room for improvement from our Metadata Vendor and our Link Resolver Vendor (see table 1), specifically for metadata and OpenURL outages. At the same time, we also see a need for our own staff to improve workflows regarding holdings and their maintenance to keep the catalog up to date with current coverage dates and access points. If our catalog is not up to date, the users seeking to go directly to journals or e-books rather than entering via the discovery service portal will never reach their chosen resources. EAU must also ensure that the e-resources we activate in the Knowledge Base are activated in a timely manner, and in the right locations.

It is important to keep the previous contexts in mind when assessing outages attributed to vendors versus those which are not (see figure 4). Often, because of issues like those previously described, “not attributed to vendor” does not mean that there is a different known contributor to the problem Rather, it means that there are so many breakdowns in the system that it is difficult to ascribe responsibility to any one party. The problems elucidated by such issues are greater than anyone single company or institution, and will need to be addressed at an industry-wide level beyond the scope of this article.

In some instances, however, the cause of an e-resource outage and the expected source of its solution is much more concrete. Take, for example, the numbers for Gale, ProQuest, and EBSCO, in figures 5, 6, and 7. Each of these vendors were unable to provide access to content that they said they would provide. This happened thirty-six times for Gale, twenty-one times for ProQuest, and twenty-two times for EBSCO.

Discussion

Metadata and holdings outages present problems greater and more endemic than a single paper can address. Because there is no established hierarchy for the maintenance of metadata, there is often not one place to resolve problems. When sources of responsibility can be identified, there are times when the multiple parties with a stake in the metadata reach an impasse regarding what metadata should be provided. For example, during one outage, it was discovered that the OpenURL link resolver was failing to arrive successfully at a given article because JSTOR had indexed it as issue 1/2 instead of issue 1. The metadata vendor, ProQuest, indexed the article as appearing in issue 1. The end result was that the issue was not resolved, and the link continued to fail. On another occasion, both the metadata vendor and the content provider acknowledged that the metadata was “not clear at all,” and that because of this, they would not change their indexing, despite explicit examples indicating that leaving it as it appeared would perpetuate a lack of access to the article in question through OpenURL linking. In such instances, while the OpenURL was failing, the failure was due to discrepancies in the metadata, which was apportioned into the metadata category. However, in the absence of a chain of responsibility or the authority to encourage the party (or parties) to change their metadata, the problem remains. It also remains difficult to track. This raises the question as to who is responsible—the vendor or the metadata provider? In the face of such thus far unanswered questions, the metadata and holdings categories (subject to a similar dearth of responsibility) appear much less represented in the Outages Caused by Vendor data. The low percentages of these problems should not be taken as indication of stellar service from vendors. Were there a clearer chain of responsibility, the numbers for metadata and holdings issues would be much higher, given that combined they represent roughly a third of the total outages received.

Bundled content also raises questions of attribution. Usually involving large numbers of abstracts, reviews or proceedings, bundling tends to be beneficial for the content provider. Rather than create a separate web page for every article in quarterly collections of hundreds of articles, vendors can combine articles into one PDF and make it available as a single file. While this is convenient for content providers, it is inconvenient for link resolvers since the metadata treats these abstracts and reviews as separate articles, not as parts of a larger PDF. It is as separate articles, with their own individual files, that the link resolver seeks to find them. The content provider does not attach the metadata of every article contained within the PDF to the web page hosting the PDF, resulting in an error message and a flawed linking system. Multiple vendors have indicated that they have no plans to separate out such bundled content into individual files on individual pages, and for this reason we tend to attribute bundled content problems to the vendor in our FootPrints ticketing system. The immediate reaction might be to suggest abandoning OpenURL linking for a more reliable linking solution. While OpenURL constructs a link based on metadata, Direct Linking relies on an identifier available in the discovery tool’s records to use as a marker to indicate where the link is intended to go. This identifier is a link to a particular full-text provider such as Gale or ProQuest or a Digital Object Identifier (DOI), ideally obtained through registration of the article with a DOI registration agency upon its publication. Because the onus is on the vendor to register the DOI, we attribute metadata issues with unregistered DOIs to vendors. However, the index, such as Summon, that contains those markers and controls which of those markers to use to direct patrons to the desired resource is proprietary material.

Broadly speaking, as Stuart, Varnum and Ahronheim point out in their analysis of direct-linking versus OpenURL linking, “From the Library’s perspective, the trend to direct linking creates the risk of a vendor lock-in because the vendor-created direct links will not work after the library’s business relationship with the vendor ends.”16 More narrowly, using direct-linking to circumvent the errors encountered in using OpenURL linking to access bundled content would still require a tremendous amount of maintenance. Some entity would need to track which vendors bundled individual abstracts and reviews into PDFs and which separated them into their own files. In addition, those vendors that separated bundled content into several smaller combined files (for example, turning abstracts from a conference into three separate PDFs, one for each day of the conference) would need to be tracked. The same entity would then need to manage direct links to the various providers offering this content in all the numerous ways they offer it. Such an undertaking would be prohibitively costly even in the short-term, let alone in the long-term when maintenance is inevitably required.

Changes

As a result of this study, EAU’s personnel realized that they needed to make many changes to their workflows to better capture certain kinds of information related to electronic outages. A systematic review of the miscellaneous “Other” category of outages revealed that there were repeat outage types common enough within that category to warrant their own category. These types included the following:

• Concurrent User Limits: Where a resource was inaccessible because the maximum number of concurrent users had been reached
• User Error: Where the resource was thought to be inaccessible due to a user’s misunderstanding of linking or access buttons, etc.
• Temporary Glitch: Where the resource was determined to be inaccessible at the time of reporting, but by the time of troubleshooting the problem had been resolved

Separating these issues from the “Other” category so that they have their own statistics will better enable EAU to track these problems and resolve them. For example, if concurrent user limits continue to rise for certain titles, selectors might choose to act upon this information and pay to increase the limit on concurrent users for affected resources. Or, if user errors keep arising for specific resources, EAU might investigate them and see if the vendor’s display or the catalog’s explanation of it could be improved to reduce the number of access issues. Temporary glitches, while ephemeral in nature, might still prompt a missive to the vendor, should they occur repeatedly and in such numbers as to become a concern. All of these issues will be reflected more reliably in future statistics, since they have been drawn out into separate categories.

EAU also realized that it needed to be more proactive about deleting correspondence tickets. These are tickets generated by emails erroneously sent to the group email address that migrates content into Footprints. Such emails tend to be about outages that have been addressed, usually from people other than those who originally reported the outage, and are sent to the ticket-generating email in ignorance of the prepreexisting ticket. Responding through the existing ticket is no trouble—and EAU endeavors to do that to keep a record in the ticket of all correspondence related to the outage. However, when the team does this, members need to make sure that they delete the erroneously generated outage tickets. While such tickets have been removed from this data, EAU has determined that it needs to be more aware in the future of the need to address such tickets as soon as they appear.

Conclusion

The landscape of electronic resources is anything but easy to articulate, even within one’s own institution. Issues attendant upon communication, technical knowledge, and organization make capturing problems with e-resources difficult. Even knowing how to group outages into categories that can then be reported may require many discussions and adjustments before reaching consensus. Even then, with a reliable list compiled, attributing outages to the correct source of the problem swiftly becomes a point of contention, especially with vendors less than willing to work with one another on a given issue.

The roadblocks presented by e-resources are not easily surmounted. No one institution can systematically rid itself of the kinds of errors seen repeatedly, across platforms, vendors and content delivery services. However, the multi-faceted nature of e-resources troubleshooting should not force libraries to accept the status quo as incontrovertible. Deciding where to place responsibility when it comes to thorny issues like metadata does not need to be a process that librarians as a profession avoid. With enough data gathered through systems like FootPrints and shared with both vendors and fellow institutions, libraries stand poised to improve the functionality of e-resources, not just for their own patrons, but for patrons everywhere. Improving our ability to describe errors, to capture examples of them and the attempts made to fix them, is the first part of what is sure to be an arduous but ultimately worthwhile process.

References

1. Rebecca Donlan, “Boulevard of Broken Links: Keeping Users Connected to E-Journal Content,” Reference Librarian 48, no. 1 (2007): 99–104, http://dx.doi.org/10.1300/J120v48n99_08.
2. Ibid., 102.
3. Cindi Trainor and Jason Price, Rethinking Library Linking: Breathing New Life into OpenURL (Chicago: ALA TechSource, 2010).
4. Angela Rathmel et al., “Tools, Techniques and Training: Results of an E-Resources Troubleshooting Survey,” Journal of Electronic Resources Librarianship 27, no. 2 (2015): 88–107.
5. Megan Finch, “Using Zapier with Trello for Electronic Resources Troubleshooting Workflow,” Code4lib Journal 26 (2014), http://journal.code4lib.org/articles/10034.
6. Carol Ann Borchert, “Untangling the Jungle of e-journal Access Issues using CRM Software,” Library Collections, Acquisitions, & Technical Services 30, no. 3-4 (2006): 224–37.
7. Carol Ann Borchert and Tonia Graves, “Using Customer-Service Software to Manage Serials Online Access Issues,” Serials Librarian 50, no. 3-4 (2006): 213–15.
8. Susan Davis et al., “Who Ya Gonna Call? Troubleshooting Strategies for E-resources Access Problems,” Serials Librarian 62, no.1–4 (2012): 24–32.
9. Sharon Johnson et al., “Key Issues for Resource Collection Development: A Guide for Libraries” (The Hague, Netherlands: International Federation of Library Associations and Institutions, 2012), www.ifla.org/files/assets/acquisition-collection-development/publications/electronic-resource-guide-en.pdf.
10. Open Discovery Initiative: Promoting Transparency in Discovery (Baltimore: National Information Standards Organization, Open Discovery Initiative, 2014), www.niso.org/apps/group_public/download.php/14820/rp-19-2014_ODI.pdf.
11. ANSI/NISO Z39.88 - The OpenURL Framework for Context-Sensitive Services (OpenURL) (Online Computer Library Center (OCLC)), accessed January 20, 2016, www2.archivists.org/groups/standards-committee/ansiniso-z3988-the-openurl-framework-for-context-sensitive-services-openurl.
12. Sanjeet Mann and Sarah Sutton, “Why Can’t Students Get the Sources They Need? Results from a Real Electronic Resources Availability Study,” Serials Librarian 68, no. 1–4 (2015): 180–90.
13. Anita Foster and Sarah C. Williams, “We’re All in this Together: Library Faculty and Staff and their Reporting of Electronic Resource Problems,” Journal of Electronic Resources Librarianship 22, no. 3–4 (2010): 124–43.
14. Rachel A. Erb and Brian Erb, “Leveraging the Libguides platform for Electronic Resources Access Assistance,” Journal of Electronic Resources Librarianship 26, no. 3 (2014): 170–89.
15. Eric Hartnett and Carole Thompson, “From Tedious to Timely: Screencasting to Troubleshoot Electronic Resource Issues,” Journal of Electronic Resources Librarianship 22, no. 3–4 (2010): 102–12, http://dx.doi.org/10.1080/1941126x.2010.535736.
16. Kenyon Stuart, Ken Varnum, and Judith Ahronheim, “Measuring Journal Linking Success from a Discovery Service,” Information Technology & Libraries 34, no. 1 (2015): 51–76.