Separating form from content: when is a book a book?

April 5, 2011 | 1 comment

NOT one of THOSEFor what it’s worth, this blog is now available over on the Kindle Store for the Amazon-imposed price of $1.99 a month.

Of course, if you do decide to read it on your Kindle, you’re going to lose the standard form of a blog: the distinctive page shell, the list of posts, and probably the comments. Just like if you read it in Google Reader or any other news application. If someone links to this article on Twitter and you use a magazine app like Flipboard on your iPad, you’ll also have a completely different experience. Same exact content; different layout depending on your circumstances.

For reading consumers, this is a significant advance. Circumstances do change: what’s convenient for me to read in bed is different to what’s convenient at the office, on a train or spending ten minutes in a coffee shop. Each of those may require different devices, different software applications and different settings depending on what I’m doing.

For these reasons, software developers and web designers have been used to separating form from content for years. Model-View-Controller is a commonly-used software design pattern that separates data (the model) from both logic (the controller) and visual interface (the view) in a system, ensuring that each can be changed without affecting the others. Now that content is moving wholeheartedly into the digital arena, it makes sense for it to harness some of the same ideas. In a book, the words might be the model, the typography and layout might be the view, and the physical framework of the book itself might be the controller.

That opens publications up to a kind of remixing they’ve traditionally been insulated from. Geeks who love Hacker News but find the interface hard to read can install Georgify to make it more typographically palatable. People looking for emotional inspiration on Twitter can spend a couple of minutes with Twistori, an app that pulls out certain tweets and displays them in an appealing, emotionally resonant way. Mostly these kinds of things have been impossible with Wuthering Heights or The New Yorker.

There are a lot of people, I know, who love the form of books, and who are frightened of that changing, ever. And it won’t: there will always be books. But digital technology gives artists the power to explore new forms for content, that can be disassociated with the content itself and applied, again and again, to different words, in order to create whole new works. If your Twitter stream can be a book, then a book can be a real-time application, or fragments scattered in time and geographic space, or anything you can get your head around. And anyone can remix, and reskin, and make the form – as well as the content – have a life of its own.

If you’re in London on May 14th, Book Hack Day will cover some of these ideas. Regardless, I’d love to read your hacks and play with your words. I think there are many possibilities, and I’m excited to explore them.

Devices and desires: why the portable device wars are a red herring

June 3, 2010 | 3 comments

A little pre-history

When I was a kid, I had an Atari 130XE. You’ve probably never heard of it. It was an 8-bit, all-in-one box that booted straight into BASIC; a flexible, well-built, sturdy computer.

There was just one problem: it wasn’t a ZX Spectrum or a Commodore Amiga.

At the time, Britain was undergoing a low-budget computing renaissance. Bedrooms up and down the country were filled with skinny boys (and yes, it was mostly boys) noisily loading games from cassette tapes and dutifully copying down source code listings from specialist magazines. The two engines of this renaissance were the Spectrum and the Amiga, and as such, the games, the tutorials and the social infrastructure were built for these two machines. Perhaps this helped me become more of a creative self-starter: I wrote my own games and stories instead of consuming other peoples’.

Later on, 16 bit computers became popular, and everyone upgraded to the Atari ST: a home machine powerful enough for creatives and musicians, but cool enough for game-playing kids. Except, perhaps inevitably, we had a PC. Running DOS. With a black-and-white Hercules display. Great if you wanted to plug economic figures through a spreadsheet, but lousy if you were a twelve-year-old who was mostly interested in playing The Secret of Monkey Island. Not only was the wholly PC incompatible with the Atari ST, but the PC was actually incompatible with itself: a game that worked on PCs with an EGA or VGA screen wouldn’t work with CGA or Hercules. Back then, the parts inside your computer were at least as important as the operating system you ran or the software you bought.

Plug and Play

Through heavy force and heavy lifting, Microsoft changed all that. Windows 95 was the first widely-accessible operating system that unified hardware platforms. Sure, you had to have an Intel-compatible processor, and it took them a while to get it right (for a while the system was redubbed “plug and pray”), but you didn’t have to mess with configuration files to get your computer working. This was a Big Deal.

