Kathy Sierra’s Badass: Making Users Awesome – the book you all should read

I’ve been reading and re-reading Kathy Sierra’s book Badass: Making Users Awesome since it was released the other day and I can’t recommend it enough.

I’ve been obsessing about teaching and skills development theory for over a decade now, ranging from the ideological like Ivan Illich and Neil Postman to the philosophical like John Dewey.

Oh, and so many research studies.

All this time I have never encountered a book that so cohesively ties together so many of teaching and training best practices into a single, sensible conceptual model.

But Kathy Sierra doesn’t just pull it off she does so with amazing clarity—explaining complex concepts in simple ways without dumbing them down.

Then she ties it all in with user experience software design without skipping a beat.

If you do any teaching or training, this should be the next book you read.

If you do any UI, UX, or product design, this is the book you should be reading right now.

It’s a short and highly readable book so you have absolutely no excuses not to.

It’s awesome. Buy it. Read it.

The print design mentality

Screen design isn’t print design and will never be print design, no matter how high the screen’s resolution gets.

Digital design needs to account for a level of changeability and dynamism that print has never had to deal with. The interaction model of print is embodied in the book object and not in the on-page design. The interaction model of digital has to be accounted for in the screen design itself and functionality needs to be specifically designed.

Continue reading

Great text transcends nothing


Working on ebooks is how I make my living. Therefor you should take everything I write about ebooks with a grain of salt. Anybody whose economic future depends on specific viewpoints is more likely to hold those views, if not for any other reason than to avoid the discomfort of cognitive dissonance.

Yes, that does mean you should be sceptical about bankers on banking, real estate agents on real estate, and insurance salespeople on insurance, especially when they are defending the societal value of their profession as a whole. Assume they are biased and compensate accordingly. Of course, that can backfire when the professional in question is aware of their own biases and has already tried to compensate.

With that in mind…

There’s a peculiar sort of joy that comes from reading a good print edition of a great book.

@AthenaHelivoy said this here thing:

If Ebooks looked good, this sudden “novel” devotion to “intrinsic worth” wouldn’t have sprung up. … “Great lit transcends blahblah” is an uralt non-argument revamped for Ebooks.

From here and here.

There we have the problem with ebooks today in a nutshell (that and the fact that none of us actually own the ebooks we’ve bought, we only own licenses).

That isn’t to say that the ebook reading experience can’t be as good as reading print in some cases. The accessibility features of many reading apps open new titles up to those partially or wholly without sight. Changing the font size similarly helps those with bad sight. Those who read a lot of books appreciate the ebook’s relative weightlessness.

But for the vast majority of readers, ebooks as presented by Amazon, Apple, Kobo, and co. have only three real advantages. They are:

  • Cheaper
  • Immediate
  • Lighter

That’s it. Those are important advantages and, in many cases, all people need to pick an ebook over print. But ebooks still have miles to go.

Ebooks generally look worse than your average trade paperback or hardcover book. If competently done, they can manage to match or exceed the quality of a cheap paperback.

But if you pick an ebook at random and compare it to its print versions, odds are the ebook will look worse:

  • Typography will generally be worse. Automated pagination in existing ereaders ignores quite a few details that print typesetters pay a lot of attention to.
  • The resolution will be slightly lower, even on retina display screens.
  • The typeface will look worse and be less readable. Most fonts are designed for print and will look too thin and wispy on a high resolution screen. Odds are none of the fonts your app lets you choose are properly designed for screen reading.
  • On a lot of devices and many apps (Android and older iOS devices) your interaction with the ebook will have a slight but infuriating lag in even text-only novels. And if your book has a lot of images you can expect a substantial infuriating lag.

Moreover, as I’ve written about before, for many readers ebooks the experience as a whole will be worse because tactility is an important part of how we experience and remember things.

Some of these problems are solvable in practice. We can embed fonts that have been designed to look good on screens. We can mark the ebook up properly and pay attention to screen-specific detail in the stylesheets. And we can make sure to read our books in apps and devices that are responsive and render the ebook well.

