In the last article in the Publishing for Tablet series, What You Need To Know About iOS and Android, we discussed which tablets and operating systems a publisher should target. Now that we’ve got that out of the way, it is time to tackle the more juicy problems.
Today’s question: How the dickens can I get my content to fit onto tablet screens and enhance my content using the wonders of digital, while retaining a production workflow that doesn’t break the bank? Well, it turns out that not all content is created equal -- let’s look at that first.
Flowable Content vs. Fixed Form Content
Some content flows. It is easy to imagine how flowable content can fit on to a screen of any size in any orientation. The content (the words, pictures and videos) is what matters. The layout is arbitrary. Some content doesn’t flow. The content and layout are conjoined at birth, designed for a certain size page. Adapting this content for different orientations and aspect ratios is far from easy.
In my world, we crudely separate publisher into books, newspapers and magazines. In each of these categories, you can find publications that flow, and some that don’t. Here are some examples:
|Books|| Most Children's Books |
|Magazines||Most Glossies||Most Journals|
|Newspapers||Most Tabloids||Most Papers/Broadsheets|
Competing Production Workflows
Fixed-form content is typically produced using desktop publishing tools (such as Adobe InDesign) as part of a print-centric workflow. If the content does need to be repurposed for another page size or orientation, it is normally a labor of love for the designer, which becomes expensive quickly. Many of the existing iPad magazines currently have a workflow that involves laying out the magazine three times -- one for print, one for landscape and one for portrait. Some publications that started supporting both landscape and portrait have already dropped one to reduce the production costs.
Things will only get worse as more devices arrive. The iPad has a 4:3 aspect ratio. Many new tablets are 16:9 or 16:10, so the content won’t fit if you want to use all of the available screen real estate. One common solution to this is “letterboxing” the content so you can reuse your 4:3 content. In addition to this, there seems to be growing consensus from the user experience camp that there are four form factors that each need different treatment -- smartphones up to 5”, small tablets up to 7”, large tablets up to 11”, and then the big monitors.
Flowable content is, theoretically at least, more suited to a multi-channel workflow. Words, images and video can be added to a structured repository, and combined with layouts and styles later in the process. However, some publishers still consider all their content to be fixed-form, even content that is blatantly flowable in the eyes of a non-designer like me. If we can’t even convince these publishers to let go of the “print layout Is sacred” mentality, we have a mountain to climb if we want to convince the other class of publications to go with the flow.
As CMSWire readers will know, it is the multi-channel workflows that require a good content management system. More on this another time, but for a great insight into the systems used by some of the larger publishers, have a read of The Trouble With Back-Ends -- CMS woes: Why publishers can’t publish on the Web by Erin Griffith. Except for the part where she writes, “There’s no such thing as a CMS success story.” That just means they’ve hired the wrong tech team.
It’s decision time. What data format should I use to render my content on the device? The common choices out there, ordered from least to most flowable, are:
- Static images -- used as the base for many of the popular systems out there, including Adobe DPS, Woodwing and others; these can be “enhanced” by creating interactive elements that sit above the image, but they are fundamentally fixed, and the file sizes are BIG
- PDF files -- not much different to static images, but harder to make interactive as nobody wants to write their own PDF reader
- Native text engines (e.g., iOS Core Text) -- these can look nice and include semantic data, but layout involves a lot of custom development; a lot of the early newspaper applications followed this path
- HTML / EPUB -- the future of flow layouts, advocated by, well, pretty much everyone; can be embedded into native apps using the embedded browsers (EPUB 3 is really just an HTML container these days)
Writing an adaptive layout engine is difficult. The best layout engine in the world is WebKit, a shining example of an open-source project that includes contributors from Apple, Google, Nokia and, more recently, Adobe. WebKit powers Safari, Google Chrome, iOS, Android and more.
Adobe’s contribution to WebKit is interesting, as it signals its obvious intent for its dominant production tools to output HTML markup at some point in the future. It started this when it released Adobe Wallaby, a Flash-to-HTML converter. It has just released Adobe Edge, a production tool for creating HTML/CSS animations using a timeline interface similar to those Flash developers would be used to. And its WebKit contribution, CSS Regions, is a step in enabling a functional HTML export from InDesign.
Adobe is a smart company, and makes its cash by selling production tools. It knows HTML is the future, and wants to make sure that it makes the best HTML authoring tools in the world. And it is working hard on solving one of the most difficult problems around -- creating a tool that can be used like InDesign but that outputs flowable content for various page sizes.
As a publisher, you want your content in HTML. Simple as that. But there are two big hurdles we need to overcome:
- Publishers need to be educated -- fixed form content cannot last forever, and the sooner they embrace variety, the better off they will be
- The production tools need to mature -- this is happening fast; Adobe Edge is one example, and Sencha Animator and Tumult Hype are two others
Easy. Next time, I’ll talk about the options you have when writing your app to showcase your beautiful HTML content, and why writing a pure web application isn’t as easy as it sounds. Don’t believe me? Read Anatomy of a HTML5 Mobile App by @fling while you wait.
Till next time.
Editor's Note: You may also be interested in reading: