Category Archives: Publishing

There is no war between Amazon and Traditional Publishing

Posted on by

There will never be peace in the war between Amazon and traditional publishing because there is no war.

One of the defining qualities of the current dispute between Amazon and Hachette is just how softly softly it is. These kind of disputes between a mega-retailer and a major supplier happen every day in other industries and are notably brutal. The retailers promote the supplier's competitors heavily and with eye-bleeding discounts; they remove the supplier's goods from sale completely; they pressure other companies to stop dealing with the misbehaving supplier. Most large retailers have clout and wield it. Amazon just lost ten times more on the Fire phone alone than they were ever likely to lose from properly blacklisting Hachette. In turn, Hachette isn't playing hardball either. They aren't making sweetheart deals with Amazon's competitors. They aren't organising eye-watering sales or promotions with B&N. They don’t have a competent direct sales platform they can use to leverage the publicity the dispute has generated. Both parties are just continuing with business as usual, just with a little bit less effort. The predominant characteristic of the argument is its sheer lack of inspiration. It’s pedestrian and mundane.

Continue reading →

Friends don’t let their friends become authors

Posted on by

Being an Author is a Shit Job

Even if you don’t believe any of the pessimistic reports and anecdotes about author income and even if you do believe all of the overly optimistic ones (hi Hugh ::waves::) being a book author is one of the shittiest jobs in the media industry. And that’s saying something, since sleaze and exploitation is the rule rather than the exception in media.

Continue reading →

iBooks Author tempts you with bling

Posted on by

It’s very easy to make a decent-looking ebook in iBooks Author, then drop in a bunch of expensive and badly thought out interactive doohickeys and call it a day.

This is a mistake. A regular book ‘decorated’ with interactive tumours growing throughout its body is not an improvement over even a regular ebook.

Continue reading →

The print design mentality

Posted on by

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 →

Book contracts

Posted on by

Normally, whenever Don tweets anything I just nod my head in agreement and move on.

My response to this tweet, however, was more ambivalent because it seems to imply that we shouldn’t be complaining about unfair standard practices in the publishing industry.

Continue reading →

Intermission: sorting through the banal

Posted on by

Everybody who knows what I do assumes that I’ve given up on print books.

—You make ebooks? Haha, you don’t need any bookcases then, do you? Must be nice.

Not that I haven’t used it as an excuse once in a while. As a rejection, it’s a little bit nicer than telling somebody that I don’t want their book because it isn’t good enough to put on my shelf—oh, and the cover’s ugly to boot.

Continue reading →

How to create value with a new thing

Posted on by