Today, we’re used to not having to tinker with our machines. Windows will adapt to just about any hardware you throw it at, and even Linux has become an easy-to-use operating system (relatively speaking).

Better yet, we have data portability: in my house we’re running Windows 7, Mac OS X and Ubuntu, and I can move my documents between them interchangeably. Thanks to the web, and Java before it, we even have applications that don’t care what kind of operating system they run on. For an end user, things just work. That’s exactly how it should be.

Finally, computing is simple, data is interoperable and consumers are in control.

Uh oh: enter the portables

So just as we get a unified computing platform that’s easy to use and relatively simple for consumers to navigate, in comes a new device market that’s as fragmented and consumer-unfriendly as the computing market was in the eighties.

Android. iPhone OS. Windows 7 tablet edition. Windows Embedded Compact. Windows Phone. WebOS. ChromeOS. Kindle OS. Whew! It’s like 1986 all over again.

As a publisher or developer, figuring out which device to build for is a headache. Each one has a different operating system, possibly a different app store (something nobody had to worry about in the eighties), and a different set of underlying technologies. Do you exploit the iPad’s current success and develop for the locked-down Apple platform? Do you take advantage of Amazon’s huge built-in market and write a Kindle app? Do you hold out and wait for HP’s exciting-looking WebOS-powered tablet (which caused a storm recently by publicly moving away from Windows)?

Plug and Play (again)

The truth is, market forces are going to apply the same pressures to the mobile market that the personal computing sector felt in the early nineties. This story has played itself out several times now: one platform will emerge victorious. Judging by the lessons learned by IBM with their Personal Computer architecture, and both Microsoft and Linux for operating systems, it’s likely to be one which is:

  • Open: anyone can add it to their system for little cost, allowing hardware manufacturers to maximize profits by concentrating on the device itself rather than the ecosystem around it
  • Sustainable: it’s powered by a solid business ecosystem that will ensure the longevity of the platform
  • Friendly: it’s a system for everyone, not just hobbyists or developers
  • Flexible: it can be used in multiple contexts, from living rooms to science labs

By this measure, Apple is condemned to be a niche player, operating at the premium end of the market. Sure, right now technophiles everywhere are salivating over the iPad, but that will last until someone comes out with something nicer. In any event, Apple’s grasp is limited to the wealthier western nations – there are far more people seeking more affordable devices waiting in the wings in other places. The third world computer revolution is very much underway.

My bet, of course, is on web technologies. But it isn’t necessarily on the Internet: it’s time we separated web technologies from the World Wide Web. Indeed, connectivity isn’t ubiquitous, and isn’t likely to become ubiquitous world-wide for a very long time. Therefore, the ability to download, install and run apps offline, as we always have with software applications, is incredibly important.

With its Chrome Web App Store, Google is leading the way, and showing that it understands what it takes to create a next-generation application platform. It’s also shown leadership over HTML 5, which it is clearly investing in as a genuine method for powering both content and software. The genius is this: anyone can build using web technologies, and web technologies can run on virtually any hardware. Google makes its money through value-added services, like advertising (to allow both device manufacturers and software developers to supplement their incomes), its app store and underlying logic via some powerful APIs. It’s not an operating system, but for most end-users, they’re making the operating system irrelevant: it’s simply the thing that runs the web browser.

My advice: ignore the hardware

Computers as we know them today will always exist, but they won’t be for everybody. If you’re developing for non-technical end users, the plethora of hardware devices available to you is a red herring. You should be thinking of the web as the platform your products will be based on. Make no mistake: you need to become an expert in web technologies now – or, of course, find someone who is.

Images:

So why do we need apps anyway?

April 29, 2010 | 3 comments

Ebooks don’t cut it: everyone wants an app

NB (May 20, 2010): A lot of my suggestions for web-based apps are part of the Google Chrome Web App Store. In fact, the .crx file used there is a zip file with very similar characteristics to epub. (I assume, as Chromium is open source, that .crx files are also open source – so the web app store is not limited to Google.) This post can be reread as an argument for building for the Web App Store.

