Building a Community of Readers: Social Reading and an Aggregated eBook Reading App for Libraries

In Brief: Library ebooks are currently read in different, unconnected reading platforms. Because all library ebook vendors use the same Adobe ADEPT system to circulate ebooks, they could be delivered to a single aggregated reading app. This article discusses social reading and why libraries should look at the technology, and details the Adobe ADEPT DRM system, OAuth, and application programming interfaces (APIs) to illustrate how an aggregated reading app could be built.

by Jenny Ellis and Kyle Cook

Book Bench: An Aggregated eBook Reading App

It’s a Tuesday morning, I am talking with my co-worker, Sally. She teaches a lot of the ebook classes at our library. She tells me about a new reading app she found on a technology blog. It’s called Book Bench.

“It’s a new reading app,” she says. “I’ve got my OverDrive, 3M, and Ingram books on it.”
“Wait. What? You put all your library ebooks in one app? Can I do that?”
“Yes,” she tells me. “Just go to the App Store and download Book Bench.”
“Okay,” I say, “ I’ve got the app. Now what?”
“Tap ‘Sign Up’ to make a Book Bench account. Then use your new account to sign in to the app.”
“Got it. Where do I add my Adobe ID?” I ask.
“You don’t need one,” she says. “The Book Bench username and password takes care of the Adobe authorization. Isn’t that cool?”
“Yeah, that will make helping people a lot easier. How do I get my books?”
“Use the settings to log in to our library’s ebook services with your library card and PIN.”
“Okay, give me just a second.” I use the app to log in to OverDrive, 3M Cloud Library, and Ingram. “Hey! There are all my ebooks!” I exclaim.
“You’ll love this next part. You know how you can’t add 3M books to your Goodreads bookshelf?”
“Yes,” I tell her. “That does bug me.”
“Book Bench has Goodreads integration,” she says. “So, when you get your books in the app, you can save your 3M and Ingram books to Goodreads too.”
“Oh, you’re reading In a Sunburned Country?” I ask. “I’m reading that too. I love Bill Bryson.”
“I’ll send you an invite to join my reading group in the Book Bench app,” she says. “We can talk about the book while we read!”

Book Bench isn’t real. We just made it up. But it illustrates how we imagine library ebooks could be. It could be exciting to explain that you can get ebooks from the library. We could be connecting with friends inside a book, sharing ideas about the books we’re reading together.

Instead, we wind up apologizing: for getting an Adobe ID; for having several separate ebook systems; for the number of steps involved in getting an ebook onto a reading device. And that’s just to the 38% of library users who even know we have ebooks (Raine and Duggan).

We want to suggest a new app. We’re calling it Book Bench. It’s an aggregated ebook reading app that would bring books from all library ebook vendors together in one place. This would allow libraries to promote a single service with a consistent user experience. It would provide a platform to support conversation around books, the kind of discussion that libraries already encourage with our in-person programming. An app like Book Bench would allow people to connect with one another inside a library ebook.

Libraries purchase ebooks from different distributors—including OverDrive, 3M, and Freading—and each distributor delivers ebooks in different reading apps. But a multi-vendor aggregated reading app is possible. DRM technology does not require a vendor-supplied platform for ebook reading. In fact, because all of our vendors use the same “Adobe Digital Experience Protection Technology” (ADEPT) system for DRM, library ebooks could be delivered to a single app, like our theoretical Book Bench app.

We will discuss social reading and why libraries should look at the technology. Then we’ll detail the Adobe ADEPT DRM system, OAuth, and application programming interfaces (APIs) to illustrate how an aggregated reading app could be built.

Connecting Readers Inside Books

Reading is both a solitary and a social activity. We read in solitude then come together to talk about what we’ve read. Our desire to talk about books is the same whether we read ebooks or print. The digitization of books did not change our desire to talk about books, but it has given us new possibilities for how we can share ideas and connect to one another (Alber and Miller, Book: A Futurist’s Manifesto).

Kindle allows readers to highlight text in order to associate a comment with a specific passage in a book. You used to have to wait to see what a friend thought about a specific passage. Digital books, where readers are connected to the Internet as they read, allow us to share margin notes in real time. While Kindle highlights let you see what someone thought about a specific passage, you aren’t able to comment back and start a conversation. We need to be able to leave comments for one another if we want to foster conversation.

