Ebooks Apps from the Inside Out – Micah Bowers – ebookcraft 2017

– [Laura] Speaking today about the history
and future of e-book reading apps and their influence on e-book creation is
Micha Bowers, founder and CEO of Bluefire. For those who don’t know, Bluefire
is a really awesome reading app, and you should all put it on your devices.
It’s very useful, very agile, and your e-books work there. So, don’t use
those other apps. Use that one. It makes me happy. In addition to helping
businesses deploy mobile application server software and cloud services
for distribution and consumption of digital publications, Micah also serves
on the board of the Readium Foundation, an open-source software organization
developing technology to accelerate the adoption of EPUB 3, a laudable
goal, an open web platform by the digital publishing industry. – [Micah] Let’s mention I’m going to talk
about e-book apps from the inside out, and that’s really pretty much the only
thing I know about, so it’s good that we’re talking about that. One of the
things that I really wanted to talk about when I was thinking about, “What do I have
to say to people who make e-books?” is that I recognize that this industry is
surreal, and I don’t know how many of you are familiar with the work of Franz Kafka.
Can I see hands? Everyone knows? All right, so most of us know Kafka.
Well, to me, the e-book industry has always been kind of a Kafka
experience, and really the question that I wanted to try to address
today is: why is it that way? Why is it so crazy? Why does
things work the way they do in this very mysterious and kind
of nefarious way, at times? And part of the reason that I wanted
to talk about that is I wanted to look at what do we do about that? How do we…?
It’s one thing to at least understand a little bit about why it’s so nutso, it’s
another thing to try to have a strategy for how to cope with that, and that’s
what I wanted to talk about today. I’m going to start with my own personal
journey on how I got to e-books. It’s relevant to how I look at things,
but it also relates to what we’re trying to do at Bluefire, and what I’m trying
to do with the Readium Foundation. So, when I first got into media years ago,
1985, started doing multimedia, I really fell in love with this idea
of video and audio, and images, and animation all working together
to create this new form of media that we didn’t have before, and I thought
that we could change the world in some small way, in the ways that we
expressed ourselves, in ways we communicated, the ways we educated,
and I went through a journey in my career of exploring that and trying to find
ways to make that work. And it went through CD-ROMs in the early days,
and Flash, and the early days of Dynamic HTML, which we called DHTML hell,
which we’re kind of still in today, and video, all put together. I had a
digital agency before this company, called LiveWire. I did that for years,
doing all these kinds of things, mostly for large corporations:
Microsoft, Sony, Adobe, etc. And as I went through this journey,
I was really looking for the solution, and it wasn’t really getting
traction, was what I was feeling. We were working with Adobe and this new
company, Bluefire, back in the mid…it was about 2005, and we ended up hooking
up with a gentleman named Bill McCoy on a different project that was not
e-book-related, but then he ended up going to e-books. And I got introduced to it,
and I really never knew how important text would be in this idea of multimedia,
and e-books really did that for me. One of the things that I really
found fascinating about e-books, as we started doing prototypes for Sony,
in fact…this is before the Sony Reader, our very first prototype was
actually a PSP, little game device, and made a little e-book reader for that.
And the thing that really struck me as we started putting these things together was
that text worked as a kind of glue that pulled all these media pieces together
in a way that I had never really expected. I had always really tried to stay
away from text, so it’s video, it’s audio, it’s animation, it’s all
these things that aren’t text. And if there’s text, it had to be
10-foot, you know, readable. But what I found, for various reasons,
it’s in a large part due to cost, trying to create an experience
that’s all new, that’s all media, multimedia, is something that
is very expensive and difficult, and it didn’t really have a mental
model for how people bought it. But e-books have a couple things that
are really important. They have this… Text is a way to glue everything
together in a very cost-effective way, just about anybody can do it and it’s a
mental model. People understand it’s a product and you can package it up, and
lo and behold, people actually buy them. That didn’t really happen with CD-ROMs. It
didn’t happen with Flash multimedia sites. It hadn’t really happened
before and so e-books became… I really didn’t expect it, but it became
kind of the end of the road for me in my advanced multimedia. After having done
interactive television prototypes for Sony U.S.research labs, I ended up in e-books,
and I’m still here 10 years later. And so, that 10 years started with,
as I mentioned, working with Adobe, and that was this thing called Adobe
Digital Editions, and a DRM system called ACS, which probably most of you know
about. There’s a lot of funny stories that I love to tell about how that came about,
and it has its own Kafkaesque story to it, but one thing I will say is that Adobe
Digital Editions originally was designed to be in the browser. And so the merger
with Macromedia and Adobe had just happened. There was this great thing
called FlashPaper that I thought was really cool because I was a Flash guy,
and it was basically a browser-based document reader. It was kind
of an alternative to Acrobat Reader, but it actually was in the browser.
And that was being discontinued and I thought, “Oh, this is going to be
great. We’ll take this new thing called EPUB 2,” that no one had seen yet,
in fact, it wasn’t ratified when we first started working on it, “and we’ll make a
re-flowable reading system and we’ll have a PDF reading system, and we’ll have a
Flash reading system, and they’ll all be in the browser and you can embed it
in any size you want, and we’ll make it really simple, make it…you can style it
any way you want.” So, Digital Editions, which you see here, which is
black, was designed to be embedded with two colours, so you can have
a theme colour and a highlight colour. So, here you see black and orange, which
were the default because of the other Sony things…the other Adobe things going
on at the time, but it would be, you could do it in any colour and put it
in the browser. And I was really excited about that, but of course at the last
minute, it ended up that, for various reasons within the company, the DRM
system that was supposed to be implemented in the browser as part of this
thing called AIR, wasn’t going to be there in time, and we had to ship this thing
in time because e-books were being taken out of Acrobat Reader, which that’s where
e-books had been. They were PDF and they were in Acrobat Reader, and that
was being used by public libraries all over the world at the time, and it would
have been taken out and there was no way to put it back in. It was too late
for that, and so we had to get this thing to market. And so we ended up having
to, at the very last minute, take this crazy monster that we had created,
that was a EPUB renderer that no one had ever seen, and a PDF renderer and this
Flash interface that all was designed to be very simple and in a browser,
and make that into desktop apps under a very, very, very tight timeline.
And that’s how ADE came to be, and that’s why it’s kind
of the odd beast that it was, and maybe still is,
but that’s kind of part of it, and those kinds of stories about how
these things come to be really are the underpinnings of this kind of Kafkaesque
world that we live in beacause you could look at it and say,
“This makes no sense.” And it does, if you know the story, but we don’t always
know the stories behind these things. So, going back to the beginning
for me, of e-books, it was EPUB 2, for me was the introduction,
and it hadn’t been ratified yet. And EPUB 2 was and is interesting because
the limitations of the HTML profile, XHTML profile it was, and due
to the target devices at the time, which were these very weak processors
with, you know, very cheap hardware really. I mean at the end of the day, the
Ink, the screens that came with were by far the most expensive part of these
e-reader devices, and they had fairly weak chips, and so the folks that were making
these systems had to target these things. And so, here’s a great question for you:
who here has ever used a web browser on an e-reader ink device? Okay, how many
of you thought that that was awesome? Okay, right, right. Well, it’s awesome to
be able to do it, but the reality is that rendering HTML is a processor-intensive
endeavour. And so what happened with what was the predecessor to Kindle, and what
happened with ADE and RMSDK, which is the…powered the Barnes & Noble
NOOK device and still does to this day, and the Sony devices, the folks
wrote their own rendering engine, they wrote their own browser, and they
wrote it from scratch. And that’s kind of a crazy thing to do in a way,
is to write your own browser, but that’s what they did, and because they
had to write something that was very processor-careful about how it used the
resources. And so that’s why you got a lot of very strange behaviours, why
tables, for example, were crazy, because it’s hard to write a table renderer.
It really is. It’s a funny thing, but it’s very difficult and that’s why you have
these odd scenarios within EPUB 2. And of course, what you see in these
devices and in these apps, and, in fact, in Bluefire Reader,
and in Adobe Digital Editions and a lot of others, it’s not even text.
So, it’s literally an image being rendered by this rendering image that’s
then sent to the screen. And so, what you actually are looking
at when you look at Bluefire Reader, or Adobe Digital Editions, or the
NOOK or any of those things, is you’re looking at a picture of text.
You’re not looking at live text in the way that computers normally render live text.
And so, when you have things where you’re interacting with these things, let’s say
you want to highlight or you want to select text, well, the reading system
implementer has to actually do some fairly odd things to make that work. You’ve
got to detect where the finger is, go back through and do a kind of in-memory,
figure out, “Well, here is that and what text is under there, and what
is the polygon of that?” And then we can display things to the screen.
And so you get these very odd behaviours. And this is just one little example
that I wanted to touch on, but it can be very confusing when
you’re interacting with something. “This is text. It’s on an iOS device.
Why is it behaving different than text normally does?”
It’s because it’s not text. Of course, one of the biggest challenges
for reading system implementers, and for the industry as a whole, that is,
I think, really under-addressed is the issue of user preferences, and this has
been something that I’ve seen throughout my career, and it really came early on.
And I remember the debates 10 years ago when we were making ADE about whether
we would have these settings or not and what the user expectations were.
And as we see today, this idea that a user can not only change the size
of their text, but change the font, change the colour, change the
background colour. I, myself, even though I’m a UX guy at heart,
that’s my focus, I’m not an engineer, I really underappreciated
it early on how much that would be a factor. I remember this
application called Stanza. Does anyone here remember Stanza? Well, Stanza
was great and I knew the guys that they worked on it, and you know, that was
a great example of where they wrote their own rendering engine. At the beginning,
they completely just stripped all the…because they had…they were
just trying to get something to work, they would just ignore all HTML. They
would just take it, they would do their best, they would display something, and I
remember dealing with their users as I was making Bluefire Reader, our current
app, and trying to understand, “Well, what’s important to them and what
do they need?” And people actually thought it was a very, very important feature that
they could have blue clouds…little blue sky with white clouds in the background
of their book and I just found that insane but did people really value those kinds
of things? And as a specification and as a community, we haven’t really
rectified that reality, that we have these users that want to have it exactly the way
they want it, and that might be pretty odd. That might be pink on green and there
might be a reason for that with the way their eyes work or how their brain
works, and so it’s not just this kind of random preference thing. It’s a whole
spectrum, but we haven’t really dealt with that. But it is a reality that we
still need to deal with, and interestingly enough, the way the reading systems have
to deal with that is rather challenging and it’s imperfect. So for example, when
we’re dealing with HTML with EPUB 2 and we’re trying to make user settings,
we’re trying to override known selectors. So we say, “Okay, we’re going to…
user said they wanted night mode. They want black background and white
text, and so we’re going to say, “Okay, text should be white and the
background should be black,” but of course that only works if you know the
selectors and if you can do it. People who make e-books can completely
defeat that. You can go in and you could…well, it depends on the system.
Some systems will completely strip anything that you do there, altogether.
They’ll do a very thorough and complete job of ripping your e-books apart
and maybe even turn them into databases like COBOL does, or put them through some
processor before they even distribute them to strip out your mark-up, but we don’t do
that. We’re against that whole idea at Bluefire, but it is challenging because
oftentimes it doesn’t work. We will have a lot of times where consumers
will contact us in support and say, “Your app is broken. This text isn’t
rendering correctly,” and we’ll find like, “Oh, actually, no, that was the way it was
intended to be. You just perceived that it’s broken.” And so, that’s an issue
that I don’t have a clear answer for, but it’s something that is definitely
part of this whole insanity. And the example of Stanza, they were
beloved by their users because of… it was one of the first apps that you
could really control your reading experience, but they were one of the most
dramatic, early on at least with Stanza. I’m just disregarding the CSS of people
like you. So, it’s an interesting challenge, and it’s been part of our
industry and something that we need to address. And of course, DRM adds
to this dramatically…the craziness. And it’s interesting, as a person who’s
spent the last 10 years trying to deal with DRM systems, trying to make them
work, trying to make them easier to use, selling to companies all over the
planet… we have 100 customers right now that license DRM technologies
from us, is that a lot of times, the complaints about DRM and the problems
that those create for users are completely different from the way that I
perceive it. A lot of times, I look at those problems and say, “Well,
that’s not DRM. That’s just something totally else and you just think it’s
DRM.” There’s other things where I think about DRM and people tend to not have
any idea about that. And I think that one of the interesting things about DRM…
and this is, again, one of those grey areas where DRM does create silos,
so Kindle is a silo in a lot of ways. But it’s not just DRM. It’s file format.
It’s devices. It’s usability. It’s the user experience. You could call
it a walled garden, but if you took down the walls, it would just be a garden
that people wanted to hang out in. But one of the challenges of this
is that in the world of browsers, you had a thing where if someone would
make a webpage and it was following specifications, and it worked great
in this browser, but then it didn’t work great over here, that would become
an issue and the browsers would look at that and they would deal with it.
And that’s how we, over time, got to a point, because of the competition
between the browsers, people would switch. Over my career, I’ve probably switched
four or five times different browsers that I’ve used, and I tend to be religious
about them while I’m using them, but then a couple years later, they fall
out of favour and I go to another one, but that’s how we get this kind
of interoperability. We have consistency across browsers and how they dealt
with them, but in the e-book world, we don’t have that. We don’t have that
because if you’ve got books from Amazon and you’re reading in a Kindle, you’re not
going to read them in Bluefire Reader, you’re not going to read them on the NOOK,
and therefore you don’t have this normal force and I think that’s one of the
biggest things that DRM does. And of course, another thing is, and this
is kind of a crazy thing about DRM, is that it tends to be within the more
independent world, meaning it’s not the monolithic Amazon or Apple, that
the books get put into a distributor and that distributor puts DRM on them.
And then when the library or the retailer sell or loan these books, or maybe they
might rent them, to the end users, it comes directly from that wholesaler,
and it comes with DRM. And if there’s a problem, that user says,
“Hey, this isn’t working right. There’s a problem with this book.”
The retailer can’t even look at that book. They don’t know what’s in there.
They can’t look in there and say, “Ah! Well, the problem is here.
We can see what the problem is. We need to tell the publisher to fix it,”
or, “Oh, this is actually right, it’s a reading system problem.” No one
knows. It’s a mystery. Is the book wrong? Is the reader wrong? Nobody knows,
and that’s a challenge as well. And that DRM lock-in is amazingly robust.
I never anticipated the impact it would have where, 10 years later since we
launched Adobe Digital Editions and ACS, there are the same rendering engine and
the same lock-in situations from 10 years ago that still exist today, and it’s
really been an interesting challenge and I’m actually kind of ambivalent about
DRM. I feel like it’s not my job to… I’m not a content owner, so I can’t really
say is it the right thing to do or not, but I do think that the impact it’s had
on our industry and the challenges it presents to the people in this room,
and to the users is something that we have to think about, moving forward, in a way
that’s completely different than the more realistic terms of how people talk
about DRM, which is its own conversation. And so along came HTML5, and that’s EPUB
3, and really, the good news for everybody here, I think, is that HTML5 and EPUB 3
changes the game for reading systems, and the reason for that is that while
that guy at Stanza, Marc Prud’hommeaux, or Peter Sorotokin at Adobe, at the
time could write a EPUB 2 renderer that’s good enough-ish. You couldn’t do
that with HTML5. It would make no sense, whatsoever. No one in their right mind
would do that, and so you have to use a browser engine, and you have to use…
You don’t have many choices, and those browser engines that you’re
going to choose are going to be relatively spec-compliant to HTML, relatively, as we
all know. I mean, they’re not perfect, but they’ve come a long way and they’re
certainly better than the EPUB 2 reading system world that we’ve lived in.
And so that’s coming. It’s just now a process. It’s in this crazy transition
phase right now and so it’s almost, in a way, worse, but the good news is it’s
going to solve a lot of these problems for everybody, and I think that’s one
of the things about EPUB 3 which has, you know, has had challenges along the
way that is going to be really meaningful. It does mean that this user preference
issues is even more challenging, at times, for the reading system developer
because with EPUB 3 comes the ability to potentially style things with JavaScript,
all kinds of other ways of managing how things are…the presentation tier, and so
that is going to be something that’s going to be even more of a thorny problem
to figure out as we move forward. So to get into a little bit more kind
of brass tacks, one thing I wanted to talk about a little bit is: how does a modern
reading system actually work? And one of the things I thought was
really fascinating yesterday about Jimmy’s presentation as he was talking about the
render path and the blockers and the render path and the render tree, and I’m
not going to go into that kind of thing, but I do want to talk about kind of the
architecture here because I think it helps us all kind of understand what’s this
magic happening under the hood. And so what we see here is essentially
Readium SDK, and Readium is something that we’ve been working on now
for three years. We have a new app, Bluefire does, called Cloudshelf Reader.
It’s free. It’s in the App Store. If you are interested in having a
decent EPUB 3 reader, it’s called Cloudshelf…one word, Reader.
That’s in the App Store on iOS, and it’s free, and it does happen
to support a DRM system from Sony DADC called URMS, not that most of you
would care about that, but just FYI, does not support the Adobe DRM. So,
unlike Bluefire Reader which is our legacy product…and, thank you, Laura, for the
kind words, but for us, we consider that now to be a legacy
platform for us, which does support Adobe DRM. Cloudshelf does not, and likely will
not support the Adobe technology for a variety of reasons, one of which is that
Adobe ties their DRM system and their rendering engines together and can’t be
separated, and they do not provide source code anymore, which they used to.
We feel like that’s a platform that we cannot innovate in anymore,
so it was fun while it lasted. But getting back to this. So, Readium,
three years into it…and just to finish that thought, there is an Android version
of Readium…of Cloudshelf Reader coming out here in about the next month, and the
amazing thing about that is we’ve been working almost every day, for three and a
half years, to get an iOS and Android e-reader app to the market, Readium being
a part of that, the Readium Foundation that they helped create three and a half
years ago, have been involved with ever since, and then creating the products
themselves. But, I met three and a half years. And it’s funny sometimes,
a little personal aside, my partner, business partner, Patrick Keating,
and I will talk sometimes and we’ll say, “Yeah,” and I’ll say, “Well, you know,
if we hadn’t invested all this money in building these EPUB 3 readers, we
could both have like, a nice house on the waterfront and each have a Ferrari,
but we’ve got an EPUB 3 reader, so hey.” So, how does that EPUB 3 reader
work? Well, there’s this thing called Readium SDK Core on the left, and that’s
a C++ library, and that C++ library has to do a few things. An EPUB 3 comes
down, and it’s a bunch of resources. It’s compressed in a zip, and inside that
compressed zip is oftentimes a bunch of encrypted assets because it’s got DRM
on it. And so you’ve got compressed, encrypted resources in a file and you
can’t just decompress and decrypt that and write that to disk and then deal with
that because that wouldn’t be kosher with the people who want DRM, and so you’ve got
to go in and figure out what’s in there, create a model for that, a virtual
model of: what’s this architecture? What’s this structure? And then you’ve
got to, on-demand, be able to stream stuff out of there, and so that’s what Readium
SDK Core does. It does a lot of really low-level, and one of the reasons
it’s C++ is that’s very performant, and you might be able to do that in native
code to the platform like Objective-C or Swift on iOS. And in fact, there’s a
project going on right now called Readium-2. It’s not really Readium 2.
It’s not like the upgrade to Readium 1. It’s really a whole different set
of projects that do similar things, but one of the aspects of that is that
they’re approaching that in a native code way to see if they can do the same
fairly low-level things of decryption and decompression, and parsing,
and so on, in native code. And then there’s this thing called RD Services,
which is kind of a glue layer between the C++ code and the native platform, and then
you actually have a web server running inside the application that is actually
serving content into the WebView, so you actually have a local web server
in your app, running, sending these assets in there. And one of the reasons…
We tried different ways to do this, and it’s the only way we could make it
work, especially with QuickTime video on iOS being able to have random access
into that byte stream. We had to use a web server and that alone, just that piece
of trying to figure out: how could we get these assets once we’ve kind
of pulled them and decrypt them? And how do we get them into the WebView?
It actually took us months and months and months of very, very challenging work.
And then you have a WebView, and these applications that iOS and Android have
in their app stack. They have this idea of a WebView, which is basically Safari
on iOS. It was a little different than Safari in the earlier versions of iOS,
and it’s a little more like Safari now. And on Android, you have a similar
kind of thing with Chrome, or what’s kind of like Chrome,
and essentially what you’re doing is you have a browser with no user interface,
not the normal user interface. You’re using it to render content inside
your app. And so you actually take this HTML resources and you’re serving it into
this WebView, but before you do that, you’re going to need to do things like
pagination and be prepared to do media overlays, and other things that are part
of the EPUB spec that a browser doesn’t really know anything about and doesn’t
really want to do for you, will fight you, but you can hammer it and force it to kind
of do it. But what you need to do is you have a lot of JavaScript for that so
you’ll inject a bunch of JavaScript. And Jimmy talked nicely the other day
about…in his presentation about the JavaScript that you might use, or the
other things you might do in order to kind of inject things into a…like, CSS
injection to do styling. That happens, too, but I’m not talking about that. I’m
talking about a big wad of JavaScript that’s going to go in there to make it so
that you can interact with that content, and that’s a reading system
and it’s surprisingly hard. And so as you look at…sometimes, as e-book
people, we might look at these things and say, “Well, it’s just rendering
an EPUB. How hard could it be?” Well, let me tell you, it’s really, really
hard. And so when it goes wrong, have some mercy. Now, one of the things
that Bluefire is doing these days is that we recognize that even though we
created this open-source thing, Readium, which we’re very proud
of and we’re happy that it’s open source, and I think that’s important to the
development of consistency across browsers or across reading systems, and I really
would like to see it get adopted more, but it’s hard. And so one of the things
that we’re doing is we’re creating a new product that we call Readium or Cloudshelf
SDK, and Cloudshelf SDK takes this crazy thing that we saw here, which is lots
and lots of different crazy libraries and a variety of various code languages,
and makes it into something that a app developer could just take, drop one
compiled library into an app, deal only in native code that they know
and is familiar to them with open APIs, and you basically say, in your app,
“Hey, app, render this EPUB,” and it says, “Ah, all right,” and it renders it, and
then it has a bunch of things like event listeners that you can tell it, “Oh, go
to this page,” or, “highlight this word,” or whatever. And it can also go
the other way where you say, “Well, I’ve just highlighted this word.
What do you…? And then the app can say, “Oh, I’d like to send it off to Google.”
But that’s basically what we’re doing now, and we just delivered to our first
client the iOS version of that. And one of the reasons our Android app
is coming slower than I had hoped is that we prioritized doing that because we
recognize that this industry desperately needs consistent EPUB 3 rendering across
platforms, and we need to make it easy to adopt if we’re going to achieve that,
and so that’s what we’re doing. And so I’m hopeful that when we make that
available, and just about anybody who wants to make an app can have a
full-featured EPUB 3 app easily, we’ll make some progress. And so to get
to the kind of last section of the talk, I want to address this question
of, “Okay, it’s crazy, it’s surreal, it’s frustrating, but how do we make sense
of it? How do we deal with it?” And so, I want to talk about what
I call the three legs of sanity. And the first is “designed for machines.”
And I know that sounds kind of counter-intuitive to people who design
beautiful things, but I think it’s an important way to help us look
at things. And what I mean by “designed for machines” is literally designed
for machines, meaning a reading system is a machine in that way. Assistive
technologies are machines, and so we’ll talk a lot about accessibility.
And it’s absolutely crazy enough, even though accessibility is the right
thing to do, morally, and for a lot of businesses and for all kinds of reasons
it actually leads to good-quality EPUBs, and it leads to being able
to make beautiful things. And again, we have to think about the fact that
things are going to change, and have changed a lot and so in the
future, if we’re going to want our books that we have now today to be
readable in virtual reality or in augmented reality, or in things that
we don’t even have words for right now in terms of how we consume information
and content, we have to have contents in machine-readable. If we focus too much
now on what it appears to people to be and less about that structure…and so,
it goes back to what we talked about, that solid structure, that foundation
of building things that…and artificial intelligence and this is, in fact,
going to be important, and it’s, in fact, going on today. One of the
creepiest things I remember reading, I don’t know, seven or eight years ago
was there was the Google scanning thing was going on and they were saying,
“Well, we might not be able to make these available to people.” I remember there was
an engineer from Google who said, “Well, we’re not scanning these for people
anyways. We’re scanning them for the AI to read.” It was a little creepy, but it
actually is meaningful because an AI can be effective in helping us do research
and all kinds of other things in the future, and so designing for machines is,
I would say, the foundation of our approach to creating beautiful and useful
books. Number two, which was about progressive enhancement… In fact, Jimmy
also talked about progressive enhancement yesterday, which I thought was
wonderful. And you know, in the past, in EPUB spec world, we’ve always
talked about graceful degradation, and that’s a thing in the HTML world
and browser world as well, and it’s a fine thing, and then that concept
being that, “Well, if you can’t play the video, then at least maybe you can show
an image.” And I think that I’ve really kind of become very fond of this concept
of progressive enhancement because it’s kind of the same thing looked at in the
other way, right? It’s, instead of saying, “Well, we have this thing we want to make,
and we can make the kind of shitty version of it,” instead, we can start with this
idea of, “We’re making something beautiful and solid, and well-structured
to begin with, and then we can build upon that,” and when we can take
advantage of when things can do better, more beautiful, more interesting things,
then we can take advantage of it, but building from a foundation. And so
I think that whole idea of progressive enhancement is huge, and there was a tweet
yesterday by one of my favourite people, Boulder…funny guy. But anyways, his
tweet was, “Well, given how hostile reading systems are, if you can manage
progressive enhancement in reading systems, you could do it anywhere,” and I
think there’s absolute truth to that. Step three: if you can’t beat them,
join them, and that’s kind of vague maybe, but there’s a…getting back to this idea
of how people…at the end of the day, this whole user-setting things and how
people want to read things. There are times when we’ve resisted, as
the e-book industry, this idea that users have this kind of control, or this idea
that people are going to read on these tiny devices. We don’t want them to…
Don’t read that on that tiny device. Read it on a big device where it looks
beautiful. But at the end of the day, that’s not going to help us and in fact,
embracing that idea…and it all kind of goes together. Accessibility, machine
readability, it all plays together this idea of accepting this idea that while
we’re people who are creating beautiful books, that we’re not creating
them as a…it’s not a sculpture. It’s not something solid in the world
that’s going to be the way it is, the way that we want it to be.
We’re creating something amorphous and something that can change
and finding the beauty in that, I think, is something to value and to help
in our mindset. And then lastly, I’d like to talk about the fact that,
while this industry is crazy, and while it’s hard and it’s stupid
at times, the work that is being done in e-books, even after 10 years of doing
it, it only gets more and more important to me. I mean, the fact that
children in Africa in a small village could have access to essentially
the Library of Alexandria, right? That means something, and the
technological skills that we’re creating in this industry and the problems
that we’re addressing aren’t at all limited to trade books. They’re not
just “The girl on the train.” This is relevant to: how do we communicate human
knowledge? How do we archive human knowledge, how do we tell stories,
and how do we do that in a way that’s accessible, that’s adaptable,
that works on different devices, it works on different screens, it’s
machine readable, all of those things, and that can be malleable so that they’re
consumed in the way that people want to consume them? It’s hard, but it’s not
limited to this industry that sometimes seems kind of small and kind of stupid.
It really is a fundamental aspect of what it means to be human, and the future
of our societies. And I think that while it sometimes seems tawdry, the e-book
world, I think we are really solving difficult problems and making progress
for something much bigger, and that the people who are in this room that help
solve those problems, even when the industry seems tough and it seems like,
well, nobody wants to pay for this kind of skill and this kind of work,
the reality is that this is laying the groundwork of skill sets
that are going to be valuable for many, many decades
to come. Thank you.

Leave a Reply

Your email address will not be published. Required fields are marked *