At Intersection: Publishing in London the other week, there was a lot of discussion from publishers looking at mobile apps as their mobile publishing solution. Rather than creating ebooks, there seemed to be a general feeling that dedicated applications presented more of an opportunity for richer content, while closing the door to pirates and ensuring that publications remained a paid commodity.

The piracy argument is kind of spurious: although app stores tend to be locked down, this presents a false security blanket for publishers. It only takes one person to crack a store for piracy to be generally possible; technology only ever becomes less secure over time. A cynical person might suggest that the piracy argument is largely spread by the people who own the app stores or provide related services. The people who will suffer are authors and publishers.

Why apps rock

However, there’s definitely an argument for using apps – not just for publishers, but for anyone who wants to create dynamic content. Anyone who’s ever owned an iPhone will tell you that native applications can still provide a smoother, more consistent experience than a web app, without the hassle of remembering website addresses or waiting for pages to load. Tweetie is a million miles better than Twitter’s mobile website – something they themselves acknowledged when they acquired the iPhone application last month.

Mobile vs app

Above, mobile Twitter is on the left; Tweetie is on the right.

  • The app doesn’t need to load its interface from the web; only the underlying data is downloaded, meaning the app can appear instantaneously, loads data faster, and provides a better user experience.
  • The mobile web app needs to sit within the browser chrome (URL and search boxes, browser buttons on the bottom, and in my case, a debug toolbar). The app, on the other hand, has a full-screen UI dedicated to Twitter.

Why the web rocks

The mobile landscape right now is a bit like the personal computing landscape circa 1985. There are a bunch of different platforms to code for:

  • Apple iPhone and iPad
  • Android
  • Symbian
  • Windows Phone
  • Blackberry
  • WebOS (now more important in the wake of HP’s acquisition)

Each of these platforms is different under the hood, and must be developed for separately. Most developers and publishers can’t afford to do this – there isn’t a way to write once and cross-compile to many platforms at once. In fact, Apple recently specifically forbade this: if you’re developing an Apple app, you’re doing so natively, or you’re violating that platform’s terms of use.

However, each of these platforms have one thing in common: they support the web.

HTML5 and ePub: a new platform for apps

As you’re probably aware already, the upcoming HTML5 standard revises the web platform to become far more suitable for apps. Improvements include:

  • Methods for offline and cached usage (so interfaces can load immediately)
  • Built-in databases and storage (so web pages can natively store their own data)
  • A paintable canvas element and WebGL 3D graphics functionality (so web pages can display interfaces more like real applications; the 3D shooter Quake II has already been ported to native HTML)
  • Native video and audio support (no Flash required)
  • Websockets (a more efficient way to connect to Internet data from web pages)
  • Built-in support for advanced functionality like geolocation

This is a big deal. Compliant browsers like Firefox, Safari, Chrome and even the upcoming Microsoft Internet Explorer 9 will be able to run applications that look and feel like native software but are powered by web standards. Between those browser engines, that’s most of the mobile platforms covered: those that don’t have an HTML5 browser built in by default should have one available to download. What’s more, both Firefox’s Gecko HTML rendering engine and the WebKit engine that powers both Chrome and Safari are open source, so anyone can pick them up and build software around them.

So sites on the wider web can be more like applications. That’s fantastic news in itself, but what about the app store model? A lot of people depend on that for revenue, and there’s no reason why that should be incompatible with using web standards.

Luckily, it turns out that ePub – the ebook standard – is really just a bunch of XHTML 1.1 pages drawn together in a specialized way and bundled up in a modified zip file. There are already established best practices for buying and selling ebooks.

If the ePub standard was updated to allow HTML5, it would evolve into a format for self-contained, multi-platform apps that could be sold in the same way as ebooks, music, videos, or apps in something like the iTunes App Store. Except app publishers would only need to build once to support many different kinds of mobile platform, thereby reducing the barrier to entry and allowing their budgets to be concentrated on building just one really awesome piece of software instead of spread across multiple devices.

