Bring on the browser books

This content has been archived. It may no longer be accurate or relevant.

From The Bookseller:

I’d like to start this month’s editor’s musings with a personal rising-from-the-ashes anecdote.

One of the other jobs I juggle alongside my role at FutureBook involves being Digital Editor for PHOENIX, a six-year-old fashion and culture magazine. At the core of PHOENIX is a bi-annual print magazine: 200-odd pages of long-form journalism on high quality paper with really nice smelling ink.

It’s essentially a mini book.

Ever since PHOENIX began, we’ve continually questioned what – if any – sort of digital presence the mag should have. How could we use digital to enhance, but not replicate, our physical hero product? How could we use digital to pull in new readers, whilst ensuring they converted to print sales? How could we create digital content of the same quality we’re known for in print – but with a tiny team on an even smaller budget?

Yep – essentially the same questions that preoccupy the big-book trade.

Two years ago, we thought we’d come up with the answer. We launched PHOENIX’s monthly counterpart, The Manual: a digital-only, custom-created magazine cradled within a bespoke app. It was interactive. It was beautiful. It was timely.

It was a huge mistake.

Why? It seemed like such a brilliant idea at the time. But we soon came to realise that, while apps are great for functional services such as Uber or banks, they’re pretty useless when it comes to publishing.

From a reader’s point of view, downloading an app is a surprisingly big barrier to entry. Not only do you have to wait a few seconds to install the app and another few seconds every time you want to download each new issue, you have to reproduce the whole process every time you want to read on a different device. And, if you want to launch an external link, its’a clumsy process that takes you outside the app – and out of your closed story-garden into a wilderness of distractions.

From a publisher’s point of view, producing and distributing content via an app is a total pain – from creating complex InDesign files to working with frustrating external shopfronts such as the Apple Store. And it’s useless for SEO.

. . . .

Last week, Simon Rowberry wrote us a very popular – and polarising – piece called ‘Is the e-book a dead format?’ In it, he explained the growing interest around Portable Web Publications (PWP), “a self-described vision for the future of digital publishing based on a fully native representation of documents within the Open Web Platform.” His cautionary note – ” how will books cope in the complex attention economy of web browsing?” – is worth listening to.

Link to the rest at The Bookseller

