How to create value with a new thing

(This is the tenth post in a series on the publishing industry’s new product categories.)

The reason why the term ‘book app’ is so dangerous is that it blinds people to the sheer variety there is in content apps and to the many possibilities apps and websites offer.

Continue reading

Readmill versus Kindle – Readmill is worth the hassle

Last week I decided to reread a couple of books in Readmill that I had previously read in the iOS Kindle app.

Let’s see how the two compare.

Kindle for iOS

It’s a turd. There’s no way to express just how awful that app is while still couching your annoyance in polite language.

It’s not awful. It’s fucking awful.

Of course, some of the annoyance stems from general Kindle awfulness such as frequent bugs in how the platform does sharing and general disregard for basic typography.

It was boring anyway

It’s completely unacceptable that a reading platform should drop the last few words off an even short passage, but that’s exactly what the Kindle does (for iOS at least).

  1. Highlight a passage.
  2. Go to
  3. Discover that the last few words of all of your highlights are missing.
  4. Swear like a sailor who has banged his knee.


It reloads and re-renders constantly. Which wouldn’t be so bad if re-rendering didn’t lose your history. This means you can’t go back from a link if you follow it and the app re-renders for some reason.

Imagine if Mobile Safari, in addition to having to frequently reload the page due to memory and caching problems, it lost all of your history in the process.

Then imagine that it does this every time you put down your iPad or switch between apps. Now you know what the Kindle app is like.

Finger-painting with overcooked pasta

Like other Kindles it repaginates on every link. Reading, navigating, and highlighting is like sieving cold overcooked pasta with your bare fingers.

The economy kind of pasta, the type you get almost for free from the bottom shelf in the supermarket. The kind that disintegrates when you put it in the pot. Not the nice wholewheat kind.

There is no consistency in position or rendering. This compromises the reader’s visual memory and is generally annoying. Like when you end up navigating back and forth a bit (y’know browsing the book) and then get back to your spot to get back to reading, it’s repaginated so nothing looks the same. Very annoying.

Crayon scribbles have better typography

The default stylesheet makes the default font (Georgia) look even more pedestrian and uninspired than it is normally. And it’s a very pedestrian typeface to begin with.

Of course, in leu of a considered default stylesheet with thought out proportions, line-height to font size ratio, indentation, and margins, we get escalating configurability.

The thing is, no matter how you tweak the line-height, margins, or which of the provided fonts you select, the app’s typography remains subpar. It just isn’t nice to read.

The font selection is crap and leaves out a host of interesting built in fonts. Providing better fonts would be a start.

Your finger is an error-prone highlighter

Swipe highlighting is a gimmick that results in having to repeatedly highlight, then delete highlight, then highlight, then delete, etc. to get it right. It’s incredibly error-prone because it doesn’t offer any method for adjusting the selection. The only advantage it offers is the ability to highlight across page boundaries which, frankly, is useful. But, surely, there’s some other way of accomplishing that without taking away the ability to adjust your selection?

Swipe highlighting: rubbish gimmick that disregards everything we know about usability.

Nobody wants to steal your stupid book

Copy-paste is disabled in the Kindle apps, both on iOS and Mac. Couple this with the bug above and this means there is no way for you to easily quote a passage without having to retype parts of it.

Why the hell do you need to disable copying and pasting? What the fuck is wrong with people?

Note to authors and publishers:

Quoting your books is a good thing.

It spreads the word. Gets you new readers. You know, all good stuff. You should be furious that Amazon is disabling copying and pasting. In doing so it’s just rounded all of your marketing staff out back and shot them in the head. You don’t want to be beholden to Amazon’s whims for marketing for the rest of your careers, do you?

Note: this isn’t a question of DRM. Even Copy-paste isn’t enabled in any title in the Kindle app, not even in the DRM-free titles.

No polish, because you know that old saying about turds and polish, right?

Kindle iOS really lets you down on the small details. For example, magnification when you highlight/select is blurry on retina devices.

There’s also this curious item in the settings called ‘Publisher Font’. The fun part is that it doesn’t seem to do a thing other than switch the font to Georgia no matter the ebook or whether it has a font embedded or not. The app doesn’t seem to support embedded fonts so that can’t be what that menu item is for. Why they ship it broken like this is beyond me.

