Project Design

Library Simplified is jointly funded by NYPL and IMLS. This funding supports a full-time position at NYPL: “Product Owner (PO) for the Library Reading Experience.” The PO, is charged with proposing ways in which to employ technology, innovation in library policies, and the full range of library offerings to deliver a better experience to more patrons. The PO leads a small technical team, and works in concert with partner libraries to analyze the digital assessment findings and move the design process forward. Library Simplified will include four phases of work with major milestones and deliverables at the end of each: (I) Fact gathering and analysis, (II) Architecture and testing (III) Build and (IV) Implementation and assessment.

Project Design


Phase 1: Fact gathering and analysis

There are three parts to the fact gathering and analysis of Library Simplified. The three parts are designed to clearly document the expereinces of users and non-users, the system infterfaces and technology architectures that deliver those expereinces and analyze the needs and wants of users and how those are met or not met.

User Experience (UX) Assessment

Mapping the User Journey -

The team will document all relevant interaction points at all partner libraries, the end-to-end journey of a user borrowing an e-book.

Heuristic Evaluation -

The team, assisted by expert consultant(s) as needed, will conduct an audit of all current screen-based catalog/reading interfaces by assessing them in terms of usability heuristics and identifying "trouble spots" in the current design.

Library Policy ‘pain’ points –

This will demonstrate how and for whom current library policies create “pain points; providing key support for senior library decision makers evaluating the pros and cons of policy changes.

Storyboard Experiences -

The team will create visual representations (storyboards) of proposed new directions intended to serve as a foundation for further prototyping. These UX Storyboards will describe the ideal process.

Needs/Wants of Users and Non-users

The project team will engage directly with users throughout the first two phases to test hypotheses and gather input. Since the first goal of this project is to build audience, at all stages it will be critical to gather insights from non-users. For example, in January 2013 when NYPL’s Office of Strategic Planning sought feedback on a new Netflix-type card, users in focus groups conveyed that they wanted to be able to check out at least 10 items and expressed anxiety about fines but also a belief that they were important to teach personal responsibility. Many non-users, on the other hand, indicated they would be happy to sacrifice the number of items available (e.g. accepting a card with a 3-5 item borrowing limit) if that meant a promise that they would never incur fines. These critically different perspectives must be considered and addressed throughout the duration of the project.

With that in mind, the project team will be tasked to conduct at least the following analysis of users and non-users:

Survey Data roll up and gap assessment -

NYPL’s Office of Strategic Planning’s User Insights Group has conducted large-scale surveys with user and non-user quantitative and qualitative data. Similar research completed by partner libraries or published elsewhere (American Community Survey, Pew) will also be included.

User & Non-User Ethnographies -
The team will conduct a small field study of selected circulating branch libraries and online users to explore the behaviors and attitudes of current users, with a particular focus on policy issues and related UX design implications.
Personas of users and non-users -
The team will also develop user personas that capture the needs and wants of the most largest and most important groups of potential users, including heavy media consumers & ereaders; and youth and students.

Systems Architecture analysis

Architectural Schematics of/for all Partners -

The Product Owner will work with partner project leads to develop a simple but comprehensive annotated schematic diagram of the IT architecture for each partner library.

Overlay of Data sources and feeds -

A key component of the architectural diagnostic will be to understand the potential sources of patron and collections data from an ILS, e-content from vendors, and supplemental UGC and/or recommendation from other third party products. This overlay, which will sit “on top” of schematic diagrams, will capture not what the systems are but also how they interact, a critical first step toward proposing ways they can be streamlined.

Market Scan -

The Product Owner and team will review products that are available to libraries but not in use at all/any of the partners. This work will come late in the Fact gathering/Analysis phase so that it can focus on exploring strong hypotheses about how new products could be integrated to satisfy unmet needs and wants.

Note: At the end of the Phase I, the team will produce and circulate a comprehensive report with all the findings and raw data. Although the team will likely have begun to develop ideas about how to solve for the user stories gathered, this report will stop short of recommendation or proposed product design. It will instead create the robust foundation for the next phase, which will be to design the actual product offering.


Phase 2: Architecture and testing

During Phase II, the team will attempt to sketch a wide variety of products that could be built and test them against user stories and user personas to identify the most impactful design. This will be an iterative process and will include engagement with a variety of external technology experts; partners will come together physically to discuss the different approaches.

Partner review and assesment of options

Partners will be asked to review the options through the lens of three main factors,

  1. Feasibility (i.e. does the partner feel confident that, if built, they could implement the proposed product at their library),
  2. Willingness to adopt implied policies,
  3. Satisfaction with goals.