Goodreads, a social network for readers, allows people to share what they are reading and discuss books. If you are on page 185 of In a Sunburned Country, you can find the title on goodreads.com and post a status update with a comment:

“Australia is terrifying. I never imagined the animals he’s talking about. Is this hyperbole on Bryson’s part? Or is the country really so deadly?”

Your Goodreads friends can see your progress update and can comment back. You can’t see the passage from the book your friend is reading, but you can have a discussion about the passage they found interesting. It is a different experience than Kindle highlights. Kindle shows you comments while you are inside a book. Goodreads shows you comments in a separate website.

Social Reading

Social reading combines the convenience of Kindle highlights with the discussion capability of Goodreads. Users are able to bring the conversation into the ebook they are reading.

Connecting inside the book is important. When you move discussion to the comment section on a blog, a discussion forum, or email, you’re no longer in the book. You have to leave the reading app and open up another program. It is easy to become distracted instead of remaining focused on the thoughts you wanted to share. If discussion can happen inside a social reading app, readers can communicate with one another while staying focused on the text.

Our colleague, Sally, uses Subtext, a social reading app that allows her to create reading groups, so she can have a discussion with her book club while they read. At the end of each chapter, a small box appears at the top of the screen where Sally can record her thoughts. At the prompt, she pauses and writes a note to share with her reading group. A small “discussion” icon in the corner shows when there are new notes from other group members. The group can talk to one another by replying to comments. (Figure 1)

The discussion you have while you are reading is different than the one you have when you are done. Social reading keeps comments in context, which allows for a shared experience of the text. As you read, you have thoughts about characters, situations, or plot, that you want to share with someone in the moment.

The asynchronous aspect of social reading lets members carry on a discussion even if they read at different times of day. Readers can record their thoughts as they occur, rather than wait for a club meeting. Groups can stretch the book discussion across an entire month. Group members can talk to one another when it is convenient and pick up a thread of conversation hours or days later. A night owl reading at 2 a.m. can carry on a conversation with her early-bird friend, who was reading at 7 a.m.

Social Reading in the Aggregated Reading App

There are different ways to organize social reading. How we organize discussion and connect people in our imagined Book Bench app, or any aggregated reading app, will determine how successful the social interaction will be.

There are two kinds of sharing: broadcasting to anyone or sharing with a limited group of people. Kobo Pulse is an example of this first kind of sharing, where you see comments from everyone in the Kobo store. Kobo has more in common with Kindle highlighting than the group discussion that happens in Subtext.

As you read a Kobo ebook, you see icons in the margins of the book which lead to comments left by everyone who bought the same book. While reading Jane Eyre, you might run across a passage that has 237 comments. It might be interesting to read the comments, but the chance that you’ll engage in a conversation with 237 people you don’t know is pretty slim.

Social reading apps are most successful when they facilitate conversation between readers with existing real-world ties. While studying BookGlutton, a social reading website, creators Travis Alber and Aaron Miller noticed patterns in user behavior. Users were 80% more likely to participate in a social reading group discussion when they were invited by someone they knew. The groups with the most participation had users who weren’t just familiar with one another, but were part of a real-world group, like a book club or a class. The actual discussion was better because people knew one another and there was a sense of trust and familiarity (Alber and Miller, Book: A Futurist’s Manifesto).

While library users might enjoy social highlighting, sharing notes, and reading community comments, a library social reading experience needs to enable private group discussion. If five library members want to form a group, they need to be able to find one another, establish their group, and organize their discussion around chapters or page numbers. A group member needs to be able to pose a question in a Chapter 3 thread, inside the book. A reader can reach out to the four other group members and ask “What is Michael Chabon talking about in chapter 3? This sentence is 12 pages long and I’m lost. Do you guys know what is going on?”

Adobe DRM & the ACSM File

If we want to enable readers to connect with one another inside a book, and create a consistent user experience, we need to bring everyone together in a single app. The key to aggregating ebooks from different vendors into a single reading app is the common Adobe ADEPT DRM system, and especially one of its features, the Adobe Content Server Message (ACSM) file.