Don’t get me started on the UI in general…

And then there are the odd updates like the one that removed margins show that the main reason why the Kindle for iOS developers add configurability is that they don’t have a clue what sane defaults would look like.

Their development process seems to look like this:

  1. Make a change to the defaults that a first year BA student in design would know is dumb.
  2. Witness a massive backlash from readers.
  3. Think that nobody can be pleased and ‘fix’ it by adding configurability without even trying to understand the underlying problem.

In short: Kindle for iOS sucks.


In comparison, Readmill is a joy. The default font is an excellent, beautiful, choice—looks like a custom typeface, not one of the platform’s built-ins. It’s the only iOS reading app where I prefer the default font over a good embedded font.

It automatically adjusts the margins when you resize the text so that the width of the text-column never gets unreadably wide or narrow.

The typography in terms of font sizes, line height, and margins are all inter-connected that way to maintain optimal readability at all font-sizes. The result is an app that is a joy to read.

Quote, share, discuss—it’s all good

  • Here we have none of that nonsense of disabling copy-paste.
  • Everything regarding highlights, notes, online sharing (twitter, facebook, wordpress), and discussions is top-notch.
  • Highlights navigation, both in-app and on the web is dramatically nicer. The Highlights sidebar is a nice touch.

UI niceties

The Readmill chrome is nice enough for you to sometimes page through an ebook and forget it is there as you get engrossed in the book. This while still being usable and accessible. There is no higher compliment for an ereader UI.

Being able to swipe up or down to adjust brightness is a nice touch. You could live without it, but after getting used to it you don’t want to.

The page number indicator is a nice and simple way of showing your progress through the book. Since the ebook is rendered as pages it makes sense to count your progress in those pages. No needless reinvention of the wheel like the Kindle’s opaque location numbers.

The only thing missing is the iBooks-style “X pages left in this chapter” which I’ve found very useful. Of course, Kindle doesn’t have any progress indicator when the chrome is minimised and an opaque, inaccessible, one when the chrome is visible and in the way.

It is slightly annoying that after you press a link you have to switch the UI chrome on to find the back link. In theory that should be simple to fix. No reason not to show the back link in some way even when the chrome is switched off.

Sidebar on configurability

A love of preference toggles and configurability is an endemic among the engineeringly minded. It’s easy to see why: they don’t mind the cognitive overhead because it fits in with how they approach all of their problems.

Having some preference toggles is a good thing. But when you add toggles and sliders for margins, font size, indentation, and more, you escalate the complexity that users need to to tackle in your app.

A reader who wants to increase the font size will now have to deal with all of those other settings because they are interrelated. Font size, line height, and margins are all cogs in the same typography machine. Change one thing and you affect the other. So a simple task to change the font size can easily become a multi-minute odyssey among a forest of buttons, toggles, and sliders.

People are also very bad at assessing their own needs. A common ailment among my relatives is a tendency for muscle, joint, and other physical aches and pains due to bad ergonomics. (A curse that I thankfully am free of.) What makes the problem worse is that they used to be bad at figuring out how they should sit, what chairs they should be using, how to use their tools, etc.. They needed to be told, by an expert. Even then, following that advice was often uncomfortable at first, even though it helped address the problem in the long run. Without expert guidance, most people will choose ergonomics and positions that will actively harm them in the long run.

The same applies to reading system configurability. People will most of the time choose settings that will make them read slower and remember less.

Finally, by adding all of those preference toggles to your reading app you have turned it into a design tool. By letting the reader control all of the variables you have forced them to become a typographer and designer. They end up having to take on all of the complexity of designing an entire ebook for themselves.

Moreover, it’s a crap design tool. I know a couple of things about designing for reading and I can’t for the life of me get an optimal reading experience out of the Kindle app or Marvin (an otherwise excellent app). I can never get the proportions right between the width of the text-column, typeface, line height, and font size. I can get those apps to be readable, sure, but never optimal.