The project team will review partner feedback, and during an in-person event, build consensus to go forward with a product build that will have the broadest impact. The team will then develop detailed technical documentation of the proposed solution that can serve as a roadmap for an in-house software development effort or become the basis of outsourced contract development work.

Implement and test

Each partner library will be responsible for implementing the test product at their institution and will bear any associated costs (e.g. securing needed data feeds from ILS or vendors). As such, partners are not formally committing to implement the product, just to go through steps (I) and (II) and then try to locate resources customized for their institution. Partner activities and contributions will be managed using an adapted Agile methodology. All partners will have access to a living online work plan that will be owned by the Product Owner but maintained and updated by the owner of each ‘to-do’. Project leads at partner libraries will convene on regular calls, not less than once a month but more frequently during the first six months of the grant (the planning and architecture phases). Partners will also meet in person at least two times during the project, for a kick-off and during the later portion of the architecture phase.

Additional elements and deliverable of the product could be optional and adopted by some partners and not others. For example, any physical component that proves too radical for one library’s senior management in terms of policy (e.g. no fines) or to costliness (e.g. delivery by mail) but other libraries may want to use this product as a vehicle for experimentation. The delivery of a better ebook discovery and access experience should be considered the base case, from which additional branches/ offerings may be added (e.g. by mail) as/if libraries are able and willing to support them. At the close of Phase II, the project team will deliver a final proposal, including product vision and detailed functional specification (RFP or similar).


Phase 3: Build

During this phase the Product Owner will identify and commission the most cost effective way to build the chosen product, estimating the time and cost associated with building the project in-house using staff resources and seeking quotes from vendors to compare the cost of outsourcing. The team will also look for opportunities to build/accelerate parts of the build by convening hackathons or codes sprints, drawing from the local developer pool in New York City hosting at one of our partner libraries, including those in Silicon Valley, and/or seek support and contributions, as appropriate, from existing industry developer communities such as Code4Lib.

Middleware/Application Backend
Normalized Catalogue/Content Inventory Application Programing Interface (API)

During this phase the project team will prepare for integration by vetting and adopting new policies and practice suggested by the product visions and by preparing any technical enablers that will be required for implementation. In addition to the existing ILS, e-content vendor platform (i.e. 3M, Baker & Taylor), and catalog frontend being in place, several more pieces of infrastructure would be brought together to make the existing components work well with one another and provide a better experience to users. The project would develop piece of middleware to coordinate ebook inventory and activity between multiple vendors across a common API, enabling 3M, Overdrive, and Baker & Taylor to be accessed and served in a uniform way. This middleware would sit between the ILS, ebook vendors (via their APIs), and the Library Simplified frontend, pulling the aggregate list of titles from the catalog, inventory details from the vendors, and facilitate user’s transaction to check out a title from any vendor. Library Simplified’s frontend would be powered by the same data feeds that drive existing catalog frontends coming out of the ILS, as well as the vendor management middleware.

Normalized Recommendation Application Programing Interface (API)

The data feeds and APIs that power this user-facing frontend would be implemented first for the web, but would also enable the creation of integrated Library Simplified native apps for mobile devices and some dedicated e-readers like the Kindle Fire and the Nook. This frontend would utilize a third-party recommendation engine, such as Hunch or LibraryThing, which would index the ILS’s corpus of ebooks, and with a little knowledge about each user (what it needs will vary depending on the recommendation engine or engines used). The recommendation engine would also interface with the vendor middleware to determine titles a patron might be interested in reading that are immediately available, will be available in a day or so, or for which the user might wish to join a longer hold queue. This common discovery interface could power more than just the e-reading experience, but discovery for all of Library Simplified’s offerings.

Client Applications
Web/Connected Client Application

Ebook delivery will be offered two ways. To facilitate immediate reading, without undergoing the arduous process of transferring an ebook to a device, the project will follow the example of OpenLibrary’s browser-based lending system and build a HTML5 browser-based reader that can be used on any browser connected to the internet, optimized both for tablets and smartphones. Checking out an e-book to read in the browser will result in the book being checked out to a server controlled by the library with the digital rights management (DRM) certificate being tied to the library server for the lending period. When a user requests a page in the book, that page will be rendered on-the-fly on the server, and sent to the user’s browser. When a user moves to a new page, the service copy of the previous page will be deleted from the server so no more than one page is available at any given time, but offering all the features of a standard e-reader including searching the full text of the book.

Native Client Application

