Baldur Bjarnason

Explanatory windows

2012-02-19T16:00:00-08:00

Where I use examples to prove a point few people care about.

It struck me that one of the many things I never got any response to in my ‘ePub Windows and Widgets’ post was my explanatory windows proposal.

So, I decided to go through some of the apps I use every day (with Google Maps as a bonus) and see which of them use explanatory windows and for what purpose.

Turns out most of them do. Some for autocompletes. Some to bring up contextual tools. Some to bring up a purely explanatory window. It is, as I said in my earlier post, a generic tool for interactivity that I think should be standardised and implemented as a primitive by ereaders.

Again, excepting Google Maps, these are all apps I use on a daily basis. I didn’t even try to look for it in other apps.

Apologies to Pablo Defendini for using my exchange with him in the screenshot.

Readium and other good intentions

2012-02-12T16:00:00-08:00

The Readium project is important, interesting, and to be welcomed. But there are issues. (I’m a sceptical bastard. What else did you expect?)

Update: It’s clear from updates, both on the Readium website and their forum, that the primary goal is to work on WebKit itself and deliver library-based components. I’ve struck out the passages below that were wrong.
Update 2: I’ve added a comment from Bill McCoy Executive Director – International Digital Publishing Forum (IDPF).

One of the classic acts of a political party in trouble is to announce a tax cut. Percentages, large dollar amounts, and a whole lot of numbers are chanted by the beleaguered politician as if it were a chant that warded off electoral failure.

These numbers, concrete as they sound, are rarely substantiated by fact because they aren’t fact. They might be facts in the future, but they aren’t facts now.

Not yet, at least.

You see, one of the problems with pushing forward with big plans, popular as they may be with the electorate, is that the electorate isn’t the system. The system has needs and a law won’t be passed unless it fulfils those needs.

The politician may be honest in his plan to cut that tax but he has to deal with treasury, lobbyists, other politicians, his friends, his enemies, his political allies. For a law to pass you need the support of so many people and so many organisations.

Before you know it, the tax cut only applies to a minority of people, most of whom happen to belong to a demographic with strong influences among the participants in the political process.

It may be cynical to say this, but it’s very hard to convince participants in an extended process like this not to act merely in their self interest.

Readium – a new open source initiative launched by the IDPF with the support of Adobe, Google, Kobo, and B&N – is like that tax cut; a popular, possibly sensible, good intention that will go only as far as its participants let it.

What is it?

The first impression of Readium is that it will be a foundational engineering project that will build the difficult, but essential, building blocks which will then be reused by the project’s supporters.

This pitch, nice and cuddly as it sounds, is the ‘I will cut your taxes by X’ part of the process. It is what saying ‘increasing implementation consistency’ and being able to embed Readium components in other apps implies. It may not be what the project is intended for, but it is what the website’s copy implies.

This is what a lot of people will interpret the project to be, which in turn will turn into our equivalent of the ‘this is what this tax cut will mean to you’ speculative nonsense that journalists churn out after a politician’s announcement. Extrapolating fantasies from vague declarations is what pundits and journos do best and I doubt they will let us down this time.

~~Because, as far as I can tell, this first impression is wrong.~~

Note: Turns out I’m the one wrong about this. Apologies.

~~Readium, judging from the project’s goals and what the FAQ says and judging from what the proof of concept prototype, is going to be a javascript framework built on top of Webkit.~~

~~If it isn’t, they need to say so, right now~~

I don’t see, personally, how they can implement a full-featured ePub engine (with all of the musts and shoulds) in javascript.

That isn’t to say that javascript-based implementations are a bad idea. They aren’t. They are a very good idea as both Ibis and Monocle prove. But they are always going to face limitations based on their execution context which are going to prevent them from implementing every optional feature of the specification.

~~And if a javascript-based implementation isn’t the plan, then shipping a half-arsed one1 as a proof of concept was a very bad idea.~~

A technical project needs to be technical

As an open source project, Readium lacks a concrete outline of its specific technical goals. Does it intend to be a low-level ePub rendering engine, in effect be a webkit branch that is extended to deal with ePub? If so, say that.

Use concrete terms. ‘Building on’ can be interpreted in too many ways for it to be useful technically.

Say something like ‘the Readium project aims to deliver a webkit branch that has been extended to deal with the needs and features that are unique to ePub3’. Outline specific technical problems that need to be tackled such as:

How will a paginated view be implemented natively in webkit’s rendering engine?
How will webkit’s API be extended to deal with media overlays, content switching and epub:trigger (just to mention a few things)?
How will the webkit library be modified to handle ePub specific security and code execution issues? And don’t pretend there aren’t any.
What components will the project deliver? Say so in exact detail.

You don’t have to have answers to any of these questions but you do need to list the questions that need answering. This is an open source project after all and you have to tell the participants exactly what questions they need to be tackling as a part of the project.

Wishy washy, vague and woolly marketing statements are useless when it comes to driving participation. Be technical and tell us, exactly, what the project intends to do.

And, no, you haven’t told us yet. At least I didn’t find anything resembling concrete technical statements on the website.

Remember, webkit first launched with working code, not a ‘proof of concept’.

Assuming the best

If we do take it as a given that they are going to work on implementing proper, rendering engine-level, support for ePub and not just faff around with hacks, then we still run into the participant issue, just like our proverbial tax-cutting politician.

Starting with zero code, since none of the participants seem to be donating parts of their proprietary efforts and the ‘proof of concept’ doesn’t seem to have a single line of engine code, the project will have to navigate the conflicting interests of Adobe, Kobo, B&N, Bluefire, Copia, Google, and others.

And even if it manages to deliver a fully-featured ePub3 rendering engine that doesn’t mean any of the supporters will use that engine in any of their projects.

Why? Because they aren’t limited by what they can engineer.

At least three of the supporting organisations (Samsung, Google, and Adobe) have shipped extensively modified branches of the webkit engine: Samsung in the excellent browser engine that comes with the bada OS; Google, twice, in the Android browser and in the Chrome browser; Adobe in the AIR desktop runtime.

The limits aren’t in what they can engineer but in what they can ship. Apple is unlikely to let an ereader app ship on iOS with full javascript support.

Why? Because an ereader app with full javascript support is an app platform as well as a publishing platform and app platforms threaten the very existence of their App Store.

So, the iOS version would require an entirely different codebase and feature set. That is, it wouldn’t be a full-featured implementation. That’s two codebases, three if you think the Android version won’t share anything with the Chrome extension.

Three codebases that share little aren’t a single project. They are three projects that share management.

The decision to support the entire ePub3 spec is made on the business level and will be governed by the corporations’ existing value network. Some of these decisions will be governed by platform risk, such as with Apple’s App Store, others by cost. Unless these companies have decided on the business level that full-featured, compatible, standard, ePub3 support is a selling point, that support is unlikely to end up in a shipping product.

We’ll see what happens. If they contribute a lot of code, then we can be optimistic.

Other issues

Not choosing a reference platform for the reference implementation is a mistake. ePub3 is extensive enough without having to deal with a mess of cross-platform issues. Pick one, like Android, to be the main target. Develop everything with cross-platform support in mind, but having a single target platform does wonders for focusing development. Leave it up to the participants to maintain ports to other platforms. It’s what kept webkit alive in the early years when it was only used by OS X. Cross-platform support can come when the project has proven its worth.

Implicitly optional features like XMLHTTPRequest are useless if you can’t deliver basic things like full-bleed backgrounds.

Supporting optional CSS modules is pointless if, like Readium supporter B&N, you override the ebook designer’s stylesheet by default.

Implementing full support for ePub3’s multimedia features is meaningless if implementations can’t agree on what codecs to support.

No amount of javascript support can address the needs of hypertext in ePub if the reading system doesn’t support non-linear chapters using linear="no". Without it a whole spectrum of ebook features, widgets, and UIs are ruled out.

And without extensive documentation, any rendering engine, no matter how full-featured, is just going to make the lives of ebook developers more difficult, not less.

Shipping a development platform without public documentation like most ebook reading system vendors do is sheer insanity.

Most of these issues aren’t solved by a reference implementation. Some of them wouldn’t even be solved if everybody shipped the same implementation. Deciding to overrule the designer’s stylesheet isn’t a technical decision but a business decision. An open source engine can’t force vendors to document the features they support. Just look at the varying levels of documentation on the dizzying number of browsers based on webkit.

Don’t be a killjoy

I know I am being too harsh.

Even if Readium ends up being just a reference implementation it would still be useful.

If it delivers a full-featured ePub rendering engine based on webkit, so much the better. A component like that would enable wondrous things in the marketplace. It’d do more to enable new, competitive entrants than it would help the project’s big supporters like B&N, Kobo, or Adobe. But, hey!, how nice of them to help disrupt themselves. Class.

But, let’s not pretend it solves the ePub fragmentation problem. You don’t solve the problem of too many differing implementations by adding a new one. The format fragmentation problem is caused by the value networks that drive product development at the various vendors, not by technical issues or implementation problems.

Support and extensive participation in the Readium project could be a sign of a change in values, but the only true signal is shipping code and published documentation.

This announcement comes with neither.

Comments

Bill McCoy (Executive Director – International Digital Publishing Forum (IDPF)) wrote this here thing:

Baldur, I totally agree with you on two key points:

business considerations not engineering will be the determinant of a number of decisions about EPUB 3 feature support. For example, whether a given ebook distribution channel permits e.g. remote data access from JS (which impacts control over valuable analytics data and direct communication with readers).

eReading app capabilities on iOS is subject to unilateral control by Apple and it would be risky to e.g. count on EPUB 3 JS features that go beyond what iBooks can do being permitted to ship there.

But I think you missed the boat on several other points, perhaps misunderstanding what Readium Project is actually doing:

for companies who have already made the business decision to robustly support EPUB 3, Readium doesn’t change a thing, strategically. It’s just tactics: a way to collaborate to help with the “when” (and, perhaps, the “how much”) while giving publishers a tool to prep and check EPUB 3 content in the meantime. Concretely, its primary aim is to help ensure we get widespread EPUB 3 support in the market this year, with a higher level of initial functionality than would otherwise be the case.

iBooks already has quite a lot of EPUB 3 features including significant JavaScript support. And, not every solution has to run on iOS.

“You don’t solve the problem of too many differing implementations by adding a new one”. Well, sure, no more than with standards: http://xkcd.com/927/! But, we have a situation where a dozen folks recently decided to implement their own EPUB 3 engines via WebKit (a la Apple iBooks). I think it’s a reasonable goal for Readium to coalesce some of these implementations and make the overall result more consistent and capable. And, while Chrome and Safari are quite different, I do think the shared use of WebKit has significantly reduced the problems many of us have personally suffered through of HTML/CSS incompatibility, by creating some sharing and setting a higher bar for other implementations - creating a “race to the top”.

“publishers liberation” is one aspect of this. A fully-featured EPUB 3 implementation can be wrapped in an app shell with PhoneGap, or combined with a publisher skinned browser extension. This can give publishers direct distribution options free of all channel fetters. This option as well as just general availability of robust EPUB 3 support can help set up a “race to the top” among eReading apps & content distributors, as we now see with browsers.

Your post included some criticisms of the proof-of-concept prototype Chrome browser extension. The entire effort is all of 5 weeks old, and “proof-of-concept prototype” is the operative term. And, the suggestion that going public early was a bad idea is contrary both the spirit of open source collaboration and the principles of lean startups. But it’s a fair point that we could have communicated the initial status more emphatically and we’ve tried to address that on the readium.org site.

And it is a half-arsed implementation. Slow as molasses on a rather newish laptop, ugly kitsch skeuomorphic UI obviously done without any input from a ebook designer on what they want, and buggy as hell. It’s an awful first impression. ↩

ePub windows and widgets – a proposal

2012-02-09T16:00:00-08:00

Ebooks have one major advantage over other forms of interactive media: They are extremely late to the game. One of the benefits of arriving after everybody else is that you get the chance to avoid their mistakes and learn from their experiments.

Interactivity in ebooks today sucks. Implementations are non-standard, diverge from their web-based parallels in both subtle and substantial ways. Implementations are buggier than Internet Explorer 6 on a pirated, compromised, Windows 98 machine. Javascript is inconsistently supported in the few cases it is supported.

Many of those involved in ebook development today don’t come from web development but are often print-oriented people who are doing an admirable job of expanding their skills.

One of the things they can’t pick up from howto pages, manuals, and tutorials are the battle scars that come from having to deal with insane browser developers. This is the only reason I can imagine why they aren’t terrified of some of the current developments in ebook reading systems and the fragmentation of the epub market.

The horrors a vendor can inflict are enormous

No support is sometimes superior to buggy support. The effort of having to deal with and hack around a browser’s buggy implementation is far greater than using CSS’s cascade or javascript’s feature detection to gracefully degrade in the absence of a feature. Dealing with iBooks’ buggy support of javascript, which changes and moves around every release, is much more expensive and time-consuming than implementing the same features for a web browser, especially when you consider iBooks’ non-existent developer tools (such as a web inspector).

Fragmentation in the features ebook reading systems support and how they implement these features will reintroduce the nightmare the web world went through during the browser war between IE and Netscape to a new generation of developers to. When the only browsers in wide use were two very broken browsers, IE and Netscape 4, and only a tiny minority used sane, standards-compliant, browsers, only the insane enjoyed dealing with the real-world practice of web development.

(The extra work involved was often called ‘the browser compatibility tax’. As Tankek Celik says “web standards are an agreement between authors and browsers”. They aren’t a private agreement between browser vendors.)

In a world where ebooks, based on web tech as they are, don’t support the solutions the web community has hammered together for the problems it shares with the web, sanity is in short supply.

Divergences

The differences between ebooks and the web, in terms of how the same basic tech is applied in the two different contexts, fall into roughly two groups: rendering and javascript.

The rendering differences, ostensibly due to the use of a reflowable, paginated, view of the text, are in fact often arbitrary and damaging. The limitations of reflowable ebooks are wholly unjustified. (More on that later.)

The decision to support javascript, however, is one that has consequences and it’s understandable that some vendors have decided to avoid those consequences. Allowing javascript means that the vendor needs to deal with security issues and implications that match that of any general purpose computing platform. When ebooks become apps, maintaining an ebook ecosystem is maintaining an application platform. A javascript platform will also, inevitably, require debugging tools that at least match that of most web browsers. The toolkits that javascript developers need to maintain a basic hold on their sanity are quite clearly beyond the capabilities of vendors who can’t even publicly provide basic documentation of their software’s capabilities. A vendor who can’t exhaustively document the features they support, in detail, version by version, change by change, has no business even attempting to implement javascript support.

Consider the differences, between the anaemic and vague iBookstore Asset Guide and the Mozilla Developer Network or even Apple’s own Safari Dev Center. The Asset Guide – secret as it is – is an afterthought that lists Apple’s own needs and requirements. It is not documentation.

The only vendor I know of who provides public documentation, with attempts to list all supported HTML and CSS features, is Amazon. Their documentation needs much improvement (see the MDN or SDC for how it should be done), but the rest don’t even seem to be trying.1

Javascript is the web’s general purpose tool for interactivity. There is no simple declarative markup for creating dynamic interactivity because there hasn’t been the need. (Actually, CSS does have a few, if a bit limited. More on that later.) In its absence we lack the basic tools to implement dynamic ebooks. This means we will have to reconstruct some of the basic primitives using the declarative and semantic tools that are available.

To do that we first need to figure out what those primitives are. And to do that we need to examine the conceptual mechanics that underly some of the technology we are using.

And so, the mechanics

Scrolling layout. The default rendering in all web browsers today. It supports every feature available in web tech because this is the context where they were invented. Any ebook vendor who supports a scrolling layout in some context (say a popup) but then cripples it, is insane. Beyond the obvious case of javascript, there is no reason to remove features from a scrolling layout.

Reflowable layout. The default rendering of most ebooks today. For all intents and purposes this should be nothing more complicated than a paginated version of the more standard scrolling layout. Instead, it is crippled. Even the most advanced implementations today lack a basic feature like the ability to set full-bleed backgrounds. Neither assigning a background to the HTML tag or the BODY tag does the trick, there’s always an ugly white margin. (See my note on full-bleed backgrounds for more detail on this issue.) Some even require an obscure, non-standard, XML file to be included to turn on basic features such as the designer’s ability to set fonts. Others override the ebook’s stylesheet unless the reader specifically chooses to load it.

I have no idea why vendors think non-standard trickery like this is acceptable. Not supporting a feature at all is one thing. There we have the hope that it will eventually be implemented. But disregarding the ebook designer’s decisions by default is arrogant and hostile. Either you support CSS or you don’t. Don’t be coy and require developers to jump through hoops.

Fixed layout. Apple’s invention, copied by others. Essentially, it’s a way of using web-technology to design an image of a fixed size. Apple’s method uses a combination of the insane and the standard. It requires an obscure XML to be set but relies on <meta name="viewport" width="something" height="something"> in each page’s header. The viewport meta tag is a de facto standard, and now well supported across the web. Amazon’s implementation, unfortunately, doesn’t use the viewport at all (it should).

Media queries. The web has been dealing with varying devices and browser capabilities for a long time but it’s only in the last few years that this problem area has been properly addressed. Media queries enable the designer to deliver different CSS statements depending on what the browser (or, in this case ebook reader) supports. The ability to have the design of an ebook adapt itself depending on whether it’s being read on a phone, tablet, desktop device, or eink reader is obviously a vital capability. Media queries let us do that based on colour depth, screen size, orientation, and, as in Amazon’s KF8, based on file format.

We need media queries. Full support, please. We’d be ever so grateful.

OBJECT tag. For the longest time web developers had to deal with two different ways of embedded interactive objects in their web pages (usually either flash or some sort of video): The EMBED and the OBJECT tags. OBJECT is the one that was standardised. The principles of the OBJECT tag, the ones relevant to ebooks, are that you point at the object’s data using the data attribute and set the parameters using a series of PARAM elements. Any other child elements to the OBJECT tag are ignored if the browser supports the media type or used as a fallback if it doesn’t.

The way Apple uses the OBJECT tag to implement no-code widgets in iBooks 2.0 breaks this in several ways. The contents of the tag are clearly used as either data or as parameters and not ignored as they should. It uses the HTML5 data-* attributes to configure the object instead of PARAM tags. Both render Apple’s format unusable in a cross-platform context. If you are going to implement widgets using the OBJECT tag (which, in and of itself, seems to be a good idea) you should at the very least use it according to the standard. Both standards, in fact. The HTML4 and HTML5 specs are in agreement on how the tag should behave.

The epub:type attribute. From the ePub3 spec: “The epub:type attribute inflects semantics on the element on which it appears”. It doesn’t change or add to the meaning of the element but it clarifies, specialises, or narrows the semantics inherent in the carrying element. Reading systems can do one of two things with an epub:type attribute. They can associated specialised behaviours with some of the terms that appear as the attribute’s values. Or, they can ignore it.

The implication of epub:type is that you can assign a role to an element and that way trigger behaviours in reading systems that understand it. This seems ideal as a method for indicating interactivity.

There are even precedents in the default epub:type vocabulary. The vocabulary, as defined, is full of print-oriented design features that have attained implicit meanings through repeated use: sidebar, footnote, rearnote, pagebreak, copyright-page, titlepage.

These are print conventions and print terms that only have connotations due to tradition.

One obvious solution for how to implement interactivity in the absence of javascript is to put together a vocabulary of interaction conventions that have connotations due to repeated practice in interactive projects, websites, applications, UI design, etc. I’m going to outline a suggestion for the start of such a vocabulary below.

By focusing on primitives that can be combined and layers we can enable intricate interactive projects at a fraction of the complexity that javascript requires.

Non-linear HTML files (linear=”no”). For any of this to work, reading systems must provide authors with a way of including XHTML files in the ebook but keeping it out of the document’s reading flow.

If I want to include an extended example using an XHTML file that is only reachable by clicking on a link I include in the text, I must be able to do so. That means the XHTML file must not appear anywhere in the ebook’s main text, not before it, not after it, not interspersed with it. I must be allowed to keep it out of the NCX file’s or the EPUB Navigation Document’s main flow.

Since, according to the ePub 2 specification, all XHTML documents that are included and reachable in the ebook must be listed in the book’s <spine> that means that any reading system that hopes to support any involved interactivity must support the linear="no" attribute (or here for the ePub3 version).

Short version: Remove any file that has the linear attribute set to “no” from the ebook’s main flow. You just gotta.

Without support for non-linear chapters the main text of even a moderately ambitious ebook will be cluttered and appended with oodles of material that completely destroys the coherence of the work. By including ancillary material in the main body (or after it, which is just as ruinous) the reading system gives the reader an extremely false indication of the book’s true length.

Not supporting linear="no" is hostile towards the ebook developer and the reader.

