If you have decided on publishing an interactive periodical title, congratulations! Having an interactive periodical means that users can scroll articles on a page, play a music sample, manipulate a map, or otherwise interact with your content in ways that are just not possible with static content. While interactive publications are more work than simply rendering a PDF replica of your print publication, they are often well worth the extra effort. Interaction can drive deeper engagement with the content, more time per page, better reader usage reporting and other advertiser-friendly benefits.

In this two-part series on Interactive Periodical Publishing on Kindle Fire I will discuss some of the technical considerations for those who will write their own periodical application or who will use a publication platform such as Woodwing or Adobe. The first part introduces thoughts on layouts, resolutions and interactions, and part two will cover how to submit your periodical app to the Amazon Appstore to minimize time investment on your end and optimize user experience.

A 10,000 Foot View of Layouts

If your content is text-centric, you can look into using a fluid layout (Liquid Layout) design. The Wall Street Journal app for Android and iOS uses a set of relative layout templates into which the daily text of the newspaper flows. Once your templates are set, you can simply stream content and the templates handle the layout.

WSJ can flow text into templates easily

If your periodical is image-heavy, or you wish to exercise more exacting creative control, you can probably constrain your digital layout work to two fixed aspect ratio layouts, one for the 4:3 aspect ratio iOS tablets, and another 16:9 layout for Android tablets. True, not all Android tablets are 16:10, but if you are comfortable with a small amount of letterboxing, non-standard devices can be accommodated. 

Table 1

WIRED Magazine has precise layout needs

Working with Resolutions

Publication platforms like those from Adobe can take a specific layout from InDesign and generate multiple renditions in which you can bundle images that are specific to the screen resolution of the target device. This can help reduce total package size and reduce asset scaling artifacts. Other platforms ask that you submit the largest assets you have, and will then scale down the assets to match the screen resolution of the target device. If you write your own app, you can make either choice, or even stream appropriate images to your app if your application returns the properties of the device on which is it running. If you do write your own app, please be aware that periodicals are often read in both landscape and portrait orientations. Your app should accommodate accordingly.

Building Interactions

If you are creating your own app, you can use just about anything you want to create interactions; Native code, Java, HTML, even HTML5. If you are using a platform like Adobe, you still have a fair amount of flexibility within the scope of the tools and webkit provided by the platform. In either case, be aware that the code you put onto any single page will use heap memory, and if you cache multiple heavy pages at the same time, you could find yourself running short on memory and fighting with the garbage collector should you ever hit onPause(). Avoiding this usually requires coordination between the content folks (who usually don’t think about heap size) and the IT group (who usually don’t think about editorial requirements). If you can flatten some of your non-interactive elements to PDF, you can save a good deal on file size and memory usage.

That covers (at a very high level) some of the important considerations to keep in mind when designing your periodical app. The next installment of this series will cover submitting your app to the Amazon Appstore, setting up In-App-Purchasing for subscriptions and individual issue sales and more.