Project Design

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.

• Library Simplified Survey One
• Library Simplified Survey Two

User & Non-User Ethnographies -

Personas of users and non-users -

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.

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).

Client Applications

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.

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.