Micah Bowers, Founder and CEO of Bluefire, was a speaker at ebookcraft 2017. His talk, titled Ebook Apps from the Inside Out, is an exploration of the past, present, and future evolution of ebook reading applications and how that impacts and informs the art and craft of creating ebooks. We hope you enjoy it as much as we did.
(Scroll down for a transcript of the conversation.)
Transcript
Ainsley: Welcome to the BookNet Canada podcast. I'm Ainsley Sparkes, and I'll be your host for this month's episode. In March, 2017 in Toronto, BookNet Canada ran its yearly conference dedicated to ebook production, ebookcraft. It's a mix of practical tips and forward-thinking inspiration from and for ebook developers. One of the speakers at this conference was Micah Bowers. Micah is the founder and CEO of Bluefire, where he helps businesses and institutions worldwide deploy mobile applications, server software, and cloud services for the distribution and consumption of ebooks, and other forms of digital publications. Micah also serves on the board of the Readium Foundation, an open source software organization, collaboratively developing technology to accelerate the adoption of EPUB3 and the Open Web Platform by the digital publishing industry. His talk at ebookcraft, "Ebook Apps From the Inside Out," was an exploration of the past, present, and future evolution of ebook reading applications and how that impacts and informs the art and craft of creating ebooks. From Adobe Digital Editions to designing for machines, you'll learn a lot in this episode. So, let's turn it over to Micah.
Micah: As mentioned, I'm gonna talk about ebook 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 ebooks is that, I recognize that this industry is surreal. And I don't know how many of you're familiar with the work of Franz Kafka? I can see hands. Everyone knows him. All right. So, most of us know Kafka. Well, to me, ebook 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 wanted to start with my own personal journey on how I got to ebooks. 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. And so when I first got into media years ago, 1985, I 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 the ways that we communicated, in 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 in the early days of Dynamic HTML, which we called DHTML hell, which we're kind of still in today, and video, all put together. And I worked as the head of 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. And we were working with Adobe in this new company, Bluefire, back in the mid, it was about 2005. Yep. And we ended up hooking up with a gentleman named Bill McCoy on a different project, that was not ebook-related, but then he ended up going to ebooks. And I got introduced to it. And I really never knew how important texts would be in this idea of multimedia. And ebooks really did that for me. And so one of the things that I really found fascinating about ebooks 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 we made a little ebook 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 though, 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 is, 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 ebooks have a couple things that are really important. They have this Texas way to glue everything together in a very cost-effective way, just about anybody can do it. And it's a mental model that 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. And it hadn't really happened before. And so ebooks became... I really didn't expect it, 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 at ebooks. 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'd love to tell about how that came about, and it has its own Kafkaesque story to it. But one things 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. And there was this great thing called Flash Paper 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 gonna be great." We'll take this new thing called EPUB2 that no one had seen yet. In fact, it wasn't ratified when we first started working on it. And we'll make a reflowable 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. We'll make it really simple, you can style it any way you want. So, a 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 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, 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 gonna be there in time. And we had to ship this thing in time because ebooks were being taken out of Acrobat Reader, which that's where ebooks 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 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, at the very last minute, take this crazy monster that we had created that was a EPUB renderer that no one had ever seen in 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 Kafka-esque world that we live in, because you could look at it and say, "Well, 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 ebooks, it was EPUB2. For me, it was the introduction. And it hadn't been ratified yet. And EPUB2 was and is interesting because, because of the limitations of the HTML profile, the XHTML profile there was, and due to the target devices at the time, which were these very weak processors with very cheap hardware really. I mean, at the end of the day, the screens that came with them were by far the most expensive part of these eReader 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 eReader 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, 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 power to 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 it'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. White 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 EPUB2. And, of course, what you see in these devices and in these apps, 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 wanna highlight or you wanna select text, well, the reading system implementer has to actually do some fairly odd things to make that work. You've gotta detect where the finger is, go back through and do kind of in-memory figure out, well, where is that? 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 differently 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 underdressed is the issue of user preferences. And this has been something that I've seen throughout my career. And it really came early on when there, 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's 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 edge. And at the beginning, they completely just stripped all the... Because 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 or 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 sky with white clouds in the background of their book. And I just found that insane, but 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 a 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 what interestingly enough, the way the reading systems have to deal with that it's rather challenging, and it's imperfect. So, for example, when we are dealing with HTML with EPUB2, and we're trying to make user settings, we're trying to override known selectors, right? So, we say, okay, we're gonna... User said they wanted night mode, they want black background and white text. And so we're gonna 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 ebooks can completely defeat that. You can go in and you can, hey, 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 ebooks apart, maybe even turn them into databases like Kobo does, or put them through some processor before they even distribute them to strip out your markup. But we don't do that. We're against that whole idea at Bluefire. But it is challenging because, oftentimes, it doesn't work. And we will have a lot of times where consumers will contact us as support and say, "Your app is broken, that this tech isn't rendering correctly." And we'll find like, "Oh, that's actually, no, that was the way it was intended to be. You just perceive that'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 thing, 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 of 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 a hundred 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. I mean, I perceive... 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." And there's other things where I think about DRM and people tend 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, right? So, Kindle is a silo in a lot of ways. But it's not just DRM, but it's file format, its devices, its 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 that. 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 probably switched four or five times different browsers that I've used and 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 that. But in the ebook 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 gonna read them in Bluefire Reader. You're not gonna read them on the NOOK. And therefore, you don't have this normal force. And I think that's one of the biggest things the 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 to 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 the 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 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 exists 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 challenge that 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 moralistic terms of how people talk about DRM, which is its own conversation. And so along came HTML5, and that's EPUB3. And really the good news for everybody here, I think, is that HTML5 and EPUB3 changes the game for reading systems. And the reason for that is that while that guy at Stanza, Mark or Peter Zwack at Adobe, at the time, could write EPUB2 renderer that's good enough-ish, you couldn't do that with HTML5, 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 gonna 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 EPUB2 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 EPUB3, which has had challenges along the way that is gonna be really meaningful. It does mean that this user preference issues is even more challenging at times for the reading system developer because with EPUB3 comes the ability to potentially style things with JavaScript, all kinds of other ways of managing how things...the presentation tier. And so that is gonna be something that's gonna 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 is he was talking about the render path and the blockers in the render path and the render tree. And I'm not gonna go into that kind of thing, but I do wanna 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 AppStore. If you are interested in having a decent EPUB3 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 technologies for a variety of reasons. One of which is that Adobe ties their DRM system and their rendering engines together and cannot be separated. And they do not provide source code, anymore, which they used to. So, 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, you know, 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 eReader app to the market, Readium being a part of that, the Readium Foundation that helped create three-and-a-half years ago. I've been involved with ever since and then creating the products themselves. But I meant, 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 EPUB3 readers, we could both have like a nice house on the waterfront and each have a Ferrari. But we've got an EPUB3 reader, so hey."
So, how does that EPUB3 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 EPUB3 comes down, and it's a bunch of resources, it's compressed in the zip. And inside that compressed zip is, oftentimes, a bunch of encrypted assets because it's got DRM on it. 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 gotta 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 gotta on-demand, be able to stream stuff out of there. And so that's what really Readium SDK Core does. It does a lot of really low level. And one of the reasons is C++ is that's very performant. And you might be able to do that in native code to the platform, like objective SEER or Swift on iOS.
And in fact, there's a project going on right now called Readium 2. That'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 these 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 reason... We tried different ways to do this, and there's the only way we could make it work, especially with QuickTime video on iOS being able to have random access into that bite 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, actually took us months and months, months of very, very challenging work.
And then you have a WebView, and these applications that iOS and Android have in their AppStack, they have this idea of a WebView, which is basically Safari on iOS. And 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. It's 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 gonna 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 handle 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, right, to do styling. That happens too, but I'm not talking about that. I'm talking about a big wad of JavaScript that's gonna 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 it, sometimes as ebook people, we might look at these things and say, "Well, it's just rendering 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 lots and lots of different, crazy libraries and a variety of various code languages, and makes it into something that an 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 that can say, "Oh, I'd like to send it off to Google." But that's basically what we're doing now.
And we've 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 are prioritized doing that because we recognize that this industry desperately needs consistent EPUB3 rendering across platforms. And we need to make it easy to adopt if we're gonna 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 EPUB3 app easily, we'll make some progress.
And so to get to the kinda the 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 wanna talk about what I call the three legs of sanity. And the first is design for machines. And I know that sounds kind of counterintuitive 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 design for machines is, literally, design 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 key crazy enough, even though accessibility is the right thing to do, morally and for a lot of business 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 gonna change, and have changed a lot. And so in the future, if we're gonna 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 an 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, eight years ago, was there was the Google scanning thing 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." But 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 the 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 wanna 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 that 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. 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.
And step three, if you can't beat them, join them. And that's kind of vague maybe, but there's a... Let's get back to this idea of how people... At the end of the day, this whole user setting things and how people wanna read things. There are times when we've resisted as the ebook industry, this idea that users have this kind of control or this idea that people are gonna read on these tiny devices. We don't want them to read. 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 gonna 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 it's not a sculpture, it's not something solid in the world that's gonna 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 ebooks, even after 10 years of doing it, it only gets more and more important to me. What I see the... I mean, the fact that children in Africa in a small village could have access to the, 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's sometimes seems tawdry, the ebook 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 gonna be valuable for many, many decades to come. Thank you.
Ainsley: We hope you've come away with some inspiration and ideas about what the future might hold for ebook creation. To learn more about ebookcraft or the work we do at BookNet Canada, visit booknetcanada.ca. Thanks to Micah Bowers for speaking at ebookcraft. And thanks to all those who helped make ebookcraft a success, including the attendees and all the great speakers. We gratefully acknowledge the financial support of the government of Canada through the Canada Book Fund for this project. Thanks for listening. Until next month.