The :target CSS pseudo-class. One of the most underrated feature of CSS today is the :target pseudo-class. Quite simply, when you link to a specific part of an HTML document using a fragment identifier (#something) the :target pseudo-class allows you to style the target specifically.

It may not sound like much but, combined with things like display, opacity, and CSS Transitions, this lets you use CSS for a large part of the most common uses of javascript today such as tabbed interfaces, zooms, accordion interfaces, and much much more.

Any ebook reading system that doesn’t intend to implement javascript should seriously consider the :target pseudo-class as it addresses a large number of use cases without any of javascript’s drawbacks.

The HTML5 data-* attributes. One of the features that the HTML5 spec provides are custom data attributes. Any attribute that starts with ‘data-’ will be treated as private data storage. This is obviously useful for javascript programming as it means you can include all of the relevant data (for configuration, etc.) in the page itself.

Apple used these attributes on the <object> tag for configuration. Which is exactly where they aren’t needed. The main value of arbitrary data-* attributes is to add configuration data to elements with no standard facilities for configuration. The object tag has the <param> tags for configuration. Using private data attributes for configuring an object tag is an exercise in wilful obfuscation.

There are also interesting proposals at the W3 for leveraging data attributes to add variables to CSS.

I think these attributes can be useful when we need to attach behaviours to pre-existing elements.

Windows

Here are three basic patterns of interactivity that can be used as building blocks for more complex behaviours. They are primitives that are in frequent use in web and UI design and they have a long history and many precedents.

Explanatory window. This is a feature we see every day: a window that pops up over the main window, with a pointer to its original context, that explains or expands upon the item it points at. Google maps labels, Mac OS X’s and iOS’s dictionary lookups, tooltips, tutorials, wherever you find them, they have been a part of our computing lives since we first invented GUI’s.

These windows are usually rather smaller than the main window. Their general design can vary a lot but the basic feature remains the same: A box that points at an element.

My suggestion is that our interactivity epub:type vocabulary includes ‘window:explanatory’ (the window prefix being an abbreviation for whatever URI that people end up settling on, possibly something PURL related). The basic idea is simple.

You would use the epub:type="window:explanatory" attribute on links (A tags) that are supposed to open explanatory windows. The file it links to would then be opened in exactly that window. Reading systems that don’t support the vocabulary would treat it as a simple link.

If the reading system properly supports media queries in the explanatory window context then we as authors don’t need to be able to dictate the window’s exact size. We could simply have the HTML file adapt its design according to the @media rules we’ve written.

Overlay window. Another basic interaction type, especially on the web, is the overlay. You click on a link and it blacks out the page and loads the target page or image in an overlay. This overlay can be full-screen – which it generally is when it’s done in native code – or it can be in the more web-style lightbox with a transparent background.

I think the exact details would be best left up to the ebook reading systems, provided they deliver on the intent and meaning the author has signified by attaching a epub:type="window:overlay" to a link.

Embedded window. A classic, used on almost every major website in existence, is an embedded window. Generally implemented as either an iframe (for HTML files) or object tags, the only thing we need here is for ebook reading systems to support the spec. There is no major reason to prevent a chapter in a book from embedding an HTML file in an iframe as long as it’s a file properly included in the epub.

The same principle applies to objects. It’s reasonable to look at the object tag for our implementations of interactive widgets.

You should be able to combine these windows, like using explanatory windows with an overlay window to create an interactive image (e.g. touch parts of an image to see it explained).

Vendors should also provide a way for an embedded view, whether it’s an iframe or an object, to transition to a full screen view, something that’s currently done on the iPad with gestures.

Layouts

Scrolled layout file. An HTML file that, once loaded in an overlay, explanatory window, or embedded, renders its contents in a scrolling layout like most web browsers do. While it may be problematic to allow authors to designate arbitrary files in the ebook’s flow to have a web-style layout, I don’t see the problem with designating non-linear files, loaded in one of the epub:type windows, as web layout. This could be done as simply as adding an epub:type=”window:scroll” to the file’s meta name=”viewport” tag.

Like so:

  <meta name="viewport" width="something" height="something" epub:type="window:scroll">

The idea being that the epub:type ‘inflects’ the semantics of exactly what type of viewport is being loaded. In this case the reading system would treat the viewport dimensions the same way browsers do, either ignore them, or use the width to scale the layout down to fit the width of the reading system’s window (depending on whichever one of the three basic window types it is).

Scrolling layout files are useful as they are more appropriate than the reflowable paginated views for quite a few contexts, such as any substantial supportive hypertext (a detailed glossary, for instance).

Fixed layout file. My suggestion is the same as with web layout files: add an epub:type attribute to the viewport meta tag to indicate that the file loaded has fixed dimensions.

Like so:

  <meta name="viewport" width="something" height="something" epub:type="window:fixed">

This file is then treated essentially like an image with fixed proportions, zoomed and scaled in the manner that the reading system treats all fixed layout XHTML files.

Vendors also should consider the possibility of letting us mixing them in with paginated in the ebook’s flow. There’s no reason to stick to conventions from print. One chapter in an ebook can easily have different dimensions from another and we should have the capability to do so if it’s appropriate for the book.

One interesting possibility crops up when you consider embedding fixed layout HTML files. If the iframe is of a fixed size (dictated by it’s styles) then the reading system should let the reader pan and zoom (or scroll and zoom if not in a touch UI) the embedded fixed layout file much in the same way you would pan and zoom a map widget.

Paginated file. In the same way that a scrolled web layout is more appropriate for some contexts and fixed layout for others, a reflowable paginated layout should be an option for the designer.

Designated like so:

<meta name="viewport" width="something" height="something" epub:type="window:paginated">

The idea with these basic window types is that you can combine them to create complex interactions. (See the “Breaking Google Maps down to interaction primitives” note for more details.)

Alternatively, if the file has no viewport tag, the epub:type attribute could be placed on the body tag.

Widgets

Solutions have to be considered along several dimensions.

One temptation with a specialised widget is to build it out in enough detail for it to solve the entirety of it’s potential problem area.

But complexity has diminishing returns, especially when a more general purpose, yet complex tool, already exists.

The web stack already has extensive, if redundant, technologies for animations. When creating a widget for galleries or slideshows we are solving problems that can be largely addressed by SVG+SMIL or a combination of CSS Animations and :target.

The only valid rationale for specialised widgets is if it makes life easier for everybody involved.

That means simple to author.

And it means that it has to be relatively easy for reading system vendors to create implementations of those widgets that are richer and of a higher quality than anything that can be done in a more general purpose solution.

Simple. Easy. Beautiful.

My suggestion is for two of the widgets, slideshow and gallery, to be an experimental media type combined with a very bare-bones JSON file.

The JSON format is simple. You describe objects like so:

{ "property1":"value", "property2":"value"}

An object is enclosed in curly brackets and is a comma-separated list of colon-separated property and value statements. It has several standard value types: strings, numbers, objects, arrays, as well as boolean values (true, false).

It’s supported in too many languages to count.

The benefit of using a JSON file is twofold:

Its object model is a much closer match to that of most programming languages, which makes implementations easier.
It places an upper limit on complexity. A JSON file cannot easily accommodate the same intricate and complex structures XML can represent.

What we have so far is this: A simple file format that addresses a subset of the problem in a very clean way.

Slideshow. In this case, this should be nothing more than a set of fixed layout XHTML files with an optional transition. The transition property on each slide object defines how that slide exits and the next enters. The duration property defines the duration of that transition in seconds or millisecond.

The file would look something like this:

{
    "type": "slideshow",
    "title": "This slideshow has a title",
    "slides": [
        {"src":"example.html", "transition":"slideRight", "duration":"500ms"},
        {"src":"example2.html", "transition":"slideUP"},
        {"src":"example3.html", "transition":"fadeOutIn"},
        {"src":"example4.html", "transition":"crossfade"},
        {"src":"example5.html", "transition":"pushRight"}   
    ]   
}

The URLs are relative to the JSON file, not the XHTML document.

The widget spec would define a set of standard transitions but reading systems could optionally implement more. If the transition is missing or unrecognised (specific to another reading system) the duration would apply to the default transition, which in my book should be a simple fade out of the current slide, followed by a fade in of the next.

The background of the slideshow is whatever background style the object tag has.

The slideshow title is optional.

Every slide is a fully interactive fixed layout xhtml file with something like this in its header:

 <meta name="viewport" width="something" height="something" epub:type="window:fixed">

The reading system should have a relative free hand in what sort of UI to implement. No point in dictating any details as the needs of the various platforms differ.

Gallery. Just a set of images with optional captions and an optional title.

Like so:

    {
    "type": "gallery",
    "title": "This gallery has a title",
    "images": [
        {"src":"example.jpg", "caption":"A fancy caption"},
        {"src":"example2.jpg", "caption":"This is already repetitive"},
        {"src":"example3.jpg", "caption":"I'm sure the image is interesting"},
        {"src":"example4.jpg", "caption":"Or maybe not"},
        {"src":"example5.jpg", "caption":"I don't know"}    
    ]   
}

Again, the URLs are relative to the JSON file, not the XHTML document.

And again, no point in specifying UIs. Whatever is best for each platform is best.

Quiz. A problem that can’t be solved by basic widgetery. Instead HTML5 rides to the rescue.

Any questionnaire or quiz needs to implement a form so my proposal is to attach validation and evaluation data to the form itself. The <form> tag would be marked with a epub:type="widget:quiz" and each input tag would be marked with the following data-* attributes:

data-answer is required and must contain the correct answer to the question. In the absence of pattern or data-answer-contains attributes the value of data-answer is checked against the input tag’s value. If the values are exactly the same, the answer is deemed to have been correctly answered.
data-answer-contains takes precedence over data-answer for checking correctness, if present. It contains a space seperated list of words that the input tag’s value must contain for the answer to be correct. No order is implied, so if the order of the words is different than it is in the data-answer-contains attribute it is still deemed correct. A partial match must be calculated against the weight given in the data-weight attribute for a partial score.
data-success contains the id of the element to display in case the reader gives a correct answer. The display state or visibility of the element is orthogonal to its use in the report since the reading system must provide their own report UI. The designer should be free to make the decision whether to display or hide the answer irrespective of the widget’s basic functionality.
data-failure contains the id of the element to display in case the reaer give a wrong answer.
data-weight is used to calculate the reader’s overall score.

The widget works as follows:

The ebook developer includes a form anywhere in the book where HTML is allowed. It is structured using bog-standard HTML tags. Its input elements are marked up with the above attributes.
The reader fills out a form and presses the submit button (which can be named anything, really, it’s up to the form’s designer).
The reading system adds the combined weights of the inputs to get the full score used to calculate the reader’s percentage score. If an input doesn’t have a data-weight attribute, the default value of 1 is used instead.
For every input, it checks the value submitted against the pattern, data-answer-contains, or data-answer tags, in that order, using the first one that it encounters. For the pattern and data-answer attributes, if the values mismatch, the reader’s score for that answer is zero. For the data-answer-contains attribute, the reader’s score is a percentage of the input’s data-weight value, or 1, if that attribute isn’t present.
The reading system then adds together the reader’s score total and calculates their final score as a percentage of the full score.
The final step is where the reading system presents the reader with a report. This reports must list the reader’s score, how many questions they got wrong and right, and should present the reader with a list of correct answers and the elements referred to by the data-success and data-failure attributes.

A few rationales:

Adding a weight to the answers allows for some granularity in evaluating the quiz’s success or failure, even in a model as simple as this.
The three different methods of checking the answers should provide the questionnaire author with enough flexibility to design a wide variety of questions.
The reading system should have quite a bit of freedom when it comes to designing the report UI.
Vendors can, optionally, store the scores and completed questionnaires, let the reader review them all, study their improvement history if they retake them, etc.

In my opinion, this should solve a large proportion of both the ebook developer’s needs in terms of questionnaires and gives vendors the freedom to implement native UIs that outmatch anything done in javascript.

3D objects. This should, hopefully, be as conceptually simple as linking to a file for a 3D object in the object tag’s data attribute.

(The details are beyond any of my expertise. I know absolutely nothing about 3D file formats or standards.)

The actual implementation is, of course, much more complicated than that, possibly even the most complex implementation detail of all of those mentioned here.

One thing to note, however, is that the background of the actual 3D object should be transparent so that the designer can set the background by styling the object tag, as with the other widgets.

Video and audio. These would be a largely solved problem if it weren’t for the fact that several of the major implementors can’t agree on formats. This isn’t even a ‘closed’ versus ‘open’ issue as it is on the web, both Amazon and Apple use patent-laden codecs. They just somehow manage to require different file formats just to make things problematic.

Stop that.

Just grow up and support what the other guy supports. That goes for all of you reading system vendors. The sanity of ebook developers is at stake here.

The proposals

I make no claim of ownership over the ideas presented here.

I am not a spec writer, nor do I pretend to know much about the nuances and detail required in the art of specification writing. Instead, I’ve stuck to plain and descriptive language where I can in these proposals.

I’ve tried to outline the problem area and the solutions as simply and as clearly as I can, in the hopes of starting a discussion of where we can go from here. I think that my proposals – combined with :target and CSS transitions – are both more flexible and simpler than anything else I’ve seen suggested or implemented, but I obviously can only see the problem from my perspective and am sure to have missed out on some issues (although I’ve outlined a few more issues in my notes linked below).

I hope these proposals help, even if they don’t end up getting used.

(The next problem I’m pondering are conceptual suggestions for authoring tools.)

Additional notes

Full-bleed backgrounds: issues and mock-ups

Starting a developer wiki, like the Mozilla Developer Network, would be a useful start. But it wouldn’t be a replacement for proper documentation unless the vendor assigns staff to maintain and add to it. Doing it as a wiki might lower costs but it doesn’t remove them. Also, Mozilla has the advantage of being a community-lead non-profit, something that doesn’t apply to any of the current ebook vendors. ↩

The semantics of ebook widgets

2012-02-03T16:00:00-08:00

Over the past few days I’ve had several interesting conversations on ebooks, interactivity, widgets, standardisation, and other issues that have cropped up as a result of Apple forking the ePub3 format.

Most of them have been people making very good points that have forced me to clarify my thoughts and reconsider some of my ideas.

One such conversation was the following email exchange with Grant Sutherland (posted with his permission).

We didn’t quite manage to convince each other, but I think we each made a pretty good case for our respective approaches for the discussion to be useful and educational to others, no matter which side you take.

Both of our respective principles and approaches to developing more interactive ebooks are, I think, much healthier than the one-sided and opaque approach Apple has decided to take.

From Grant:

Hi Baldur,

I’m a writer, currently published by Macmillan.

I’ve been interested in the development of ebooks for some while, and have been enjoying your posts.

( I wrote something last year along similar lines, probably out of date). Traditional Publishing is a Burning Platform

In relation to your recent exchange with Joseph Pearson, I agree with you both about the widgets being authored declaratively (with bindings).

However I strongly disagree that microformats are the appropriate solution for books (however useful they might be on the web). The ‘vocabularies’ extension in epub3 allows for any numbers of xml dialects to be dropped into the basic xhtml5. Why not use them? They’ve already been developed rigorously (e.g. ChemML, KML) and something like TEI seems to me ideally suited as a basis for interactivity/enhancement in a variety of non-fiction ebooks. Microformats are meant to evolve towards useful common standards; but in this case, the common standards already exist.

Why reinvent the wheel?

Anyway, just a thought.

Regards, Grant

http://grantsutherland.net

To which I replied:

That’s a valid point and it’s one I debated a lot when I was an academic studying and authoring interactive projects. Generally speaking, only a minority thought it was a good idea to reuse these vocabularies because they simple weren’t designed for our purposes (creating interactive texts). I was a part of that minority in favour of reuse. I changed my mind as soon as I gained more practical experience in authoring interactive projects.

There’s only one, widely accepted, open format that suits our purposes: HTML+CSS+JS. There hasn’t been a need to create a new format for interactive hypertexts (which is what we are talking about, since text is a subset of hypertext) because we already have one. The problem arises when we remove JS from that equation; we need simple methods of getting back some of the interactive functionality we’ve lost. None of the other pre-existing formats suit our purposes because we’ve just given up on the only one that does.(^1)

So, short answer: Because it’s not reinventing the wheel. Not really.

Most of those XML formats, like TEI, are both specialised and largely focus on meaning (that is, preserving a fidelity of the information it carries). But when you are creating an interactive project you need to explicitly declare your intent: this is how this element is supposed to behave. Using existing XML formats for this purpose can get extremely complex and awkward because it’s not what they were designed to do. Relying on a reading system to infer a behaviour based on semantics is an extremely limited way to author interactive ebooks.

(TEI is also bloody complicated.)

Microformats is a term that Joseph Pearson brought up and I’m not quite sure I agree with it being applicable in this circumstance, because microformats generally describe semantics and meaning and not behaviour and intent.

A simple OBJECT tag, configured by linking to something like a json file using the PARAM tag, is much easier to author than any of these pre-existing XML formats, and has the added benefit of being both explicit in terms of the behaviour that’s desired, and flexible in terms of how the reading system wants to implement it. It’s also something that’s very easy to implement in almost any programming language. None of these apply to a complex XML vocabulary, even if it really did what we need it to do.

A small set of simple but flexible widgets (behavioural objects) is very much outside the remit of any of the preexisting formats.

The only exception I can think of are SVG+SMIL which could cover a lot of bases but even that is still quite complicated both to author and implement (which is why support is so sparse and buggy, even among web browsers).

And even then SVG+SMIL doesn’t cover some of the basic behaviours we need.

I’d love to have it, though.

For authored interactivity we either need javascript (to implement and attach behaviour to semantic elements) or we need simple but configurable objects. Any other solution is too complex to author and implement, or simply doesn’t solve our problem.

For the record, I don’t think the iBooks widgets cover exactly our needs either. They are a starting point.

So, that’s my reasoning. I hope it makes some sort of sense :-)

best, baldur

The footnote:

(^1): There are very good reasons for abandoning javascript in the context of ebooks. The biggest reason is security. An ebook is a much more persistent object than a web page. Turning an ebook into a fully-fledged javascript app platform opens readers up to exactly the same security issues as any other app platform, viruses, trojans, worms, etc. etc. It’s understandable that many ebook platform vendors might want to avoid that. In many cases javascript support may simply present substantial and expensive problems that are very hard to solve.

Consider for example iBooks, the only epub platform that supports javascript: It is buggy as hell and updates regularly break working code. It breaks away from established web behaviours in subtle and not so subtle ways that is complex to tackle. And it crashes. A lot. Especially when you are on an iPad 1.

Addendum. I do miss proper javascript support in ebooks. It has the merit of years of development and testing and phenomenal mindshare. But, I think it’s clear at this point that cross-platform javascript is a non-starter in the ebook realm. If that’s the case, we need to start thinking about alternatives.

From Grant:

Hi Baldur,

Thanks for the thoughtful reply. I take your well-made points.

I think your key statement is this one:

For authored interactivity we either (a) need javascript to implement and attach behaviour to semantic elements or we need (b) simple but configurable objects. Any other solution is too complex to author and implement, or simply doesn’t solve our problem.

My own belief is that certain classes of texts are well-suited to solution (a), whereas others - and I would guess that among these are the type of interactive texts you’re working on - are more suited to solution (b).

As an example of a text of type (a), take any classic history. By impregnating the text at appropriate points with the various <bio>,<time> and <geo> related tags of the TEI, a work like ‘Decline and Fall…’ could be gently enhanced by the reading system with a sidebarred timeline, map and bio reference. The primary purpose of this type of enhancement (and, in my view, probably the only useful kind of enhancement possible in this type of work) is navigational. It is clearly not a hugely ambitious aim, but it has the inestimable advantage, over the many ‘snake-oil’ type’enhancements we’ve lately seen, of actually being useful. Because this is the kind of text I tend to read, my view is admittedly skewed toward this solution.

(In a way, the Kindle’s X-Ray facility is something like this, but prone to error because it’s using text-mining to make the semantic enhancements. And it’s ugly.)

As to texts of type (b), I think you are absolutely right.

There is obviously a massive problem here with the stability of this type of book. And I think the lessons to be learned about ‘maintainability’ will be learned from the past experiences and current best-practices of programmers.

The big lesson I see is that ‘unstable’ is the natural state in this world. I’m reminded of the old joke in biology: ‘We biologists have a special word for obects in a stable state - dead.’

Publishers want ‘stable’, but I don’t think they’re ever going to get it in this area. The best they can hope for to manage the ‘instability’ of these books in a commercially viable manner.

My own guess is that books will come to exist on a (lumpy) spectrum of stability that looks something like this:

Plain-text, stored on clay tablets (the first, and still the best for longevity)

Plain-text, stored on paper

Plain-text semantically enhanced, stored on computers. Behaviors (if any) determined by reading system.

Plain-text semantically+programmaticaly enhanced, stored on computers. Behaviours (if any) determined by some combination of reading system and program embedded in text.

With regard to your remarks about the widgetization of behaviours, I agree that SVG+SMIL is the only sane long-term answer. In the meantime, here are a couple of links that might interest you (if you’re not aware of them already):

http://www.simile-widgets.org/

http://lively-kernel.org

Simile uses json to populate a set of predetermined html/css/javascript widgets. Lively-kernel is less straightforward, and more buggy. It’s widgets are primarily customizable javascript objects. But if you look here:

http://lively-kernel.org/repository/webwerkstatt/documentation/HowConnectWorks.xhtml

you’ll see that they use a similar mechanism to that <object> PARAM technique that you’re suggesting (but in their case from one highly configurable javascript object to another, rather than from json to html.

Hope some of this is of some use to you.

Regards, Grant

And me:

I’d like to start off by saying that I generally agree with you, in an ideal world semantic text combined with authored javascript would be the ideal solution for creating interactive texts. The only point I’d make is that in this circumstance the programmer becomes a co-author of the text (interactivity is an act of authorship) but those who can work in this context that embrace this and partner with a skilled programmer will end up creating remarkable things.

There is a subset of interactive patterns that can’t be tied into semantics since the behaviour is the primary carrier of meaning (understanding is derived form the actions the reader takes). In this case you have to author a non-semantic widget into the text. Texts full of this behaviour lend themselves to solution (b), as you call it. They are also, in my opinion, generally only appropriate to non-fiction; like you I’m skeptical of the benefits of ‘enhancing’ narrative text.

Then there’s the issue of supporting true interactive narratives, creating a platform that can support hypertext and non-linear stories.

In either case, creating these texts hasn’t been that much of a problem because we have had a tool at hand: Javascript.

The problem is that javascript in ebooks is looking like a non-starter at the moment. The only major platform that implements it is iBooks and even there support is buggy enough to make development substantially more difficult than developing a scripted web site. I think it’s pretty much a certainty at this point, based on the discussions and debates I’ve witnessed and participated in, that javascript won’t be universally supported in ebooks like it is on the web.

Which, really, is the origin of my conundrum.

On the stability of these texts:

Very true, and it’s a problem I and other academics who were researching and teaching in this field ten years ago have had to tackle again and again, and, believe it or not, what we have now is much better than it was.

Most of the interactive works I studied ten years ago and I cited in my research are unplayable now. Hypercard projects, Director-authored CD-ROMs, old flash files, and plain old executable programs, many of the big, influential, texts are now hard to access, locked in a dead platform (Mac Classic). So, this has been a subject of debate for decades now. There was a lot of worrying and scaremongering about the issue at the time, but it ended up not being as much of an issue as people expected.

Of course, some works have been lost. It’s hard to find and play a Voyager Expanded Book today. But the solution was articulated by Mark Bernstein (of Eastgate Systems, publisher of hypertext, maker of tools, etc.): The only thing that preserves works is interest.

When there is interest, someone will make sure that the work is available and accessible (see, for example the conversion and update of the “If Monks Had Macs” CD-ROM).

When there isn’t interest, no amount of open formats or standardisation will save the work from oblivion.

Of course, there are exceptions such as the rights situation with many of the Voyager Expanded Books, but that kind of legal bind won’t be solved by any amount of standardisation.

And, as I wrote, we’re in a much better place now than we were then. We have an open standard, ePub, which, even with books published on the Kindle, will remain an archival and authoring format.

Extending that format with a set of documented, standardised (even if just a de facto standard) objects will not threaten their archivability in any way, provided we do it in a sensible manner.

Which brings me to Apple’s new iBooks 2.0 format. That format runs the risk of instability and obsolescence. It’s undocumented, intentionally incompatible with the standard, extends it in odd ways. It’s a very problematic approach to creating interactive texts.

With javascript ruled out, we need to establish a path forward in ebook interactivity that isn’t dominated by the proprietary and exclusionary path Apple is taking. The only way I see of doing that is describing a set of simple, but configurable, interactive objects that can be combined and used to create fairly rich works.

Both the Simile Widgets and Lively Kernel are similar to what I think we need, but not quite. (In either case, projects like these are ruled out by the fact that javascript is a non-starter on many ebook platforms.) The Simile Widgets are a little bit too specialised and complex. Lively Kernel is too tightly integrated with javascript both conceptually and in implementation.

I think the next step for me would be to write up a description of the forms of interactivity I think are needed for ebooks (there are a few basic actions that can be combined to create 90% of what authors of interactive works need) followed by a list of widgets, with suggested format extensions, that would implement those forms of interactivity.

I wouldn’t be surprised if, with a little bit of thought, those of us who want this can come up with conventions that are closer to the semantic ideal than the hodgepodge of opaque data that Apple is using.

I think, for example, that epub:type can be put to effective use. One approach would be to create a vocabulary of interactivity for epub:type which might give us the best of both worlds—if we assume that an interactive act has meaning in and of itself, that is.

The analogy would be ‘footnote’, which is a name of a print design feature that has attained an added meaning derived from its common use. If we define a epub:type vocabulary for commonly used interactive design features, especially those that have attained some added meaning from repeated practice, then I think we would have something that is sustainable, usable, and would satisfy the qualms of most.

I’ve really enjoyed this exchange. :-) Would you mind if I posted this conversation on my website? I won’t do it if you’d rather I didn’t, but I think a lot of people would find it interesting to see an exchange that presented both sides equally like this.

best, baldur

References:

iBooks widgets – to javascript or not to javascript

2012-01-31T16:00:00-08:00

Opinions are a nuanced thing and not to be caricatured by people with an agenda.

I’ve been pleasantly surprised by the attention my three iBooks posts have recieved1, but one aspect of that attention is something I never expected.

Although, I should have, I guess.

I have been quoted in so many different contexts and to support so many different sides of somebody’s pet argument that I’ve long given up keeping track. Judging by some of the blog posts out there I’m anti-Apple, pro-Apple, pro-standards, anti-standards, pro-javascript, anti-javascript…

By this point I’m almost expecting to be quoted as for or against somebody in a South Wales by-election.

So, I gave up on reading the sites that linked to those posts. It would have been a waste of time. The discussion veered into irrationality from the get go.

I do, however, follow links in my twitter feed and that’s how I came upon this blog post: A favour from Goliath: How Apple does ebook widgets right by Joseph Pearson

There he points out some of the strong points in Apple’s approach to interactive ebooks, namely that no-code widgets are easier for authors to use, generally perform better (reading systems can opt for more efficient implementations than javascript), they are a functional description of intent that reading systems can adapt to their context, and they can be implemented by ePub reading systems that don’t otherwise support javascript.

All good points that I agree with. No-code widgets are a good idea. And not just for ebooks, they might well be a good idea for the web as well. I was nodding along with most of the points he made.

Which made this little paragraph more than a little bit surprising:

So we were surprised and delighted by some aspects of the .ibook file that iBooks Author spits out. Their extensions to EPUB are done precisely the right way. They’re not done with dollops of embedded JavaScript — a fact that Baldur Bjarnasen (sic) laments.

Now, I don’t mind much having my name misspelt, it happens so often that I’ve long since ceased worrying about it.

But, mischaracterising my opinions is a different matter. I don’t lament the fact that the widgets aren’t implemented in javascript. I only lament that Apple didn’t choose to implement their new capabilities in a standards-friendly way on top of ePub3.

For the record, here’s what I said about iBooks widgets:

The solution they chose for widgets is also perplexing since ePub3 provides a solution exactly for this use case: Bindings.

ePub3 provides a standard method for defining handlers for media types it doesn’t support. Through the bindings element Apple could have provided handlers for its widgets, written in javascript, so that its books would have been forward compatible with other, future, ePub3 reading systems.

Now, you may not see how this contradicts the previous quote, but it does.

The bindings element allows for fallbacks, written in javascript, for those systems that don’t support that specific mediaType object natively.

The javascript is only for those reading systems that:

Don’t support the widget natively.
Support javascript.

This isn’t nitpicking. I completely agree with Joseph Pearson on the positive qualities of native, no-code, widgets. I just think that Apple should have done them in such a way that would allow for javascript fallbacks for ePub3 clients that will support it. Javascript is the only cross-platform, standard, way of delivering interactivity at this level and we shouldn’t intentionally exclude the reading systems that choose to implement it.

Another detail he forgets to mention is that iBooks 2.0 supports javascript-based widgets. Apple only implements five widgets entirely natively (the Keynote slideshows are largely HTML/CSS/JS) and heavily promotes the capability to fill your books with widgets coded in javascript when the native ones don’t suffice.

My problem with Apple’s widget implementation is that it’s a bit crap. It suffers from a couple of flaws that limit it and make their long-term use a pain in the arse. (At least, if you hand code. You’ll probably be fine if you just use iBooks Author.)

To wit:

Intentional incompatibilities

Using data-* attributes instead of PARAM tags specifically prevents the use of ePub3’s BINDINGS tag to point at JS implementations of those widgets in those cases when a native implementation is not available. A compliant ePub3 reading system wouldn’t pass the data-* attributes on to the handler document.

Rubbish as a microformat

There are clear principles behind the design of a microformat. From the microformats wiki:

solve a specific problem

start as simple as possible

solve simpler problems first

make evolutionary improvements

design for humans first, machines second

be presentable and parsable

visible data is much better for humans than invisible metadata (see: Principles of visibility and human friendliness).

adapt to current behaviors and usage patterns, e.g. (X)HTML, blogging

ease of authoring is important

reuse building blocks from widely adopted standards:

semantic, meaningful (X)HTML, i.e. POSH. See SemanticXHTMLDesignPrinciples for more details.

existing microformats

as a whole, e.g. use hCard for representing people

in part, reusing particular semantic class names, following microformats naming principles

well established schemas from interoperable RFCs

modularity / embeddability

design to be reused and embedded inside existing formats and microformats

enable and encourage decentralized and distributed development, content, services

explicitly encourage the original “spirit of the Web”

The iBooks 2.0 widget formats are none of these things. They are opaque, unreadable, complex, represent a complete break from current practices, don’t reuse widely adopted standards, so on and so forth. It’s a format that is patently unusable outside of a WYSIWYG application.

Which is fine, but limiting.

I probably should state my opinion on the iBooks 2.0 format once, as simply and cleanly as possible, so that people would stop making shit up and claiming it to be my opinion.

What I think

With the iBooks 2.0 format, Apple has innovated and extended the ePub3 format.

Their innovations and extension are, for the most part, clever and well implemented. There’s not much in it that I disagree with on a technical level.

My issue is that they could have done exactly the same thing, but done them in a standards-friendly manner. Instead, we have a format that is full of intentional incompatibilities with ePub3 – the format they extended – HTML, CSS, and javascript. These incompatibilities are non-trivial, both to implement and to circumvent.

(One such incompatibility is that you can no longer link to stylesheets in the XHTML files using the LINK element. You have to use an xml-stylesheet declaration. There are many many others.)

Moreover, I truly think that Apple would have been better off if they had decided to strengthen the ePub3 platform instead. They wouldn’t have been limited by the ePub3 format in any way. They could have chosen to do exactly the same thing they have done with the iBooks 2.0 format (with the possible exception, possibly, of the CSS layout extension, but tackling that subject would be material for several other blog posts, I think).

They would have gained much more mindshare, both among publishers and readers, and, together with other ePub platforms, would have presented a much more formidable opposition to Amazon’s Kindle platform.

Instead, they chose to implement what I think will be a short-lived niche format.

I don’t see how that makes any sense, not in terms of business, not in terms of finance, not in terms of marketshare.

The iBooks 2.0 textbook format, The iBooks 2.0 built-in widgets, and The pros and cons of the iBooks 2.0 textbook format ↩

What do we want from the Kindle platform?

2012-01-31T16:00:00-08:00

I thought it might be an interesting exercise to brainstorm a list of things developers, designers, and readers need from the Kindle platform (or any ebook platform, I just started with the most dominant one).