Publishers sell eBook files encoded with Adobe DRM. DRM controls what you can do with an ebook besides read it—how many devices a book can be on at a time and how long it can be checked out. DRM-encoded ebooks get stored in a retailer’s Adobe Content Server.

OverDrive, 3M, Freading, Ingram, and Baker & Taylor all sell Adobe DRM-encoded ebooks. Whether you are purchasing directly from Kobo or checking out an item from a library that contracts with OverDrive, after you click ‘Download,’ the behind-the-scenes action is the same.

Key parts of the Adobe DRM system (ADEPT)

• Adobe Content Server: Server that stores DRM-encoded ebook files and tracks the use of those books once they’ve been delivered to the user. Each retailer/vendor has its own Adobe Content Server.
• Adobe: The activation service keeps track of registered Adobe IDs and the devices authorized with those IDs.
• ACSM file: “Adobe Content Server Message.” Carries the name of the book and the location of the Adobe Content Server that stores the book.
• Adobe ID: Unique ID associated with a specific user. It unlocks the ACSM file.
• Adobe Reader Mobile SDK: Software development kit that companies use to build their own Adobe DRM compatible mobile reading apps.

Downloading an eBook to a Laptop

Sally wants to borrow Fahrenheit 451 from OverDrive to read on her Sony Reader. She uses her library card to check out the book, then clicks a link to download the ebook to her computer. As far as Sally is concerned, she has just downloaded the ebook. After she opens the file, the book loads in Adobe Digital Editions and she moves it to her Sony Reader.

What Sally doesn’t see is the complex interaction between her computer, Adobe, and OverDrive’s Adobe Content Server. What is hidden from her is the key to the aggregated reading app, the ACSM file.

First, Sally clicks the download link in her OverDrive account. Adobe’s Content Server 4 Overview shows how this works (Figure 2):

1. A request is sent to OverDrive’s Adobe Content Server: “Hey, someone wants an ebook, Fahrenheit 451.”
2. OverDrive’s Adobe Content Server returns an ACSM file. The ACSM file is not the ebook. It is an access token for the ebook. The token contains only the title of the book and the location of the Adobe Content Server where the book is stored.

Next, Sally opens the ACSM file with Adobe Digital Editions, though she does not realize that is what she is doing; in her mind, she is just clicking on an image of the book cover. Opening the ACSM file triggers a series of interactions between OverDrive’s Adobe Content Server, Adobe, and her computer. (Figure 3)

1. Adobe Digital Editions asks for an Adobe ID, then connects to Adobe’s servers to see if the Adobe ID is valid. If Sally has not reached her limit of authorized devices, Adobe sends an authorization message and associates her computer with her Adobe ID.
2. Once the computer is authorized, Adobe Digital Editions grabs Sally’s Adobe ID and the ACSM file, and passes this information to OverDrive’s Adobe Content Server. OverDrive’s Adobe Content Server encodes the ebook with Sally’s Adobe ID and adds the lending period set by her library, usually one to three weeks.
3. The Adobe Content Server delivers the DRM-encoded EPUB file to Sally’s computer, where it opens in Adobe Digital Editions. Since the EPUB ebook, Fahrenheit 451, is associated with Sally’s Adobe ID, only devices with her Adobe ID can open it.

No matter where she borrows or purchases a book, the ACSM file is handled the same way. (Adobe Systems, Architecture)

Adobe DRM and ACSM is the Same on Mobile Devices

When Sally moves to a mobile device, like her iPad, downloading looks different, but nothing changes with Adobe DRM. She uses her library card to borrow a book from OverDrive and she clicks a download link to download the ebook to her OverDrive app. The behind-the-scenes communication between her device, Adobe, and OverDrive’s Adobe Content Server is the same. But the outcome is different.

On her laptop, Sally downloads an ACSM file. She must open that file with Adobe Digital Editions. On an iPad, the ACSM file is sent directly to her OverDrive Media Console app. The difference lies with how OverDrive download links are coded. When she clicks the download link on an iPad, the OverDrive web site detects she is on a mobile device and automatically opens the ACSM file in the OverDrive app. This makes using OverDrive on iPad easier, but has nothing to do with Adobe DRM.

