By John Parsons
Many pixels have been spilled (including a few by this writer) over the strategic pros and cons of native apps and browser-based, HTML5 content for publishing. In fact, there is no “war”—no clear either/or distinction—between these two approaches. However, there are basic advantages and disadvantages to each, which content publishers should consider as they plan their long term mobile strategy.
When Apple introduced the iPad, a mere 36 months ago, publishers scrambled to put something on these “new” portable devices. App content ranged from enhanced digital facsimiles to complex (and often very expensive) multimedia projects. Eventually, digital edition providers and developers began to offer tools for creating native content apps. Meanwhile, since tablets and smartphones already have built-in browsers, many began to consider publishing their content outside the native app environment, using the emerging HTML5 and CSS 3 standards to create an attractive, interactive publication.
In theory, both approaches can be handled by a publisher’s internal staff: by the print design team in the case of apps or the Web design team in the case of HTML5. Not many have the resources to do both. Clearly, we need a new type of service provider—one that can offer both approaches, and does them equally well, at a reasonable price.
Skip ahead if you are familiar with tablet or smartphone apps, which are simply programs, like Word for Windows or MacOS. App developers use a Software Development Kit (SDK) and a programming language to create a user interface and various functions for the computer—in this case the tablet or smartphone—to carry out. For publishing, this means a customizable “reader,” usually created and supported by a service provider, which serves as a virtual container for each issue. Depending on the quality of the reader, users can experience a publication’s text, images, sound, and video in a way that best suits the device—and hopefully benefits the user.
One of the strengths of native apps is that they can easily take advantage of a specific device—either its hardware components (like a camera) or the operating system (like its file system). By definition, software developed for a particular device should work well on that device. Because apps are developed for a known hardware/software environment, interactive features like video and image galleries can be used with a high degree of confidence.
Apps can also give the publisher and the end user more flexibility when it comes to offline (or local) versus online content. Text, images, and—within reason—audio/video content may be stored on the device and viewed later, without an Internet connection. Conversely, an app may include live HTML5 content, updated continuously when there’s an active connection. Sometimes, it’s in a browser-like window, but it can also be displayed transparently, without the user even realizing that it’s Web content. To publishers with rapidly changing data (like stock quotes or weather updates) or streaming video, this Harry Potter-like capability is a very attractive proposition.
A compelling benefit for apps today is the fact that good typography and page design are very attainable—sometimes as an extension of techniques used in the print world. Even when separate print and app versions are required, a publisher’s existing design and production skill set can be employed. There are also service providers that can cost-effectively translate a publisher’s print content into an attractive, well-designed app.
Another plus for using content apps is commercial. Visibility on digital venues like Apple’s App Store/Newsstand, Google Play, or Amazon’s Kindle Store means potentially greater discoverability and ease of distribution—for a price. Keep in mind, however, that newsstand discoverability can diminish in value as more and more apps are added.
Finally, apps offer publishers something that traditional Web publishing has not: a closed environment. From early accounts, it appears that subscribers are more willing to pay for tablet app editions than they have been to pay for secure Web content. The reading experience itself is also more controlled. In a well-designed app, readers can click to view related content, but can more easily return to the main article.
The downside of apps is twofold. First, as Forrester analyst J.P. Gownder recently noted (ZDNet; April 9, 2013; http://zd.net/YbeuKe), the tablet market is rapidly fragmenting, with new devices, operating systems, and screen sizes proliferating. In many cases, this means additional development for each screen. Even the iPad, formerly a single device “target” for app developers, now has two different screen sizes (four, if you count horizontal and vertical orientations) for which app content must be designed.
The other disadvantage is cost. Besides the multi-screen challenge, the labor involved in creating and supporting apps can be significant. Since most publishers are not primarily software developers, apps can become an unwanted cost center. Fortunately, there are some excellent service provider options, but each publisher should be aware of the total cost involved in app development.
[In the next installment, I’ll tackle the browser-based, HTML5 approach to mobile publishing.]
John Parsons is the Principal of IntuIdeas LLC (www.intuideas.com), a writing, research, and consulting firm in Washington State. He was formerly Editorial Director for The Seybold Report.