12 thoughts on “Bring on the browser books”

  1. THIS. That is why I convert most ebooks to my chosen format, to use the book reader I like the best.

    I like two different comic book readers for CBR or CBZ files, which are often the format of choice for scanned pulp magazines. I’ve been reading old pulp zines like Adventure that are scanned and available from places like the Pulp Magazines Project:
    http://www.pulpmags.org/magazines.html

    And I read pdfs primarily in Acrobat because I can edit them there, at least on my pc (I have the pro version for work). Also because pdfs are done to preserve page layout and conversion often borks that layout considerably.

    So really, I have the Kindle app because its a shopping tool as well as a reader, and Moon+, My 2 CBR/Z readers, and Acrobat. I try others, but none have stuck for reasons articulated by JustAReader and MKS.

    Al the voracious reader

  2. I put apps in a reader folder, but I only keep readers I use a lot. No bespoke tools except the Kindle app.

    • Specialized reading apps only sound like good ideas to app developers.

      1) Storage space on my phone is not unlimited. I use enough apps and enough data that I frequently have to prune away rarely apps to make room for new stuff.

      2) Every new app means a new interface I have to learn and a new collection of settings to manage. I don’t need a dozen or more different ways to accomplish the same underlying task – reading.

  3. I hate bespoke apps for individual books, magazines, podcasts, etc. I feel that my device’s interface is being seized for advertising space as the icon sits on my screen unecessary, unused, and redundant. It offends my sense of efficiency. Plus, many apps have idiosyncratic command design. I don’t want to learn 15 different swipe-menu-button templates to listen to 15 different podcasts.

  4. Browser-based is the same as app-locked.
    Consumers have been burned by app-locked ebooks in decades past (TomeRaider, iSilo, among others) so savvy readers avoid them like the plague.

    In fact, one of the drivers behind Nook’s decline is that they took away the ability to download transportable files for backup purposes. Savvy readers will not buy any ebook they cannot backup on ther own. (This is one of the biggest knocks against DRM and the main driver behind DRM-stripping software.)

    Bottom line: if the only way to read a book is by logging into some corporate server, its sales prospects will be greatly diminished. Corporate publishing apologists may wax lyrical about the approach but it is readers who choose what to buy, what to read, and where.

  5. And browser books can easily be converted to other formats using Calibre or other tools if you decide that the browser experience is not for you.

    I have a lot of free books from Gutenberg and other similar sources and convert them to epub when I want to read them on my phone or tablet, or to mobi format if I want to read them on my Kindle.

    Personally, I prefer to pick a dedicated reader program (like Kindle, Moon+ Reader, Komik or Comical, or Adobe Acrobat) instead of the browser experience, but html can be read on a whole lot of platforms.

    Al the greatly voracious reader

    • I have a lot of free books from Gutenberg and other similar sources and convert them to epub when I want to read them on my phone or tablet, or to mobi format if I want to read them on my Kindle.

      A very rational approach.

      However, I observe I am so lazy I will pay Amazon for stuff that is free on Gutenberg. Not sure how many others are similarly afflicted. Click.

      • I keep backup folders on different hard drives (drives fail unexpectedly, and storage is cheap), but my primary library is in Calibre already, plus I use Calibre Companion to wirelessly transfer books to my tablets/phone. While I’m uploading them its easy as pie to convert the files to preferred format as it transfers them.

        To me Calibre is the antithesis of iBooks… the library and transfer system is nonproprietary and works on many platforms, it converts from proprietary to free formats at my command and stores them in an easily readable file system AND it doesn’t take my book away and hide it when I put it into Calibre to start (instead, it makes a copy in the Calibre library, preserving my chosen file structure where the original is)… So no cost, no hardware lock, no format lock, no obscure filing, and that is why I’m a Calibre evangelist. Live it, like it, use something else if you want…

        As for the ease of Amazon over Gutenberg, I too am guilty of that. No shame in it at all.

  6. Interesting. In their case it was the ink that smelled, not the paper. I think they may have something there…

  7. Of course, ebooks are already websites — they’re just a packaged file of html pages. You can open one with a browser today and click away (not pretty, but functional).

    In my experience, you want stable content media, and can tolerate volatile platforms that use it. Every time the content media mutates, there’s a major disruption: 78 rpms to 33 rpms to CD to MP3. The most disruptive is the pre-digital to digital transition.

    Since ebooks are past that divide, being already digital, any media transition (“the future of EPUB”) will be digitally mediated, with straight conversion being the first main step. But since the display platforms being touted will be volatile, you can expect all the enhancements to be platform-specific for quite a while, and many will dead-end. Think of Apple products as an example of volatile and platform-specific things.

    This isn’t something that the world will suddenly lurch into that authors need to be alarmed about. Plenty of room for fits and starts, and high confidence in the ability to transition without significant pain.

    • I took time to read a few W3C documents on Web Publications. They discuss potential requirements that could become the nucleus of a draft specification. It is a long way from a specification and published specification is a long way from consumer impact. I found the documents interesting, but they don’t contain anything that a developer could take away and start building a prototype.

      The future of a spec at this stage is often determined more by who is contributing than the contents of the spec. I look for organizations capable of making something happen. Amazon, Apple, and Microsoft do not appear in the contributor list, no hardware types that I could recognize; Google, Hachette, Wiley, and Adobe did contribute along with a handful of foundations and universities. It didn’t strike me as a powerhouse.

      You never know what might happen, but I doubt that we will see Web Publications flipping the publishing world anytime soon. Still, I’m glad that someone is thinking about this stuff.

      BTW, off-line availability is one of the clearer of their required use cases.

  8. Assuming this requires “always on” internet, thanks but no thanks. Maybe in a decade or so, but for now Comcast victims like myself have daily outages, and even more frequent “throttlings.”

Comments are closed.