The only design configuration a reading app should have are font size, inversion (switching to light on dark), and contrast. These toggles are based on physical reader needs. Some eyes just work differently from others. They aren’t preferences but requirements for a section of your readership.

Everything else should be controlled by the system and derived from the variables the reader does control. That way you give them an optimal reading experience without excluding anybody.

Which means that the only thing missing from Readmill is a contrast slider.


The idea of having an API for my reading platform of choice is intriguing. It means that the platform owner doesn’t have to solve all of the issues the readers have. In theory, that should mean that I could put together a script that exports my Readmill highlights and notes into a usable format for writing. And that means that all sorts of apps out there will and have been rolling out Readmill features. It promises to increase the benefit I gain from the platform immensely.

Here come the downsides

Readmill’s single biggest flaw is the absence of anything resembling library management. Your books are presented in a very nice looking list that you can filter to show only finished books or those you’re currently reading.

Of course, Kindle for iOS’s library management is also rubbish for largely the same reason. You only have a list of your stuff that you can filter in rather limited ways.

Both apps need collections. They need the ability to browse the book by author. And because Readmill also supports PDFs you need to be able to filter by file type. Browsing by subject matter would also be nice, but the general quality of ebook metadata might not be up to snuff for that to work. Of course, if there was an app out there that used ebook metadata in interesting ways in its library UI, then maybe publishers would be more motivated to put in the effort to make it nice.

One serious annoyance is that sometimes Readmill will get the metadata seriously wrong (like marking all volumes of a book volume 1). Without an ability to correct that metadata in the app (while sending the correction upstream as a suggestion, of course) few people are going to bother to tell Readmill about errors when they happen.

Most people’s routine is a bit like this:

  1. Load the ebook into Readmill either via a ‘Send to Readmill’ button or opening it directly using the app on the device.
  2. See that the service seems to give some of the ebooks the wrong title.
  3. Either ignore the error and read on or switch to another app in frustration.

Very few are going to bother with going to the Readmill website, navigate to the book page and make a ‘suggestion’ there. Readers need to be able to correct a book’s title in-app

Finally, none of the major ebook vendors, at least those with any selection to speak of, offer direct Readmill integration. Why Kobo doesn’t let you set it up so that all of your purchases get automatically added to Readmill is beyond me.

The thing everybody does wrong

All highlights lose all formatting and don’t include images. This is the case for all ebook reading systems today. I know this is a difficult technical problem (well, so I’m told) but this is essential for any book that isn’t a prose novel. Formatting for many titles is integral to their meaning. Changing a list into a jumbled paragraph can render a highlight unreadable and this happens all too frequently.

Conclusion: Readmill is worth the hassle

Even without the social features or the highlighting features, Readmill’s UI, design, and typography are enough to make it, in my opinion, the best ebook reading app available for iOS devices.

When you add the platform’s general features such as social sharing, discussions, and an API, then it becomes an unbeatable choice. It’s so good that it’s worth whatever hassle you have to go through to get your ebooks into it. Even if that means using a notoriously crap application to convert your existing library to DRM-free epubs. Even if that means having to manually download the Adobe DRM files from Kobo to upload into Readmill whenever you buy an ebook.

I’ll put up with all sorts of nonsense now when I’m trying to get ebooks to read because reading in Readmill is nice enough to be worth the hassle.

Readmill is, quite simply, the benchmark for all future ebook reading apps.

Ebook silos, update

Yesterday, I wrote a post on ebook silos and missed opportunities.

Some people seem to be missing the core criticism in the post. The problem, as I see it, is in the infrastructure and in the market we have in place. This is not a lament for how lazy people must be or how stupid existing developers are for not implementing these things already.

Existing ebook reading apps are bland out of necessity. The ones implemented by silo owners need to appeal to and be useful to everybody. They can’t not be generic. Specialisation is not an option when you need to appeal to the lowest common denominator.

The independents have a different problem. They need to both implement detailed support overly complex file formats and they need to target one of the silos (generally Adobe’s playground, which is a fraction of the overall market).

Because the market involved is so small and the end result is that their apps have to have broad appeal. A specialised app targeting a fraction of a fraction of a market is not economically viable when you are employing a team of developers.