ACSM files can be opened by any Adobe compatible app. You can open an OverDrive ebook in the Books-a-Million app. You can open a Freading book in the Bluefire app. The brand of the app doesn’t have to match the store where you get a book. What matters is that the app is authorized with an Adobe ID.

The ACSM file is the common denominator for all library vendors. Each vendor makes Adobe DRM-encoded books available for checkout. Checked out books are listed on Sally’s bookshelf in her OverDrive account. If she can access the ACSM file, she can download the book to any Adobe-authorized reading app.

Vendor ID: Adobe Authorization without Adobe ID

Vendor ID is a part of the Adobe ADEPT DRM system. It allows bookstores to authorize their branded reading apps with a store login instead of an Adobe ID. The Adobe authorization process still occurs, but the customer never sees it.

Any ACSM file can be opened by any Vendor ID, no matter where a book was purchased. Books-a-Million is a good example of Vendor ID in use.

Sally creates a Books-a-Million store account to buy an eBook at booksamillion.com. She uses her email as her login. When she finishes payment, Books-a-Million instructs her to download the BAM Reader 2 app. When Sally opens the BAM Reader 2 app, she is asked to authorize the app with her new BAM login. This is just like authorizing Adobe Digital Editions with her Adobe ID.

When Sally authorizes the BAM Reader 2 app with her BAM ID and password, she triggers an interaction between the BAM app, the BAM store database, and Adobe. The steps for authorization with Vendor ID are described in Adobe Digital Publishing: Vendor ID Specification (Figure 4):

1. BAM Reader 2 takes the BAM ID, then connects to the Books-a-Million customer list to see if the BAM ID is valid.
2. The Books-a-Million customer database sends back a message that confirms that the BAM ID is valid.
3. BAM Reader 2 communicates with Adobe to complete authentication. The app contacts Adobe’s Activation Server and provides an authorization token that says the BAM ID is legitimate.
4. The Activation Server connects to the Auth Service at Books-a-Million to look for an authorization record that matches the authorization token that was sent by the app.
5. The Auth Service confirms that the BAM ID is legitimate.
6. The Activation Server takes the authentication token and records the BAM ID and device information into the Adobe database.
7. The Adobe Activation Server authorizes BAM Reader 2 with the BAM ID (Vendor ID). No separate Adobe ID sign-up is required because the Vendor ID is an Adobe ID. (Adobe Systems, 2)

Once BAM Reader 2 is authorized, Sally sees a list of the books she has paid for and can download them. The word authorize is important. Sally isn’t just logging in to see the list of ebooks she has paid for. She’s authorizing the app with her Books-a-Million ID to unlock Adobe DRM-encoded ebooks.

Accessing an Adobe DRM-encoded ebook works the same as our previous example. When Sally wants to download Water for Elephants, which she previously purchased at booksamillion.com, she taps the cover image in her BAM Reader 2 bookshelf to download the book. (Figure 5)

1. BAM Reader 2 sends a message to the Books-a-Million Adobe Content Server.
2. The Adobe Content Server sends back an ACSM file with the name of the book and the location of the Adobe Content Server where the book is stored.
3. BAM Reader 2 grabs Sally’s BAM ID and the ACSM file, and passes this information back to the store’s Adobe Content Server. The Adobe Content Server associates the ebook with Sally’s BAM ID.
4. The Adobe Content Server delivers a DRM-encoded EPUB file to Sally’s app. Since the EPUB ebook, Water for Elephants, is now associated with Sally’s BAM ID, only devices authorized with the same Vendor ID can open it.

This series of interactions between an app authorized with a Vendor ID, Adobe, and the Adobe Content Server is identical when dealing with any ACSM file.

The user experience for Books-a-Million is straightforward and simple. Sally signed up for a Books-a-Million account to purchase an ebook. She signed in to BAM Reader 2 to read her book. Sally was never asked to create an Adobe ID. She didn’t need to create one because her Books-a-Million login is dual purpose: it 1) signs her into the web site and 2) authorizes the app.

Building the Aggregated Reading App

If you can gain access to the ACSM file, you can put library books from any vendor in one reading app. Our imagined reading app, Book Bench, could use either Adobe ID or Vendor ID. There are four general ways Adobe ID or Vendor ID could be implemented.

1. Universal App with Adobe ID

Our aggregated reading app with Adobe ID could be used by any library system. The advantage of using Adobe ID is versatility. Patrons would be able to add library books and purchased ebooks to the same reading app without tying them to a library Vendor ID. Readers who want to participate in a reading group discussion could bring their borrowed and purchased books together in the same app.

Readers would still create an Adobe ID at Adobe.com, just as they have for years. The drawback is that the Adobe ID is perceived as an extra step. It also brings DRM to the forefront. It is disappointing to sign up for Adobe ID, since the only purpose is to add DRM to the books you want to borrow. It feels like a barrier that makes it take longer to get free books from the library.

Bluefire Reader and Readmill, reading apps not associated with any specific store or ebook vendor, are two examples of type of universal reading app. Douglas County Libraries has an individual version of this called DCL Reader. Their app is branded to a single library but, because it is authorized with Adobe ID, can display ebooks from anywhere.

2. Individual App with Vendor ID

Our aggregated reading app could use the library card number as Vendor ID. Individual libraries would each purchase both a branded app and a Vendor ID implementation. Patrons would download their library’s app and sign in with their library card and PIN. They would load ebooks from all their library’s distributors to their library’s single app. The negative perception of an extra step would be eliminated by using an existing user ID, the library card number.

Adobe would communicate with the patron database to authenticate users and authorize the reading app. Because the authorization occurs through the patron database, the app would only work for one library. Unlike our first option, this app would be for library books only because patrons would not want their purchased books to be tied to the library’s Vendor ID.

3. Consortia App with Vendor ID

Libraries could join together as a consortium in order to create a single, shared aggregator app that uses library card numbers as the Vendor ID. Individual libraries would each have to purchase a Vendor ID implementation. The user interface on the shared app would require patrons to first identify their library, then enter their library card number and PIN. Because cardholders would choose their library from a menu, the app would work for any library in the consortium.

The 3M Cloud Library is an example of a shared app that uses Vendor ID.

4. Library-Agnostic App with Vendor ID

Libraries could join together as a consortium in order to create a single, shared aggregator app and a new web service we refer to as “Book Bench.” Instead of using the library card number as Vendor ID, the Book Bench username would serve as each cardholder’s Vendor ID. When patrons sign in to the Book Bench app with their login, they would also be authorizing the app, just like the Books-a-Million example described above.

The new web service includes an additional step, as with signing up for an Adobe ID, but the perception would be different. Instead of having to sign up for an additional account, the Adobe ID, users are signing up for a service, Book Bench, that will enable them to read all their library books in one place, whether those ebooks are hosted by OverDrive, 3M, Freading, or another library vendor. The reason for signing up for the ID can change the perception that the ID is a negative. Plus, the web service can have additional features and add value in a way that signing up for Adobe ID does not.

Bookish is an example of this type of Vendor ID authorized app and web site.

The two universal aggregated reading apps described above, one with Adobe ID (1) and the Book Bench Vendor ID (4), could be used and promoted by any library, anywhere. A single app promoted by all libraries would improve the visibility of library ebooks because we would all be advertising a single service.

Getting Books to the App

We’ve shown that the ACSM file is the key to downloading ebooks to a non-vendor reading app. To access the ACSM file, a user needs to be able to login to an account and view all of their borrowed ebooks. We’ll refer to this as a bookshelf view, similar to what we saw with the BAM Reader 2 app in our Books-a-Million example. Only this time, instead of viewing a bookshelf inside the retailer’s app, we’ll be accessing an online account on an app that is outside the store ecosystem.

The tools we’ll need to duplicate the bookshelf functionality seen in BAM Reader 2 are OAuth and an API. An API is protocol or interface that “gives programs access to information” (McGuire and Croll). OAuth is a web standard that enables users to grant apps or websites limited permissions to personal information stored in another account (Brail and Ramji, 5). If you’ve ever used “Sign in with Facebook” or “Sign in with Twitter” on a web site, you’ve used OAuth (5).