This would be in a lot of peoples’ interests: app publishers, device manufacturers, browser vendors and consumers alike. There’s a lot of money tied up in a venture like this. The only question is, will the International Digital Publishing Forum, which controls the ePub standard, be foresighted enough to see this opportunity?

Update: Steve Jobs weighs in

Apple’s CEO has written a little about why HTML5 is the future of mobile apps (albeit in the context of his platform’s refusal to support Flash):

HTML5, the new web standard that has been adopted by Apple, Google and many others, lets web developers create advanced graphics, typography, animations and transitions without relying on third party browser plug-ins (like Flash). HTML5 is completely open and controlled by a standards committee, of which Apple is a member.

[…] Flash was created during the PC era – for PCs and mice. Flash is a successful business for Adobe, and we can understand why they want to push it beyond PCs. But the mobile era is about low power devices, touch interfaces and open web standards – all areas where Flash falls short.

[…] New open standards created in the mobile era, such as HTML5, will win on mobile devices (and PCs too). Perhaps Adobe should focus more on creating great HTML5 tools for the future, and less on criticizing Apple for leaving the past behind.

Make no mistake: HTML5 is the platform to bet on.

The future of publishing

April 18, 2010 | 1 comment

Intersection: PublishingThanks to everyone who came to Intersection: Publishing yesterday. Our fascinating round-table discussion was cut off far too soon: I think we could have gone on for days and only barely covered the issues. It’s clear that an open conversation that treated publishers, authors, readers, technologists and lawyers as equals was long overdue. (Missed it? Watch this space.)

I thought I’d write down some of my takeaways while they’re fresh in my mind:

DRM is misunderstood from both sides.

From some publishers, support was shown for Apple’s locked-down App Store business model, with the assumption that it would prevent piracy. Of course, this isn’t the case. I think Sven Edge put it best to me during the post-debate drinks: “any technological system only becomes less secure over time.” In other words, you cannot assume that any technology is unbreakable; someone will do it. Trusting your business model to DRM is therefore a very bad strategy.

Publisher advocacy of locked-down Digital Rights Management technologies apparently occurs because authors need to be reassured that their work won’t be stolen when it becomes available online. A few authors present disputed this point of view. Regardless of this, more work needs to be done to educate non-technical people around the issues, in a calm way that takes in all points of view and doesn’t attempt to reform the fundamentals of copyright law or rights agreements in the same breath.

The market for electronic publishing is still too fragmented.

Many publishers present were worried about the variety of devices and platforms present on the market, as well as their quality. They simply can’t afford to target all of them, and many are either choosing to wait or work with third-party companies to develop solutions for them. All agreed that a single, open platform that allowed publishers to create content using something approaching their existing skill-sets is desperately required.

There also needs to be an open equivalent for apps, to give publishers a choice, and to allow them to deliver to multiple platforms at once. During the debate, I suggested encapsulating HTML5 (which has all manner of app-friendly capabilities) in the ePub format (which produces stand-alone bundles of content that can be sold and transferred between devices). I intend to write more about this another time.

The publishing industry is following the patterns laid out by the music industry.

On the future of publishingPublishers are signing authors rather than books, and are beginning to gather extra revenue through talks and activities surrounding books, just as – for example – musical artists like Madonna are beginning to sign to concert promoters rather than traditional record labels. Together with the DRM arguments above, I think there’s a real danger that the publishing industry could go down exactly the same road. (On the topic of DRM, note that iTunes is now DRM-free – don’t count that any restrictions on iBooks or App Store items will last forever.)

The knowledge gap goes both ways.

The assumptions that geeks take as being gospel are not gospel. The assumptions that publishers take as being gospel are not gospel. Each side needs to listen to the other and contribute to a productive conversation, without demeaning anyone’s expertise or experience. There needs to be both give and take.

To put it another way: the models that govern software do not govern publishing and the models that govern publishing do not govern software. These remain two different businesses, and must be treated as such.

There was some very heated debate yesterday, but also a great deal of very constructive argument. I’m really looking forward to continuing the conversation.

Next Page »