Other problems are solvable in theory. LaTex and similar systems show that automated pagination should be a solvable problem. And there shouldn’t be any reason why we can’t match the overall typesetting quality of print.

The problem is that we manifestly don’t. And that’s because none of the key players care. It isn’t an issue of can’t but one of won’t.

Publishers don’t care about ebook quality. They’ll scrutinise every detail of the print edition while, as @liza quipped at the Books in Browsers conference the other day, not bothering to mark up a list in an ebook as a list. Ebooks, even from big publishers, are full of OCR errors and other mistakes. Almost every ebook backlist title I’ve read so far has had an OCR error in it somewhere (a numerical ‘1’ replacing an uppercase ‘I’ being the perennial classic). Publishers quite simply do not care what the ebook version looks like.

Ebooks are often hidebound by the demand that they match the styles of their print edition, even when many of their print design choices are grossly inappropriate for digital. (Like drop caps. Drop caps simply do not work in digital since they can’t be done without compromising accessibility where they break up the word.)

Hang on…

The Drop Cap rant interlude

Modern drop caps are a nostalgic affectation by people keen on spicing up their books with decorations but who are too stingy to pay an actual illustrator to draw an actual goddamn illustration.

Originally most drop caps were proper illustrations. Each was lovingly rendered with an awareness of its context, often commenting on them in witty and clever ways, and they did a marvellous job of spicing up the reading, as all well-made illustrations do. Reusing the drop caps from a book made about as much sense as reusing the illustrations.

Then drop caps became homogenised, pasteurised, blended, stamped, and cookie-cut into standard typographic forms. They got pre-made as fonts for people who wouldn’t know decent illustrations even if they were beaten into their heads at a picket line. People who think they can get the same effect as an illustration by buying something pre-fabricated from a font foundry.

You can’t. Never. The only effect you get from a modern pre-fabricated drop cap is vacuous nostalgia and the joy of being able to piss on the grave of the art of book illustration.

Then add to that the fact that they simply do not work in a cross-platform and accessible way in digital and you get only one conclusion:


Yes. I hate drop caps. Unless you’re doing them properly as custom illustrations, of course. Then you get a pass.

The Joy of Reading

There’s a hard to define thrill that comes out of reading a good book that is well supported by it’s context and design. It’s like those moments in theatre where everything comes together to bring you a well-written play, with a great set design, perfect costumes, fantastic actors, with tone-perfect direction. The text of a play cannot transcend its actors or its staging no matter how great. Its words cannot dispel the curse of a mumbling actor or wash away the colours of a garish set. No phrase, no matter how beautifully crafted, can tone down an overacting diva.

A novel, no matter how great, cannot transcend its typography, packaging, or design.

Ebooks, quite simply, have to improve.

The Google Wave Heuristic

What dooms software projects?

Everybody quotes the opening lines of Anna Karenina at some point. You know the one. It’s the bit about happy families being all alike in their yaddayadda-blabla and how unhappy families are all unhappy in their unique blablabla.

There’s plenty of stuff in Anna Karenina you could quote, but I guess most people give up on it before they get to the second half. Which is a pity because it’s a good book.

It’d be easy to reuse that line in a software context and say that software projects that succeed are all alike (well executed, designed, and marketed) while those that fail all fail in their unique ways.

Unfortunately, it’s the other way around. Every software product that succeeds seems to be its own story, have its own value proposition and work in its unique way from implementation to marketing. Software projects that fail, conversely, tend to careen off the road in similar and often predictable ways.

The biggest and most common mistake is to build software nobody has any need for. It doesn’t matter how well executed an app is if nobody has any need for it. No need, no buyers, no income. Product fails. This is surprisingly common, even in corporate projects for in-house use.

Then there’s the septic code issue. Some code is simply so bad that it’ll take the entire project down.

But one rule of thumb for spotting potential failures that I’ve been using is what I call the Google Wave Heuristic. (Just a rule of thumb, mind. Not a hard and fast law.)

If the product’s tentpole feature doesn’t directly help the user at the task they’re using the product for, then the product is likely to fail.