What follows is a quick, rough, unedited, off the top of my head, list.

What do book developers need from the Kindle platform?

Firebug or Webkit Inspector in the Kindle Previewer and, preferably, on the devices as well.
Design capabilities that match and are compatible with existing web tech. Including full bleed backgrounds, support for background-color: transparent (which doesn’t seem to work for DIVs in Kindle Previewer at least) and RGBA/HSLA colours.
Unify the media, video, and audio requirements. Try and support all the same formats as the other guys. Bonus points for enabling youtube video embeds in some way.
Better support for links. That includes linear=’no’ support and support for epub:types to enable things like popup windows, definitions, etc.
You should also be able to mark any non-linear page as fixed layout.
Steal an idea from Apple. No-code widgets to simplify the development of interactive books. The six built-in widgets that iBooks Author offers are a good start. (Do it in an ePub3 compatible way, preferrably.)
Covers should be multi-resolution icons. Separate bitmaps for each context.
An empowered ecosystem of toolmakers
Display:none support of some kind for older versions of mobi. Even if it’s just using a preprocessor in kindlegen.
Does the KF8 support IDPF font embed obfuscation?

What do toolmakers need from the Kindle platform?

Kindlegen as a brew recipe would empower command line tools. http://mxcl.github.com/homebrew/
Kindlegen as an API or through an embedded library, or even a bundle, would empower apps like Scrivener. Let apps that want to integrate mobi file export ship with an integrated kindlegen.
Kindle Previewer as an library with an API would help them even more. It should be powerful enough for people to be able to write plugins for their text editors to quickly generate a preview of the HTML file they’re editing.
Barring that, enable the previewer to watch a directory or file and quickly generate a new preview when it changes.
Document everything.
The best path to tools is compatibility with epub.

What do readers need from the Kindle platform?

kindle.amazon.com as an API. People should be able to have all of their book notes and quotes synced to their note-taking apps, like Evernote, Simplenote, or even as a directory of text files for the Dropbox-based note apps. Developers of writing and note-taking apps should be able to add kindle notes syncing with no more effort or paperwork (as in no paperwork to speak of) than it would take them to add Simplenote syncing, for example.
Give publishers the opportunity to deliver alternate covers and alternate themes that the reader can choose instead of the defaults.

All APIs, libraries, etc. need to be self-serve. That is, something a single programmer can sort out in a few minutes without talking to another human being. Nobody is going to create a plugin for a $50 text editor if they have to ask permission or sign a legal document.

Disruptive crap

2012-01-26T16:00:00-08:00

One of the reasons why big publishing is in trouble is that they have overshot the quality requirements of most fiction readers.

I’ve been circling this point for a while now1 but I believe that the big publisher, the international titans of publishing, are inevitably going to stop publishing.

That isn’t to say that they will exit the book market or the content industry, just that they will migrate towards higher margin businesses such as publishing services and more wide-ranging content development.

In other words, stop publishing.

This development won’t be caused by Amazon’s bullying or Apple’s egomania, not directly. The primary driver of big publishing’s eventual demise is that their competitors are willing to sell their products for much lower prices.

It’s not Amazon that’s driving prices down, if it were, they wouldn’t limit their 70% royalty rate to ebooks priced over $2.99.

Now, one of the big counterarguments is that these micropublishers can’t take over the market because they publish crap.

Their books look bland; don’t come even close to the typography and design of big publishing’s print books.

Their covers are often atrocious; no investment in the often magnificent covers that decorate the print industry’s output.

Their books aren’t edited; stories that waffle on, sentences with odd punctuation, a quirky interpretation of grammar.

Their research is non-existent; historical texts full of anachronisms, both in language and in setting.

In comparison, big publishing’s primary output, printed books, look like the over-engineered, angular, supermodels that dominate the fashion industry: A benchmark for artificial beauty.

What people don’t realise is that no sane person wants to date a supermodel. The ebook innovators, compared to the industry’s traditional output, publish crap and that’s why they will win in the long run.

The big publishing houses see these books as too rubbish to be publishable ant that’s why they will lose win in the long run.

Interlude

Most of my ideas here are based on Clayton Christensen’s theories on disruptive innovations.

A good overview of his ideas can be found here: Understanding How The Innovator’s Dilemma Affects You.

Clayton Christensen outlines some of the process himself here: The Innovator’s Battle Plan.

This 110 minute lecture is one of the best crash courses in his ideas I’ve found: Capturing the Upside.

The Theory

My present theory on the publishing industry is this: Big publishers have overshot the quality requirements of most fiction readers.

This overshoot is the fundamental cause of the disruptors’s ability to undercut big publishing in price.

The quality overshoot is, as I see it, twofold:

The print format dramatically exceeds the reader’s needs in terms of design, typography, durability, and resolution.
The publishing process dramatically exceeds the reader’s needs in terms of book length, attention to linguistic detail, and editorial micro-management.

Furthermore, the split process of delivering both a printed book and an ebook from the same source material compromises the publisher’s quality control on issues that the reader does care about: Formatting, readability, and not omitting major parts of the text. (All issues that frequently dogged major ebook releases in 2011.)

The format overshoot

Delivering a book to that fulfils the aesthetic standards set by big publishers is expensive.

These books are laid out in Indesign, a nightmarishly expensive piece of software to begin with, by designers who often pore over every letter in every word in every sentence on every page to make sure that the text is just right.

The typographic detail that Indesign and a printed book are capable of delivering is generations ahead of anything the web can make, let alone ebooks who steadily remain a few years behind the web in design capabilities.

This is also detail that most fiction readers don’t care about at all. Most of them are satisfied as long as the choice of typeface doesn’t alienate them. A decent embedded font and good XHTML/CSS templates for the book’s contents and you will have exceeded the requirements of every buyer you are capable of reaching. (‘Capable of reaching’ is a key phrase here. Make note of it because I won’t explain it.)

Covers are the printed book’s public face. A cover sells a book, identifies it, burns it into memory, promotes it—a printed book lives or dies by its cover.

Ebook covers are icons. They are multi-resolution signifiers that need to serve as symbolic proxies for the book in various contexts. An ebook reader rarely sees the cover fullscreen; it exists almost solely as an organisational thumbnail in searches and app interfaces. An ebook cover fulfils a different purpose and relies on different disciplines than a print cover. An ebook is badly served by repurposing the print cover.

Most printed books last much too long as objects. Of course, I want my favourite translation of Dante’s Divine Comedy to last several lifetimes so that it can be handed down for generations, but most fiction writers don’t – as we say in Iceland – even reach Dante’s heels with their toes2 when it comes to writing. A crime yarn is, after you’ve read it a couple of times, clutter.

Most avid readers have piles and piles of books that are just in the way once read. The space saving aspect of ebooks is, for many, a big selling point. The smaller the average flat and the more often people move, the bigger a point it is. (I don’t think, for example, many Americans appreciate how much smaller living spaces are on average here in the UK.)

The quality overshoot

The print publishing process has resulted in a very standardised, almost uniform, cultural artefact. The mainstream book is 350-500 pages long, often structurally micro-managed, and polished to an artificial standard of grammar and syntax,

This grammar, pushed by the publishing industry and bildungsphilister, is an artificial construct. The english language is a wilder beast than that. Just because you dislike another person’s use of language, it doesn’t mean you’re allowed to be an arsehole about it.

(See “Proper English: Myths and Misunderstandings About Language” for a good starter on the subject. And, no, I’m not saying that bad writing is fine. I’m saying that polishing everything to fit the standardised grammar of the publishing industry is very expensive.)

Not only do most readers have laxer ‘standards’ on grammar than your average line editor, but they are also often disproportionally receptive to seeing their own language styles used in the texts they read.

In other words, don’t polish the charm away.

The uniform length is the clearest example of how big publishing has left a large market unaddressed. (One of the early things that romance publishers did, once they got into ebooks, was to offer a variety of book lengths because they realised that sometimes you want a story that will only last an hour.)

The structural micromanagement is admittedly my pet peeve, because that level of structural obsession isn’t backed by any of the psychological research that has been done into enjoyment and pleasure.3 It simply isn’t an effective way of affecting people emotionally or intellectually. A textbook example of diminishing returns.

The undershoot

The disruptors, self-publishers and micropublishers, still manage to undershoot the reader’s requirements on a regular basis.

They are getting better. A network of services has built up around them: editorial, cover design, proofreading, formatting.

They build up the quality controls they can, around the low prices they have settled on. Over time there will be consolidations of one sort or another, and bigger publishers will grow out of the vibrant mulch that dominates the lower price points of the ebook market.

But, their margins will never be as big as that of our current big publishers.

Which brings us to the big publisher’s dilemma:

They can’t compete on price because they’d have to decimate their own companies to manage it and they’d have to deliver a product that their every instinct tells them is utter rubbish.
They can’t compete on quality because, even though they presently dominate in terms of revenue, the new entrants are steadily taking over in terms of unit sales. The reader doesn’t care that much about the quality a big publisher can deliver.

Their only solution is to get out of publishing, get into services, multi-faceted ‘content’ development, and licensing. It’s the only way they can maintain their margins and continue to deliver value to their shareholders.

Publishers are going to have to stop publishing, because crap is too disruptive.

In reverse-chronological order: A few future sources of ebook innovation, Futurebook 2011 Impressions: New publisher business models, The publishing animal, What a publisher does, Convert or engage, Hypotheses and testing, On quality in publishing, and Identifying publishing innovators. ↩
Að komast ekki með tærnar þar sem að annar hefur hælana. It’s an Icelandic idiom that roughly translates as not reaching with your toes where somebody else has his heels. It’s a way of saying that somebody else is far ahead of you. ↩
Some of the basic theories on emotions, off the top of my head: The Peak-End theory. The Gottman ratio and here. Csíkszentmihályi’s Flow. There’s also the two-factor theory of emotion, but that one’s probably not relevant to publishing. ↩

Me, elsewhere

2012-01-25T16:00:00-08:00

This blog post collects a few of the things I’ve been doing elsewhere on other sites. I’m doing this more for my own records (it’s dumb to have to google for your own stuff), so feel free to ignore.

Bookseller article: In depth: Iceland’s book market
Futurebook: Facebook isn’t the content industry’s saviour
Futurebook: The nine problems that hold back Icelandic ebooks
Futurebook: Futurebook 2011 Impressions: New publisher business models
Futurebook: A few future sources of ebook innovation
All of my Futurebook pieces so far are listed on this page: Baldur Bjarnason’s blog posts
I wrote a short piece on the Publish! event in Bristol for Creative Times: Publish! A day of innovation on the future of the book
I also liveblogged the Futurebook conference, although I only did so using Simplenote: Futurebook keynote, Device matters: Trends in content consumption, Discoverability and pricing strategies, International, Content Strategies: new revenue streams, and The new publisher.

Also, yesterday, I was on the panel for a really nice event done by Creative Times and Bristol’s Pervasive Media Studio: The Beauty of Digital #2: New technologies, old aesthetics and where the two meet.

It was a lot of fun, filled with smart people. I did a short piece on how modern publishing isn’t anything like what publishing used to be throughout its industrialised history, right into the 1920s/1930s.

The pros and cons of the iBooks 2.0 textbook format

2012-01-20T16:00:00-08:00

Delivering a bespoke format cannot have been an easy decision for Apple, since, as a company, it has come to know very well the benefits of working with standards.

This is the third post I’ve written on the iBook 2.0 textbook format. Previously:

There has been a lot of discussion on all sides on this new format Apple rolled out with iBooks 2.0. Some of it valid. Some less so. Some against all experimentation. Some not caring about standards at all. None of them change the fact that Apple has forked the ePub3 and CSS standards. It doesn’t matter if you agree or disagree, your opinion won’t alter reality.

One thing that bears mentioning is that almost everything ePub-related in the new format is completely standards-compliant. Where Apple has deviated it is not from the ePub format, but from CSS. Their widget format is, not as much a deviation from the standards, but a disregard of the standards and the philosophy of providing sane fallbacks for lesser reading apps.

Delivering a completely custom format has costs. Basing the format more cleanly on established standards would enable further code reuse, both authoring and rendering code, compatibility with other tools, and still enable Apple to gain leverage by rolling out features that its competitors can’t hope to match for months, if not years.

So, why do it?

Instead of getting into a tiff about it, I think evaluating the costs and benefits of the approach is more likely to deliver an understanding of why this has happened.

Note, I’m not getting into some of the issues with the iBooks Author app, as its limitations are not that of the format, and vice versa. Although, if Apple later on added support for ePub3 import and export to iBooks Author, that would solve a lot of the problems I mention below.

The cons

No fallbacks, no forwards-compatibility

Apple’s custom format, with a custom CSS layout model and bespoke widgets do not provide for much in terms of fallbacks for lesser reading systems, nor do they offer any future-compatibility with whatever ePub3 systems that might be rolled out.

These textbooks are tied to iBooks 2.0 on iPads. No iPhone support at the moment. No Android support ever. There’s no doubt that Apple doesn’t see this as a flaw, but for both publishers and readers, it is. A publishers have always had the option of selling their books in the iBookstore (or any ebook store, for that matter) DRM-free. This has allowed readers to move some of the books they buy to other platforms when they want. This is good for the reader at, despite what some publishers say, a minimal cost to the publisher.

This is no longer possible with the iBooks textbooks. The format doesn’t provide for much in terms of sane fallbacks for the built-in widgets or the layout features. Even if publishers had full documentation for the format and hand-coded their books, they’d still be hard-pressed to deliver a book with sane fallbacks for those using lesser reading systems.

The same applies if we look at hypothetical, full-featured, ePub3 reading systems that match, or closely match, iBooks 2.0’s capabilities. Because of the differences in the format, delivering a textbook that works sanely as a iBooks textbook and as a ePub3 book is difficult, if not impossible. Some of the issues could be solved through automatic conversion (the widgets, at least), but the CSS layout models is sufficiently different to thwart, in my opinion, most attempts at conversion. You’d have to implement the CSS layout twice.

This means that, unless Apple eventually adds ePub3 capabilities that match the textbook format to iBooks, publishers will have to implement interactive ebooks twice, and readers who buy interactive ebooks from Apple will be locked in iBooks.

This isn’t good for publishers. This isn’t good for readers. This isn’t good for authors. This is just Apple, being selfish.

Bespoke = legacy format from hell

One of the features planned for iBooks textbooks that doesn’t get much mention are updates. One of the core concepts is that you buy a textbook once and it gets updated by the publisher.

Congratulations! You have now bought into the legacy format from hell.

A format that doesn’t work with a publisher’s workflow, differs in important but subtle ways from standard formats, isn’t supported by any of the industry’s tools, is, long-term, going to be a torture to support.

Even if iBooks manages to build itself to a majority market position (by no means sure, given how tiny they are at the moment), publishers still need to support other platforms, and those platforms, by virtue of supporting open standards will have a much greater ecosystems of tools and processes to build on.

Even Amazon, with it’s custom Kindle formats, didn’t fork or extend CSS in incompatible ways, and it has pretty good support, with KF8, for ePub as an authoring format.

It’s less standards friendly in other ways, such as its deviations from the de facto standard fixed layout format, but Amazon’s crimes don’t excuse that of Apple’s.

In any case, with the new textbook format, Apple cuts textbook authors from a growing tools ecosystem that even Amazon is supporting. (The latest kindlegen has pretty good support for converting ePub files to KF8.)

The pros

Delivers capabilities beyond that of ePub3

One reason mentioned for forking the standard is that Apple needed to deliver capabilities beyond that of ePub3.

The ePub3 format allows for extensions and provides for ways of implementing those extensions with fallbacks for less capable reading systems.

So this simply is not true. The ePub3 format doesn’t limit them in this manner, and Apple could have easily addressed whatever limitations it had encountered, during the standards process, where they had a considerable influence.

Delivers an exclusivity that a standards-based format cannot

Also something I find hard to believe. ePub3 does allow, for example, for extending the format’s capabilities with widgets, so there’s nothing in the format that prevents competitive differentiation through new widgets. Apple deliberately didn’t use these capabilities in the iBooks 2.0 format. ePub3 also doesn’t limit the creator of a reading system from supporting cutting-edge CSS features, such as early draft standards, which enables a similar sort of system of experimentation as browser developers have been maintaining.

Apple could have provided all of the same features it did, using early drafts of CSS standards, instead of going off in a completely custom direction. This would have given them all of the same benefits of exclusivity as their current approach. Competitive differentiation does not benefit from completely forking the CSS standard when they could have differentiated themselves in standards-friendly ways, as they have done in the past with web browsers. Whenever Apple has extended standards with Safari, they have always brought their extensions to the W3 for standardisation, often well before the features are rolled out in an official version of Safari.

You’d think that this would kill off any attempt at differentiation, but despite this, Mobile Safari remains the best, most capable, mobile browser in the market, far ahead of the competition, even with the advent of Android 4.0. I don’t see why the same approach wouldn’t work with iBooks.

Standards are too slow

True. If you were talking about limiting yourself to Recommendations or Candidate Recommendations, then that’s very true. But nobody does that. There isn’t a single major browser vendor whose CSS support is limited to Recommendations or Candidate Recommendations.

If there had been no proposed standards, early drafts, or discussions in the CSS Working Group about delivering the capabilities that Apple requires, then this would be a very valid point. In that case, Apple would even be doing vital research work that would benefit the standards process later on.

However, this is not the case.

The CSS Working Group has been in discussion on advanced layouts for years and in 2011 it finally saw some progress in the standardisation process as both Microsoft and Adobe entered the fray with full vigour. Apple has been a full participant of this work, been clear about their needs and requirements, and has been fully aware of its progress.

As a result of the work over the last few years, there are now several promising proposals being discussed. Apple has no excuse for completely inventing a new approach. If they had needs that weren’t being addressed by the proposals they should have done more than just send one vague e-mail.

To wit: They could have implemented one of the discussed standards instead. Or, they could have helped fix the discussed approaches instead of going completely on their own.

Those who accuse standards bodies of being slow also don’t appreciate the IDPF’s phenomenal speed in putting together the ePub3 standard, a process where Apple was a pivotal member.

Who cares? iBooks still supports standard ePubs

That is not the issue at stake. Sure, iBooks supports standard ePub2 files, which are much more limited in the interactivity and designs they support. They aren’t going to remove support for that format.

The issue is that the new format raises questions about the future. As a member of IDPF and a participant in the ePub3 standards process, Apple seemed to be committed to delivering support for the new format.

Apple was the IDPF member that had come closest to delivering the features and capabilities of ePub3 with iBooks.

The idea behind ePub3 is that it would, finally, bring ebooks to a relative feature parity with the web and enable more advanced authoring and reading tools. The iBooks Author application is exactly the sort of app people expected would be brought to market as a result of ePub3’s capabilities. The iBooks new textbooks are exactly the sort of dynamic, interactive, and rich ebooks that ePub3 enables.

Now that Apple has decided to deliver both as a part of a custom format that throws the future of ePub3 into question. Apple isn’t an outsider who decided that a format somebody else didn’t have the capabilities it needed, it is essentially one of the format’s co-authors. One of the format’s biggest proponents and supporters has forked ePub3.

This is akin to Google deciding to build support for an incompatible fork of the HTML5 standard in Chrome after it had gone through the trouble of building consensus around the standard.

Will Apple add ePub3 to iBooks now? If they do, will they do a full-featured implementation that matches the capabilities of the textbook format, or will they just work like a warmed over ePub2 files?

What was the point of Apple’s participation in the ePub3 standards process?

No. I have to say, I still don’t understand why they did it.

The iBooks 2.0 built-in widgets

2012-01-19T16:00:00-08:00

The built-in widgets that provide the brunt of the interactive features in iBook’s textbook format do not use javascript in any way.

Some additional reading before we dive into my short post…

Daniel Glazman (CSS working group’s co-chair) wrote about iBooks Author and the format it generates: “iBooks Author, a nice tool but…” “Apple (re-)invented the Web totally incompatible with the Web. “
Turns out you aren’t allowed to sell the books you create in iBooks Author outside of iBooks: “The Unprecedented Audacity of the iBooks Author EULA”.
The Vook blog notices some of the same things I have: “iBooks 2 and iBooks Author: Another opportunity & headache”. “This is a proprietary file format that only plays in iBooks (edit: it’s not quite epub2 and it’s not quite epub3, nor is it quite XHTML5—plus the widgets are iBooks built-in components rather than open standards JS).”
Updated, 2 February 2012: I’ve clarified my perspective here: iBooks widgets – to javascript or not to javascript. For the record, I don’t lament the fact that these widgets weren't implemented in javascript.

This is the second post of three I’ve written on the iBook 2.0 textbook format. Previously:

The widgets

iBooks Author provides authors with six built-in widgets:

Gallery.
Media (movies and such).
Review.
Keynote.
Interactive image.
3D.

As far as I can tell, after putting together a sample book with most of these widgets and then inspecting that book’s code in BBedit, none of these widgets use javascript in any way. I couldn’t find a single line of javascript in anywhere in the ebook’s files.

Why is this important? Because javascript is the only cross-platform and standard method for delivering interactivity in hypertext files, such as HTML or ePub. The way Apple has implemented these interactive widgets is through object tags with custom types and data attributes. The type tells iBooks what sort of widget it is and the data attributes give it the parameters. The code to do this are iBooks-only extensions to the webkit rendering engine they are using.

Here’s the full code, as far as I can tell, of a gallery widget:

<object type="application/x-ibooks+anchored" data-anchor-ref="danchor-gallery-0">
    <object type="application/x-ibooks+anchorednormal">
        <object id="gallery-0" class="s12" 
        type="application/x-ibooks+widget" 
        title="Gallery 2.1 Lorem Ipsum dolor amet, consectetur" 
        data-widget-type="gallery" 
        data-geometry="affineGeometry(440,435,1,0,0,1,291,164)" 
        data-fullscreen-only="no" 
        data-content-layout="top-bottom" 
        data-corner-radius="0.000" 
        data-content-padding="0.000" 
        data-gallery-show-thumbs="no" 
        data-gallery-share-caption="no" 
        data-stage-corner-radius="4.00000" 
        data-stage-geometry="affineGeometry(440,327,1,0,0,1,0,28)">
            <svg xmlns="http://www.w3.org/2000/svg" id="textShape-497" viewbox="0 0 440.000 38.000" preserveaspectratio="none" data-widget-object-type="caption">
                <title>
                </title>
                <desc>
                </desc>
                <rect class="s3" x="0" y="0" width="440.000" height="38.000" />
            </svg>
            <div data-widget-object-type="gallery-item" data-gallery-item-fullscreen-crop-rect="0 68 600 446">
                <img data-widget-object-type="gallery-fullscreen" src="assets/images/knights1-b.jpg" alt="" /><img data-widget-object-type="gallery-thumb" src="assets/images/ScaledThumbnail.jpg" alt="" /> 
                <div data-widget-object-type="caption">
                    <a id="textShape-499-hint" class="shape" /> 
                    <p id="textShape-499-p0" class="s13">
                        Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do tempor incididunt ut labore et dolore magna aliqua. 
                    </p>
                </div>
            </div>
            <div data-widget-object-type="gallery-item" data-gallery-item-fullscreen-crop-rect="0 307 600 446">
                <img data-widget-object-type="gallery-fullscreen" src="assets/images/knights2-b.jpg" alt="" /><img data-widget-object-type="gallery-thumb" src="assets/images/ScaledThumbnail-1.jpg" alt="" /> 
                <div data-widget-object-type="caption">
                    <a id="textShape-500-hint" class="shape" /> 
                    <p id="textShape-500-p0" class="s13">
                        Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do tempor incididunt ut labore et dolore magna aliqua. 
                    </p>
                </div>
            </div>
            <div data-widget-object-type="gallery-item" data-gallery-item-fullscreen-crop-rect="0 323 602 447">
                <img data-widget-object-type="gallery-fullscreen" src="assets/images/knights3-b.jpg" alt="" /><img data-widget-object-type="gallery-thumb" src="assets/images/ScaledThumbnail-2.jpg" alt="" /> 
                <div data-widget-object-type="caption">
                    <a id="textShape-501-hint" class="shape" /> 
                    <p id="textShape-501-p0" class="s13">
                        Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do tempor incididunt ut labore et dolore magna aliqua. 
                    </p>
                </div>
            </div>
            <div data-widget-object-type="gallery-item" data-gallery-item-fullscreen-crop-rect="0 28 605 450">
                <img data-widget-object-type="gallery-fullscreen" src="assets/images/knights4-b.jpg" alt="" /><img data-widget-object-type="gallery-thumb" src="assets/images/ScaledThumbnail-3.jpg" alt="" /> 
                <div data-widget-object-type="caption">
                    <a id="textShape-502-hint" class="shape" /> 
                    <p id="textShape-502-p0" class="s13">
                        Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do tempor incididunt ut labore et dolore magna aliqua. 
                    </p>
                </div>
            </div>
            <object type="application/x-ibooks+shape" id="textShape-498" data-widget-object-type="title">
                <svg xmlns="http://www.w3.org/2000/svg" id="textShape-498-svg" viewbox="0 0 440.000 18.000" preserveaspectratio="none">
                    <title>
                    </title>
                    <desc>
                    </desc>
                    <rect class="s3" x="0" y="0" width="440.000" height="18.000" />
                </svg>
                <div class="s4" id="textShape-498-div">
                    <a id="textShape-498-hint" class="shape" /> 
                    <p id="textShape-498-p0" class="s14">
                        <a id="anchor-1" />
                        <span class="c7">
                            Gallery 2.1
                        </span>
                        <span class="c6">
                            Lorem Ipsum dolor amet, consectetur
                        </span>
                    </p>
                </div>
            </object>
            <img id="gallery-0-alt" src="assets/images/gallery_74D001F0-1189-45F5-A788-7BF5204EF72E_fallback.png" alt="Gallery 2.1 Lorem Ipsum dolor amet, consectetur" /> 
        </object>
    </object>
    <object type="application/x-ibooks+anchoredgutter" data-geometry="affineGeometry(125,158.897705,1,0,0,1,50,0)" data-gutter-order="0" class="s15">
        <div data-widget-object-type="style-info" data-widget-style-type="paragraph-style" class="s16" /> <img id="gallery-0-gutter" class="s3" src="assets/images/flow.png" alt="" /> 
    </object>
</object>
<svg xmlns="http://www.w3.org/2000/svg" id="textShape-106" viewbox="0 0 962.000 686.000" preserveaspectratio="none">
    <title>
    </title>
    <desc>
    </desc>
    <rect class="s2" x="0" y="0" width="962.000" height="686.000" />