(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 →

HTML is too complex

Posted on by

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

The syntax of HTML and XML—angle brackets and closing elements—isn’t complex. It’s tedious, but it isn’t complex. If the problem lay in the basic syntax we’d have an easy time fixing it. The problem with markup complexity lies in the underlying model. Or, in the lack of one. Simply put, HTML is a mess.

This is from an email sent by Matthew Thomas to the WhatWG mailing list (that list was at the time responsible for the development of HTML5) almost ten years ago. Everything it says is still true:

In response to the proposal that HTML5 add a host of semantic elements, each with no default rendering to distinguish it from other elements, Matthew predicted the following:

  • The A-list of Web developers will begin using all the elements
    correctly on their Weblogs, and they will feel good about it.

  • A greater number of Web developers will never use most of these
    elements, but they will replace all occurrences of <div> on their
    pages with <section> because it’s more “semantic” (just like they
    did with <em> for <i> and <strong> for <b>), and they will feel good
    about it.

  • The vast majority of article producers (Weblogs and online
    newspapers) will never use <article>, because there’s no visual or
    behavioral benefit from doing so. So <article> will never become a
    reliable way of dissecting or aggregating pages.

  • The number of knowledgable HTML authors, the proportion of HTML
    pages that are valid, and therefore the overall usefulness of the
    Web, will be less than it otherwise would have been because of
    HTML’s increased complexity.

I’d argue that his prediction, ten years ago, was pretty much spot on:

  • The A-list rewrote their own sites to use fancy HTML5 semantic elements, then wrote books, presented talks, and sold workshops teach people how to do the same.
  • The hangers on and wannabes try a bit but don’t use any of the elements except maybe header and footer, and possibly article after that was blessed as a generic sort of standalone content container instead of section. Most of the elements are regularly used incorrectly.
  • The vast majority don’t use any of the semantic elements unless it’s by accident like a thoughtless copy-paste.
  • The only reason why the proportion of valid HTML files has increased is because HTML5 retroactively blessed invalid files as valid, provided they wear the HTML5 doctype.

The web remains too unstructured for article to become a good way for ‘dissecting or aggregating pages’ as originally envisioned. The HTML5 outlining algorithm isn’t used by anybody (except the A-list gurus) and, even worse, supported by very few browsers or screenreaders.

As Matthew Thomas mentioned in the email above, unless there is an immediate visual or behavioural benefit to using an element, most people will ignore it. This is compounded by the angle-brackets mess of HTML. By completely separating design (CSS), behaviour (JS), and structure (HTML) the specification gods have taken away the context that would make it easier for us mere mortals to give our documents a meaningful structure.

That’s without getting into the problems with the syntax itself.

While the separation makes using HTML for documents and ebooks more difficult, it is essential for it becoming an app platform, which obviously now the web’s primary purpose.

(Most websites today are just web apps for delivering ads. They certainly aren’t made with readability in mind.)

There was a long period of time when the markup of most websites was unreadable because they used a mess of nested table tags to render the site. The markup was meaningless and complex. For a few years, though, after that, when you viewed the source of your average website, you would have seen relatively clean and nicely structured markup that most people could understand, even without specific knowledge about HTML. Google’s web crawlers loved simple, well-structured documents and so the web filled with them.

Now we’re back to seeing almost the same level of complexity and messiness in most web pages as we saw in the worst days of table-hacking. The semantic elements from HTML5 are largely unused. Those that are used such as <header> and <footer>, are used incorrectly because people misunderstand what they mean. Every page is riddled with div elements with opaque classes and IDs nested in a document structure that is more complex than many I saw in the table-layout days.

This escalating complexity is arguably one of the biggest ongoing issues in web development because it makes things like authorship, search engines, discoverability, and automation more difficult than it should.

You see, if the markup you assign to a piece of content has a specific meaning, you can write code that’s aware of this meaning. You make human meaning machine readable. This is useful if you want to make the text more searchable or if you want blind people to be able to hear it with their screenreaders. If the markup is too complex (both the underlying model and the markup syntax) to use properly, the humans won’t be able to do the markup properly, making the content’s meaning machine-opaque again. HTML5 has a big problem with markup complexity where even A-list developers have spent countless hours debating what the various new semantic elements actually mean.

Hint: They don’t mean what most of us assume they mean. Section, Article, Footer, Header, all of them have differences in meaning from what we’d assume from existing practice or basic understanding of English.

HTML5 is itself complex. Most developers can’t or won’t put in the effort to properly mark up their content semantically. EPUB3 and its ilk add even more complexity, more ‘semantic’ elements and attributes, all of them even more difficult to understand and harder to explain than the basic new semantic elements of HTML5.

Badly implemented complexity, such as in HTML5 and EPUB3, means we get all the pain and difficulty of escalating complexity, but with few of the benefits. Unfortunately, these are formats whose limitations we have to work around and surpass. They are a disadvantage on both the web and ebook industry. One of the tasks publishing has ahead is to try to neutralise that disadvantage.

The ebook as an API

Posted on by

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

The problem many publishers are facing is that their titles need to be reused in a variety of contexts.

Book apps are very unfashionable at the moment but there is a brisk trade in small, fairly cheap, and functional apps based on book content, where the content is often licensed by a small app development outfit from a small publishing outfit or book packager. These range from military history apps, to children’s apps, to travel guides and in many ways are prototypical Content Development Kits like I described in an earlier post.

Then we have a variety of web and app gateways popping up that sell access to ebooks on a subscription basis, either directly to consumers or to libraries or other educational establishments.

The source format for these apps is often an EPUB version of the title and this is, in the cases I know, the source of a lot of problems and complications. The structure of the EPUB doesn’t tell the app developer where to hook the functionality of their app into the title’s content. This means that the app developers have to spend considerable time adapting and editing the text of the title and its structure. In some cases they have to spend more time on pulling structured text out of a crap EPUB than on the development of the app itself.

For most large publishers they see development as the single biggest cost of creating apps from their titles. This is because they are focusing on the digital equivalent of a tent-pole blockbuster movie. Small publishers and small app developers tend to focus on smaller scale apps with a much bigger emphasis on code reuse. For them, anything that cannot be automated is a liability and a cost centre.

You can think of a structured ebook file as an API. Most existing ebooks don’t need any API capabilities. A novel benefits little from it.

Reference books, however, gain immense value from becoming detailed and functional APIs in the digital space.

A reference book that is the source of only one or two concurrent editions in print can be the content source for hundreds, if not thousands of apps. A classic example being the dictionary services built into Mac OS X and iOS.

Any reference title can be a similar source provided that its content has been made available as an API.

Unfortunately, we don’t have many formats or tools that make this easy, making a lot of these services custom jobs.

Rewind

Stop. Go back. Reread. Can you tell what the big problem is with what I wrote above? The idea that publishers could benefit from turning their titles into well structured ebooks—files that can serve as APIs—has a fatal flaw:

Only certain kinds of books have the internal structure that suits this purpose. Books that can be mapped onto a database structure (e.g. reference books) work perfectly. Structured non-fiction tends to work well. Anything that has a story less so.

Even the most structured dictionary or reference book is still not flexible enough to really suit the purposes of app, web, and interactive media developers. They need more. They need content that is adaptive.

What they need are structured projects that offer enough variety in their fabric to adapt to varying devices and context. Instead of single length chapters you need entries that have full-length, abridged, even more abridged, and tweetable versions of the chapter’s content. You need the chapter’s full title, tweetable title, display title (if different). Every chapter needs descriptions of varying lengths (like the chapter’s content). Do that for every chapter in the project, mark it up so that it’s usable, and you’ve got the beginnings of something really flexible.

Adaptive content

What this means is quit thinking that what you are doing is designing and creating for the final presentation. You’re not in the business of making brochures. You’re not in the business of mobile applications. You’re not in the business of making web pages. You are in the business of making content and structuring that content so that it’s presentation independent, so you can get it out onto whatever device or platform you want to. (Karen McGrane – Uncle Sam Wants You to Optimise Your Content For Mobile)

Adaptive content—making things work for mobile, web, desktop, apps, tablets—is not just a design problem but an authorship, business, and editorial problem.

A large content library is not an asset in this context but a liability. It’s an ossified monolithic resource when you are surrounded by small and nimble players using small and flexible resources. The individual smaller players do not represent a threat—most of them are more likely to fail than not—but as a whole they do. Where each one may only address a tiny sliver of your back catalogue’s target market, they do so with content that is more flexible than yours because they had to start from scratch. Or, they have had the time and focus to adapt it by hand because their survival depends on this one title, which is a level of attention you can’t give to tens of thousands of titles.

As a collected whole, the smaller web players, self-publishers, three person publishing houses, indie app developers, and the like, are much more likely to be able to properly leverage the advantages of digital publishing than a large publishing mega-conglomerate. Publishers approach each edition as something that demands a unique design, custom editing, and detailed work to adapt the title’s content to that editions particular form. This isn’t scalable, neither in terms of labour or cost.

Adaptive content is essential when we face a plurality of devices. Having a ‘mobile content’ strategy means that you are just making the same dumb mistakes again because there will be other platforms in the future, and if your content isn’t readily adaptable you’re just going to face the exact same problems again that you are facing now with the mobile transition.

Not to mention the fact that you are opting out of a revenue stream from licensing your catalogue to various developers.

Your existing non-fiction titles are flies caught in amber. They exist only as evidence of a single evolutionary context, incapable of adapting or changing to survive in a new one. Because of the costs and work involved in making an extensive back catalogue adaptive, it becomes a liability when competing with a host of smaller outfits starting from scratch.