In Google Wave’s case the tentpole feature was real-time synchronisation and messaging but the products pitched were chat apps and document collaboration. Neither of the major use cases of Google Wave directly benefited from its tentpole feature. From the user’s perspective, Wave chats weren’t an improvement on a nicely implemented native client and document collaboration wasn’t any better than in Google’s own Docs.

Another example was a major product launch I was involved in years ago. A software company released a new major version of its application and the flagship feature that had consumed the majority of the team’s production hours was (drumroll please) … a new licensing system. Its main benefit was that it made the application hard to pirate. It was also incompatible with all existing off-the-shelf licensing and ecommerce systems.

The initial launch was a massive dud but recovered later on as the team knuckled down on improving the app. It finally began to gain headway once it showed substantial improvement over its predecessor. Of course, the next major release after that ended up getting delayed for years and upon collapse pretty much took the company with it—but that’s a story more appropriate to a pub context than public consumption.

(But, yeah, I’ve been involved in enough failed software projects to begin to recognise the smell. It’s very distinctive.)

Every application is judged by the user in terms of how much awesome it lets them do. If you are spending a massive amount of hours and efforts on a feature that you don’t know whether the user wants and has no obvious bearing on the awesome factor, you are probably doing something wrong.

There’s a potential opportunity cost to every feature built into an app. Every tentpole feature you implement that doesn’t directly address the user’s goals means there’s another feature you didn’t implement that might have made the user feel awesome at their task. Worse yet, a lot of these features are ‘invisible’ features where the engineering team spends untold work-hours papering over perceived flaws in the target platform. These are platforms that are generally already massively popular with countless apps where the users don’t seem to mind said platform flaws.

The idea that there is revenue-generating value in fixing these flaws is a completely unproven proposition and undertaking it is generally very risky. If solving the ‘flaw’ were easy or at all worthwhile, it’s likely the platform owner would have done so already. Attacking these gaps is likely to result in a feature that doesn’t work that well and doesn’t directly address the use case at hand.

Also, every new feature is a nail in the ground tying you down, making it harder to change your app. This makes it harder to iterate the app and adapt as you discover how to make the best tool the user can find for the task you address.

Examples of apps doing it right are Readmill and Aldiko. Neither of them were released with support for DRMed ebooks at launch, a feature many would say were a core requirement for any new ebook reading system. What they did is prove their core value proposition. Readmill proved the value of social highlights and ebook commenting. Aldiko proved the value of their UI and features. Then they iterated on increasing that core value. Not only did they avoid shipping with useless tentpole features at launch, they launched with just enough features to let them prove the core proposal of their app.

Interlude: People don’t know what they want…

But they do know what they tend to do.

Whenever I say the first half of that line people assume I’m just repeating the Ford adage (‘if I’d asked people what they wanted they would have demanded buggy whips with glitter or something’). That’s not what I mean.

If you ask people what they want from a word processor, they will simply proceed to describe Microsoft Word (something they know and is familiar). If all software companies did their research this way, all they’d end up doing is cloning existing apps.

(Come to think of it, that would explain a lot.)

However when you ask people what they tend to do whenever they tackle a specific task you tend to get much more interesting answers. You can get remarkably specific stories of how their current apps don’t work well, or how they tend to do X whenever they work on Y to get around problem Z that’s built into the app they currently use. Once you start to take them down this path a light bulb will go on above some users’ heads (not literally, of course) and they will begin to talk about their actual problems that they’d like to solve and not just describe their current work environment. But nobody knows what they want unless you walk them away from the ‘describe the familiar’ place they all start at.

Better yet, stalk user forums for the problem area. The more people write in the forum with the question ‘I can’t figure out how to do this and it’s vital for my project’ the more likely it is that an app directly addressing that will be successful.

Anyway… People don’t know what they want but what they do speaks volumes.

What is the web good at?

The web is absolutely rubbish at offline, pagination, parallel processing, intensive computation like image processing, security, and complex animation. There are various cutting edge browsers that can do some of those things but none of them do any of them well and sometimes they are quite simply disastrously bad.