</svg>
<svg xmlns="http://www.w3.org/2000/svg" id="textShape-107" viewbox="0 0 962.177 0.024" preserveaspectratio="none">
    <title>
    </title>
    <desc>
    </desc>
    <path class="s6" d="M 0 0.024394 L 962.176758 0" />
</svg>
<svg xmlns="http://www.w3.org/2000/svg" id="textShape-108" viewbox="0 0 0.000 620.000" preserveaspectratio="none">
    <title>
    </title>
    <desc>
    </desc>
    <path class="s11" d="M 0 620 L 0.000022 0" />
</svg>
<object type="application/x-ibooks+shape" id="textShape-109" data-original-id="textShape-104">
    <svg xmlns="http://www.w3.org/2000/svg" id="textShape-109-svg" viewbox="0 0 924.000 20.000" preserveaspectratio="none">
        <title>
        </title>
        <desc>
        </desc>
        <rect class="s3" x="0" y="0" width="924.000" height="20.000" />
    </svg>
    <div class="s4" id="textShape-109-div">
        <a id="textShape-109-hint" data-original-id="textShape-104-hint" class="shape" /> 
        <p id="textShape-109-p0" class="s9">
            <span class="c6">
                8
            </span>
        </p>
    </div>
</object>

In theory, other reading systems could reverse-engineer the code for this, or a conversion tool could be built that provides javascript that renders this, but that task is enormous given the undocumented complexity of the parameters possible and the variety of features these widgets support.

The problem

The biggest disappointment with the iBooks 2.0 textbook format isn’t that Apple decided to extend ePub. They have done so before. Fixed-layout ePubs, because it was a fairly well documented extension (even though that documentation wasn’t public) and conceptually straightforward, ended up being a positive innovation for the ebook industry.

The biggest, most heart-wrenching, disappointment is that Apple could have done all of this in a standards-friendly manner.

Instead of using an undocumented extensions to CSS, they could have built on the proposed standards for regions and text-wrapping.

The solution they chose for widgets is also perplexing since ePub3 provides a solution exactly for this use case: Bindings.

ePub3 provides a standard method for defining handlers for media types it doesn’t support. Through the bindings element Apple could have provided handlers for its widgets, written in javascript, so that its books would have been forward compatible with other, future, ePub3 reading systems.

The widget problem can be solved either by conversion tools or by competing reading systems by reverse engineering the data attributes and object types Apple uses, and writing compatible handlers.

But I don’t see an easy way to convert the layout code to more standard CSS. The basic model behind Apple’s method and the methods proposed by the CSS WG differ in fairly fundamental ways.

I hope I’m wrong.

Update: iBooks widgets – to javascript or not to javascript. Again, I do not lament the fact that these widgets weren't implemented in javascript.

The iBooks 2.0 textbook format

2012-01-18T16:00:00-08:00

Today, Apple released both iBooks 2.0 and an authoring app called iBooks Author. The new iBooks, the authoring app, and Apple’s new textbook category are all based on a new ebook format Apple has invented.

I’ve spent a few hours staring at the innards of a file exported from iBooks Author in an attempt to understand what it going on. I still only grasp a fraction of what they are doing, but I figured I might share my theories at this point.

The good

Apple’s new format is mostly ePub3. It has valid NCX and OPF files. The XHTML files are all XHTML5. It uses SVG extensively. Promising.

The meh

The XHTML files all use declarations of the form

<?xml-stylesheet href='*' type='text/css' media='*'?>

to link to CSS files, instead of the more usual (and certainly more standard way, since they’re using the HTML5 doctype) link element.

The mimetype iBooks uses for these files is application/x-ibooks+zip. In and of itself not bad news, but it is a clear indicator that Apple doesn’t want this to be treated like ePub. That is, they do not want to have to worry about making sure that the output of iBooks Author is readable in ePub reading systems.

Yup, that’s a cue for ominous music.

The bad

The CSS files are full of undocumented extensions to the CSS standard, few of which seem to be from any version of any spec I could find on the W3.org website. Things like:

-ibooks-layout-hint: inline;

and

-ibooks-list-text-indent: 0.0000pt;
-ibooks-strikethru-type: none;
-ibooks-strikethru-width: 1.0000px;
-ibooks-underline-type: none;
-ibooks-underline-width: 1.0000px;

and

-ibooks-gutter-margin-left: 50.0pt;
-ibooks-gutter-margin-right: 25.0pt;
-ibooks-head-height: 660.0pt;

and

-ibooks-line-hints: textShape-0 p url(../hints/content1-landscape.plist) 13 7;

Apple has chosen to use custom properties to define strikethroughs, underlines, margins, and heights in various contexts, with no standards-compliant fallbacks, to get a level of control over the visual design that standard CSS does not offer.

The ugly

A lot of the layout and text-wrapping features of an iBooks 2.0 file are defined in non-standard ways.

The XHTML files contain object elements with types such as application/x-ibooks+flowhead and application/x-ibooks+shape that tie in with the way the file is laid out in undocumented ways. The CSS link to .plist files with properties called -ibooks-line-hints. Your guess as to what that’s for is as good as mine.

They use CSS like this to define some text-wrapping and layout areas:

@page ::nth-instance
{
    height: 748.0pt;
    width: 1024.0pt;
    ::slot(textShape-122)
    {
        height: 668.000pt;
        left: 512.000pt;
        top: 40.000pt;
        width: 0.000pt;
        z-index: 1;
    }
    ::slot(media-7)
    {
        -ibooks-box-wrap-exterior-path: directional contour both 12.0pt 0.500000 false;
        height: 668.000pt;
        left: 535.000pt;
        top: 40.000pt;
        width: 440.000pt;
        z-index: 2;
    }
    ::slot(textShape-1)
    {
        height: 334.000pt;
        left: 50.000pt;
        top: 40.000pt;
        width: 440.000pt;
        z-index: 3;
    }
    ::slot(textShape-0)
    {
        height: 300.000pt;
        left: 50.000pt;
        top: 408.000pt;
        width: 440.000pt;
        z-index: 4;
    }
    -ibooks-positioned-slots: textShape-122, media-7, textShape-1, textShape-0;
}

This CSS is, as far as I can tell, completely non-standard. The only public documentation I can find is an e-mail from an Apple employee to a W3.org mailing list.

This piece of code is going to be gobbledygook to all web browsers and all ePub reading systems. I don’t see an easy or straightforward way of converting this piece of CSS into anything understandable by other apps.

It is one thing to deliver a format that is ePub3 in all but name. The differences between the iBooks 2.0 format and ePub3 seem all but trivial. But when that format is built around non-standard extensions to the CSS rendering model and all of the XHTML and the CSS are built around that extended model, the file is likely to forever be useless and unreadable in other reading systems.

The work involved in converting an iBooks 2.0 file to a standard ePub3 is likely to be easy.

The work involved in converting the iBooks 2.0 CSS to something ePub3 reading systems or browsers, however, is likely to be too great to be worthwhile.

Rewriting the CSS for a complex, intricately designed, book from one layout model to another is also probably impossible. The reason why Apple chose a non-standard layout model is probably because the ones currently standardised and proposed by the W3 cannot deliver the designs Apple is aiming for.

Update: I also wrote a post on “The iBooks 2.0 built-in widgets”.

Update 2: My last thoughts on the subject. “The pros and cons of the iBooks 2.0 textbook format”.

The publishing animal

2012-01-16T16:00:00-08:00

Publishers, in ecological terms, are at the top of the publishing industry’s food chain. They are highly adapted to their, now changing, environment.

The fauna

The value that most publishers have provided in recent history1 has been relatively clear and obvious to even the most biased outsider. They provide capital for writers and others involved to finish their work. They arbitrage between the numerous unknown writers who think they’re the greatest thing since sliced bread2 and the even more numerous readers who are tired of the unimaginative, self-important, idiots who think they’re the greatest thing since sliced bread.

They have invested in a intricate quality control infrastructure, which has been developed over several decades and affects every step of the bookmaking process, from writing, to the design, to the printing, and to the delivery of the final package.

They are business-to-business corporations who know that their survival has hinged on their ability to give booksellers the tools they need. Tools booksellers then use to unload semi-coherent tripe onto a sub-literate populace—buyers who really should know that their time and money is better spent on a boxed set of Pixar movies, not on whatever self-important hipster the ‘literature’ industry has decided to push this week.

They have built up relationships with the megafauna of the publishing world: Distributors and printers, two animal species that are routinely inaccessible to individual actors.

They are, in short, specialised animals who, over the last century of publishing, have been the fittest of the lot and so have survived.

The microfauna bloom

The problem with publishers isn’t with publishers as a class of species. There’s still room for larger animals that live higher up in the publishing food chain.

The problem isn’t that all publishers must die and be replaced with writers acting alone.

The problem is that their environment has changed, completely and drastically.

Like an algal bloom, the explosive growth of small and self-publishers – enabled by the entrance of a new megafauna species, the ebook ecosystem vendor – has in many ways sucked the oxygen away from the big publisher’s environment.

This is only a bad thing if your intellectual faculties are crippled by nostalgia and you have a pathological emotional attachment to ill-suited companies who have to be kept on mechanical ventilation to survive.

The ebook infrastructure has nothing in common with the old retail infrastructure that provided publishers with the nutrients they need to thrive, an infrastructure heading towards an inevitable collapse. When ebooks eventually become half of the book market, the old print infrastructure will be trying to survive on half the revenue it formerly took for granted. There is no industry that can cope with a loss of revenue of that magnitude, in such a short space of time, without collapsing.3

This means that existing, previously fit, publishers are facing a new environment where their capabilities for dealing with distributors and booksellers has little economic value. It means their quality control processes are inappropriate and over-costly for the ebook market. It means they are ignorant of new methods of arbitrage between the mass of unknown writers and the crowd of bored schlubs that enable them to connect with each other without turning book browsing into a full-time job. Most of the costly, energy-intensive, characteristics that made them fit for the old world, are making them slow and unfit for the new world.

A new species?

Anybody who has given the history of innovation even a cursory read knows that the incumbents rarely survive. The very characteristics that made them fit and well run in the old environment are liabilities in the new.

But, a mass extinction isn’t such a bad thing if the big blokes dropping dead are dinosaurs and you are a lean, mean, mammalian surviving machine.

Some of the value a publisher provides remains. A single writer can’t be expected to build up a network of designers, coders, editors, marketers, just writing the goddamn book is difficult enough4. Some of them will, not because they have to, but because they want to. (Tackling a multi-dimensional problem like that is actually fun.) But, that’s one thing the new publisher can provide.

Another vital ingredient in the bookmaking stew is capital. Writers, designers, coders, editors, and everybody else involved need money to live and eat and sleep occasionally.

Finally, even though the new marketing and arbitrage environment is different from that which surrounded the old publishers, it still rewards expertise and participation.

The new publisher is a small company, only a few employees tapping into a network of services and freelancers. It can thrive by selling ebooks at a fraction of the price the big publishers demand. And, most importantly, its output is no more and no less vacuous and inane as the regurgitated MFA-slime that it replaces.5

It’s just crap in different ways.

Of course, there will be good books here and there, but good books are, and have been for decades, such a minute quality in the publishing industry that they are completely irrelevant in economic terms. A well written book in the ebook era is just as much of an aberration as it was in the print era.

If the publishing industry had to survive on just selling good books, it’d disappear overnight. All bookstores would close. Amazon would fold. Rakuten would flush Kobo down the toilet like a dead hamster. Apple would continue without missing a beat, possibly with a sigh of relief. Good books are a rounding error in the economics of publishing.

Ebooks will do nothing to change the fact that most people are idiots with no taste6, both inside and outside of publishing.

Recent history in print publishing being anything that happened after World War One. ↩
But they all know they aren’t, which is the reason why the profession is cluttered with neurotic, passive-aggressive, fucks. ↩
The definition of collapse I’m using here is that of Tainter’s: “Collapse is a rapid transformation to a lower degree of complexity, typically involving significantly less energy consumption.” This isn’t to say that print will die out or that it won’t be important, just that the print publishing ecosystem will be substantially simpler and be able to survive on much less revenue. ↩
Obviously, since so many seem to be so so bad at it. ↩
Of course, the new publisher is already here. Plenty of them around. What I’m saying is that there’ll be more of them and that there will be fewer big publishers. ↩
It gets worse. Even the smart ones are usually just bildungsphilister—little more than caricatures. ↩

A day of innovation on the future of the book

2011-12-07T16:00:00-08:00

I’m here at the Media Futures day on books and innovation and the future, that sort of thing.

Coming at this with no expectations; the programme seems interesting.

First off is a short introduction, followed by talks on innovation and the book by William Higham, Alastair Horne, and Michael Kowalski

Then we have show and tells on making money on digital by Anna Lewis, Meg Geldens, and Charles Catton.

After lunch there’s a panel which has something to do with the question pioneers, or playing it safe? At least, I think it’s supposed to be a question. It seems like one of those things you’re supposed to ask, or think about, in events like these. The panel members are: Dean Johnson, Erica Wolfe-Murray, and Naomi Alderman.

The next to last part will be talks and show and tells on inventing the future by Dave Addey, Chris Book, and Alexis Kennedy.

Lastly, talks and show and tells on how to innovate by Matt Marsh, David Burton, and Mike Phillips.

This might be an interesting day.

The chair Nico Macdonald mentions that innovation has historically been lacking in publishing. Not sure I agree with that, it’s just been completely ignored by the mainstream.x

Innovation and the book

First off, William Higham, the Next Big Thing. He works with applied trends. That’s a glorified fortune teller, then (haruspex is my favourite term for these professionals).

I remember this guy from monday. Was bored then, feels like boredom isn’t far off now, either. A lot of these observations can be kind of interesting, the problem is with pretending that they are about the future; they’re about the present and the past. He doesn’t have any way of knowing whether any of these current trends will carry into the future.

Anyway, I’m skeptical, but I’m sure somebody out there finds his talk useful.

Next, @pressfuturist, Alastair Horne, author of Future of Publishing Report.

Roughly, his points in my words (I’m less polite than him):

The effects of the digital transition affect everybody in the publishing chain, all disciplines. People in the industry now a new adaptable mindset, an agile and flexible approach. The problem is that people in the publishing industry do not have these skills and many of them don’t have the mindset. The low turnover of staff in the industry compounds the problem, as publisher will need to invest quite a bit of money in training staff, which makes them more desirable by other industries. In short, pay will have to rise, which means higher costs in an environment where margins are collapsing and prices are descending.

Workflows and processes for print don’t work with digital. They limit potential business models, revenue models, and product opportunities. The problem won’t be competing with publishers (because they’re broken as well) but competing with startups and new entrants into the field.

The new devices that are growing the fastest are multi-functional devices. It’s easy to buy a book on them, but it’s also easier to buy games and movies (and they’re probably considerably cheaper, and the games will last longer).

Interactivity doesn’t work as an afterthought, it needs to be there from the start. Essentially, it’s hard to interpret this differently, he’s saying that we have to stop thinking about books.

He does a massive comparison with the intro to WWI. Quite a few mischaracterisations, IMO, but let’s see where he’s taking this. Essentially, things are volatile. Goes into an entire thing about alliances (but I thought one of the things that started WWI were all of the alliances that forced everybody into the war after that Archduke dude got shot?).

Publishers, in his opinion, need to partner with newcomers, gain all the same skills as the competitors have, build up a direct sales business to compete with Amazon and Apple, walk on water and turn the water into wine. (I’m skeptical that they can do this. Can you tell?)

Baldur’s opinion: It’s nasty to say this, but maybe the new entrants and startups should win and the old guard should just go bankrupt. Then the new media capable staff from the old guard can just go work for the new guys. In fact, that’s what almost always happens with these sort of disruptive changes. I’m also not sure that it’s healthy to view Amazon or Apple or any of the new big customer relationship companies as your enemy. What’s healthy is not being beholden to them, but an adversarial stance isn’t going to benefit anybody.

Next, Michael Kowalski from Contentment. Talks about cheap and easy app production. You need to deliver a product that works in both orientations.

He raises the idea that ebooks and apps are just two different kinds of containers for the same content.

Two types of ebooks: Flowed and fixed layout. (Old news to anybody familiar with eproduction). He presents fixed layout as the only way to design ebooks, that you can only to damage limitation in flowed ebooks.

Two which I say: Dude! Web design! Flowed all the way! Designed! Sheesh.

Mentions that printed books have a few interactive affordances themselves that shouldn’t be discounted. OTOH, he presents the digital solutions as superior, which isn’t necessarily true.

Anyway, he’s now going to show us how to make an app thingy. Presents the magic solution: HTML! Everything’s based on HTML.

I hope this isn’t news to anybody here who’s listening to this.

Points at Phonegap, pugpig, and Baker, which are all app frameworks for turning HTML apps into native apps.

There’s a lot of history and methodology that web developers have learned that can now be applied to ebook development. This is a point I’ve been harping on incessantly.

“Indesign is a paint program.” Both the epub and HTML outputs are, in his opinion, unusable out of the box.

He says that web people don’t understand designed content. Speak for yourself, dude.

He’s planning to show some screenshots from the app version of the Future of the Book Report. Looks like he’s embedded the PDF there and added interactive content around it – tweets, at the moment, and links – (all of the pages look identical to the PDF I read yesterday).

Baldur’s opinion: Judging from both Futurebook 2011 and today, there is a clear flight to higher margins taking place in the industry. That’s the reason why everybody is still hoping enhanced ebook apps thrive. The need to produce apps on the cheap is a part of this flight.

Making money from digital

Haidee Bell Chairs.

Anna Lewis begins. Founder of Completelynovel, an online publishing platform with all the doodahs and wingdings. Valobox is a digital-oriented spinout. It’s about creating a ‘premium content layer for the web’.

Whatever that means.

Books are premium content. As they tweeted it: “@pressfuturist: #publish2011 @anna_cn: ValoBox creates a premium content proposition for the web. Agrees publishers shd work with start-ups, unsurprisingly.”

Books should be as accessible as a web page (my caveat: as accessible as a well made web page). She isn’t talking about accessibility here, but about lowering barriers to purchase and use. Put the content first.

Social. She says that there has been a fundamental shift in the way we access information.

Valobox is an online widget, basically. A widget that embeds the book with social features and doohickeys. Doesn’t look that bad.

The widget looks like is just a preview, and you can buy the whole book or just for each page. You can pay your way into the book piece by piece, just buying one page at a time.

Also has the same sort of sharing thingamajigs as your average over-cluttered web page.

Private beta. ‘Social commerce.’ Rewards for sharing if people buy.

She’s asked: How would you sell the idea of this?

The answer: Think about conversion rates. Certain bits of the book are more valuable than others, information about which bits are those valuable bits is, well valuable. (She was more eloquent than that, my syntactic failure, I’m afraid.)

Somebody asks a question of how you prevent people from just stealing the content.

Her answer: You can’t really. Which is an honest and true answer. You can just try to make it difficult.

Baldur’s opinion: I’m very skeptical about the whole pay for every page thing, the embedded widget thing, the social thng, well, the whole Valobox, in fact. This concept also only really has value for non-fiction that can be exploded and disintegrated. Reference books, etc. The problem with that is that those titles are being slaughtered by free, ad-supported, web sites, which are always going to trump the nickel and diming that this business model is based on.

There’s a good chance you won’t eve be able to get people to steal these books, they’ll just go to the websites instead.

Meg Geldens. CFO, Touchpress, makers of the Elements and Solar System. This should be interesting.

Two distinct things about the company: 1. Brings together a diverse set of skills; software, engineering, tv, design skills all in one company. 2. Partnership model. They partner with content/intellectual property owners, publishers, museums etc.

Looks really good. These are in essence, high end boutique projects, the iPad equivalent of coffee table books you actually enjoy.

They didn’t expect the sequence of content adaptation they’ve been seeing: The iPad versions are later adapted into book form. Their next project is already lined up for adaptation into print form.

On making money: It depends on how you define success. 1. Financial success. Quick return versus long shelf life. 2. Critical success, awards. 3. Attention getters. Apps that have garnered a lot of attention.

Their unit sales seem to vary a lot. Revenue/royalty model, the money’s shared between partners.

Their budgets are big and getting bigger: A hundred to a hundred and fifty thousand pounds and more. She describes fifty thousand pounds as “bare bones.”

Shows The Waste Land. It’s a pity that I have a lifelong dislike of any poetry written after Paradise Lost (give me Sonatorrek or Divine Comedy any day over the newer stuff).

Looks very nice, though. Full of the kind of rubbish obsessive compulsives like and pseudo-intellectuals pretend to need.

Key features of a successful product on Apple’s platform:

Universal topics, global appeal for translations.
Content needs to be well suited to the iPad, developed specifically or carefully adapted.
High levels of quality and software engineering.

We get a preview of Skulls. Which does sound cool. It’s in the hands of Apple, should be released soon.

She got some ‘book is still’ king comment from the audience that I’m immediately tuning out.

Baldur’s opinion: This sort of product isn’t going to save the publishing industry, the skills and competencies involved are too rare and valuable for that to happen. But it is going to be a nice niche for those who have a passion for making something beautiful. Very expensive. Very difficult to pull off. Even harder to sell. The production budget is going to have to be matched by an equally big advertising/promotion budget for this kind of business to work reliably. I’ll bet the average combined production and marketing budgets for this kind of project will end up in the one million dollar range within a few short years.

Hard to do. There will be a lot of dead bodies on this road.

Charles Catton, Publishing manager, Amber Books.

His presentation is called “The Great Gamble?”

How can we get the content to people in the best possible way, sometimes it’s print, sometimes it’s ebooks, sometimes apps.

Amber books are an illustrated book packager, sometimes publisher. He shows some of the print books they’ve done in the past, full of high quality illustrations. They own the rights to everything outright, don’t have to pay royalties or anything. They pay everybody a guaranteed fixed fee.

Gives them an advantage in the digital world, they are free to experiment as they choose.

Apps and ebooks, two key areas.

The only way to make money in apps is to ‘make awesome apps’. It’s a tough market with big budgets and low prices.

They’ve done apps with different models. Expensive budgets, he calls the ‘roulette option.’ Or, cheaper budgets, which he calls the ‘blackjack option.’

Some of the apps they’ve done is on a revenue share basis: They give an app developer the content and get a revenue share deal. Simple apps. Low cost to them, and low risk, (hence profitable).

Other apps have a higher budget, with simple animations, which have sold well in the education market. Few features, but focused on the needs of students (like notes).

The Dragons! app is actually something I’m more likely to buy than anything Touchpress does. Dragons are cool.

Ebooks: The safe bet? Don’t cost very much and you see revenue quickly.

Charles says, true… for fiction. Illustrated fiction isn’t there yet. The formats available for flowed ebooks today aren’t that interesting for illustrations, yet.

Fixed ebooks. Shows a hybrid chinese/english version of Art of War (which looks super-cool, can I have a hybrid italian/english version of Dante’s Divine Comedy? I’d pay good money for that.) He isn’t happy with the costs of converting PDFs to fixed layout ebooks.

Next experiment is an ebookstore app that allows people to buy the print PDFs through an app. (Should be interesting, provided the prices are reasonable.) It’s a low cost avenue to getting a big backlist of illustrated books onto the market.

They’re planning on doing the vertical niche thing and approach other publishers in that genre (military history).

Publishing has always been a gamble.

Baldur’s opinion: I think the biggest takeaway here is that Amber Books are both lucky and smart. They take considered risk and don’t bet the house. Neither of their app approaches look as good as Touchpress’s but they do the job, people seem to enjoy them, and they are, by the looks of things, consistently profitable.

Hard to find any flaws with their strategy. Ebookstore, ebooks, all look like sound tactics.

Pioneers or playing it safe?

Chaired by Suzanne Kavanaugh from Skillset. Should be more of a discussion/debate thing than the others.

They plan to explore the conflicting needs of taking risk. Apparently the chair likes disagreement.

Dean Johnson from Brandwidth.

“What Book?” Brandwidth are in the camp of intelligent pioneering. They’re playing with client’s money, so even though they do take risks, they need to be somewhat qualified.

Publishing isn’t all about books. (I seem to be hearing this a lot, both today and on monday.) They want content that has more potential, “access all areas”.

The preexisting market (book readers) have specific expectations about UIs, how things work, what sort of content, etc., while the games market has more flexible expectations.

“Discoverability is key.” Keep hearing that as well.

They have a lot of cross-pollination between the games, music, and book app categories.

“Fun and discovery.” Go beyond boundaries. (Hard to tell what that means, in practice.)

Take outside influences and feed back into publishing. App innovation is about looking at the past, find hidden gems in the back catalogue, present, look at current cutting edge, future, look at devices, future capabilities.

TV is suddenly going to become relevant again, because of discoverability. Your content becomes discoverable within other content. Apps promoted within TV shows and bought through some sort of interactive thingamabob.

What advice would you give publishers whose content are page turners (as in book material, not app material). Answer: You don’t need us.

Baldur’s opinion: I get the feeling that these companies are getting further and further away from text content. Not that it’s a bad thing, just some people might be shocked how different the business might end up being in the future.

Erica Wolf-Murray, Lola Media.

A lot of businesses have intellectual assets that could be used to create content that generates new revenue from new markets.

Uses an example of a company that had a lot of experience involving colour, colour choices, design, decoration and mentions that they could have been able to do something like an obscure TV show I have never heard of.

There is a huge space to develop your apps in other ways. Sounds like she is a particularly inventive licensing agent, really.

She is platform agnostic.

Baldur’s opinion: No real opinion. This is definitely expertise that the publishing industry today is looking for: Adapting diverse and complex assets into revenue.

Naomi Alderman, novelist, journalist, games writer.

She’s presents a game concepts: A phone-based running game. When you run it features audio clips that present the story. Zombie-themed. Looks like a lot of fun for running types. With missions. Very cool.

Big part of the idea is that it is fun to make. Pre-funded with Kickstarter. The pre-funding helped with publicity.

Zombies can obviously be used to sell anything.

Kickstarter enables you to gauge what is a little idea and what is a big idea. You can’t guess that alone behind your desk. Kickstarter gives you extremely qualified feedback, people are voting with their money. So, you can get a feeling for how much potential the idea has before you start your work.

Exciting times.

Transferring plainly your back catalogue without creativity or ideas is more of a risk than not. Involve the writer, tech people, and designers from the start. Get the collaboration started from day one.

Her recommendation for Brits who want to use Kickstarter? Get an American friend.

Baldur’s opinion: Kickstarter, or that model of pre-funding, really is a game changer. Other people have explained it better than I have, but I love love love the idea behind it and the concept. And zombies are always cool. Impossible to dislike the combo of the two.

Questions:

One question is where can we find more authors like her, who engage with the digital arena? Naomi’s answer: If you have authors who are under forty, they are probably up for it. Just ask them. Many of them would love to do it, if the publishers were, well, game.

The inevitable “what do I need publishers for?” question: Naomi’s answer: Some of the major publishing houses are going to go to the wall. When major authors are jumping ship (like JK Rowling) the hit will be too much for some houses. Publishers need to come to their authors with exciting ideas. If you just play the money game, then the authors will leave when the money’s better elsewhere. Also, she says that she doesn’t really get editing from the publishers any more. “Editorial input? Where is it?” (Justifying yourself, as publishers do, by an act they are patently not performing, is a fairly reliable path to self-immolation.)

Dean talks about how publishers have a lot of ‘disconnected assets’ that can be turned into apps and other products. There are opportunities for both publishers and readers when they come together.

“What do you use to create your apps? Do you design them just for Apple?’ Dean says: Built as sensibly as they can, but there are limits. When you want to make the most of a platform, both in terms of features and revenue, you need to do a lot of work specific to that platform that isn’t transferable to others. But you try your hardest to work sensibly.

Naomi: Make friends with developers who know what they’re talking about.

Inventing the future

Adam Gordon, Future Savvy, chairs. He went into great detail explaining that he is a futurist and what that involves. I used the chance to rest my fingers.

Dave Addey, Agant.

Did “Malcolm Tucker: The Missing Phone”. (I really like this idea. Have to get this app.)

First app nominated for a TV Bafta.

If you haven’t seen The Thick of It, then you have missed out!

Faber & Faber published a book that is “Malcolm Tucker: The missing dossier.” Agant was approached to adapt, and they had the idea of doing it as a missing phone, instead of the missing dossier, with phone specific stuff. It’s Tucker’s iPhone, with voicemail, twitter, voice notes, who has been calling. The twist is that there is one new voicemail on the phone: A message to Ollie. Sooner or later you start getting e-mails, messages on the phone. The story plays out in real time. Personal calls. Then you begin getting messages form Malcolm himself.

Has a 17+ age rating due to the swearing. App cost 4 pounds, people were more than willing to pay. Paraphrased quote: “This is the kind of app that makes getting an Iphone worth it.”

It was done with the writers and Armando Ianucci and the publishing company, but no involvement from the BBC. The creative people, actors, etc. got very much behind it. Faber also get credit for taking a risk on this.

People bought both the app and the book, cross-promotion, not cannibalisation.

What next?

Something less sweary (limits promotion): The story of Apollo 11, based on the same story engine. They’ll be writing about the experience of creating it at apollo11app.com and @apollo11app.

Q: What made them choose the price? Dave: There is a slightly arbitrary threshold for apps, so they had to match the environment. They knew though, roughly how big the potential audience was (based on iPhone ownership and TV viewing figures) and that they are borderline fanatics, hence the slightly high, for an app, launch price (it’s lower now).

Baldur’s opinion: Fuck it. Just go and buy this app. Throw money at them. Brilliant. Absolutely brilliant.

Chris Book, Bardowl.

“Audiobooks Reinvented.” Calls himself a technologist. Knows nothing about publishing. Massive audiobook fan.

There was really only one retailer in the audiobook market, so he saw an opportunity to solve a lot of the problems with the established model.

Delivering the entire book is both a business and technical problem. The reader has to commit their money beforehand, without actually knowing too much about whether the audiobook is any good, beyond a small preview.

Their technical solution (Bardowl’s, that is) is also a business solution: Streaming audiobooks on a subscription basis. Subscription revenue is allocated based on minutes listened, per title. More like radio revenue than audiobook revenue.

Shows some smartphone adoption stats. (Short version: lots of ‘em).

Mentions that social music has boomed and the ‘second screen’ blablabla. (Not wrong, just heard it a lot this week.)

Technically it caches the stream so that there aren’t too many disruption as you commute, wander off into the wilderness. Also, the obligatory sharing thingamabobs.

Audio is an underused asset, in his opinion. (Sounds right to me.) 50/50 revenue share.

The futurist chair asks a question about social media feedback. Answer: You can measure consumption accurately (where people stop or start listening). The quotes can tell you what parts strike an emotional chord.

Baldur’s opinion: Seems like a good idea that promotes sampling of audiobooks. Could be complementary to the “buy the whole thing” model. Nobody ever mentions any numbers or estimates of what value these lightweight social features add to the platform. Not necessarily saying they’re bad, just would like to see harder, more empirical, justifications. Seems like a neat company for those who like audiobooks.

Matt Marsh, Firsthand Experience.

“How do you go about designing for these new reading experiences?” About a collaboration with PlasticLogic, a UK-based eink company that makes flexible eink screens. (Or, at least develops them. Aren’t they perpetually on the way?)

This is a story from 2006, PlasticLogic didn’t want anybody talking about this sooner.

In 2006, the iPod was the hottest thing around. They wanted to be the iPod of text. (Must have got punched thoroughly in the gut by the Kindle, iPhone, iPad combo, huh?)

They had to start by estimating what all of the requirements were. What would drive adoption, content, behaviour, locations, etc. Do few things well, rather than lots half-arsed.

They wanted a device that was perfect for the moments it was good for. Did a series of interviews with early adopter type people. (First mistake there, IMO.) Tried to use ethnographic research to investigate leisure reading. (A standard tactic used at pre-self-destruction Nokia, actually. Which just about tells you how well it works.)

Easy to design for yourself. Designing for lots of people is tricky. (That’s why so many fail.)

Findings: Create a set of live sketches of people, what made them tick in terms of reading.

“Reading reality.” People do an awful lot of interrupted reading and have four or five different kinds of reading matter on the go at the same time.

The client (that’d be PlasticLogic) was thinking about the iPod approach of having the entire library available on the device all the time. Research told them that making sure the device was with you at the right time mattered more, being able to catch moments of reading.

Then the obvious digital features, annotations, samples, etc.

When people were reading for longer, people chose different sorts of content.

People had an incredible aversion to being locked into a single distributor. They don’t want to be owned by a single company. (Kindle’s neatly disproving that, at the moment.)

The luddite skew has obviously changed in the intervening five years.

The conclusion: Unapologetic (proudly digital), undemanding (just about the text), flexible, simple, robust.

Baldur’s opinion: I’m not sure how far you can get in designing a device using this methodology. But, then again, what do I know? The observations are sound. One of the key selling points of reading on mobile phones is interrupted reading, catching moments throughout the day. OTOH, you could argue that most of their conclusions have been disproven in the intervening years.

How to innovate

Chaired by Paul Squires. Founder / Managing Director, Perera.

Tom Abba, Lecturer, University of the West of England.

Everybody’s already said what he wanted to say, saves him time. We’re talking about the book and it has been unpacked in a variety of ways today.

The relationship between form and content: Make beautiful things. (Not a bad principle in general.)

I’ll need to link some of Tom’s blog posts about his project here. He describes it better than I ever could. But in short, it was a mixture of physical objects and atomised, video clips, audio, and distributed atomised text. It began with a physical object and attempted to draw you into the digital fragments through mystery.

He wanted to make websites that don’t look like websites and to force people to download the story fragments rather than read/watch them on the web.

Make things that are ever so slightly mysterious, don’t explain everything.

Baldur’s opinion: My only real feedback, and I’ve told Tom this, is that his project was too cryptic. You din’t know what you were getting into which led some who should have been interested to avoid it, and some who shouldn’t have looked at it to become very frustrated.

David Burton, Head of Innovation, RedWeb.

“How to create an environment for rapid innovation.” Trying to do something a bit more exciting. Got awards by changing their processes and values. One of the projects was Hackproject: Where people get together and build cool stuff in 32 hours. No extensions. Very active, no chance for research. Always ends with deliverables, have to deliver a fairly polished prototype.

“We’re going to make something that hasn’t been done and might not be possible.” Some get excited. Some not.

Why hack projects? OK to fail, low cost, everybody is in the same circumstance. Good way to explore. Chance to show off your capabilities. It gets stuff built.

First you create the environment, set apart the time, and you start with a problem to be solved.

Early part of the hack day is about ideas, what, not how.

Then they visualise and share (sketches, layouts, etc.).

Some of the projects are just fun and funny, some are practical. But the fun trumps the practical. Random House is going to use one of the ideas developed in a hack day.

Baldur’s opinion: One of the keys, it sounds like, to hack days is creating an environment where it’s okay to do stupid things and fail. It’s effectiveness probably depends on what the culture in the company is like. Some won’t, well, hack it.

Mike Phillips, Director of i-DAT, Plymouth University.

Makes the point that software is the thing that is actually driving everything, the hardware serves the software.

Tools, concept and context of media and publishing has been changed by digital. The problem is the concept has been juddering on with little changes.

(He misinterprets a toilet diagramme he puts up as there are quite a few squatting toilets in use in Japan, for example. It’s not that these people are unfamiliar with toilets, they are used to a different design.)

I’ve lost track of where he’s going with this. It feels like he’s skipping over tech history like a flat rock over water.

One of the project they’ve been working on is with architects, a tweeting building among other things.

Another is tweeting pods that hang from trees. Another a monitoring doohickey that connects to a phone and broadcasts your bodily stats.

You put two things that don’t work together and something new appears.

Things go wrong on a regular basis and things need to be reinterpreted and adapted. That’s why he thinks we need academia.

Baldur’s opinion: Sorry, faded out a bit during this one. It seemed a bit disjointed, but that may well have been my concentration failing.

Question: Can each of the panelist give us one principle for innovation?

Tom: Design for yourself first, worry about your audience later.

Mike: Being comfortable with uncertainty. (He didn’t put it that clearly, he waffled.)

David: Start with an idea. Work with a personal problem.

Questioner’s own answer: Build for quality, where quality is fit for purpose.

Question: What will happen to the climate for innovation over the next few months?

Tom: We talk ourselves into austerity (a mindset thing) and once the 2012 Olympics are over, a gap will open up for a lot of things. Smaller, nimbler might be in a better position than larger institutions.

Mike: Austerity is going to break a lot of monoliths and universities will have to begin to talk to people outside of academia and the civil sector. Financial limitations can promote creativity.

David: DIY culture is feeding innovation faster and faster.

That’s it. The end!

What a publisher does

2011-11-29T16:00:00-08:00

After reading the discussion on Google+ on Edan Lepucki’s post on why not to self-publish (read it, it’s pretty good, not as one-sided as you’d think) I began yesterday to think again about the changing role of the publisher.

What follows is a stream-of-consciousness list of tasks a publisher should be able to tackle. It requires a pretty wide-ranging set of skills.

Off the top of my head, so apologies if I miss any obvious ones or if some of these make limited sense:

Make sure that typos are tolerably few and far between.
No formatting errors. The markup should be clean.
No missing text.
Positioning. What worldview will the book inhabit? This informs all design, typesetting, copywriting, website, sales, marketing, and PR decisions later on.
Design. Of the cover. Thematic design. Consistency over all of the author’s books. What kind of consistency? Exterior design that ties in with marketing and positioning.
Typesetting and interior design. More and more important with the rollout of KF8 and epub3. Has to be consistent with exterior design and complement it.
Writing copy. Back cover. Descriptions. Bio. It’s a different skill from other kinds of writing.
Website development and design. Again, keeping consistent with interior and exterior design. All done with the commercial impact of the website in mind.
Support. Be ready to update the ebook, website, whatever.
Maintain relationships with review sites. Know which ones to approach for each book and how to approach them.
Be a part of the reader communities that might be interested in your books. Don’t be a shill. Take a sincere interest in the subjects your readers are interested in.
Follow all mentions and chatter about your books, your writers, your genre. Promote the positive and decide if the negative needs to be responded to. It’s usually best to ignore them.
Maintain relationships with the various outlets, retailers, distributors, book clubs, etc. Be prepared for when something goes wrong. Know what format or tactic is appropriate for which outlet.
Value and positioning. What formats? Hardcover? Paperback? Collector’s editions? What outlets? What sort of customer?
Do the stats and analytics: What is the ARPU (Annual Revenue Per User)?
Do the stats and analytics: What is the CAC (Customer Acquisition Cost)?
More stats: What’s the website conversion rate? Absolute Unique Visitors?
Maintain an e-mail list of some sorts. Understand how best to use it.
What’s the mailing list conversion rate?
What’s the mailing list’s ARPU?
What’s the reader attrition rate? How many of those who buy the author’s first book buy the second?
Maintain relationships with review sites. Know which ones to approach for each book and how to approach them.
Follow all mentions and chatter about your books, your writers, your genre.
Give authors guidance and advice on how to avoid the major PR gaffs.
Have a response plan ready for when they inevitably invent new gaffs to make.
Have a response plan for all major gaffs, those committed by your people, your partners, or your authors.
Devise a set of principles for how partners, authors, and customers should be treated, how you and your staff should behave when representing the publisher, and put together a plan for how to fix it when it turns out those principles are being broken.
Maintain relationships with journalists, reporters, media outlets. Help them as much as they help you. Try and make sure that whenever you contact them, you are making their lives easier, not more difficult.

Note that I didn’t mention editorial processes, book acquisition, or author advances at all. This is the baseline for all publishers, including those who do nothing but reissues, or those who, legitimately in my view, maintain that the quality of the text is a matter of the author-reader relationship, and the publisher’s role is that of a gatekeeper, not developer of the text.

The clearest value a publisher has to an author is when they offer design, sales, marketing, and public relations expertise that can take years to develop. A publisher with a strong skill set in those areas, and stable relationships to build on, should never have to worry about the ebook transition.

The burgeoning self-publishing infrastructure will benefit publishers as well. A mature market for editorial services, design services, etc., is just as useful to publishers just as it is to self-publishers.

Design pseudoscience

2011-11-07T16:00:00-08:00

Designers use rounded corners so much today that they’re more of an industry standard than a design trend. They’re not only found on software user interfaces, but hardware product designs as well. So what is it about rounded corners that make them so popular? Indeed they look appealing, but there’s more to it than that.

From Why Rounded Corners are Easier on the Eyes

On the surface level, this is a well-researched design article, full of examples and references to research that supports its statements.

It is also complete nonsense.

Now, it isn’t unstructured nonsense, the sort of gobbledegook you find in the notebooks of the severely schizophrenic and the columns of daily newspapers, but internally coherent structured nonsense where the writer is building up to the point he wants to make, facts be damned.

Note: Other people’s writing aren’t facts. They’re just shit other people write.

So, what, specifically, is wrong with it?

None of the references prove the writer’s point. One is a nonsense PDF from a neuromarketing firm (an evil industry responsible for a large portion of the bullshit pseudoscience news organisations today call science coverage). Two are thought exercises full of speculation with no data, testing, or research to back them and have a whole lot of words like ‘cognitive’ thrown in for that fancy science-y feeling. One is a diagram style guide with no references to support its mandates. One is a piece of research into a particular facet of how our eyes work with no conclusions or statements on the validity of rounded corners in design.1

The reasons why we like rounded corners probably have nothing to do with rounded corners.

We don’t like designs that have rounded corners because they have rounded corners. We like rounded corners because they are in designs we like. Get this wrong and you’re making the mistake of claiming that it rains because the streets are wet.

When fantastic modernist designs with square corners are popular, we like square corners. When Jonathan Ive puts rounded corners on shit, we like rounded corners.

Don’t resort to pseudoscience to validate your preferences in fashion trends.

Generalising from research abstracts is dangerous and dumb. Even minor changes in context can completely transform the conclusions of almost any study published and most of us aren’t competent to judge which changes are important and which aren’t. ↩

A tale of three blog posts

2011-10-27T16:00:00-07:00

A week ago, a blogger named Guido Henkel posted a blog post about Amazon’s new and upcoming Kindle Format 8. He pointed out what he thought were serious shortcomings in the format, namely that it had no realistic mechanism for backwards compatibility for those devices that would not support KF8

“Amazon introduces new Kindle eBook format and makes a major misstep.”

That Saturday, a day later, after seething in annoyance since reading Guido’s blog post, I posted a response on G+. Guido is wrong. KF8 has several mechanisms for backwards compatibility, all of them standard practice in web design. I then railed against ebook designers in general, including slamming them all as useless. (Post follows in its entirety.)

“It’s called web design.”

It’s called web design

This post has been making the rounds on the net and on Twitter. It neatly outlines the absolute worst case scenario in terms of Kindle Format 8’s backwards compatibility:

http://guidohenkel.com/2011/10/amazon-introduces-new-indle-ebook-format-and-makes-a-major-misstep/

It is also, quite wrong.

First of all, a quibble. Ragging against Amazon when they’ve announced that they’re bringing support for the new format to over half a dozen different platforms (“latest generation Kindle e-ink devices as well as our free Kindle reading apps” equals the new Kindles, Kindle Fire/Android, iOS, Mac, Windows, and possibly Blackberry) doesn’t give them enough credit for effort.

But the heart of the complaint is that the format won’t be backwards compatible with the older Kindles which won’t support KF8, that only a super-intelligent AI could dynamically generate a compatible MOBI file from an arbitrary KF8 file.

He uses the following example:

“Let me illustrate this with a very simple example. Say, you have an image and you add the float property to it, to have it embedded in your text with the words flowing nicely around it.”

“When converting such a file, all KindleGen can really do is ignore the float property — which, coincidentally, all the devices do already. As result, on a Kindle 2 you will now have the image sitting on the left side of the screen with nothing surrounding it. Perhaps the first line of the text that was supposed to float around it will sit firmly at the bottom, creating a huge, ugly gap. Surely not what you had in mind.”

“If you had properly formatted a version for MOBI devices, instead, you would perhaps have centered the image in this case and spaced it out a little more. That is where KindleGen’s auto-conversion will fail you miserably, because it cannot make decisions like that for you. Things will, undoubtedly get even nastier when your formatting is more complex than this one very basic example, and I would not be surprised if certain elements would even disappear entirely.”

If only there were a profession that specialised in using CSS to target designs for a variety of platform with a variety of capabilities…

Oh, wait… There is. It’s fucking web design.

Look at the added feature list for KF8.

Two things to note: KF8 supports more selectors than MOBI does and it supports @media styles. It doesn’t offer full support, so we can’t target styles based on resolution, orientation or such, but it does load all styles targeted at “All” or “Screen”. MOBI files should ignore both selectors and all @media styles, including those supported by KF8. And if they don’t, my bet is that Kindlegen 2 will transparently strip them from the part of the file that is intended for older MOBI-supporting devices.

This suggests a simple solution to Guido’s backwards compatibility problem. Namely, put all of the KF8 specific styles in an @media style targeting “All”.

Guido’s post also assumes that Amazon isn’t going to use any of the multitudes of fallback mechanisms that web standards offer. Their inclusion of the “source” tag and @media styles, for example, indicate otherwise.

Now, usually I’m all in favour of scepticism and needless doom and gloom, the majority of my output on the internet’s various social networks (Twitter, Tumblr, G+) is proof of that, but this post is not only needlessly negative, it also smacks of a complete fucking ignorance of standard web design and development practices.

And if your fucking ebook designers don’t fucking know web design then they’re fucking useless.

Now, Saturday posts hardly ever get any attention, so I wasn’t really surprised that I only got a few responses to it, but the coming Monday I got a small firestorm of responses, none of them even seemed to notice my central point. All of them railed against my slam of ebook designers.

I did the only decent thing, acknowledged that I had been wrong and apologised, although that wasn’t enough for some people.

But I couldn’t let go of the fact that hardly anybody even acknowledged my point: KF8, and epub3, are web formats which require web development skills. The problem posed by Guido was insurmountable without web dev skills, and easy with them.

So, I sat down and wrote a detailed, even-handed, well constructed and argued blog post that explained that point exactly and in a way that I think was accessible even to those who don’t know anything about web development.

“CSS and ebook design.”

What interests me now is the attention these three blog posts received.

The detailed, fair, and balanced post hardly got any response, didn’t start any discussions, and seemed to just disappear within minutes of being posted.

The angry, rude and insulting blog post had a lifespan that lasted for several days and prompted quite a few discussions. Sure, most of those discussions were just angry people shouting at me, or people taking completely the wrong point, with almost nobody actually responding to the post’s message, but at least you knew people had read it.

The ignorant blog post full of misinformation and falsehoods, on the other hand, just keeps on building an audience, getting links form high profile blogs, cropping up on Twitter on a regular basis, all without any sort of criticism or pushback.

I guess this means that rude and nasty trumps reason, and ignorant trumps everything else. I’m kind of curious as to what people think I should have done. Guido’s original blog post is wrong. It’s reasonable to assume that a correction and an explanation would come from the community (and the correction couldn’t come without an explanation of the whys and hows). Was the reasoned blog post too long? Was the angry blog post too much of a turn off for ebook designers? Why are people who should know better still posting and tweeting links to Guido’s original?

I don’t know.

CSS and ebook design

2011-10-23T16:00:00-07:00

As often happens, a post I wrote on a Saturday, to no response, suddenly took on a life of its own on Monday.

In this case I vented my spleen in response to what was a fairly ill-informed post on a major mistake Amazon is supposedly making with its new Kindle Format 8 (KF8 for short).

The problem being that the problems as outlined are problems only if you don’t understand the technologies underlying both KF8 and Epub31, namely, HTML5 and CSS3.

Now, in my usual fashion, I went way over the top in both language and tone. Calling all ebook designers who don’t know web development useless was offensive and for that I apologise without reservation. I also swore too much.

However…

Any ebook designer who doesn’t know web development, CSS specifically, will severely compromise their job security unless they do bone up on those skills before KF8 and epub3 gain traction in the marketplace. Not heeding that warning because of the tone of the message is foolish.

Let me start again from the beginning.

I made my first website (now blessedly disappeared into the ether) when Netscape Navigator 2.0 was only a few months from being released2. Anybody who knows how the next ten years went would know that the web browser landscape was dominated by a series of often wildly incompatible browsers, some of the more horrible of which simply refused to die. I still get a shiver at the thought of the work we had to put into supporting Netscape 4.0 the mere mention of Internet Explorer 6 to a web developer will prompt loud swearing, hissing, spitting, followed by a series of uncontrollable sobs.

CSS was developed in this landscape and over time has gained features specifically to tackle the issue of delivering designs to a variety of largely incompatible browsers that support wildly diverging features.

The way we dealt with Netscape 4, for example, was to use @import stylesheets, a feature all newer browsers supported, but Netscape 4 didn’t. Child syntax selectors (elem > elem) don’t work in Internet Explorer 5, 6, and 7 but can safely be used in other browers. Some of these solutions were unreliable hacks. Some of them are still legitimate ways of delivering CSS to specific browsers (like CSS conditional comments in Internet Explorer). But, generally speaking, newer browsers support a host of selectors that older browsers do not. Under the right circumstances a well chosen selector can be a reliable way of having your design degrade gracefully for those users who hate their computers and still insist on using insecure and buggy browsers that are a malware writer’s wet dream (people seriously endanger their computers by not updating, although that’s another post entirely).

CSS then standardised on a method for delivering stylesheet rules depending on things like screen resolution, screen DPI, device type, device orientation, browser mode, and more: The @media rule.

It works really well. It’s supported by all modern browsers, including the latest versions of Internet Explorer (both desktop and mobile). It solves a lot of problems that used to be very difficult or almost impossible.

Which brings me back to the post I was responding to. The original poster presented what he thought was an intractable problem. The older Kindle devices don’t support the CSS properties, selectors, and rules that KF8 offers and often need starkly different designs from what are appropriate for a KF8-supporting device. He didn’t see how an ebook developer could solve that problem and declared that Amazon had made a major mistake. Meanwhile, KF8 supports @media rules for “All” and “Screen”.

I hope you see why, in this specific instance, an ebook developer who doesn’t know web development is indeed fucking useless. He can’t solve a problem that is Web Design 101. He doesn’t see that Amazon is offering him a variety of capabilities and tools specifically designed to solve his problem and solve it with an elegance and grace that is rare in the tech world. Without web development skills, the ebook designer in this situation only has the option of remaining with the limited Mobi format or to abandon older Kindle devices.

Ebooks are facing explosive growth. They are being read on a multitude of divergent devices. Reading systems are being updated to support HTML5 and CSS3. There is no way to tackle an ecosystem this diverse, with all of the problems this variety presents, without using the tools offered by CSS. You can’t just learn CSS just as it relates to ebooks. KF8 and epub3 ebooks support the full CSS stack and are facing all the same problems CSS solves for web sites. Learning CSS in this context is learning web development. You can’t avoid properly and fully learning CSS. You simply can’t.

And to use those tools you absolutely have to understand CSS. You have to understand @media rules. You have to understand how the cascade works. You have to know how to solve specificity bugs. You should understand why using #id selectors in any other way than as a singleton increases the chance of intractable specificity problems.3 You should understand how pseudo class selectors affect specificity.4

If you don’t understand these (and many other) concepts you are going to run into problems you cannot solve.

A way of getting around this, often thrown at my head when I debate this, is for a designer to collaborate with a ‘coder’ – a term I that is sweeping, vague, inexact and dismissive.

I’ve done this myself in web development. I recently, for example, collaborated with the extremely skilled Kári Emil Helgason. It was both fun and rewarding and the reason why it worked as well as it did was that he knows CSS and understands web development.

Now, that isn’t to say that this wasn’t a true collaboration. As I implemented the design, I solved several problems he couldn’t have tackled without spending much more time and effort than I did. I implemented a Wordpress template in a fraction of the time it would have taken him at the time. He came up with really nice designs I couldn’t have (and I mean really nice). I implemented things much quicker than he could have, and solved problems that probably would have stumped him.

But the heart of the collaboration was in tackling both the intractable issues that arose (both technical and non-technical issues) and had to be worked around, and the feedback we got from those responsible for a lot of the content of the site and were responsible for supporting it. We exchanged ideas for solutions and tweaks, all bearing in mind what is and what isn’t possible in the browsers we were targeting. This wouldn’t have worked if he didn’t understand the cascade, how colour works in CSS, or the theories behind how CSS works.

The problem with presenting the designer/coder collaboration as a way of avoiding having to learn CSS is that in the real world HTML and CSS is the lingua franca of any such collaboration. The CSS coder is not going to know book design lingo, which doesn’t anyway reflect the concepts and models and issues of coding CSS. Even if the designers don’t have the confidence to write the code they need to understand it conceptually and once they do that they know CSS, they’re just a bit slower at it than someone more experienced.

Not learning CSS because it might get replaced is misguided because the only thing that’s going to replace CSS3 is CSS4. It’s been around for over 14 years and will easily be around for several more.

With KF8 and epub3, the web stack is the ebook stack. It has all of the same features. It suffers from all of the same problems. I don’t see any way out of fully dedicating yourself to understand HTML and CSS if you are intent on a longterm career in ebook development.

