I think we’re missing a trick here. With 2010 being the Year of the e-Book, (or, at least, the Year of the Please Apple Release The Tablet Please We Beg You), most of the design work that is doing the rounds is around the interface: BERG’s beautiful work for Bonnier is a great example. We know that a device with a colour HD screen, an always-on connection, GPS, sound, video and so on will give magazine designers all sorts of new toys to play with. From a content-designer’s point of view, I couldn’t be more excited.
From a publishing standpoint, too, e-books are thrilling: the dirty jobs of printing and distribution fall away, replaced with an upload to the iTunes store – or the publisher’s own – and a direct billing relationship with the client. For advertisers it will offer all of the advantages of web advertising with the rich-media and contextual advantages of appearing within a publication, so for a skilled ad-sales team it’s sure thing, and with the Great Media Crisis entering its second decade that sort of talk is catnip to a big media company like Bonnier, or (the one I work for more often) Condé Nast.
But while BERG’s work, and other pieces like it, are beautiful to see, they leave me very frustrated. The client-side development is very exciting to do – especially the systems-thinking that you need to do to take the entire customer journey from browsing to buying to backing-up – but the harder work, the more fundamental work, isn’t done. I’m talking about the editorial workflow. Bear with me.
At the moment, the average magazine is made from a combination of Microsoft Word, Photoshop, In-Design, shared-drives, and PDFs sent to the repro house. As each step of the analogue production process has been replaced by a digital version (film photography to digital, for example) that bit has been swapped out and replaced. The upshot is that we have accidentally efficient production processes that are optimised to getting a print magazine out of the door every four weeks or so. When you then try to put that magazine onto the web, as we do with WIRED every month, the process is mostly cut-and-paste. This is one of the reasons why magazine websites aren’t very good: you lose so much simply because of the way you have to get the content from one medium to the other. The rest of the content you never had in the first place (for example because the original copy wasn’t written in HTML, and so doesn’t have links in it.)
With e-books, and especially with e-book concepts, the stories are published with the implication that the system knows a whole load of stuff that a print magazine doesn’t. The articles are written in hypertext, they have location data and subject cataloging, there is associated video and audio and additional photography, and so on. For a magazine title that is made entirely and exclusively for the e-book format, that’s not a problem. For an existing title trying to make the transition from paper through web to specialised digital device, it’s a show-stopper: the workflow at British Vogue, say, can’t handle it today. Neither could WIRED.
So a real design challenge for e-books isn’t to design the user experience (which is dependent at the end of the day on the device capabilities anyway, which are pretty much unknown) but rather on designing a system that would allow existing publishers to transition their operations from ramshackle print to All Knowing Digital. We already know much of this: you can take the lessons from blogging CMSs, add in photography handling from places like Photoshelter, combine metadata collection from sources like Google Maps and OpenCalais, and version control from Git, and you’re halfway there. Combine it with process changes, where you require writers to file direct to a system that forces them to add in metadata for example, and you’re closer still. Of course, in two sentences I’ve described a process that really encompasses the whole old-media crisis, but I do think it’s a challenge that can be met. In later posts, I’ll talk about how.