A browser is really good at rendering scrolling text quickly, with images, decoration, links, and light declarative animation. And it does this on more platforms than I care to count. Everything about this task has been optimised to hell. Ever wonder why you can’t turn scrolling off on mobile by setting overflow: hidden on the body tag? It’s because browser vendors have optimised every pixel of the core document scrolling task breaking some web development edge cases in the process.

(Even with all that work it still goes wrong sometimes. Which does to show how risky it is to attempt to replace it with something hammered together by your engineers in javascript.)

The web is also really good at doing whatever it does cross-platform, on every major computing platform you can get your hands on, provided you stay away from cutting edge features. If structured properly it’s almost automatically accessible. The few built-in UI widgets it has (forms, textareas, buttons, etc.) come for free. A web app is always up-to-date. The only way to be certain a regular web page stays at an older version is to disconnect your device from the network—browsers often don’t cache even when you ask them to. Web browsers are also pretty good at pulling stuff down from a web server you control and getting better at pulling things down from other people’s servers.

So, one obvious thing browser-based apps are awesome at is be front-ends for stuff that actually takes place on your server.

The way people have been making web-based ebook reading apps is to treat all of the major features of a web browser like liabilities. Once you stop spending most of your engineering effort implementing and constantly repairing a feature or two (pagination and offline) and once you begin to treat the core characteristics of the web as advantages your project is much more likely to succeed.

Not guaranteed, just more likely simply by virtue of having more engineering hours to spend on making core tasks awesome.

Besides, how many normal users open a web browser and demand ‘let this be offline!’? Hardly anybody outside of geek circles is even aware of the technical possibility of an offline website. For most the very idea is an absurd paradox. To them the web is what’s online. And where are the queues of people demanding paginated website? You are more likely to find angry crowds demanding that crap pagination blog plugins be turned off as those seem to be universally rubbish. I’d bet that when faced with native, problem-free, pagination and scrolling, most people don’t care either way and will use whatever is default. (And then get used to that default and howl in anger whenever the app dev changes it, natch.)

I’m biased, obviously, by the fact that I have never encountered a javascript-based pagination implementation that worked comfortably and without issues in the default browsers on recent iOS and Android devices.

Engineers have a tendency to see software as a bag of features to be implemented. Most engineers I’ve met have had a strong inclination to assume that this or that feature should be implemented simply because that’s how it’s usually done. No thought given to the user task as a whole. Almost every engineering team I’ve encountered when tasked with making, say, a word processor would end up cloning an existing app instead of breaking the task down to fundamentals and asking themselves what is it really that we need to do? What is the user trying to accomplish? What skills does this app complement? Do we need to address every task that that Word does or can we pick one and do it really well? How do we make the user feel awesome at their task?

But, no. Ask them to do an ebook reader and they will attempt to reimplement iBooks, page curl and all.

Dismissing the potential of serious web-based reading based on existing ebook-oriented web apps is a bit like dismissing online chatting just because Google Wave failed.

If the core selling points of your web-based ebook reader is that it paginates and works offline—two features that native apps easily do much much better—then you’ve already failed.

What is really holding back web-based ebook readers?

There isn’t a need for them.

There is very little in general that web-based readers could do that trumps existing apps. You can’t make them cheaper (end-users aren’t paying for reading apps directly). Most reading systems are already cross-platform to an impressive degree. You’d be hard pressed to surpass native apps in convenience. They might serve to get past platform limitations such as the Kindle Fire’s ban on competing ereading apps or Apple’s app store limitations but those are more vendor concerns than user concerns. And you need the user to be on board because otherwise it’s pointless.

It’s not clear at the moment what problem from the reader’s perspective a web-based ebook reader would solve that existing native apps don’t.

Once upon a time I would have said that a web-based ereader would be great for the social reading thing, but Readmill proved you don’t need the reading app to be on the web to gain the social networking features of a web app. You can divide the responsibilities quite neatly between the native and web app, letting each do what it does best.

I’m convinced that if we didn’t already have ubiquitous ebook apps, a web-based ebook reading app could well be a smash hit. But we do have them and new apps without a unique value proposition won’t replace them, no matter whether the new app is web or native.