It’s not all bad, though. It looks like you can freely avoid javascript.

How is Epub3 supposed to be capitalised? Epub3? ePub3? EPUB3? Dunno. ↩
I actually never downloaded version 2, going straight to 2.5, , if I recall correctly, and then to 3. ↩
That is, only use the #id selector alone. As soon as you start nesting it (‘elem #id’ or ‘#id elem’ or ‘#id:class’) you are treating it as a class selector, lose all of its speed advantages (the rightmost selector is always the speed bottleneck), and are going to run into odd problems where you are trying to change the colour of an element but it’s not working because the rendering engine has seemingly arbitrarily decided that an earlier rule has more specificity. ↩
If you don’t, then you’re likely to eventually run into a problem somewhere setting the colours of your links. ↩

The loss of ambient intimacy

2011-09-14T16:00:00-07:00

Ten thoughts on the problem with Twitter and why my life improved by escaping planet Twitter.

Two months ago, I decided to concentrate on finishing one of my projects and one of the things I sacrificed in the name of productivity and time was Twitter. Strangely enough, but also unsurprising, my productivity didn’t change in any measurable way. (Turns out other things like regular sleep is more important than a mild addiction to a social service, whodathunkit?) What did change was stress and anxiety and fun. Less of the first two and more of the third.

Google Plus started shortly after I quit Twitter, but it hasn’t even come close to replacing Twitter in any way, having fewer people than an Icelandic business ethics committee; that service is a non-factor in all of this and suffers from its own issues. I’m not arguing that Google Plus is superior to Twitter, there isn’t enough there there to argue anything about Google Plus either way. It’s a ghost town that needs more people before we can come to any conclusion about it.

Thinking about this inspired me to revisit some of my notes I wrote on Twitter’s flaws. I tweeted most of them in the early days of Twitter, but all of those are now lost somewhere in Twitter’s inaccessible archives (if they even exist anymore).

(Aside: If you can’t tell the difference between becoming more productive because you stopped using twitter and deciding to be more productive and sacrificing Twitter to that end, then you deserve all of the crap self-help books that litter your desk. One is ‘it rains because the streets are wet’, the other is ‘the streets are wet because it rained’.)

Besides, if I want to, I can have much more fun procrastinating by watching Count Duckula or Danger Mouse episodes, or even better, alternating Danger Man (huge Patrick McGoohan fan, me) and Danger Mouse, than by tweeting. The fifty minute Danger Man episodes are, by the way, much better than the twenty-five minute ones. Skip the first season if you’re interested in watching Danger Man and go straight to the meaty long episodes.

There’s a lot I could cut down on in the name of productivity, but, in truth, productivity is more about not wasting time on crap and nonsense than it is about reclaiming time spent on entertaining frivolities. Twitter, on the other hand, has long since stopped being just an entertaining frivolity and, for regular users, becomes a substantial feature of their lives.

That also means it is a substantial time drain.

I wouldn’t have decided to cut Twitter out of my life were it not for one fact: It had stopped being fun. Discussions on Twitter wasn’t fun anymore. Venting your thoughts in a short series of tweets wasn’t fun. Posting links resulted in tweets in vehement and violent agreement and disagreement in equal measure and any interaction threatened to blow up into a tweet brouhaha. Twitter had stopped being fun.

Anybody who complains about a lack of civility and social niceties on the internet can count on being mocked, laughed at, and ridiculed. Pleas for a civil web are usually met with reactions where the participants argue that such things are the inevitable price we pay for the freedom, convenience and speed of online communications, all delivered in a tone and with a demeanour lends undue credence to their case.

The web is a rude, crude, and emotionally violent place. It’s a landscape of embarrassing openness, irrational hostility, ritual humiliation, unprovoked mockery and more than a little bit of grade-A, radioactive, highly toxic stupidity. Shit like that happens sometimes.

The problem lies in the idea, often hinted at, seldom clearly stated, that you can’t make nice places on the net. At least, not for long. It’s easy to fall into this trap. Those of us who have been online since the nineties have seen pleasant websites abandoned, nice communities devolve into name-calling, and online groups implode in spectacular flamewars.

The problem is that we have also seen sites like Metafilter.

They might not outnumber the glorious fuckups, but the web has more than a few nice corners for us to visit, it’s what makes us return to it, again and again. What is really interesting, though, are the cases where you can find the same people, on two different sites, but one is clearly a more pleasant, constructive, and informative experience than the other.

For example, compare Facebook and Twitter.

One of the reasons why cutting Twitter was an easy decision is that, for me, at least, Twitter has never been a particularly pleasant experience. It is addictive, it gives you an insight into the life’s and interests of a community of people you select, it enables you to easily engage with people beyond that selected group, it could even be a lot of fun, but it was never pleasant. Discussions escalate too quickly into hot-headed arguments, forced brevity too often eradicates the verbose fluff of civility that lubricates social interactions, all opinions become stark because qualifiers are excised for their character count, and all the while that same brevity decreases emotional distance.

Emotional proximity – the very same ambient intimacy that drew us to Twitter – combined with an enforced lack of verbose social niceties makes for a society of acquaintances that are constantly on the verge of hostility.

This is easy to deal with when times are good, stress levels are low, and people don’t have any worries, but now that we are all surrounded by anxiety and distress – even if our own situations are fine – a level of tension builds up that is hard to vent safely.

The very same openness about the casual details of life that is the foundation of ambient intimacy builds tension and anxiety in times of stress. A problem shared is only a problem halved if you have the space and time to couch your language in the words of politeness and respect that otherwise carry no information.

Twitter compromises our capability to express our feelings and takes away the cues we rely on to judge the feelings of fellow members of our community.

In short:

Twitter makes us autistic.

Twitter also exaggerates another problem that is inherent in most of the web’s social software. Communities on the web self-select around mutual agreement. Conservatives socialise only with conservatives, liberals with liberals, Apple fans with Apple fans, geeks with geeks, programmers with programmers, photographers with photographers, and, in many cases, outside opinions are met with hostility.

Twitter exacerbates this problem in many ways:

It increases the intimacy of those in the community.
Length limitations eradicate the nuances in both the attempts of outsiders to engage with those in the community, and in the responses of those members, leading to outright hostility.
It makes it much, much, easier for an outsider to throw a short, casual, remark at someone in a community like that.

One symptom that results is that often when you tweet your opinion of something (a short phrase with a tweet, for example) you’re immediately drawn into a confrontation with members and representatives of multiple and incompatible world-views without the space, means, or tools to adequately express the details and complexity of your opinion with the respect and civility such an exchange requires. The end result is that, over time, you are trained by the various communities on twitter not to tweet at all.

Most of these problems are the direct result of the 140 character limit on tweets, an archaic technical limitation that doesn’t even exist for text messages (phones have, for over a decade, transparently worked around the 140 character limit). One solution is simple: Raise the limit. Even just matching Facebook’s 420 character limit would go a long way towards enabling people to use more natural language in their conversations and interactions on twitter.

The usual counter-argument is that brevity is a feature of Twitter and, obviously, if you aren’t convinced that human interaction sometimes requires verbosity, then there is very little that can be done to convince you that the character limit needs to be raised.

Except that you probably wouldn’t notice much of a difference and that a balance can be struck:

Brevity can be promoted, even if it isn’t enforced. Make the status update character count go bright red once it goes over 140 characters, and make the user click the ‘tweet’ button twice to confirm the action if the character count is over 280, much in the same way as the iOS App Store purchase button works.

-176 Post this anyway

Give people the ability to post longer tweets when necessary and promote brevity through UI design.

Another feature that makes the character limit such a problematic issue is that all of Twitter’s social features require text to be embedded within the tweet itself: Usernames and tags both can easily consume a disproportionate amount of your character quota.

This design has a devastating effect on group discussions, exactly the place where subtlety and civility is the most essential. The more people participate in the discussion, the less meaningful and civil the tweets become, purely because of the necessity of including the usernames of all involved. Add a hashtag in there as well and discussions become content-free confrontations.

The way Twitter has integrated its url shortener into its service points to a way they could solve this problem completely: Usernames and hashtags that are at the front or back of a tweet shouldn’t count towards the character count and simply become a part of the tweet’s metadata.

This solution shouldn’t prove controversial, even with the fans of the mythical benefits of twitter’s enforced brevity.

One of their primary failings is Twitter’s utter lack of anything even resembling permanence.

It can be argued that the lack of archives and the inability to explore past tweets just a the way the service works, the ephemeral nature of each individual tweet would be undermined if Twitter fixed its archival problems.

Discussions are a different beast. The work that goes into discussions and the number of people involved means that there is a strong need to preserve them. They are also the one thing on Twitter that is likely to appeal to outside participants, who often refer to them and continue the discussions in other forums such as weblogs. Twitter users often resort to third party solutions to collect discussions for this purpose, but this is feature that should be provided by Twitter itself: Permalinks for discussions.

There are other problems with Twitter’s discussion views, and many ways it can be improved, but that’s well beyond the scope of this blog post.

Lists are what you’d call in Icelandic stílbrot—a sudden break in style. They are very unlike any other feature of Twitter. Discussions, replies, hashtags, were all developed organically and operate by adding metadata to individual tweets. Most of Twitter’s features are implemented with the addition of metadata. It would seem more logical and consistent of Twitter to have added metadata to your contact list: Allow the user to organically tag the people they follow and let them dynamically filter their timeline based on the tags.

Lists don’t solve the problem of filtering your timeline and increasing the signal to noise ratio. Separating them out from the regular timeline makes it much easier to add even more people to the list and overload it to such an extent as to completely counteract whatever benefits it might have otherwise had to the signal to noise ratio.

Twitter lists operate more like chatrooms than filter mechanisms. Their conversational and social dynamic is different from that of the rest of twitter.

Twitter isn’t a place where you post your thoughts and actions. It doesn’t take more than five minute inspection of the tweets and stream of most active Twitter users to see what it’s really about, what consumes their days, fills their lives, what it is that they really care about—their passion and joy.

Twitter is about consumption, the food you eat, the crap you drink, the things you buy, the sites you scan, the books you read, and the TV you watch.

Twitter is where you advertise your consumption and your opinions on what others consume. Opinion and debate on Twitter doesn’t exist as such, it all hinges around consumption on some level. You don’t debate an issue, you argue about what somebody said in a blog post. You don’t talk about feminism or equality, you tweet about how stupid somebody on the radio is. Twitter is a system for codifying mindless reactionary posturing and displaying it on an online billboard so that everybody can see what sort of person you’d like to be thought to be.

Every tweet is about who you think you are, what you like, what you dislike, what you stand for and against, and none of them are about your fears, your doubts, the anxiety, desperation, and feeling of free fall that comes with any act of creating. Twitter is an identity production and consumption system.

This is why the owners of Twitter will become rich. Twitter is about laying your identity as a consumer bare, opening the wallet at the heart of your soul, placing yourself in the constellation of brands. This is why they will be wealthy. Twitter is desire, mimetic desire, the longing of the savage pack animal who wants to fit in, it is the voice of those who play the game of life by the rulebook. This is why they will succeed. Twitter isn’t advertising, it’s what happens when advertising is internalised.

This is why they will become rich and you will remain poor.

Twitter, Facebook, Myspace, Friendster, Blogger, Wordpress, Tumblr, Linkedin… They all have value because they have people, and one of the core tenets, the one article of faith that underlies all of the financing of these companies, is that the more people these sites have, the more value the network will have. This idea is variously labelled as Reed’s law or Metcalfe’s law, depending on how important you want to make your crap sound.

Both of the ideas, when presented by entrepreneurs and venture capitalists are about value in holistic terms: the value of the network in its entirety. Which is reasonable, since they’re greedy selfish arseholes with no ambition in life except to get rich, fuck off and leave the ruins of the world to us proles.

However, both ideas, as useful as they are to hipster geeks who want to become rich, fail to address the idea of what creates value to individuals.

It doesn’t matter how many people a network has if its very design makes civil discourse difficult.

It doesn’t matter how many experts a network has if they never talk, exchange ideas, or collaborate.

It doesn’t matter how many writers a network has if they’re forced to use a crippling subset of the riches the written language provides.

It doesn’t matter how big a network is if everybody’s behaving like a fucking arsehole.

A network whose ties are strengthened when the crowd has blood on its teeth and skin under its nails, whose fabric is reinforced when an outsider, or an unlucky stranger is ritually mocked, humiliated and taken apart, is not a network whose value increases with size. It is a savage horde. Every time one of us mocks someone we disagree with on one of these sites, every time we insult strangers because we know it’ll strengthen our bonds with those ‘like us’, every time we set upon the stupid and ignorant like a pack of dogs, the illusion of the knowing man falls further and further away.

Disagree, argue, complain, if you have a point to make, but when you throw a gripe to the crowd as if you were throwing a bone to the dogs, you are using your legitimate issues to feed the community bond at the expense of the fabric of civilisation.

We know social websites can be kept constructive, uplifting, and civil through both technical design and careful maintenance.

But most of them are designed solely to feed the savage and monstrous heart of the packaged and branded consumer.

Will I return to Twitter?

I don’t know.

Because Twitter is a near-perfect Skinner Box, simply avoiding it is going to be easier than just tempering my use.

I wonder if operant conditioning causes the same sort of anxiety in lab rats as it does in young hipsters who don’t understand the nature of self-control.

Quick tip: Self-control isn’t a muscle, it’s a finite resource that runs out if you try it too much, relies heavily on glucose and blood-sugar levels, fails if you’re tired, and disappears if you’re drunk (avoidance is the only tactic that consistently works); bad habits are most easily broken by replacing them with benign ones; you can strengthen your resolve in one area by giving in to temptation in another; if you have to be exposed to a temptation, abstraction works better than distraction (e.g. imagine that the marshmallow is a cloud); and if you don’t want to cheat on your significant other, don’t go out for a late night drink with someone you fancy, if you do, you’ll wake up considerably more single than the day before. These are all things your mother should have taught you when she was raising you (including the crash course in How Not to Cheat).

My method of kicking Twitter was simple: I stayed away from it as much as possible, and, whenever I got the urge to check Twitter, I’d check Techmeme instead, a news source I loathe with a passion. I’d spend 30 seconds staring in disbelief at links to posts written by PR toadies before closing the tab and returning to work. After a few days of being unusually aware of the tech media’s general idiocy, I stopped checking Techmeme altogether.

I didn’t even follow links to tweets or Twitter profiles while I was kicking the habit.

This, not so coincidentally, is similar to the method I used to kick coffee: Every time I had the urge, instead of having a cup of coffee, I’d have a cup of green tea. I don’t particularly like green tea, so, once I’d replaced my coffee habit with a green tea habit, cutting my green tea consumption down to next to nothing was doddle. It also bears mentioning that I haven’t had a data connection enabled (not even wifi) on my iPhone for a year and a half, which makes these sort of temptations easier to resist.

I also know that I couldn’t have kicked both coffee and Twitter at the same time. Anyway…

Twitter is a good way to follow the issues and links that interest the social groups I follow, I may simply decide to try to lurk. A self-imposed ‘no tweeting’ rule would enable me to follow updates but still be available in case somebody throws a question my way. I don’t know if that’s feasible, the very design of Twitter goes against such use, and I don’t know if I have the self-control to expose myself to Twitter and not to fall into old patterns of use.

The tragedy of Twitter is, as it was with Facebook, Myspace, and Friendster before it, that its very popularity consumes the very resources needed to fix the problems inherent in its user interface and design, meaning that its fast growth will be followed by a steady deterioration in user participation. Instead of continuing to improve the user experience, Twitter’s development team alternates between frantically keeping up with continuous growth and haphazard schemes for revenue generation.

I hope this will change, but, as it stands, Twitter is too broken for full-time use.

Friday links and reading

2011-08-25T16:00:00-07:00

Just a few things that caught my interest this week.

From http://www.niemanlab.org/2011/08/accessibility-vs-access-how-the-rhetoric-of-rare-is-changing-in-the-age-of-information-abundance/:

Because here’s the thing: Knowledge is not a lean-back process; it’s a lean-forward activity. Just because public domain content is online and indexed, doesn’t mean that those outside the small self-selected group of scholars already interested in it will ever discover it and engage in it.

The article references the curator buzzword, but the basic point is sound. Access isn’t expertese. You can inform and delight people by connecting them to publicly availabe information in ways they couldn’t previously imagine.

From http://www.alistapart.com/articles/making-up-stories-perception-language-and-the-web/:

In the last chapter of each installment, [Dickens’s] sentences grew shorter, more active, and more visual. This made the text dynamic and active, compelling further engagement. Take the last lines of the first installment of David Copperfield (the close of chapter three):

I’m lukewarm about the article as a whole, a lot of it seems to reaching, rather, but I didn’t know that about Dicken’s.

Fun fact: Dickens is one of the few major 19th century author’s I haven’t read. Not a single book. They’re on my to read list along with another gazillion things.

From http://justinelarbalestier.com/blog/2011/08/25/writing-liar-with-scrivener/:

In the acknowledgements of Liar I wrote the following: “Without Scrivener this book would most likely not exist.” Ever since people have been asking me to please explain. Here, at long last, is my explanation.

A good overview of the capabilities Scrivener offers. For the record: I love Scrivener. One of my favourite apps.

From http://blog.fawny.org/2011/02/02/gaylives/:

When you tell us it’s wrong to report on gay public figures, you are telling gays not to come out of the closet and journalists not to report the truth. (What you’re telling us as gay journalists is even worse.)

When you insist being gay couldn’t possibly matter less, what you actually insist is that the subject never be brought up in the first place.

A few months old, but good. Joe Clark wrote this when Tim Cook was made interim CEO.

From http://blog.fawny.org/2011/08/25/cowardsplus/:

It is the height of hubris to assume that, since all your tech friends scurried up the gangplank onto the Google Plus ocean liner, a host of other groups you claim to give a shit about will inevitably do the same, and their right to be known by a pseudonym is one you will defend to the death. Can’t you do something that would really help those you claim to defend – even if it hurts, like adopting a homeless gay teenager or donating a couple of grand to a real-world charity every year till the end of the decade?

Whenever I read Joe Clark I’m reminded of this exchange from Die Hard 2:

John Mclane: “Maybe you’re not such an arsehole after all.”

Special Forces Leader: “Oh, I’m an arsehole, all right. I’m just your kind of arsehole.”

Joe Clark, as awkward as it is when you’re the subject of his scorn, is my kind of arsehole.

And as much as I hate to say it, after my fretting and worrying about the pseudonym issue, he makes an excellent point.

Convert or engage

2011-08-03T16:00:00-07:00

The ebook debate is locked into dichotomies of past versus present, dynamic versus fixed; split into factions, when all that matters is engagement, both with the readers and your colleagues.

On my way to work this morning, munching a croissant as I walked through Reykjavík city centre¹, I thought about Joseph Esposito’s post on the role of dynamic versus fixed publishing in scholarly publishing.

It’s a thing I do when I walk: leisurely ponder stuff I’ve read recently.

My thoughts started off on a simple tangent, a straightforward position that’s getting to be a personal cliche of mine. Namely, even though Joseph explicitly refers to the dynamic and fixed concepts as a continuum, he goes on to treat it like a dichotomy.

Everybody seems to fall into this trap, they know—intellectually—that it is a continuum, or a spectrum, but they all go on to talk as if fixed represents the past, and dynamic the future, never the twain shall meet.

This simply isn’t true. If you go outside of the confines of mainstream publishing you’ll find dynamic, conversational, publishing everywhere: Comics, games, local publishing, indie magazines, fanzines, small press, small newspapers. Dynamic publishing, where the readers take an active role in shaping the output, outnumbers fixed mainstream publishers and has done so for a long long time. Mainstream publishers have more revenue, but that’s more due to the occasional blockbuster than a characteristic of standard practice.

This is without wandering outside of the myopic realm of English-language publishing. Cultures vary, and many national publishing industries are profoundly different—and more dynamic—than what the British and North Americans are used to.

But those aren’t the same, they aren’t real publishers.

Therein lies the rub. Many people in the mainstream publishing industry see themselves as all there is, and their way as all that has been done. What makes mainstream publishing ‘fixed’ is their worldview, and no technology can fix that.

You can see how far off course I am by now. This line of argument has precious little to do with Joseph’s blog post, since he is actively engaging in a debate. He’s proposing ideas, listing the pros and the cons, and, instead of presenting what he thinks is the one true answer drawn from the holy scripture of truth, he’s asking questions that don’t have easy answers and hoping people will discuss them.

By this time, I’m interrupted by a tourist who asks me for directions to the nearest bakery. I point her to a nice one that’s only a few metres further up Laugavegur, and, as I return to my march to work, I notice I’m not thinking about Joseph’s blog post at all, but Craig Mod’s, specifically his post ‘Post Artifact Books & Publishing’.

This is the point where all of my prior discussions on Craig’s post have turned into heated arguments.

Craig’s post is the epitome of the perspective that ‘all past practice is double-plus undynamic’, of the view of dynamic versus fixed as a dichotomy, of the idea that mainstream publishing practices are all that matters and all that needs to change. His post is also not an attempt at a debate. He might think so, but if it was, he’d make sure to reach out to those who ‘don’t believe’ by referring to earlier experiments, examples of dynamic publishing that precede the current ebook vogue. He’s certainly erudite enough to know of them, and it would be much more effective at reaching out to those in publishing who would like to keep their current processes, thankyewverymuch, than his current angle of attack. The way to get people to accept a new process is by pointing at antecedents, not by eloquently demonstrating with fancy designs that everything they know is obsolete.

You don’t make friends by calling them stupid, which is what ‘Post Artifact Books & Publishing’ effectively does.

I guess that’s okay, because that’s not what the post is for. That's not its purpose.

It isn’t an argument. It isn’t an entry in a debate, or an attempt at a dialogue. It’s a shibboleth.

It’s a way for the digerati, the ebook avant-garde, to identify themselves by linking to, pointing at, retweeting and +1ing a piece of text that outlines their worldview.

A shibboleth is not supposed to convert, it is supposed to exclude the heathens.

And Craig’s post does that very well.

Which is the thought I have in my head when I clock myself in at the office and take one last gulp of the orange juice I’ve been drinking on the way to work.

It's the last day before I return home to the UK! Woohoo! ↩

CSS3 Hyphens

2011-07-29T16:00:00-07:00

This piece of code:

Modernizr.addTest("hyphens", Modernizr.testAllProps('hyphens'));

Adds a test to Modernizr that will add ‘hyphens’ to the class attribute of the HTML root element when the browser claims to support CSS3 Hyphens.

Chrome is a false positive as, for some weird reason, it claims to support -webkit-hyphens, but no other value than ‘manual’.

Most importantly, I haven’t tested the various versions of IE, but at the very least it works properly on Opera, Firefox (correctly identifies the currently released versions as not supporting hyphens) and Safari (correctly identifies it as a supporting browser).

Still, untested as it is, might be useful to somebody else.

You could use this, in combination with Modernizr.load, as a polyfill (dynamically load js to add advanced features to non-supporting browsers), but polyfills are a problematic concept when you are actually required to support your website.

Polyfills work extremely well for covering edge cases. For instance, if you run a mac-oriented site and only expect a fraction of your traffic to come from IE7, and all of the other browsers support a feature you really really want to use, a polyfill becomes reasonable. You only expect to use it with one browser, in a context that you understand.

A website that has to support a dozen different browsers in differing versions, only three of which support the feature you want (as is the case with hyphens¹), will end up serving the polyfill to most of the visitors.

Instead of filling in the edge cases and only loading it so rarely that rare bugs aren’t likely to surface, the polyfill becomes major application code that needs to be worked on and supported. This, in and of itself, is not so bad, if it weren’t for the fact that this is a major piece of application code that you expect to discard—it’s a feature the browsers are working on implementing, otherwise it wouldn’t be a polyfill.

A polyfill for hyphens doesn’t make much sense.

CSS3 Hyphens are supported by Safari, Mobile Safari, and the upcoming version of Firefox; nothing else as far as I can see.
↩

Just you & Google

2011-07-28T16:00:00-07:00

One of the things I’ve noticed in Google+, a side effect of the Circles feature, is that many people have no public life whatsoever on the service; everything they say is to one Circle or another.

In many ways this mirrors the way people lead their day to day lives: You don’t work in hiding, shrouded by paranoia, but your activities are only seen by colleagues, friends, acquaintances, and family. Your public life is incidental and minor; your encounters with strangers have strict protocols that have been ingrained in both of you from childhood.

Basing an online service on this structure has obvious benefits. You reenact online the rules and protocols you apply to your daily life, like an anthropologist’s theatre performance, each rule simplified and exaggerated and enacted by unbending code. It requires no learning. It requires no adaptation. It suits those who are uncomfortable with dealing with people, social situations, and the changing, infinite, idiosyncrasies that come with both.

This also has obvious flaws. Whatever benefits Google Plus gains from breaking away from Twitter’s bad example and not enforcing an heartless cull of the verbal fluff—the cushioning that makes social interaction so much more pleasant and nice— it loses by being staid and predictable; serendipity is lost and unappreciated.

There’s a risk in trying to author software to closely match observed models of human behaviour. By modelling the status quo you make fluid traditions concrete and inflexible.

Knowledge is not adoption

2011-07-23T16:00:00-07:00

As a comparison, this is still a greater percentage of people than use Twitter.

From Podcasts: Who still listens to them? on the BBC’s website.

My mother listens to a lot of podcasts and is on Facebook, but she isn’t on Twitter.

Which is also the reason why Twitter is weak where Facebook is not. Despite its popularity among early adopters, it isn’t a mainstream technology, and the people running it don’t seem to have a clue as to how to reach the mainstream.

My mother has heard of both. My father (slightly less computer literate) has heard of both. Even my grandmother has heard of both. You can’t listen to Radio 4, for example, without hearing podcasts mentioned on a regular basis. All regular listeners will know what a podcast is, even if they aren’t interested.

Besides, it’s not a question of what people have heard of, it’s a question of who they perceive the service to be for.

Podcasts are radio episodes on demand. Easy to understand and easy to pitch to those who like radio. The radio stations themselves here in the UK and in Iceland do a lot of the work involved in evangelising podcasts. They mention them in adverts, and they promote them on air with the iPlayer and the like as ways to catch up if you’ve missed an episode.

Twitter, on the other hand, usually doesn’t hook people until they’ve used it, and even then only if they know a lot of other people on the service. The vast majority of people still don’t see the point of Twitter, even after they’ve understood exactly what it does.

The most common response I’ve heard after describing Twitter? “Oh, it’s for geeks, then?”

It doesn’t help that Twitter doesn’t actually add any value to your life, just sucks time away. (There’s a reason why I quit Twitter. I’m not a fan.)

My mother, and most of the mainstream public, know by now exactly what Twitter is. They just aren’t interested.

HTML5 history API

2011-07-22T16:00:00-07:00

The problem with Backbone.js and Spine.js gracefully degrading History API routing to hash fragment routing is that it’s entirely reasonable to want to use both the History API and hash fragments together in an AJAX app.

You might want to use them together, the History API to manage the state of the apps dominant view, and hash fragments to manage sidebar navigation (an UI style that’s very common in iPad apps, for example).

Not to mention the fact that by using hash fragments for graceful degradation you are committing to maintaining two versions of all of the app’s urls for a very, very long time.

It means you need to maintain support for all of the hash fragment urls in your js code.

The server doesn’t even get to see the hash so it can’t route you to the correct content, it has to send the reader a js app, which then decides what to fetch and load via ajax. The server can’t do any redirection because it never even sees the hash fragment.

So, when you use the History API with a fallback to hashChange, you end up maintaining:

All of the regular URLs on the server, for search engine crawlers, those who navigate directly, via bookmarks, etc.
JS routing for all of the regular URLs for whatever fancy History API-based navigation effect you need it for.
JS routing for all of the hash fragment versions of the URLs for all legacy browsers (which will be around for a very very long time).

Also, remember, the hash fragment versions don’t get any benefit from basic HTTP features, such as redirects.

You could leave it all to the framework you’re using (and you probably should), but all of this adds to the complexity of the app, reduces its flexibility and thus makes it more likely to be buggy and brittle.

The sensible thing, for content sites, would be to gracefully degrade from History API support to just no ajax whatsoever, and always maintain the purity of the URL. Apps that don’t need to be crawled (like Gmail) can OTOH stick to using hash fragments to maintain state.

Your friends, in boxes

2011-07-16T16:00:00-07:00

Can We Ever Digitally Organize Our Friends?

He, and almost everybody who thinks about thinks about social networks, including Google, asks the wrong question.

The last thing we want to do is to organise our friends; create a digital information architecture of our extended social network.

What we really want to do, and need to do, is to easily keep control over what we say and to whom. It may sound like the same thing, but it isn’t.

If you think about the Circles interface as a way to categorise your speech (family stuff, work stuff, hobby1, hobby2) and think of it as labelling your friends according to what sort of things we’d like to say to them, then it becomes a much easier thing to manage with a lot fewer circles.

If you approach Circles as a way to type and categorise your friends, then you’re going to end up insane, as the information architecture is much too complex to express in the Circles model and your brain doesn’t keep track of that information, anyway.

On twitter:

Mike said this here thing:

Twitter enforces thought disciplne! Evn f u mst do ths.

To which I said:

There’s thought discipline and then there’s unusable restraint. The 140 character limit, which turns into a 120 char limit as soon as you enter into a discussion, is idiotic, counter-productive, sabotages civility, and destroys any hope of maintaining a productive debate. The qualifiers, politeness, and general verbosity that Twitter forces you to excise is essential in keeping conversation civil when you’re in a community of acquaintances, which is what Twitter really is (was?).

Uncivil communities flame out and die. Twitter’s fate is for it to be an aggregation of loners, broadcasting at their followers, occasionally shouting at each other for perceived slights, because they have no way of knowing the true intent behind the pared back sentences thrown at them.

Thought discipline and temperance are well and good, and they have their place in essays, blog posts and articles, but words aren’t the products of an evolutionary dead end—the mind’s equivalent of the appendix—they are a part of our language for a reason; they have a role to play in conversation and in writing. We exist to each other as actions and words. Being stingy with words is being anti-social.

Twitter is anti-social.

There… that wasn’t too long, now was it? :-D

Localstorage & messaging in ePub

2011-01-26T16:00:00-08:00

I decided to try and find out if localStorage and Cross Document Messaging could be used with ePub's non-linear documents in iBooks

The short answer is: no.

The good news is that localStorage otherwise works in an ePub document in iBooks.

The idea I had was that, since we have to deal with the idiocy of having no CSS absolute positioning, I could use a document marked as “non-linear” in the spine as a kind of popup window. The theory being that you could click on a link or a button in the ebook, the non-linear document would open up full-screen, as it does in iBooks, with the UI/controls/wiggly widgets the reader could twiddle with, and, upon returning to the book, finding that the book had responded to those actions.

A classic example would be a gamebook: You get to a passage were you have to solve a task. All the links would be disabled until you click on the “fight” button (or “pick lock”, or whatever) and, once completed or failed, the book could decide which links to enable based on how it turned out.

Turns out that's not possible. Which is a shame, since, without overlays or some sort of popup, it is rather difficult to create usable interactivity widgets.

Localstorage works in iBooks, but it seems that the non-linear pages and the main book pages do not share a database. Values set in the non-linear page return null on regular book pages.

The second idea was to see if Cross Domain Messaging worked between non-linear pages and the opening book page. This would enable the non-linear page to send data to the opening page. It doesn't work. No matter what method you use to open the non-linear page.

If you want, you can have a look at the test ePub and see if I did something wrong.

You can also see the component xhtml pages: Localstorage Test. Messaging Test.

The localstorage test page is slightly different from the epub one, it has an added “target” attribute necessary to make the damn linked page pop up. Links with defined targets don't seem to work in iBooks.

Note: Neither of the tests will work in ePub readers that don't support javascript. To my knowledge that means only iBooks and possibly some of the browser-based readers.

Javascript in epub

2011-01-25T16:00:00-08:00

I used some spare time this afternoon to throw together a few ePub experiments

After throwing together the Modernizr ePub experiment earlier today I decided throw together another one. The code isn't the prettiest I've written, the page itself is ugly as sin, and some of the transitions are a bit jumpy, but on the whole it works.

In web browsers, that is.

Two out of the three experiments work in iBooks, the third does not. It's a slideshow of three images. When you press 'next' in the third experiment, the first image fades out as it should, but the next image doesn't appear. However, if you double tap where the image should be, iBooks opens up the full-screen thing it does and displays the correct image, so it obviously knows what should be there, but isn't displaying it.

Now, in a web browser I'd be able to open up Firebug or a Web Inspector and figure out what it is that's causing this, whether it's a bug in the app, in my code or something else. In iBooks… well.

Other issues with these experiments is the rendering model necessitated by the lack of positioning in ePub which caused problems at every point and at every level and that is entirely due to the idiocy of those who hammered the standard together.

You can see the html page from the ePub here, or, if you wish, you can download the ePub file itself.

An epub experiment

2011-01-24T16:00:00-08:00

How can people say book design is dead when they see something like this?

I'm going to post this one without much comment.

You can find more information on Modernizr on its website and if you want to, you can download the "Modernizr in ePub" file itself.

What is an ebook?

2010-12-20T16:00:00-08:00

A few days ago I participated in an online discussion on the nature of the ebook

Edited a bit for coherence and clarity.

Introduction

neustudio: Today we will here from @MatthewDiener, @pablod, @ebookNoir, @BookDesignGirl, @FakeBaldur.

neustudio: They are all ebook pros and frequent contributors to hour discussions

Mathew Diener

MatthewDiener: Snuck out of benefits meeting to be here for first half hour at least. Can’t miss time with my peeps. I think the most important defining characteristic of an eBook is that it is first and foremost text. It is intended to be read. But an eBook should not simply be a digital copy of the print edition. The text should be enhanced with the advantages of the form.

The text should be reflowable. It should resize to any screen & remain readable. eBooks should be readable on multiple devices. eBooks should support DAISY/text to speech. eBooks should allow access to content for readers who have difficulties w/ print text. eBooks should take advantage of linking for TOC, cross referencing, notes, & access to content & resources outside the book itself. Index, too. An index can be a great tool for readers if it is fully linked to text. eBooks should include images, audio, and video files when this content enhances the book, allowing primary source inclusion for multi-media.

pablod: @MatthewDiener so by your definition, a PDF file is not an ebook? I completely agree.

MatthewDiener: I think a PDF is a PDF. It serves a single purpose (to mirror a print edition), but it does not realize potential of eBook/digital.

MatthewDiener: Aldiko & ScrollMotion are making eBook apps, but most apps aren’t eBooks anymore.

MatthewDiener: eBooks are content containers; they need a common structure.

MatthewDiener: And that is it for my time. Who’s next?

Pablo Defendini

neustudio: @pablod is up

pablod: Hi! So, here’s a definition of an ebook: the written word, marked up and hyperlinked. This is purposefully vague and inclusive. Anything above and beyond this then gets slapped with a qualitative moniker: ‘enhanced,’ ‘picture,’ ‘interactive,’ etc. So: if an ebook is the written word, marked up, that means we use regular old markup (X/HTML) to do so, right? If an ebook is a set of HTML + CSS docs, what makes it different from a website? I don’t have an answer for this.

vyallamelli: @pablod Books are to be read, page by page website to be browsed :) Sorry for this interruption

vyallamelli: @pablod eBooks only provide portability nothing else to be different from a browser

vyallamelli: @pablod Cross book, document linking, this is something that ebooks still cant do

pablod: What do ereaders (the ‘browser’ for ebooks—iBooks, Kindle, Nook, etc) bring to the party that a regular web browser doesn’t? What could an ebook in a regular web browser do that current ebooks can’t?

tobiasbuckell: @pablod stricter adherence to standards? Don’t like sloppy code?

pablod: .@tobiasbuckell There is that, certainly. But that depends on the software maker.

pablod: That’s what I’ve got for . More questions than answers. As it should be. Let’s get it on! ;)

JulietaLionetti: @pablod I’d like an answer from the (human) reader point of view to the question of what a book can do in a regular web browser.

eBookNoir

eBookNoir: me next. eBooks are not simply reproductions of the printed book, they don’t act the same and shouldn’t be expected to. An eBook follows different rules than a print version, dont look look printed books. That’s ok, we shouldn’t focus on that as a deterrent. To define an eBook we need to think differntly than what a printed book is & realize that the future of the book as a whole is changing. eBooks are content and needed to be treated as such and could be in a variety of forms, a big question is what isn’t an eBook?

Is an App or an online platform an eBook? eBooks are ever evolving, it’s not simply text anymore, it’s audio, vid, interaction.

vyallamelli: @eBookNoir Any e-document that does not have a definite structure as a book is not an eBook

vyallamelli: @eBookNoir True! Its up to the reader to classify the eDocuments

eBookNoir: @vyallamelli -good point, but that is also being challenged all the time, by writers & everyone, a standard is only so good if followed

JulietaLionetti: @eBookNoir I’m afraid that apps have a different discursive structure than ebooks.

Colleen Cunningham

neustudio: @BookDesignGirl has some thoughts to share

BookDesignGirl: Hi all! Here’s my observations and opinions from my own little corner of the world… An eBook is 1) digitalized content 2) built for various eReader platforms. Can’t have one w/out the other, which makes challenging. An eBook is a contained set of content. This makes it different than a website because it’s expanded and updated less frequently. An eBook can be a PDF, ePub, or an app. Because each format affects context of content, Editorial should be involved in decisions. A PDF eBook can support audio & video embedding, bookmarking, web linking, searches…in a grid that can support complex content. eBook reminds us content is priority and format it’s presented in is secondary. How does your reader want to access your content? An eBook has a beginning, a middle, and an end like its printed counterpart, but the ordering of the content is up to debate.

Debate re: if eBooks should mimic printed books show how little we know how readers experience & digest long-form digital content. Producing an eBook is a challenging, inventive, pain-in-the-neck, exhilarating, thought-provoking, ever-evolving experience.

Baldur Bjarnason (that’s me)

neustudio: @FakeBaldur is going to bring it on home

fakebaldur: Okay. My turn. (Short version: I agree with most of the others :-)

Interactive media has a 26+ year history of creativity, design, traditions, tropes & a canon to match. Ebooks as a medium have to have an added meaning beyond interactivity. They need to be differentiated from web/flash/games. The only thing ebooks have, that the interactive media genres don’t, is a tradition of longform text. Which leads to a very simple answer to the question “What is an ebook?”: Longform text, prose or poetry, in a digital context.

It doesn’t have to be linear, but if you replace the longform text with video & twiddly knobs, it ceases to be an ebook. Text, and the presentation of the body of text, has to be the heart, spine and body of the story. But the content of an ebook could be remediated into something that is more interactive and goes beyond the ebook form.

fakebaldur: That’s my answer :-D

Discussion

neustudio: group, any comments, questions for our presenters?

vyallamelli: I think the term “eBook” has been broken up and squashed completely by self ideology

adamjury: @MatthewDiener A good PDF is better than a bad “eBook” (A term fraught with baggage, as regularly illustrates… ;-) )

adamjury: “eBook” already means so many different things to different people, I try not to use it in customer-facing communications.

MatthewDiener: @adamjury I agree. And with content like basal curriculum, PDFs may be a much stronger digital presentation format.

adamjury: @MatthewDiener Absolutely. The type of content you publish should guides format. I publish RPGs; they don’t work well as ePub, yet.

tinahender: Wow. It does appear that many of you think a picture book or art book cannot ever be an “ebook.”

vyallamelli: Any electronic form of a book other than the printed book is an ebook.

neustudio: What about children’s books, art books, comic books?

fakebaldur: @tinahender As soon as you get into a digital context, picture/art/photo books can become their own medium, and flower really

eBookNoir: @tinahender - I dont know if I’d say that. I can see the definition of an eBook changing, always.

pablod: @tinahender never said that.

vyallamelli: Its like Printed book, is hard back, paper back, hard bind, soft bind, or spiral bind, do we call it some other book

fakebaldur: .@neustudio e.g. ‘What are Digital Comics?’ - The answer to which would be a variation of: Sequential art in a digital context

pablod: @tinahender I would love to have an art ebook… on a 15-inch tablet. devices need to catch up to intentions.

jennybullough: Any electronic form is an ebook: @vyallamelli — so is the author’s Word file manuscript an eBook?

cdcasey: I’m curious, would most agree that eBooks need a separate workflow, separate from (and not tacked on to) the print design process?

vyallamelli: @jennybullough Yes it is one just that he wont sell it Copyright.

pablod: I think that art, picture, comics, etc, along with science and textbooks, will move away from traditional ‘book’ pigeonhole.

vyallamelli: @cdcasey eBooks dont need a separate workflow, just the current needs to be upgraded/migrated to add in eBooks

crych: @cdcasey re workflow: not tacked on, not separate; for pref., XML first

vyallamelli: @neustudio Yes ISBN-International Standard Book Number

eBookNoir: @cdcasey - I’d say they need to compliment each other.

fakebaldur: Re: @pablod’s Qs: The diff between browsers/websites and readers/ebooks is that browsers are hostile to reading. They don’t feature tools for highlighting, no built in notes, no cross-device synchronisation, no book-level metadata/search. It’s an User Interface/User Experience thing. Browsers are designed for info-grazing & are about as conducive to reading as a library index card system.

JulietaLionetti: @fakebaldur Brilliant definition of reading on browsers. Thanks.

pablod: @vyallamelli actually I think print needs to be ‘tacked on’ to e-production, in fact (no matter what Adobe would prefer). @cdcasey.

BookDesignGirl: @cdcasey XML ideal but corporate here struggles w/ that - can we do it, can we afford it, no … not in the budget this year.

jennybullough: I disagree @vyallamelli an electronic file does not = an ebook. Just like my handwritten journal does not equal a book. ISBN = book

vyallamelli: @pablod Absolutely, digital content production makes life is easy for print producton. I do it day in day out

ritchielee: 2,500 line nested NCX amended; glad that’s over #thedoubletruthruth

cdcasey: @pablod interesting view. I agree they need to be complimentary, but one shouldn’t inhibit the other

pablod: @fakebaldur can’t say I disagree, but some of those limitations can probably be eliminated in the document’s presentation layer

vyallamelli: @jennybullough Its the perspective why would any book be called an eBook?

cdcasey: @BookDesignGirl I think the XML TLA scares some people ;-)

neustudio: Taking the easy way out: Let’s make really cool things and then figure out what to call them.

BookDesignGirl: @cdcasey re: XML TLA scares some people | Yes, it’s “change”! so for us eBook after pBook b/c correx entered at pBook correx stage.

vyallamelli: When Guttenberg project brought 100s of books in text format for easy portaibility and called it ebooks no one objected why?

neustudio: @cdcasey: @BookDesignGirl What is TLA?

cdcasey: @neustudio Three Letter Acronym

fakebaldur: @pablod Then the browser becomes little more than an app platform for implementing an ebook reader like @ibisreader .

MatthewDiener: Have to go to a meeting, but this was/is a fun Hour. I can’t wait to read the conversation that follows.

pablod: Taking a long view here: I think ePub/ereading systems etc are a transitional stage for the written word. Almost a ghetto created by corporate, technical, or marketing needs.

cdcasey: @fakebaldur or iBooks

adamjury: @jennybullough Is a limited-edition title sold only directly and thus with no ISBN assigned not actually a book?

pablod: @fakebaldur BINGO.

vyallamelli: No one told, Are Gutenberg text files eBooks or just text files.

pablod: THIS—> “Taking the easy way out: Let’s make really cool things and then figure out what to call them. ” via @neustudio.

crych: @pablod So do you see a gradual melding of ereading systems and browsers?

cdcasey: I’m not sure I would call an original Word file an eBook any more than I would call an original typed manuscript a printed book.

tinahender: I think it helps, when we are discussing ebooks, to consider we aren’t all working w/ same type of books. But they are all books.

pablod: @crych yes I do as a matter of fact. This is actually already the case. Look at iBooks: it’s essentially a simple version of Webkit.

jennybullough: Good questions @vyallamelli and @adamjury ! What I think we need to avoid is assigning ISBNs to every e-file.

tinahender: @pablod “15-inch tablet” Art book epub on iPad can look pretty good.

eBookNoir: what is an eBook is always going to change, will always be in flux. As long as the tech continues to change, so will eBooks.

pablod: @jennybullough Too late! (I hate that too.)

jennybullough: Agree! @cdcasey not sure I would call an orig Word file an eBook any more than I would call an orig typed manuscript a print book.

JulietaLionetti: @tinahender Maybe, we should start thinking without the book in the centre. Books are not all the same good.

adamjury: @jennybullough Agreed. I don’t assign ISBNs to any of our electronic books: PDF, ePub, Kindle. Can do without. (maybe not forever)

pablod: @tinahender it can and it does, but try looking at, say, a big Taschen book on there. Relatively low res screen, small viewport.

eBookNoir: @jennybullough @vyallamelli @adamjury isbns are a whole other discussion within itself for eBook creation. It’s all metadata.

jennybullough: @adamjury Can a book be sold without an ISBN, even in limited direct-only quantities? I thought ISBN was tied to royalty/sales

emilyw00: @Poliorcetes cosas interesantes acerca de #booksinbrowsers si sigues @pablod y hoy.

pablod: @tinahender Want: 15 inch iPad with Retina-class display. The stay-at-home, coffee table iPad.

cdcasey: @jennybullough depends on the vendor

cdcasey: @jennybullough Apple requires a separate ISBN, while Amazon doesn’t require one at all

vyallamelli: @eBookNoir Agree!

tinahender: @pablod But higher-res iPad is coming, don’t you think?

pablod: @adamjury unfortunately, best practices dictate that you should… for now, at least. @jennybullough.

adamjury: @jennybullough Of course it can. I don’t need to assign an ISBN to something to be able to track sales. :-)

pablod: @tinahender maybe, maybe not. That Retina display is GPU intensive at bigger sizes.

jennybullough: Blank journals are called “books”, are sold as goods, yet these have no ISBN. Does content = book? (channelling Yoda over here)

aramanc: Been in concall. “XML TLA scares some people” - Implementing XML needs to be driven by Business reasons, not just because it’s XML

vyallamelli: @jennybullough Not all content is book

pablod: @tinahender A retina display on current iPad would need a resolution of 4096×3072 O.o

jennybullough: .@pablod @adamjury @cdcasey So it seems best practices are not always practiced… and the standard, isn’t :) Confused yet? I am!

tinahender: @pablod I don’t actually think the 15” is necessary. Just Retina display.

vyallamelli: @aramanc The best business reason -> XML = Cost effective and powerful Workflow :)

BookDesignGirl: @MichelVrana Yes! U following the discussion now? So many interesting thoughts on that re: ebooks could be so much more than print.

pablod: (I hope my math is correct. I suck at math)

vyallamelli: @pablod Its ok everyone does at some point in life!

fakebaldur: Not all print book genres/forms will end up as analogous ebook genres/forms. e.g. Comics are going off on their own on digital

vyallamelli: Do not compare pbooks with ebooks or ebooks with ebooks, waste of energy is evolving everyday :)

adamjury: @pablod I’m gonna ignore “Best practice” for now, in this case. Certainly until I buy our next block of ISBNs. ;P

neustudio: How did this format work for the peeps?

pablod: To me, the interesting thing is going to be the ‘hyperlinked’ bit. Concept linking, doc linking, comment linking, social reading

vyallamelli: @neustudio Great! Wonderful!

cdcasey: @neustudio certainly spurred a good discussion

JulietaLionetti: RT @pablod: To me, the interesting thing is going to be the ‘hyperlinked’ bit. Concept linking, doc linking, comment linking, social reading

BookDesignGirl: @vyallamelli re: do not compare pbooks w/ ebooks or ebooks w/ ebooks | Hard not to do when considering how to reach our readers!

JulietaLionetti: @neustudio Liked it!

vyallamelli: I think 10 years from now we all be back to pBook reading

ecodedoce: RT @pablod: To me, the interesting thing is going to be the ‘hyperlinked’ bit. Concept linking, doc linking, comment linking, social reading

pablod: For that to really take off, we need to leave the silos/ghettos of ereader platforms. See @booksquare’s latest post

vyallamelli: @BookDesignGirl Its like an ever changing menu, tastes change, But at the end food at home is the best:)

BookDesignGirl: @neustudio This was fun - the discussion this generated could go on forever. Let’s try this again.

neustudio: @MoriahJovan deserves credit too, but couldn’t join us today.

vyallamelli: @aramanc Thats why powerful

pablod: @vyallamelli I think 10 years from now, I will have never left pbook reading in the first place.

cdcasey: @aramanc I think the advantage of XML is supposed to be that it can be transformed into something for any platform

vyallamelli: I am a big fan of MoJo RT @neustudio: @MoriahJovan deserves credit too, but couldn’t join us today.

fakebaldur: @neustudio That was fun. :-)

aramanc: @neustudio Great, but only saw the end , now have some reading to do to catchup, but looks like a very spirited discussion

BookDesignGirl: @pablod @vyallamelli I just finished reading my first eBook on my Sony eReader. Liked it. Back to my stack of pBooks.

adamjury: It ain’t a print vs. ebook world. It’s a print and ebook vs. ignorance world. ;-)

vyallamelli: @pablod In the industry for 11 years never read a book even as a PDF :( sad isnt it

cdcasey: @pablod pbooks will exist for as long as we have trees :)

neustudio: Thanks, @adamjury @tinahender @vyallamelli @cdcasey @jennybullough @JulietaLionetti @aramanc @emilyw00 for a lively discussion

neustudio: Thanks especially to panelists @MatthewDiener, @pablod, @ebookNoir, @BookDesignGirl, @FakeBaldur.

MoriahJovan: @neustudio Oh, well, it’s just I have nothing prepared. I’ll participate in the convo. @vyallamelli .

vyallamelli: @MoriahJovan Its fine! We know you are among the best :)

tinahender: Thanks @neustudio, presenters, and everyone for lively and interesting discussion. Off to produce more p-books! :)

crych: Thanks to everyone and thanks to @neustudio for organising and chairing. I thought format worked well. We’ll have to do it again.

jennybullough: Thanks for a great discussion @neustudio @adamjury @tinahender @vyallamelli @cdcasey @pablod.

aramanc: @cdcasey Its certainly one of the main ones, was trying to catchup on the speed of conversation.

vyallamelli: @jennybullough You are most welcome!

vyallamelli: Bye All! at will catch up sometime later!

stephenTiano: Re: do not compare pbooks w/ ebooks or ebooks w/ books - Why? Seems downright odd NOT to make such a natural comparison.

MoriahJovan: Crap. I DID miss it. I was…um…formatting. LOL

neustudio: I’m off to work on pbook myself! Bye group!

fakebaldur: That was a blast. Thanks all. :-) @JulietaLionetti @crych @neustudio @MatthewDiener @pablod @ebookNoir @BookDesignGirl.

vyallamelli: @StephenTiano Thats what leads to no complete understanding of anything

MoriahJovan: @JulietaLionetti CRAP!!! headdesk I even had it on my calendar!!! WAh!!!

MoriahJovan: At least I’m not going to get fired for missing the meeting.

crych: @pablod: re diff epub & website: still like Jon Noring’s Internal Ref (browser) vs Doc. Org. template (epub) http://twurl.nl/ulve8l.

tinahender: @jennybullough @vyallamelli I’m totally converted to ebook reading, too. At least for straight-text books. It’s the convenience!

MoriahJovan: @pablod Actually, I am starting to reverse the order: digitize, then design for print. So much more efficient.

CoverMonkey: RT @adamjury: It ain’t a print vs. ebook world. It’s a print and ebook vs. ignorance world. ;-)

crych: @MoriahJovan Well, you know, If it would make you feel better we could always give you a whole session to yourself.

JulietaLionetti: YES RT @crych: @MoriahJovan Well, you know, If it would make you feel better we could always give you a whole session to yourself.

BookDesignGirl: Thanks @neustudio @crych @MatthewDiener @pablod @ebookNoir @fakebaldur and all for another great Hour. Be safe out there.

MoriahJovan: @crych Didn’t we do that once? O_o @julietalionetti.

MichelVrana: So, how do we replace page numbers in ebooks in order to refer to passages. Chapter & paragraph numbers perhaps?

MoriahJovan: Did we do a “why ebooks have to reflow” session yet?

ritchielee: @MoriahJovan a LOT of people are selling them as that, and it’s a crime #apdfdoesnotanebookmake

pablod: @MoriahJovan exactly.

MoriahJovan: Aarrgh I HATE that. RT @ritchielee: @MoriahJovan a LOT of people are selling them as that, and it’s a crime #apdfdoesnotanebookmake

crych: @pablod: though one wonders how much existence of <spine> in epub owes to tradition of print publication

JulietaLionetti: RT @MichelVrana There’s a great post by @tina on ebook referencing pages and passages. Can’t find the link right now. :(

adamjury: FWIW, although I love PDFs and sell them more than any other format, I think calling them “ebooks” just muddies waters.

epersonae: interesting crossflow of tweets: @RepoRat at #idcc10 & @fakebaldur with .

BookDesignGirl: @adamjury re: calling PDF “ebooks” just muddies waters | OMG, we’re gonna have to take this outside, aren’t we ;0)

