The web and ebooks have little in common
My ‘End of ebook development’ post got a couple of replies. One thing that struck me about them is that they seem to assume there is some sort of equivalence between websites and ebooks.
There isn’t, at least not when it comes to development, production, design, and editing. The only thing the two have in common today are some of the nuts and bolts that make up the file formats.
When it comes to the nitty gritty of making things, they have about as much in common as a bespoke suit and a woollen cardigan, having the same base materials might be the only thing they have in common.
There are efforts underway to change this. In the long term, the point of EPUB3, as I understand it, is to move ebooks onto the web stack. That doesn’t mean ‘do what you’re doing now, but render it in webkit’, although that’s what most people seem to think.
It means fundamental change to the development, production, design, and editing processes behind ebook publication.
Because the ‘End of ebook development’ was really about applying web processes to ebook development.
It’s not really about abolishing development but about decoupling it from the writing and publishing process. So no ebook development, just theme, systems, and tools development.
In most cases, the way web development works today is as follows (generalised and simplified, of course):
The web guy (that’d be me), the designer, and somebody from either marketing or sales work together on the basic design of the website. The designer, after taking on board the needs and specifications of the company, comes up with a few ideas. Those get discussed. I give feedback on whether those would be good web designs and if there would be any implementation issues.
After a few iterations of this, the designer has put together the designs for some key websites and a design language that we can use to create all of the necessary components that the company needs to put their websites together.
I go and implement a theme or set of templates for their CMS, sometimes doing the necessary server-side programming to make it work, sometimes working with their programmers to get the integration done.
Once I’m done and the work has been fully tested, approved, and accepted, I and the designer can go away.
Whenever the marketing department wants to update the website they go into Drupal or Wordpress, write the post in the rich text editor widget and press preview. If it looks all right in the preview, then the markup is probably semantic because the only elements that are given styles in the CSS are semantic elements in that context.
A well structured stylesheet and a good CMS means that all of the pages have a solid semantic structure, which is good for search engines.
They then press ‘publish’ and the page is live. No need to call in the web guy or the designer.
They can manage google analytics, optimise their keywords/SEO, update their website, add news items, rewrite their product descriptions, etc., etc., all without ever calling the web guy again.
If web development worked like ebook development:
- The marketing department would write everything in an old version of Word and call the web guy whenever they wanted to update the website to do a ‘conversion’ from .doc to HTML.
- The ‘conversion’ would be done mostly by hand and regexes, an error-prone process that requires a massive QA process before every publication. It’s just much too easy to delete something you shouldn’t have or mistype something when you’re doing it by hand.
- All of the design would be done after the fact, leading to massive lead times from writing to publication. No company would be able to use their website to respond to rapidly changing events. Synchronising website updates to an event would require plans worthy of a large-scale military invasion. Each page would get a somewhat custom design.
- It would be impossible to do any testing on the same machine that the work is being done on. The site has to be uploaded to a special ‘web browser’ device that has no testing features and caches everything like mad so that you can’t see your changes or find out if they work.
- Every browser would be a version of IE6, incompatible with all of the other versions of IE6, each broken in subtly different ways.
- The writer would have no way of previewing what they write and have to go by Word’s WYSIWIG interface to set their document’s structure, leading to a largely unstructured document with unsemantic markup.
- Some browsers would allow javascript. Others wouldn’t. None of those that do allow it support the same APIs and features, turning a bunch of them off or on arbitrarily in every release. They certainly wouldn’t offer anything that resembles a debugger.
- A few of the browsers wouldn’t even bother to load any of the website’s CSS at all, preferring their own styles, even though they only cover a fraction of the structural semantics in the site’s code, leading to massive usability issues and miscommunication.
- There would be no serious tools anywhere. No Coda. No Expresso. No BBedit. No BlueGriffon. No Firebug. No Aptus. No Dreamweaver. No Hype. No Sandvox. No Rapidweaver. No Flux. Instead people would be trying to jury-rig Indesign to create websites.
If I had a dollar for every time I had to go in and fix a page somebody broke by hand-editing the markup, I’d have enough for another iPad and a couple of really nice accessories.
(Of course, I’ve been making websites with other people for over twelve years now.)
HTML is human-readable, but experience tells me that it certainly isn’t human-writable. Browsers use a complex parsing algorithm to compensate for errors because people keep insisting on editing markup by hand and keep doing it wrong. Even with the compensation algorithm, these errors still often manage to cause rendering glitches and massive security problems, not to mention ruining the HTML file’s overall semantics.
(Ebooks have it even worse because ereaders treat everything as XML, which allows for no errors. Which just makes the current status quo in ebook production that more insane.)
Hand-editing markup or CSS should never be done as a part of a website’s publishing process unless it’s a web developer’s personal website. Even then, they should have the sense not to do it unless they just can’t avoid it.
Write out the themes/templates by hand. Test the hell out of them. Then use either a simplified markup language (like markdown) or a CMS’s rich text editor to write and publish. Fewer errors. Less QA. Nobody touches the HTML (it’s all generated from templates, etc.). Everybody wins.
The worst, least semantic, markup I have ever seen didn’t come from WYSIWIG web design tools. It’s generally either hand-written markup or generated by an ignorant, lazy, server-side programmer.
A few CMSes I’ve seen that transitioned from table-based layouts to div-based layouts, for example, didn’t actually change the markup’s structure, but just replaced everything with divs (think thousands of nested divs instead of table, tr, and td tags). The result was a nightmare to work with.
Even the worst tool-generated markup isn’t as bad as the crap people write out by hand or some of the indistinct tag goo generated by a lazy server-side programmer.
Most modern CMSes generate tolerable markup because their survival depends on it. SEO is a major driving force in web development and the foundation of good SEO is good markup.
The exceptions are WYSIWIG tools such as Hype, but they are both edge cases (you wouldn’t use them for every page) and specialised (there isn’t much harm done if the markup for an animation isn’t that semantic). They also improve over time. Dreamweaver generates much better code now than it did a few years ago. There’s no reason to assume other, newer, tools won’t improve as well.
Complex and powerful design tools (the web equivalent to Indesign) are an edge case in web development. Most of the time you create a theme that matches the specific design needs of the client and there isn’t any need to do a complex custom design after the fact.
Given how extensible CMSes today are, there is no reason to believe that even the most complex design needs can’t be met by a combination of a custom theme and plugins/extensions to the CMS. There are very few cases that aren’t covered by this and it has the benefit of being able to reuse the design as often as you want.
At worst, you’d have to do a custom job in django or something similar.
Even one-off publications would benefit from this process as it enables the writers and editors to preview the final work throughout the writing process, which tends to improve the quality of the project’s structure and generated markup enormously.
So, there’s no reason why theme-based development can’t address complexity in design as long as it’s a standard complexity based on a reused design language.
For this to work in the ebook context there needs to be a single ebook platform (that’s why I called it an utopian fantasy, an ideal to aim for, in the original post). It needs to reach the same state as the web platform does once IE10 is released. (The web being a single platform despite its variances.) That one platform thing is an inevitability, but it looks like it might take decades.
There’s also a difference between single app one-button-publishing (one app to serve all) and an ecosystem of simple publishing tools and extensible systems. I’m advocating the latter.
The more difficult and complex the ebook is, the greater the likelihood is that it should have been a website or an app. The means need to suit the ends (to use John Dewey’s terms). A lot of what is non-fiction in publishing today is being taken over by websites and apps. They should be websites or apps. Trying to extend ebooks to cover all of these use cases (ends) is foolish.
It’s crazy that I can only buy Merriam-Webster’s English Usage Dictionary as a Kindle book and not as an app. It’s a piece of work that would benefit enormously from a custom interface, detailed searching and cross-referencing tools, and other custom gewgaws that a bespoke app could give it. Ereader platforms can never address all of those specialised features for every specialised genre of text.
(Tech references belong on the web, for example, which is why Safari Books is such a piece of genius).
Some works – some ends – do benefit from the means that ebooks and ereaders afford. But the longer ebook development and production remains as difficult as it is, the more appealing websites and apps become as alternative means to those ends.
Fixing these processes – simplifying them drastically – is key towards making sure that ebook growth doesn’t stall once fiction and simple non-fiction has transitioned. It isn’t the manifest destiny of ebooks to rule all publishing.
Unless the industry gets its act together, large parts of publishing will migrate over to the web and to apps, not to ebooks.
Web production isn’t ideal. It’s a highly flawed process based on inherently insecure technologies that are always on the verge of broken. But even at its worst (which would be mobile web dev, today) it doesn’t even come close to being as broken as ebook development.
The current state of ebook production is insane. The sooner people realise this and accept it, the sooner they can work towards fixing it.