One way I can see it succeeding is if you found a specific group of readers who aren’t being served well by existing apps and would benefit from a specialised reading app. A web-based reading app might well be the most effective way to deliver a cross-platform app for that niche.

The other way it could work is if you make an ebook app for those who sincerely prefer scrolling over pagination and are willing to compromise to get it. Might not be a large group, but it might be enough to be worthwhile as a niche reading app.

The Smell of Death

Most software projects fail. No matter what some programmers might like to think, making software is more like art than engineering. As in, 90% of everything is crap and it’s often hard to know why.

The vast majority of projects begin to exude the stench of death well before their first public release and implode safely in the confines of a corporate server room while the management team tries to figure out who gets the blame.

Some get released and fill the room with the whiff of doom as soon as they see daylight.

Like Bookshout for example. That app had such a stench to it on its first major release that it’s amazing their PR reps managed to find a pundit to shill it in public. (Don’t bother to Google it. It’s not worth trying.)

  • Tentpole feature nobody cares about? Check. (Their DRM circumvention screen-scraping hack.)
  • Awkward and iffy UI design? Check.
  • No unique value proposition? Check.
  • Half-baked typography? Check.

And to compound everything the tentpole feature was extremely brittle and insecure as it relied on getting the reader’s Amazon password and scraping their account page.

Basically, it didn’t give us any reason to use it. The DRM circumvention feature was a way to make user migration easier, but that’s assuming the user wants to switch in the first place. They never gave them any reason to.

Of course, I haven’t tried it much lately, but that’s more to do with the fact that the latest version keeps crashing on me than anything else. I have a three crash quota before I give up on an app. Do I have serious doubts about Bookshout’s long-term survival? You bet.

Google Play Books on both Android and iOS is another pair of apps that have started to become a little bit too ripe for public exposure. When Amazon’s Kindle app looks more at home and is better designed on Android than Google’s own then you know there’s some serious upper management disinterest going on. Why Google persists in making their own app is perplexing. The rationale for both Android and Chrome is pretty clear: keep the market competitive. Google Play Books does no such thing. What would make the market more competitive is Google shuttering their own app and working with other vendors such as Bluefire, Aldiko, or Readmill to integrate Google Play Books directly. Bonus points for paying app vendors referral fees for every book bought. In the meantime, the current state of Google Play Books is just embarrassing.

Finally—and I feel bad saying this as I’m a fan of the people involved in these projects—every web-based ebook reader I’ve seen so far had at least a whiff of the old death-smell from the outset. These projects were all put together by amazing people capable of amazing things but in most cases there just isn’t a product there—no reason why a reader should care and switch.

What’s worse, the insistence of most of these projects on paginating every book has tended to limit them to the absolute cutting edge, which means they lose the cross-platform advantage of going with a web app and pits them against every odd new bug and every vague inconsistency in every immature specs they are relying on.

That’s without getting into the mess that passes for offline support in most browsers.

When even recent releases of Chrome Android and Mobile Safari aren’t close enough to the cutting edge to work comfortably you can quite simply be certain that you don’t have the foundations for a mainstream product.

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 kindle.amazon.com.
  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 kindle.amazon.com 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.

What are self-publishing’s biggest pain points?

I’ve found that the more time you spend in a problem area the more you realise how many of your preconceptions were mistaken.

So, instead of just assuming I know what the pain points of self-publishing are based on my own experience, I figure the best thing to do is to simply ask people.

In general, publishers face two separate problem areas:

  1. Making the book as good as possible. This means making the text as good as possible (writing and editing) and making the product as good as possible (typesetting and design).
  2. Finding a paying readership for the book. (Selling, marketing, PR, events, etc..)

I’m pretty sure most problems self-publishers face fall into those same areas but I also suspect that their specifics and details are going to be unique to self-publishing.

And by self-publishing I basically mean any publisher with only one or two employees and who publishes only ebooks.

So, what are self-publishing’s biggest pain points? I’d really appreciate any answers, either in the comments below, twitter or, if you want, in email. (My email is baldur.bjarnason@gmail.com for those who prefer not to contribute in public.)

Continue reading

Designing the covers