crych: @MoriahJovan: Did we do… “why ebooks have to reflow”… yet? Not as such & clearly contentious. Send me note: crych at telus dot net

adamjury: @BookDesignGirl Reliable sources say that if I jab my hair in your eye, you lose. ;-)

JulietaLionetti: Must go now. Thank you again for a wonderful hour.

samldanach: Preach it! RT @adamjury: It ain’t a print vs. ebook world. It’s a print and ebook vs. ignorance world. ;-)

adamjury: @alizasherman Too complicated for Twitter, as we just spent ages “arguing” about “What is an ebook?” in hour.

tinahender: @JulietaLionetti @MichelVrana “referencing pages and passages” Not me, but @MoriahJovan. I don’t have link handy either.

MoriahJovan: @julietalionetti I’m the one pounding the line-and-verse hobby horse. Here: http://is.gd/i34F5 and http://is.gd/i34IB @tinahender.

MoriahJovan: @BookDesignGirl No. IMO, a PDF is a print book on screen. An ebook that doesn’t reflow isn’t an ebook, IMO. @pablod @ritchielee.

JulietaLionetti: @MoriahJovan See how I am? All confused. :(

zumayabooks: @StephenTiano If p-books=ebooks, then all the technos telling publishers they need to do all kinds of stuff would be out of work.

MoriahJovan: @ritchielee Now you’re getting into lay nomenclature. http://is.gd/h8RaE @pablod @bookdesigngirl.

MoriahJovan: @pablod Unfortunately, Kindle’s version of MOBI doesn’t. It honors very little.

MoriahJovan: @pablod Or I should say, less than straight MOBI does.

MoriahJovan: Is there a difference between an ebook (XHTML/CSS) and a web page? Not if you do it right.

MoriahJovan: @BookDesignGirl Oh, yes, what @pablod said about formatting, too.

ritchielee: @MoriahJovan @BookDesignGirl @pablod It’s also about being fit for purpose; supplying PDF as your digital version is plain lazy

MoriahJovan: @ritchielee Or simple ignorance. Or simply hanging onto tradition as much as possible. @bookdesigngirl @pablod.

ritchielee: @MoriahJovan if only we did just epub!

adamjury: @ritchielee @MoriahJovan @BookDesignGirl @pablod Or it’s the right tool for the title, and appropriate for the budget/market.

MoriahJovan: @ritchielee That’s what I mean. Pub ppl might insist PDF IS an ebook & offer only that b/c they don’t really know better.

MoriahJovan: @adamjury I’ve turned down work I don’t believe should be in E.

MoriahJovan: Yes, and in that case, I don’t like it at all. RT @ritchielee: @MoriahJovan A lot of people will just make do.

MoriahJovan: @adamjury Agree again. Did you see this? http://is.gd/h8RaE The analogy holds w/ other labels across the digital landscape.

adamjury: @MoriahJovan Ayup. Client ignorance is nothing new, the topic just keeps changing… ;-)

MoriahJovan: @adamjury And since they pay the bills… LOL

jctremblay: Back from the gym and snow shoveling. I missed the discussion, but thanks everyone for today talk. I’ll catch it using

thDigitalReader: @tinahender I don’t think an art book would work well on anything other than the iPad, so no.

adamjury: @thDigitalReader If open/compatability is req. to be an “ebook,” is anything sold on a closed platform (Kindle, iBooks) an “ebook”?

thDigitalReader: @adamjury My objection was practical, not philosophical. I just don’t think they’ll work.

adamjury: @thDigitalReader WRT practicality - if you make something optimized for 1 device/platform/software, it should be advertised as such

adamjury: @thDigitalReader And that’s why we sell “PDFs” and “ePubs” and “titles on the Kindle store” but not “ebooks”. ;-)

Hypotheses and testing

2010-10-24T16:00:00-07:00

Customer development for publishers

I’m continuing my thoughts and research notes on electronic publishing here, obviously written mainly as personal notes, unedited, disorganised and possibly quite incoherent.

Since my earlier research notes were comprehensively poo-pooed by the few that read them, take all of the following with a grain of salt.

Most useful theories and models of entrepreneurship are subsets of Saras Sarasvathy’s Effectual Reasoning model. The core of her idea is to use the dichotomy of causal reasoning versus effectual reasoning to analyse the differences between the established business decision making process and the entrepreneurial decision making process.

The short version is that entrepreneurs don’t begin with the causes or what they’d like to specifically accomplish and make (causal reasoning) but with what they can effect with their resources and skills and work from there (effectual reasoning).

Even shorter version: The reason why I have no interest whatsoever in print publishing is that I’ve been making websites for 16 years, did my PhD on ebook interactivity and have been working for several years now in software sales and marketing (ebooks are, IMO, for the purposes of sales and marketing, a subset of software).

Ebooks are the only subject that seem to tie together my interests, skills, experience and training. The reason why I don’t write about the role of print in these research notes isn’t because I don’t believe print hasn’t a future but that these notes are personal, foundational research on what possibilities there are for me to go in life.

Might not amount to anything. Consider this me thinking out loud.

One well-tested and currently popular software entrepreneurship model is Steve Blank’s Customer Development, built around four steps in a company’s buildup.

These definitions are taken from Brant Cooper’s “What is Customer Development?”

Each step is supposed to test and validate a business assumption.

Customer Discovery. Assumption: “A specific product solves a known problem for an identifiable group of users.”

Customer Validation. Assumption: “The market is saleable and large enough that a viable business might be built.”

Company Creation. Assumption: “The business is scalable through a repeatable sales and marketing roadmap.”

Company Building. Assumption: “Company departments and operational processes are created to support scale.”

You only exit each stage once you have proven and tested the assumption for that step. You don’t leave Customer Discovery unless you have some empirical evidence that your product “solves a known problem for an identifiable group of users”, for example.

Most people don’t see how Customer Discovery is relevant to electronic publishing but that becomes clearer if you rephrase the steps:

Step One: Formulate your hypotheses about what readers want to read, in what formats, at what prices, and where they’re likely to find them. Or: In what format and at what price is the book you have written (or about to write) likely to solve a problem for the largest number of readers.

Boredom, under-stimulation, and skills development are three problems books are good at solving. Throughout step one you test your hypotheses about the variables above.

This can be done by designing a landing page with a book preview that collects the e-mail addresses of those interested to be notified when the book is released (useful for establishing contact with readers for interviews, there’s a lot you can only find out from people in a phone interview). This test has the advantage of being easily iterated, given the right circumstances you should be able to test for interest in varying formats, prices, covers and titles.

An alternative test is to set up a simple ecommerce site and sell an early draft of the ebook (Minimum Viable Product, in Customer Development lingo) using e-junkie, cartloom or Big Cartel’s upcoming pulley app (if you’re lucky enough to be a beta tester). This has the benefit of giving you a large degree of certainty in your findings (since they’re willing to part with their money) but possibly has a lower conversion rate because a lot of readers aren’t willing to buy from an unknown ecommerce site.

The third test is identical to the second, but instead of using your own ecommerce cart, you do a low-key release of your book on the Kindle and link to that and rely on affiliate data to make up for not being able to track the checkout/sales process. Benefit: Possibly a more realistic test of actual market performance. No need to set up an ecommerce chart on your own site.

You don’t exit step one until you have gathered empirical evidence with a series of tests that leaves you reasonably certain that your format/price/book combination has an identifiable readership (if you don’t know who they are, you can’t sell to them). Surveys are also useful once you’ve started to form a picture of what your readership looks like.

Identifying the readership is, in my opinion, more important than tailoring the book for a specific readership (which is just causal reasoning). That’s why I’m not talking about testing variations in the book itself. The goal is to identify who actually wants to read the book and what formats, platforms and prices suit them, and, just as importantly, what sort of features or services your website needs to support.

The way to maximise the value of all of this research is, obviously, to gear it around testing for a series rather than a single book, but that’s a whole other research note to write, I think.

Step Two: Referring back to Brant Cooper’s overview of Custer Development linked above, this step consists of three things. 1. You have identified the target readership. Those of your identified readership that have encountered it are passionate about your book/series and you understand the core value that you are providing to them. 2. You understand how to market and sell to that readership and “have proven that every dollar that you put into marketing and selling your [book] results in more than one dollar back.” 3. Your target readership is large enough for the sales and marketing processes to be scaled up to a level where they can sustain a publishing business (which might just be yourself and freelance help, or might involve something larger).

In Steve Blank’s own words, step two or Customer Validation, is “where you develop a sales model that can be replicated and scaled.”

He also likes to say that “facts reside outside your building” so the only way to really find out what’s going on is to get out of the building and talk to customers.

Step one and step two are also iterative. You often find out in step two that you’ve got something wrong and that you need to go back to step one and reiterate the discovery/hypothesis testing process. That is good. Every time that happens you’ve discovered something important.

The core of step two is to figure out how to sell your book or series. It doesn’t matter whether it’s word of mouth, search engine ads, Facebook ads, direct sales/marketing tactics, the various possibilities need to be tested and measured and repeated. The only thing that matters is that for every dollar you spend, more than one dollar returns in sales and that the difference is enough for a sustainable and scalable publishing business.

Only when you have developed a process that can be repeated and scaled do you exit step two.

Also note that wide distribution immediately sabotages any hope you have of exiting step two. It’s hard enough to try develop a sales and marketing process for one platform. The Smashwords tactic of uploading one file and automatically distributing it to a dozen large platform is foolish, short-sighted and completely devoid of any sort of understanding of where and how people are supposed to find your book.

For step one and two, stick to only a couple or even just one target distribution platform. You can always scale up to wider distribution once you have tested and validated the basics.

Step Three: This is where you spread out to other distribution platforms. This is when you roll out support for the other ebook stores you hadn’t supported before. This is when you start investing, properly, in sales and marketing.

This is actually the first time you think about launching, pitching stories to the press, give interviews, etc.

Step Four: This is when the publishing house is actually born, when you shift your research and development efforts from discovery to providing the most value to your readership.

On quality in publishing

2010-10-06T16:00:00-07:00

If you do not know who the customer is, you do not know what quality is

The issue of quality in publishing has been on my mind over the last few weeks, culminating in a short twitter debate I had with Mike Cane yesterday on editing. ‘Quality’ isn’t a simple subject:

O’Reilly’s notions of what’s NOT important for publishing were surprising to hear. They’re shaped by O’Reilly’s formative experiences in publishing. He claims to fight the notion that publishing is about quality. His first books sold even though they didn’t have an index or an ISBN, or even a spine. They didn’t have pretty formatting, but they had good information, and they paid attention to the things that mattered for the job they were meant to do. In a book about programming, the code samples needn’t look good, but they do need to be correct, without extra spaces that break syntax. They were selling books for $5, and people would call up from Europe asking them to overnight a copy. (Go To Hellman: Philosopher Tim O’Reilly Lights Up Publishing)

Now we come to the heart of the minimum viable product issue: how can we build quality in if we do not yet know who the customer is? All of our professional standards that lead us to want to get it right the first time – all of them were developed originally in a non-startup context, one where the customer was known in advance. Startups are different, leading to this axiom: if you do not know who the customer is, you do not know what quality is. (Lessons Learned: Good enough never is (or is it?))

I’d like to repeat that last point: If you do not know who the customer is, you do not know what quality is. This ties in with O’Reilly’s quote above, as well.

In my earlier research note on incumbents versus innovators in publishing one point I repeated was that incumbents over-produce, they over-invest, over-engineer; they are tackling numerous problems and issues that have surfaced in the publishing process over the last few decades, some which may not be applicable any more.

The point there, and here, is that the incumbents will always dismiss the innovators’ products as rubbish, as being almost an insult to the customer, as something with no quality control or even intentionally ‘worse’.

Editing is one of the current bugaboos, it’s the incumbent’s shibboleth. The idea is being fostered, spread and promoted that nobody can or should get published without a one on one session with a professional editor; without the help of the high priests of publishing, the readers will hate you.

The problem with the ‘editing is a must’ viewpoint is twofold:

1. There’s no evidence that the readers care. The readers do care about sloppy formatting, crap designs, unusable metadata, missing covers and high prices, but judging by sales and online reviews, they don’t care about the editing. This is not a question of editing being an invisible art, but a question of obviously sloppy or non-existent editing in all major best-sellers (not a surprise) and in all major award winners (tripe like Franzen’s being the latest example) which aptly demonstrates the unimportance of editing. Having a book published with crap editing doesn’t lose you sales, doesn’t lose you readers and, as can be seen by the vast ocean of sewage that is literary publishing, doesn’t lose you the respect of critics or other writers.

Which brings me to the second half of the problem.

2. Critics don’t care. They love self-involved rubbish that wades around in the mulch of fleeting contemporary affairs, mayfly fashion trends, two-dimensional characters, and overwrought narrative structures, written in a language and style that only a creative writing professor can love. If this rubbish is the result of professional editing, the only sane thing to do is to gather up all those ‘editors’ on a desert island and nuke it ‘till it’s glass.

None of the above matters, it’s irrelevant because editing in its current form is going to go away, because you can’t have editing as a functional part of the publishing infrastructure and low ebook prices, both at the same time.

Cheap or edited, pick one, and the market has already chosen for you.

Economics, margins, market forces will mean that, as I’ve said before, quality will solely be determined by the writer’s ambition and efforts and the readers’ demands.

Mike Cane responded, I commented, and I figure I might as well add the comment here:

Don’t put words in my mouth. I don’t like most of the stuff published today, but I didn’t mention all of those in my post. I mentioned literary fiction for a specific reason: Their endemic flaws, structure, language, characterisation, are specifically the problems an editor is supposed to solve.

The point with the two quotes in the post, one from O’Reilly and one from Eric Ries on software product development is that “If you do not know who the customer is, you do not know what quality is.”

The discussion on editing in publishing and self-publishing centres on the idea that every book needs to be edited, that it’s a basic requirement of passing some sort of abstract bar defined by publishing incumbents.

But as the two quotes point, and as you point out, out the sole determinant of quality, of what is good, are the readers and their tastes.

And they plainly care less about it than they do other issues, metadata, covers, design, formatting errors, pricing, and such. I don’t see any evidence in the market that a book that has got the full editorial treatment is any more likely to be accepted as good by readers and critics than a book where the publisher spent most of their resources on PR, marketing and design instead. Which, incidentally, is cited as one of the reasons why Douglas Rushkoff changed publishers: Publishers weren’t doing any editing, so he decided to go with one that got the book to market quicker.

Final addendum:

First, I’d like to note that I’m specifically talking about fiction publishing here and the more wishy-washy kind of non-fiction (that is to say, most of it). I’m not talking about technical publishing which benefits enormously from detailed and thorough technical editing.

One thing people are missing is that I’m not just saying publishing won’t be able to maintain an editorial infrastructure when prices and revenue go down. One thing that appears again and again as I do my research into the business processes of publishing is that the value of the editorial infrastructure is largely unproven.

If neither critics nor readers care, and it has no proven ROI, then a new publisher who focuses their resources on PR, sales, marketing, error correction and design, will economically outperform the publisher who does all of those things as well as editing. They’ll have lower margins and make more profit on the same revenue as their old-style editing counterparts.

Continuing with business processes that have unproven ROI and a completely subjective impact on quality is nothing more than superstition, magical thinking of the worst kind. ‘Tradition’ isn’t a business-level argument, and sticking to it for its own sake will lead to nothing more than bankruptcy.

Of course, a lot of writers and artists recoil in horror and disgust when presented with business and efficiency arguments of any kind, and retreat to abstract, literary arguments, but that’s also the reason why publishers will continue to exist and why the future won’t be dominated by self-publishers.

Identifying publishing innovators

2010-10-06T16:00:00-07:00

Changing dynamics

Some thoughts on publishing innovation, largely based on Clayton Christensen’s writing on innovation in the tech industry and personally informed by being a part of the software industry.

Raw notes. Shitty first draft. Etc. You have been warned.

Part of my effort to find my path forward, both in my personal life and in my career, I’ve spent some time thinking about what an innovative publisher would look like. Identifying some characteristics of an innovative publisher is a first step, a thought exercise to try and create a conceptual image of something that I don’t believe exists yet.

And if this mythical beast does roam in the wild, publishing a description is probably the best way to have it pointed out to you.

As such, these notes, random as they are, lean heavily on Clayton Christensen’s writing on innovation, specifically on his notion that the innovator is targeting a group of customers that have been overshot by the incumbents.

The idea is as follows: The incumbents, through years of development and quality control, have built up a set of processes and products. The innovator undershoots the incumbent by targeting an undesirable (to the incumbent) audience (to cheap or not interested in the incumbent’s over-engineered product) or is believed to be non-existent (nobody’ll buy that or tolerate it). The innovators develop newer processes, new distribution channels and new products that target this product segment and then builds upwards, growing market share. By the time the incumbents see what is happening they cannot respond and often don’t want to — a common reaction is to cede market share and flee to a higher margin segment.

The publishing industry is being transformed as we speak, but I don’t think we have any true innovators yet.

The incumbents are following the incumbent playbook to the letter. Their attempts at entering the ebook markets consists solely of integrating ebook technology into their already over-engineered, over-costly product development processes, and the few times they put any unique effort into their ebook developments they go straight for the high-margin, high-perceived value ‘enhanced’ and ‘expanded’ market.

If this is the incumbent playbook, what would the innovator’s look like?

Publish first, correct later

In a world where both the Kindle and Apple’s iBooks allow the reader to re-download an ebook, the innovator avoids hiring copy editors or proof readers, instead relying on a small group of beta testers/readers. Whatever errors and mistakes that slip past the beta readers are corrected when found or pointed out and the ebook re-uploaded.

Unlike the incumbent’s the innovator’s ebook is likely to be published with more errors. Unlike the incumbent’s the innovator’s ebook will be corrected throughout its available lifetime and the corrections will almost entirely just be those the ebook’s audience values, while the incumbent strives to do, beforehand, all of the corrections the audience is perceived to value. The innovator promises updates and follows through on those updates. They include a notice and a link in the ebook that gives the reader the opportunity to subscribe to e-mail notices of when the book is updated (even if they then go to the Kindle or iBook to do the actual update).

Over the lifetime of the ebook, the one published by the innovator will be a closer match to the quality expectations of the innovator’s market segment while the incumbent’s will overshoot the expectations of most of their market segment while still failing to meet the demands of the high-margin, high-revenue audience it is trying to flee towards.

Digital only

At the margins and prices the innovator targets print publishing is simply not an option except in special edge cases. The dual-track process of developing a book for both print and e- will not only be seen as unfeasible by the innovator but as border-line insane and the idea met with the same kind of incredulity as a suggestion to a hamburger stand owner that he should expand into serve Kobi Sirloin Steaks alongside their cheap, greasy, post-pub-crawl-special heart-attack hamburgers.

The innovator only does print as a special edge case and doesn’t develop any in house processes or overhead to manage its development. This enables the innovator to keep prices low.

Low, low prices

The prices set by the innovator are so low, the incumbent fervently believes that they are either sold at a loss or subsidised by some other revenue source. The incumbent simply does not believe that an acceptable product can be made for that prices with any process. The low prices, enabled by simpler, fewer processes, enables the innovator to reach a market segment despised by the incumbents as either too stingy or too greedy. The incumbent is likely to believe that catering to this market is not only unfeasible but threatens to destroy the viability of the entire industry (because they don’t believe it can be addressed sustainably). They don’t see the innovators as competitors but as saboteurs, huns at the gates, barbarians, savages without reason or sense.

Template-driven designs

Innovators will embrace the path taken by the web industries and base their entire work-flow on template-driven web technologies. Rather than giving each book a custom design, each line of books has a programmatic design template. Some innovators will base their entire publishing pipelines on the epub export output from Apple Pages without ever touching anything more complicated or involved.

The covers will harken back to the tradition of Penguin paperbacks, grid-driven, stylised and standardised covers designed first and foremost to be seen at the small icon-like sizes seen in the book listings in the reading applications. The first innovator to hire a good software icon designer do develop a company-wide cover template will be seen as a pioneer and hated for debasing the industry.

Diverse marketing

Each innovator is an explorer of their particular segment of the market, one size does not fit all, and the innovator marketing processes will be as diverse as there will be innovators. Each innovator will develop and build up specific processes that are effective at reaching their market.

Under-engineered

Where the incumbent spends a small fortune to develop an interactive book application or, if that ever becomes possible, an equally expensive scripted and dancing HTML5 epub, the innovator uses the plain old hyperlink to shunt all interactivity and dynamic behaviour to where it belongs and is more cheaply developed: on the web. When scripting is available the innovator will use it simply and functionally, always preferring to put interactive components on the web rather than in the book where it complicates the testing and expense by an order of magnitude. The innovator embraces the anti-design characteristics of the ebook market and saves their aesthetic energies for the cover design and illustrations.

The writer’s voice, crap as it may be

Innovators publishes the writer’s text mostly as given, preserving the idiosyncrasies of the writers voice. Mistakes, stylistic errors — even what most publishing incumbents would call bad writing — that the writer doesn’t care about and the readers don’t complain about, should not be fixed. They let crap writing pass in blockbuster books anyway. Quality should be determined solely by the writer’s ambition and efforts and the readers’ demands.

That’s all I can come up with so far in this shitty first draft.

An interesting discussion

2010-06-27T16:00:00-07:00

Twitter stage fright

You wouldn’t think that you could get stage fright in anticipation of a twitter discussion but last week proved that I can. I had the immense pleasure of being asked by Lindsey Martin to talk about interactivity for ebooks as a part of #ePrdctn hour.

It was a lot of fun to be able to discuss a subject I’ve researched for years and years with people whose practical knowledge of ebook production and design vastly outweighs my own.

The resulting discussion, as a result, struck a balance between theory and practice, which was all the more interesting an achievement given the limitations and constraints of twitter as a medium and a testimony to how interesting the online eproduction community is. That said, my summary below leaves out some of the discussion to make the write-up easier to follow, but you can find the entire unadulterated thing over here.

In any case, the discussion follows, loosely edited. My crimes against grammar remain, mostly, intact. Eeeeeextreeeme Interactivity.

Okay, #ePrdctn hour here I come. I’m here to talk about interactivity for, in and surrounding linear ebooks. There is a lot of prior art, for those who are open-minded and curious, e.g. Voyager Expanded Books + a lot of the web. But I’m just going to dive in with some practical concepts you should be able to apply today in your work.

First: Content Interactivity. This ranges from embedded video to interactive infographs to sortable tables. Anything in the main text. Content Interactivity is problematic in epub/kindle but almost doable. It’s also the preferred pig-lipstick :-) used to flog enhanced ebook apps. It is also the kind least suitable/most problematic for those publishing both in print and in E; you end up forking the work.

Hyperlinks are a part of the text and need to be a part of the authoring process from very near the beginning. Print tools aren’t designed for authoring hypertexts and are liable to make life difficult. Any text that has interactive main content is a hypertext, even if it has a print version as well. In fact all text is hypertext, just most happen to be linked in a linear order, but that’s a diff subject :-D. Anybody with an interest in CI needs to at least consider web tools or a serious hypertext writing tool such as @eastgate’s Tinderbox. With a real hypertext tool multiple link types and multidirectional links (think “return to …” links) are much easier.

For video there’s a thousand years of design precedence for how to embed it in ebooks. Every time there’s been an image laid out with text from the scroll onwards there’s a source for video embed design inspiration. Until you can do something like an animated dropcap with a transp. alpha channel, video in ebooks will be fairly toy-like.

The gold standard for interactive graphics these days would be dynamic online overviews of election results. But coming back to the subject of ‘static’ interactivity. Don’t underestimate how much of the programming can be pushed to the edges.

Second. Framing Interactivity [FI]. Any kind of widget, hyperlink or UI that brings context into the frame of the work. Classic FI examples are comments on websites, “share this”-type buttons, related links or Kindle popular highlights. Although, a link can be any kind of interactivity depending on its use, As @eastgate says, the link is just a new punctuation mark. Framing interactivity — discussions — can take on many more forms than just the typical blog-style comments. Discussions can be Tufte-style curation where, as soon as the moderator gets a new comment that makes a point better than an old comment the mod drops the old comment, resulting in a highly readable “best of the best” thread. (See “Ask Edward Tufte: Moderating internet forums: What’s smart, not what’s new”). Other kinds are ‘Talking Stick’ discussions (only those with the token can speak). Queued (only speak when it’s your turn).

Framing Interactivity isn’t about inviting people into the text but to provide the text with a fluid boundary that forms a context. Think of a painting’s frame. It affects your interpretation of the painting but even if it was made by the painter it’s usually not studied as a part of the work itself, no matter how influential or vital it is.

So Content Interactivity and Framing Interactivity. Main text and context. Now for the third main type.

Third. Deconstructive Interactivity [DI]. Any UI that breaks the text apart and represents it in an explorable form. You’ve seen and used Deconstructive Int. more than you think. Search is a classic example, as is Amazon’s Search Inside the Book. A publisher that has its entire backlist in a structured XML format could and should offer structured search of all of its books. Search in dialogue. Search in dialogue by this character. Search in text set in X location. Search character descriptions … … And the search results can have Framing Interactivity of their own where they could be shared, discussed, etc. Comparative search results: Search for the same term in the dialogue by two different characters.

The good thing about DI is that you can implement this today, full speed ahead and damn the ereaders! Do it on your website. You could offer various deconstructions on your websites for potential buyers to explore and try out. Possibly even planting easter eggs that, if found by explorers, gave them a discount. The biggest thing holding Deconstructive Interactivity back ATM is the difficulty with linking directly into ebooks. But even though that prevents a lot of Awesome from being implemented it doesn’t prevent all Awesome, if you know what I mean :-). You could have character profile pages, subject pages, that are dynamically generated from the book backlist XML files.

The book has always been a social app — the only question with ebooks is whether and how you want to formalise it. Final point: Books are discussion totems, they encapsulate a debate, vantage point and group of people into a social object.

Q: crych: Would you agree that footnotes, references etc. in print are ‘hypertext’ even if static? A: Absolutely. Hypertext doesn’t have to be programmed or dynamic. Nor does interactivity in fact.

Q: eBookNoir: wht do U think of the interactive component of haptic feedback that i C sum readers R coming out w/, will it help? A: Haptic feedback has potential + anyt that uses our sense of touch, which is something underappreciated in new media.

Q: MatthewDiener: Would you consider chunking & recombining/mashing up different books as Deconstructive Int.? A: Absolutely. And the mash-up can be intra-series. A structured search, mashup or whatever over an entire series.