Code doesn't change minds
My post on Amazon winning has resulted in a few emails that politely suggest that I shut up and contribute code to this or that software project which will supposedly solve everything I’m ‘griping and whining’ about.
As I said in my Readium post, the problem isn’t on the engineering level but on the business level. B&N, Kobo, iBooks, all override the author’s stylesheet by default to one degree or another.
Replacing their current rendering engines with a hypothetical, stable and feature-complete, Readium wouldn’t change a thing. Their current rendering engines are more than capable of doing the things I’m asking for (full-bleed page backgrounds, page borders, page margins, and such, nothing ambitious). They’d just use Readium to improve the rendering of their default stylesheets and still continue to limit the capabilities of author stylesheets, because the decision to do so in the first place wasn’t technological. It wasn’t driven by a lack of engineering resources.
These and other vendors in the ePub space are deliberately limiting the design capabilities of the format to reduce differentiation between publishers and to try to turn text-oriented ebooks into commodities.
Epub can’t be a “reliable packaging of Web content” when the vendors keep disregarding the rules of the cascade order; one of the basic principles of how CSS works. They’ve all gone through effort (a great deal of it in B&N’s case) to enforce some of their defaults and prevent author stylesheets from changing those defaults, in effect forcing the user agent stylesheet to take precedence over the author stylesheet.
This can’t be solved by engineering because it isn’t an engineering problem. These vendors want basic ebooks to be limited in this way. I get the impression that they are fine with limiting proper design capabilities to the mid- to high-end of the market: textbooks, illustrated non-fiction, magazines, etc..
When the problem isn’t technological, can’t be solved by engineering, but is caused by business decisions made by managers, ‘griping and whining’ is exactly the thing to do. In fact, it’s the only thing we can do that has any chance of effecting change.
Because I’m not griping and whining about how impossible it is to compete with Amazon. I’m complaining about self-destructive policies that limit what ebooks can do, complicate cross-platform design, and, yes, make it difficult for those vendors to compete with Amazon.
You see, I’m not competing with Amazon. Not in any way shape or form. I’m a regular user, because the Kindle is, from a reader’s perspective, the least painful platform to use. I’d just prefer Amazon wasn’t the only sane player in the market. But they are.
It doesn’t matter that KF8 is (considerably) less capable than ePub at the moment because ebook developers are actually allowed to use all of the limited capabilities of the former but only a fraction of the full capabilities of the latter.
Similarly, I’d like the tablet space to be more competitive. But when I find that all Android tablets suck compared to the iPad, I’m not about to start hacking the Android OS source code. Why? Because no line of code I can write will change the braindead decisions made by tablet manufacturers.
Were I an app developer I’d complain, loudly, on my blog and hope some of the people who are making these decisions will listen. Because a lack of updates, ugly vendor skins, too narrow an aspect ratio, etc., etc., aren’t problems with the Android source code. (Seriously… Why is it so difficult to find an Android tablet that doesn’t suck in some way?)
If I were an app developer I’d complain about how the vendors who are using an open source OS and a more open platform are undermining that platform with their self-destructive policies and decisions. Then I’d go out and buy an iPad. Because Apple is currently the only sane player in the tablet market.
But I don’t do apps, I do ebooks, so I don’t complain about the idiocies of Android vendors.
I also do websites and over in the web world when I complain about dumb decisions or bugs (which I have done) I am not asked to contribute code to webkit or Firefox. I’m asked to submit a bug to their bug or issue tracker. Which I rarely have to do because somebody generally beats me to it by a mile. (This is actually due to the web world’s now standard practice of constantly delivering preview versions of their browsers for developers to test and report bugs on.)
Even when I’m complaining about dumb management decisions in the web world and not bugs, some of the engineers involved still want you to submit a bug report because engineers like having something quantifiable to report to their superiors to try to change their minds.
And they all do have bug trackers or offer built in methods of reporting issues. Even Safari has a “Report Bugs to Apple…” menu item. iBooks has no such thing. Nor, that I can find, do any of the other ereader apps. And the responses I read on various forums from employees involved in these platforms convince me that a decent portion of the problems ebook developers are encountering wouldn’t be considered bugs.
Note that Chrome doesn’t share a bug tracker with Safari, even though they use the same engine. Different apps have different bugs even though they share some of the underlying code.
Ereader app vendors could learn, a lot, from web browsers:
- Frequent preview versions.
- Always give the reader both the option to zoom or to increase the text size, no matter what the context is. Don’t require web/ebook developers to change their code to enable this.
- Let the reader set a minimum font size—a GUI equivalent to marking a CSS declaration as !important.
- Ship all versions with a DOM/CSS inspector, debugger, and console.
- Bug trackers.
- Let developers disable the cache.
- Steal Safari’s idea of an opt-in “readability” view that overrides the author stylesheet on a case-by-case basis.
As with the decision to override author stylesheets by default, only a couple of the features above are solved by standardising on one rendering engine, and even those that would be solved need to be enabled and supported, which is a business decision. Standardising on a rendering engine also won’t solve the problem with delivering to Boot2Gecko, for example, if that ever gets traction.
So:
- I’m not whining or griping about Amazon. I don’t mind them at all. I just don’t want them to become the only player in town.
- I’m not really whining or griping about ePub either.
- I am whining and griping about how ereader vendors intentionally limit the design capabilities of ePub books by default. This can only be solved by evangelism as we need to change their minds, not their engineering.
- Their standards support is a mess largely due to vendor decisions and policies.
- Only a fraction of ebook developers’ problems can be solved by standardising on a rendering engine. The policies that dictate which of the engine’s features are enabled and usable are what’s the heart of the problem.
None of these things have anything to with the IDPF, really. Whenever I have criticised something the IDPF is doing, I’ve ended up coming away with my mind changed to a more generally positive outlook on IDPF efforts (CSS PGT, Readium, etc.). In fact, I’m now pretty sure that the IDPF are doing the best they can under the circumstances. The problem is with ePub vendors and their policies, not the standard.
I hope this clarifies what I’ve been trying to say.
Code doesn’t change minds, but neither does writing, it seems.