One thing me and Jenný have in common with our parents is that we tend to talk about our work a lot. As a result we know way too much about linguistics and journalism (our mother’s fields) and psychology (which is what dad does).

It also means that we are very much aware of each others tastes and priorities when it comes to design, writing, and illustration. And one particular taste we share is a dislike – bordering on grumpy annoyance – of typical fantasy and science fiction covers. Those covers generally fall into two categories, with very few exceptions:

  • A photorealistic painting of pretty people in poses, often in some state of undress.
  • A photorealistic painting of a big impressive thing: spaceship, dragon, sword.

Both are very very common and very very boring.

Now the original inception of the Knights and Necromancers series was based on a highly stylised etching of three ravens that my sister made more than a decade ago (I’ll write a blog post about that one of these days) so a logical thing to do would have been to base the styles of the covers on that print.

But that wasn’t the effect I wanted.

I wanted the covers to do two things:

  • Be entirely unlike a typical fantasy cover.
  • At the same time work as a fantasy cover.

One approach would have been to take the approach Penguin did in the sixties and seventies with cover designs based on a tight grid and often abstract images.

But I wanted a cover that implied a sort of sketchy roughness. I wanted it to be as rough and loose as the typical fantasy cover is realistic and detailed.

Jenný came up with the idea of charcoal on textured paper and after she’d done the first illustration it was clear that she had understood even better than I did exactly what it was that I wanted.

So I then gave her a list of what I wanted on the other covers along with reference photos. She generally ended up ignoring the references, except for the worm on the cover of book number three, which I think she completed in record time, after which she felt icky for days. (Like most Icelanders, she doesn’t like bugs, so drawing one was a bit of an ordeal.)

One particular thing has come up time and again as me and my sister have been working on Heartpunk and other Studio Tendra projects is that most people really don’t get why everything takes so much time.

Obviously, a lot of the lead time in big(ger) publishing is due to artefacts of their chosen process, many of which are not really applicable to an ebook-only outfit, but even that leaves out the one big reason why long lead times are actually a good idea when possible.

Namely, a longer lead time increases quality, more so than anything else you can do. Even without involving other people, freelancers, staff, or money, taking a little bit more time to think (or not to think, to get a bit of distance) is the one major thing you can do that will drastically improve the quality of your work.

Nothing improves a blog post more than letting it rest for a night before you publish.

And when you’re working on something more substantial, giving a work a few week’s distance between iterations can be the difference between a half-baked plot full of warped and broken sentences and something more solid.

(For example, the first draft of Knights and Necromancers 1: Days of wild obedience was completed over two years ago.)

The same applies to covers.

After Jenný had completed the initial illustrations it was my turn to figure out how to turn those illustrations into covers.

That’s where time comes into the picture. It went something like this:

I do a test design of a cover, which everybody in our informal feedback group likes, but to which I always say “eh, I don’t know’. I wait a few days and do another iteration, which everybody likes, but to which I say “eh, I don’t know’.

Then I do another—well, you can see where this is going. The League Gothic for the titles was the biggest surprise of all. I’m generally not that fond of it but it just clicked in place when I tried it for the main title. The aspect ratio was another surprise. I’d always envisioned much narrower covers but the overall style just didn’t feel right until I made them wider.

At this point, Studio Tendra has done eleven covers: the six books of the Knights and Necromancers series, four books in a series of annotated public domain books (which I’ll tell you all about in a few weeks’ time), and one in an aborted project you probably will never hear anything more about.

(So, yeah, we’ve got a pipeline of stuff to publish that’ll last us well into 2013.)

Jenný’s taken on more and more of the layout and design part of the cover creation process. The covers of our next project are almost entirely her work where there’s not much left for me to do except to make sure that there are no typos in the text.

And a few days ago we finished the last two covers in the Knights and Necromancers series. I haven’t added them to the Heartpunk website yet, but here’s a preview for the impatient among you.

Click to embiggen:

The cover of the fifth book in the Knights an Necromancers series, a charcoal sketch of a cat

Book number five

Knights and Necromancers 6

Book number six

And all of the book covers in a nice gallery thing: