1.
Jeff Sterling
Chief Technology Officer

2.
2
OverDrive is located in
Cleveland, Ohio, USA
Our mission:
“A world enlightened by reading”
OverDrive is the leading digital media distributor
and technology provider for libraries and schools

3.
3
…
Why did OverDrive create Libby?

4.
4
• In 2010, the OverDrive App was released for
iOS and Android™
• Today, it’s highly rated…
• iOS: 4.5 stars
• Android: 4.5 stars
• And very popular…
• DAU: 950K
• MAU: 3.6M
IOS is a trademark or registered trademark of Cisco in the U.S. and other
countries and is used under license. Android is a trademark of Google Inc.

5.
5
• Also in 2010, an Australian startup Booki.sh
released a web publishing platform which
featured an elegant ebook web reader
• The Booki.sh reader worked on any device with
a modern web browser with absolutely no
software to install

6.
6
• In 2012, OverDrive acquired Booki.sh to add an
ebook web reader to our product offering
• The Booki.sh ebook web reader was re-
architected for scale and became “OverDrive
Read”
• A true ebook-as-a-service platform where every
book is a URL
https://goodereader.com/blog/e-book-news/
overdrive-acquires-cloud-based-company-booki-sh

7.
7
• In 2014, audiobook support was added to the
platform and became “OverDrive Listen”
• Same benefits as OverDrive Read – no
software to install

8.
8
• OverDrive now has three ebook reading
experiences and three audiobook playing
experiences
• Users have to decide if they want to download
to the OverDrive app or read/listen in their web
browser
• The three apps had different UI/UX, different
features, and weren’t connected
OverDrive
for iOS
OverDrive
for Android

9.
9
• In 2015, it was clear we needed to consolidate
our app technology
• OverDrive Read/Listen is our best and most
innovative platform:
• Notes and highlights
• Synchronization
• Full-text search of ebooks
• Zoom-able fixed layout ebooks
• Read-alongs (i.e. narrated ebooks)
• Clear goal: leverage a single reading platform
on the web and in our apps
OverDrive
for iOS
OverDrive
for Android

10.
10
• First attempt: embed Read/Listen within our
existing native apps
• But, the OverDrive app was architected around
downloading content files (EPUBs and MP3s)
• And, OverDrive Read/Listen were architected
around streaming ebooks and audiobooks from
the web
• Ultimately, we decided this was a dead end

11.
11
• Our app has three main contexts with
noticeable seams:
• Search & discovery – website
• Shelf management – native
• Reading experience – web app
• What if we created a brand new app that
was entirely a web app and eliminate these
seams?
• And while we’re at it, let’s re-think the entire
user experience from the ground up (act like a
startup)

12.
12
…
OverDrive’s new reading app for public libraries

13.
13
• At it’s core, Libby is a beautifully designed
single page web app
• Extreme care was taken to make the Libby web
app feel like a native app
• Libby web app performance and
responsiveness was deemed critical
• Libby is fully functional in a web browser, but
requires the user to be online
13

14.
14
• Libby is even better as a native app
• The Libby native app “augments” the web app
with native capabilities
• The web app “client” is considered the boss
and drives the native “shell”
• The shell should not make decisions; it should
respond efficiently to instructions from the client
14

15.
15
• The web app client and native shell work
together by sending JSON messages over a
simple “bridge”
• Example bridge message from the shell in
response to the client requesting network
information:
{
"dest": "client",
"name": "network:info",
"connection": "cellular",
"reachable": true
}
Native Shell
Web App

16.
16
• Getting Libby to function well while offline was
our biggest challenge
• Once we made the decision to move the entire
UI into a web app, we could approach the
offline challenge consistently throughout the
project

17.
17
• Using bridge messages, we built a “cache
roster” system:
• A JSON document listing URLs that should be
downloaded locally
• When any of these URLs are accessed by the web
app client, the native shell serves them from its
locale store instead
• Cache rosters allow Libby to deliver “packages”
of content to be served transparently from local
storage
• The Libby web app is not aware that the
requests are being served locally
Native Shell
Web App
local storage

18.
18
• Cache rosters used by Libby:
• Web app roster
(HTML, JavaScript, CSS, font, images)
• Covers roster
(cover images for shelf possessions)
• Book rosters
(ebook/audiobook content files)
• Whenever the version of a roster changes, the
entire roster must be re-downloaded

19.
19
• We have used bridge messages to deliver
similar augmentations that take advantage of
native capabilities:
• Background audiobook playback
• Haptic feedback
• Geolocation
• Device orientation locking
• Notifications (coming soon)

20.
20
…
Web browser and offline native app

21.
21
• Single deliverable, multiple platforms
• Simplified help and support because UI/UX is
identical across platforms
• No app store review step for updates
• Updates are instant and mandatory

22.
22
• Web blocking affects Libby disproportionally to
native apps (e.g. parental controls in iOS can
break Libby)
• Accessibility features are more difficult to
implement in a single page web app, but we’re
working on it
• Appearance of infrequent updates in the app
stores

23.
Jeff Sterling
Chief Technology Officer
@meetlibby