While the browser-based model works only when connected to the internet, it doesn’t replace reading on a dedicated app that can be used offline. Delivery of ebooks can be arduous due to the complex requirements of the underlying DRM. Major sellers like Amazon and Apple own the process from end-to-end and have created the illusion of no DRM within that ecosystem. Library Simplified will do something similar by taking advantage of the existing e-reader software on devices which is compatible with libraries and making the delivery experience to those apps seamless via the checkout API of the vendor middleware, and serving the book to the user via a special URL. By visiting that URL to pick up the book, they’ll be presented with a list of options, and by clicking on the user’s preferred reading app, Library Simplified will trigger via special URLs to tell those apps to access the books directly, without any special steps. This leaves the possibility open for a set of Library Simplified native apps, but makes immediately actionable the seamless checkout of ebooks to smartphones, tablets, and some dedicated readers without needing to build specific apps for each platform.


Phase 4: Implementation and Assessment

By the time the technical build of the new product is complete, project managers at NYPL and each partner library should have prepared their library for integration, meaning that new policies and/or practices implied by the product have been approved or adopted and that technical infrastructure is ready to integrate. As the product is rolled out, local marketing campaigns will advertise the tools and encourage use.


Communication Plan

In parallel to the technical build, the project leads at partner libraries will prepare and implement a communications plan focused on reaching all libraries that may be interested in implementing the product. This communication will include dissemination of the final product vision as well as detailed information and instructions implementation requirement. This communications push will leverage the deep industry knowledge and networks of the partner libraries include dissemination by taking advantage of channels such as ReadersFirst, listservs provided by ALA, PLA, ULC, DPLA, and other marketing opportunities with state and local library associations. The partners will seek to speak about the project and encourage other libraries to implement it at conferences and directly with peer institutions. The goal will be to ensure that all libraries are aware of the opportunity and that as many as possible choose to adopt the product.

Each partner will also prepare a marketing plan to make the public aware of the product once it is launched by their libraries. These will undoubtedly leverage low-cost marketing approaches like using the library's social media presence, but will also purchase paid marketing to the degree resources permit. Partners will be encouraged, but not required, to use their partner stipend to seed these marketing budgets and to supplement these activities in other ways.


Evaluation

NYPL and partner libraries will pool data about use and qualitative feedback from users, staff, and other stakeholders to assess the degree to which this project is meeting its goals. Evaluation and assessment will measure the following objectives:
  • The project has been successful in disproportionately attracting new users
  • The project has succeeded in driving use (and to what extent)
  • The project has accelerated a rise in use of electronic collections as compared to the national average over the same period
  • There is a deeper understanding of the impacts of alternative policies tested through this project (including for example, return rates, holds pick-ups)
  • Product users are more satisfied with their experience using the library than users who access the libraries resource through traditional pre-existing channels
  • To understand and document opportunities to improve core systems (other than the product this project creates)

Evaluation of this project will be based primarily on use, but will also include quantitative and qualitative feedback from users and stakeholders. There will be six main inputs to assessment:

  1. Use data reported by partner and participating libraries sent on a quarterly basis. (At any time throughout the first year, partner libraries and other invested stakeholders may request data and/or findings from the NYPL team. At the end of the first year after product launch, all use data will be included in one comprehensive summative analysis that will be made publicly available.
  2. Demonstrated user behavior from embedded analytics in the product
  3. Self-reported use data and feedback from participating non-partner libraries. (At a minimum, the project team will work to identify (a) the total number of libraries that have adopted the product and their population served and (b) the total number of users of the product (likely available from embedded analytics and therefore not dependent on survey response).
  4. Insights from user direct testing, conducted as part of the product design phase. (The primary purpose will be to compare and improve competing prototypes, but the team will also use these interactions with users to glean insights, especially qualitative.)
  5. Quantitative and qualitative feedback from user via feedback box, surveys and focus groups. (NYPL User Insights team will lead a process with partner libraries to gather summative and formative feedback from users and non-users)
  6. Input from other stakeholders including partner participating and other libraries, and industry partners, including interviews, a partner staff survey, and a partner retrospective or ‘post mortem’.
All data will be analyzed by NYPL’s Office of Strategic Planning. Both the findings and the raw data will also be made available to partners and open for public dissemination.


Resources

Product Development / Engineering

Product Owner / Engineering Manager - James English
Application Architect, NYPL - Leonard Richardson
iOS Client - Gwendolen Quinn / Sam Tarakajian - NYPL Android Client - Mark Raynsford - Independent, UK

NYPL Labs

Based at The New York Public Library's landmark central branch on 42nd Street, NYPL Labs is an award-winning design and technology team working to re-imagine The Library for the Internet age.

Learn more...

Mauricio Giraldo - UX Designer and Labs Engineering Manager

  Other Contributors

Ben Anderman, Raduz Benicky, Juan Corona - Evident Point, Corp
Hadrien Gardeur - Feedbooks, SAS
Mikael Menu, Jean-Marie Geofroy - Mantano, SAS