Subtext and Readmill, two social reading apps, use OAuth to connect users’ online ebook accounts and APIs to display ebooks in a bookshelf view within the reading app. These apps will help us illustrate two ways libraries might create a bookshelf view in the Book Bench reading app. One option would use OAuth to connect directly to a patron’s individual accounts with each ebook vendor. Here, the ebook aggregation would happen in the app. The other option would use an OAuth connection to display ebook titles already compiled in an online account. The ebook aggregation would happen in the account.

Use OAuth to connect to multiple vendor accounts

Sally uses Subtext on her iPad. Subtext has an option that allows her to connect the app to her Google account using OAuth. The Google Books API allows Subtext to display titles Sally has access to in her Google Play account. When Sally chooses to open a book, the Google Books API confirms she owns the book, then delivers the full-text in Subtext (Goldman). The reading app is pulling books in from an outside retail account. The aggregation is happening inside the reading app instead of in a central online account.

The Subtext-Google connection is analogous to the connection that would occur between Book Bench and Sally’s OverDrive, 3M, Axis 360, and other ebook vendor accounts. If ebook vendors develop a bookshelf API, Book Bench could use that API and OAuth to pull in books from separate library ebook vendors. For instance, Book Bench could pull in books from a user’s OverDrive, 3M, and Axis 360 accounts and aggregate them in a single view within the reading app.

Use OAuth to connect to a single online account

Our colleague, Sally, uses Readmill on her iPhone. Readmill allows her to aggregate all her ebooks from different retailers into a single online account, so she can access them from the Readmill app. When she purchases an ebook from Google Play, Feedbooks, or another ebook retailer, she can add the ACSM file to her readmill.com cloud account. She authorizes the Readmill app to view her online account and titles are displayed in the app bookshelf. When she taps on the title of a book, an ACSM file is downloaded to the Readmill app. Adobe confirms that the app is authorized with an Adobe ID. The book is then transferred to the Readmill app.

Readmill is analogous to the aggregation that exists in New York Public Library’s BiblioCommons implementation. The Digital Checkouts and Digital Holds section in Sally’s New York Public Library BiblioCommons account displays all her borrowed ebooks from 3M Cloud Library and OverDrive on a single bookshelf. (Figure 6) Ebooks from different vendors are consolidated in a single online user account. Sally can use the download link in her BiblioCommons account to send her OverDrive ebook to a reading app. This is accomplished with screen scraping, a way of grabbing data without a formal software connection between databases, but it illustrates what a bookshelf API would do.

ReadersFirst and the Development of Vendor APIs

The New York Public Library BiblioCommons implementation demonstrates that a single, consolidated bookshelf is possible. Library ebook distributors do not yet offer a bookshelf or lending API or OAuth connection to developers across the board, but it is technology libraries could ask them to add.

The missing pieces that would enable an aggregated reading app are uniform authorization protocols, and holdings and lending APIs. ReadersFirst, a coalition of public libraries, is working with content providers and urging them to develop these protocols and APIs.

Creating a Community of Readers

Libraries have always connected people around books, creating communities of readers through book clubs, storytelling, book festivals, and author talks. These connections have been made in the physical space, bringing neighbors from the local community together. But communities span more than local geography. A reader’s community isn’t just their local library; it is anyone they know, from college roommates and friends to family members, all of whom might all live in different states and belong to different libraries.

The social tools we see appearing in ebooks can help make connections through reading beyond the walls of the local library.

The Future of Social Reading

The future of reading will include social discussion and sharing. Library readers will want to connect with one another inside the pages of a book.

Social reading is going to be broader than what can happen in a library’s aggregated reading app. Readers will want to connect to friends in the library app and also friends reading on other platforms, like Nook or iBooks. This kind of cross-platform communication is coming. In fact, the kind of bridge that creates a connection between two different reading platforms already exists.

Social reading services ReadSocial and Readmill both offer software APIs that can connect users on different reading platforms. The connection works by having each store’s platform install the exact same API. If Book Bench and Nook both install the same social reading API, users could share highlights and comments even though they are reading on two separate platforms. The API is the bridge that lets readers communicate.