The solution to this conundrum is both simple and difficult (like so many simple things are).

Generally speaking, the way to promote variety in any given software genre is to make sure that it’s possible for a solo developer or a small team of developers to create and maintain an app in the genre. Only a solo developer (maybe a duo) can hope to make a living by addressing a fraction of a fraction of a market.

I’m convinced that, if a solo developer found a way to implement one a specialised ereader that was useful and valuable to readers, they’d be able to make a decent living from said app.

One such example is Marvin. It’s an ereading app that focuses on configurability, text analysis, Dropbox support, proper annotations export, and a lot lot more. It is quite different from most other ebook reading apps in the market and is quite excellent. It’s not for everybody, but it is unique enough for there to be a large group of people who both have been waiting for an app like this and are eager enough to use it that they are willing to break the DRM on their existing library to use it.

Anybody who is in any way dissatisfied with their current ebook reading app owes it to themselves to try it out.

Which brings me to the compromises needed to make the byzantine mess that are ebook file formats manageable by a small team. Marvin offers a few pointers in that direction:

  • No DRM support.
  • Only EPUB 2.0 support to begin with.
  • Limited support for ebook design and styling, which is okay for a small app because all of its users opt in to no styling. They know what they are getting.
  • No support for video or audio.
  • No FXL support.
  • No PDF support.
  • No attempt to achieve full spec coverage but instead a laser-like focus on implementing features that crop up in customer feedback.

Now, Marvin owes a bit of its success to luck, but I still think it offers us hope for how things could go in the future. Solo developers and small teams will experiment with apps. Some will fail. Some will succeed.

—Couldn’t Readium SDK help?

Possibly, but that’s not what it’s for. As I see it, the primary goal of the Readium SDK is to get large corporations who are competitors to collaborate on improving their support for the various incredibly complex flavours of EPUB (2, 3, FXL). This is hard enough without trying to address the needs of solo developers as well.

The cost of acquiring a license usable in a commercial product bears this out. After September you need to pay $60 000 to join and get a license or you need to contribute work and source code. Both are going to be way beyond the means of a solo developer attempting the already difficult and risky task of a specialised ebook reading app.

And that’s okay. Readium SDK has an already unenviable goal (achieve full format support in all major big-corp generic readers). Maybe once that’s achieved and all major apps have shipped with full EPUB3 support, maybe then the foundation will reassess the licensing terms. Before then they are more than justified in focusing on trying to solve the problem they set out to solve.

—What would really help?

More publishers going DRM-free would help a lot, especially those catering to less price-sensitive specialist subjects. That would open up the market for a developer to enter with a specialised app catering to those readers.

In fact, O’Reilly’s pioneering work with DRM-free might well be an opportunity for a developer-oriented ebook reading app, one with built in REPLs and consoles for various languages. Imagine being able to run and play with example code in a variety of common languages from a dev ebook just with a tap. Imagine having access to each platform’s documentation as you read a book on a specific problem area; having access to the official documentation for a method with just a tap.

More comics publishers following the example of Image Comics (they sell DRM-free comics direct, not enough of them yet, but it’s a start) or Thrillbent might open up the field for a specialised comics-oriented ebook reader, one that only supports FXL ebooks and PDFs. They might even be justified in only supporting PDFs and CBRs.

I’m convinced you don’t need full EPUB3 or DRM support to create an excellent app that is sufficiently useful to enough people to be a viable business for a tiny team.

The app would have to be specialised and solve very specific problems for very specific group of people with very specific needs. Just making an ebook reader with cool and unusual features isn’t going to work again, even if it did work for Marvin. You need to both delight and remove pain. Delight alone will not do.

I’m not saying it would be easy. It’s clearly a difficult problem. But it would be interesting.

Ebook silos and missed opportunities

ETA: I’ve posted a followup to this post that hopefully clarifies things and offers a few suggestions: Ebook silos, update.

Ebooks can be transformed by context. Print books cannot. No matter where you take the print book, no matter what room you read it in, it will remain in the same form and have the same affordances as it did on the day it was first stacked in the bookstore.