Help Create a Successful Community of Readers

Support ReadersFirst and tell ebook vendors that we want APIs and authorization protocols that will allow us to move books and data to our library accounts, and also move them directly to ebook reading apps. Ask vendors if the APIs they are developing will incorporate a bookshelf feature so that borrowed books can be displayed inside an app on a virtual bookshelf. Look at license agreements and make sure that ebooks can be moved to other apps. Ask vendors about their roadmap for the future to see if their vision matches your library’s goals.

Try social reading. Learn how it works and experiment with friends or book clubs at your library. Experiment with Subtext, Readmill, Copia—social reading apps that will open Adobe DRM-encoded ebooks, including library ebooks. Try Bookshout!, a social reading app and store. Figure out what features you like in these apps and what you would like to see improved. Existing social reading apps can help us determine what type of interaction would best support conversation for library book clubs as well as discussion among friends.

Book Bench is entirely theoretical, but an aggregated library reading app is possible. It could do more than unify a patron’s reading experience. It could help bring readers together. By working together, libraries can make this a reality.

Many thanks to our reviewers, Brett Bonfield, Erin Dorney, Jim Loter, and Bryan Jones, for their edits and perspective. In addition, thanks to Micah Bowers, Jason Sacks, Andrew Goldman, Matthew Bostock, Travis Alber, Aaron Miller, Natalie Rios, and  Jeremy Zhe-Heimerman for help with our research.

Further Reading

Above the Silos: Social Reading in the Age of Mechanical Barriers, by Travis Alber and Aaron Miller, for a history, overview, and outlook of social reading.

“On the Adobe eBook Platform,” by Micah Bowers, for an overview of the Adobe ADEPT platform.

Sources

Adobe Systems, Digital Publishing Group.

• Adobe Digital Publishing: Vendor ID Specification. October 10, 2011.
• “Architecture.” Adobe Content Server 4. Retrieved from: http://www.adobe.com/products/content-server/architecture.html 

Alber, Travis and Aaron Miller.

• “Above the Silos: Social Reading in the Age of Mechanical Barriers.” Book: A Futurist’s Manifesto: A Collection of Essays from the Bleeding Edge of Publishing. Edited by Hugh McGuire and Brian O’Leary. Sebastopol, CA: O’Rielly Media, Inc., 2012. 127-144.
• Personal interview. Nov. 2012.

Bowers, Micah.

• “On the Adobe eBook Platform.” Bluefire Reader : News and commentary from Bluefire Productions, the creators of Bluefire Reader.  Parts 1 -7.  Jan. – Jun. 2012. Retrieved from: www.bluefirereader.com/blog/?cat=4
• Personal interviews. Feb. 2013.

Bostock, Matthew. Personal interviews. Feb. 2013.

Brail, Greg and Sam Ramji. OAuth: The Big Picture. n.d. Retrieved from: http://info.apigee.com/Portals/62317/docs/oauth_big_picture.pdf

“Downloading 3M Cloud Library eBooks for NOOK.” eReady Richland.  Apr 2012. Retrieved from: http://rcpleready.wordpress.com/3m/nook/

Goldman, Andrew. Personal interview. Feb. 2013.

Google Inc. “Using the API – Google Books API Family.” Apr 2012. Retrieved from: https://developers.google.com/books/docs/v1/using#WorkingBookshelves

McGuire, Hugh and Alistair Croll. “Book as API” 15 Feb 2013. Slide 9. Retrieved from: http://www.slideshare.net/bitcurrent/book-as-api-hugh-mc-guire-and-alistair-croll-toc-nyc-2013

Rainie, Lee and Maeve Duggan. “E-book Reading Jumps; Print Book Reading Declines.” Pew Internet. 27 Dec 2012. Retrieved from: http://libraries.pewinternet.org/2012/12/27/e-book-reading-jumps-print-book-reading-declines/

Sacks, Jason. Personal interviews. Feb 2013.

Yue, Ching. “Vendor ID Part 1: Overview.” Datalogics Blog.7 Jan 2013. Retrieved from: http://blogs.datalogics.com/2013/01/07/vendor-id-part-1-overview/#more-634