An ebook could, in theory, be reformed, rebound, and recast at will. A writer who is reading for research could open it in an ereader specifically designed to enable writing and integrates directly with writing tools. A student could use a specialised ereader that is full of mnemonic tools, structured note-taking, and export functions that integrate with common reference management software. A genre fiction reader might use an app that stamps all ebooks into the same aesthetic template, configured by the reader into the form they consider ideal.

It’s easy to imagine how these would work:

The writer’s ereader wouldn’t atomise the reader’s annotations but would present the annotations for a book as a single, freeform, document that could be edited, extended, filled with notes and exported in formats compatible with common writing tools (Word, Scrivener, etc.). Every set of annotations would be a commonplace book in machine-readable form. Bonus points for automatically syncing to Evernote and Dropbox.

The student’s ereader would integrate directly with Endnote and offer mnemonic features such as regular pauses for recollection, forcing the reader to note down what they thought the preceding pages were about (research shows that if you stop, close the book, and try to recollect what the preceding pages were about your recall will subsequently be improved). There’s a lot of research on learning styles and tools that would be a goldmine for this sort of UI experimentation.

Then there’s the potential for a specialised comics app. Fixed layout formats require dramatically different UIs for optimal treatment of annotations, clipping, highlighting, and browsing. It’s easy to imagine a comics ereader that makes it easy to clip and visually annotate sections from the comic book. It’s also easy to an app that specialises in the format would offer a much better experience than the schizophrenic status quo.

The genre reading app does not have to limit itself to design configurability. A reading app for crime and mystery stories could integrate an extensive database of firearms, poisons, historical crimes, police terminology, and common codes for crimes.

That’s without getting into the various features that nobody offers because everybody’s trying to be the same:

  • Scrolling instead of pagination. I’d jump on a well-implemented scrolling ebook reading app (iBook’s jerky crap is not it).
  • Autoplay/autoscrolling. Sometimes you want to force yourself to keep a reading pace.
  • In-text annotations. Sometimes I want to edit the actual ebook itself.
  • Dropbox syncing for my library and annotations.

None of these features require new standards or extensions to old ones. They could work with plain text if you wanted.

An app that is everything to everybody is bland. Generic is dull. Specialisation creates immense value.

But instead of specialisation and diversification among ereaders we see convergence. Ebook reading app become more similar with every release. They all aim to support the same rendering features, in roughly the same way (infuriating differences in style overrides notwithstanding), surrounded by the same constellation of widgets and tools.

  • Highlights? Check.
  • Highlights made more ‘natural’ by behaving like a highlighter? Check.
  • Notes? Check.
  • Notes mades social in some way, via sharing or a dedicated service? Check.
  • Highlights that lose all formatting whenever they are moved into another context? Check.
  • Offer a selection of four to five fonts (plus the ever present ‘publisher defaults’)? Check.
  • Sync all of this bland crap using a proprietary syncing service allowing no other alternatives.
  • Limit the export of all of this bland crap to something even blander and more useless than what you already offer like text-in-body email.
  • A neato brightness UI that makes people swoon because their Stockholm syndrome has lowered their expectations so far that they have to look up to see the bottom of the Mariana Trench.

Check. Check. Check. Any ebook reading app that doesn’t behave like this is aiming to. This is the ‘ideal’ they all seem to be striving towards and when pressed for answers on why they don’t try to solve hard problems (like proper annotations export), the only reply is that the standards for those hard problems aren’t there yet.

And they will never be there because the best standards are those that standardise existing best practice. Nobody offers proper annotations export and so there is nothing to standardise.

But just focusing on the individual features is the wrong way to look at the problem.

Which, obviously, is silos. You’re locked into the ecosystem you bought the ebook from. Nobody will ever create a specialised Kindle ebook reading app for writers or for students. There will never be much variety in how ebook reading apps based on Adobe’s RMSDK behave. The only app that will ever work with ebooks bought from the iBookstore is iBooks.

The one major and unique strength that ebooks have over print, flexibility and fluidity, the characteristic that has the biggest potential for adding value, has been thoroughly walled away by the silo mentality. Ebooks could have been a transformative sea change in how we read books but instead are nothing more than a second-rate alternative to cheap paperbacks.