It walks users step-by-step through the entire authoring and publishing process, providing links to more detailed content along the way. Here’s the Table of Contents to give you an idea of what the PDF includes (click image to enlarge):

Special thanks to Keith Gilbert for authoring the content. Again, here’s the link:

DPS Getting Started Guide PDF

DPS Gallery Submission Form

Even if you don’t have an app or use DPS, it’s fun to check out the gallery.

First, take a look at Colin’s video. Then come back and read the rest of this article for additional details.

Click here to watch Colin Fleming’s video

First Folio Free

Here’s a common experience. Someone wants to check out the new magazine on their iPad, so she downloads the free app from the App Store full of anticipation. When she opens the app, she doesn’t see any content–just a library with issues for sale. So she gives the app a poor rating, deletes it, and goes back to play another level of Angry Birds.

With First Folio Free, publishers can now select an option in the Account Administration tool that entitles the most recently published retail folio to first-time users of an app. That way, when users download the app from the App Store, the most current issue can start downloading, providing a better initial experience for some publications.

Select this option in the Account Admin tool to enable First Folio Free. [Click image to enlarge.]

As a publisher, you’re probably concerned that users will try to abuse the free download privilege by uninstalling and reinstalling the app whenever a new issue is available. It doesn’t work that way. The DPS app gets mapped to the device, so if users uninstall and reinstall the app, they’re entitled only to the original complementary folio, not the most recently published folio.

To see how this works, you can download an app I created called Northwest Scenery. The first few folios are retail ($0.99), but the most recent retail folio is downloaded automatically when you launch the app. (At this time, the entitled retail folio is the Spring 2013 issue with a fox on the cover.) You’ll always be entitled to that issue as well as the other free issues. You would need to pay* for the remaining retail issues.

*Note: Feel free to download the Northwest Scenery app, but don’t bother purchasing content. All the retail content is available elsewhere for free, or will be soon. I set up retail content in this app only to understand the DPS/iOS publishing intricacies, not to supplement my income (I make my extra cash during Friday Night Poker).

Automatic Download Options

The DPS App Builder includes two new options for downloading folios.

Automatic download options for subscription apps. [Click image to enlarge.]

The “Always open background downloaded issue” is great for Newsstand subscription apps, especially frequently published apps. For example, if a publisher selects this option for a daily newspaper, users can launch the app in the morning and instantly view the issue that was downloaded in the background overnight.

The “Auto-download latest entitled issue for new readers” works great for the “First Folio Free” feature we just discussed. When a user installs the app for the first time, the most recent folio starts downloading automatically, letting the users see a cover or table of contents almost immediately. If you don’t make the most recent retail folio free, the most recent free folio is downloaded automatically.

Welcome Message

You want to let your customers know that you’re giving them a free issue. One method is to create a pop-up message on the cover of your most recent issue. For example, you can create a two-state MSO with one blank state and one state with the welcome message. When the user taps the close button, the blank state “appears,” making the message go away. Or, you could do this through HTML. Check out Allure for an example:

Allure tells customers that they’re getting a free issue. (Click to view larger image.)

If you just add that two-state button without doing anything else, all your customers—including your loyal subscribers—will get the same message. That’s where the next feature comes into play.

Conditional HTML

The conditional HTML feature is the digital equivalent of a blow-in card. A blow-in card is what publishers use to encourage anyone who buys a magazine off the rack to fill out the card and purchase a subscription. These are the cards that you see under your coffee table or scattered around an end table of a waiting room.

Here’s how it works in the DPS world. The publisher creates either an HTML article or a Web Content overlay. The source HTML files include ReadingAPI JS code that can look at the folio and determine how it  was downloaded—as a free issue, as a complimentary issue (First Folio Free), as a single purchase, or as part of a subscription. The HTML files include different content for each folio type.

The same Web Content overlay displays different content depending on how the folio was obtained. [Click image to enlarge.]

Tapping the Subscribe Today button in the overlay displays subscription options. [Click image to enlarge.]

The process for setting up this digital blow-in card feature requires intermediate HTML coding skills. Follow these general steps:

1. Obtain the Adobe ReadingAPI.js code from the DPS Developer Center.

The DPS Developer Center is a great resource for advanced features. [Click image to enlarge.]

 
The ReadingAPI.js file returns different values for different ways that folios are obtained. [Click image to enlarge.]

Folder structure for Web Content overlay with conditional HTML.

In most of the Northwest Scenery folios, an Ad displays different HTML content depending on how the folio was obtained. Here are the calls in the index.html file to the AdobeReadingAPI.js file.

The index.html file includes different content for different folio types. [Click image to enlarge.]

Download NW_Scenery_Conditional_Web_Overlay.zip

3. Create the HTML article or Web Content overlay.

In Northwest Scenery, I created an overlay, but I could just as easily have created an HTML article.

Select this option in the Overlays panel. [Click to enlarge image.]

For either an article or overlay, it’s important to select an option that allows access to entitlement information. The option is available in the Web Content section of the Overlays panel or in the Folio Producer Editor when an HTML article is selected.

4. Build and test the app.

Use DPS App Builder to build a development app. Use test accounts in the sandbox environment to purchase folios and subscriptions so that you can test the conditional HTML content without actually paying for retail content. Look for instructions in the publishing companion guide that you download from the Help menu in DPS App Builder.

Again, you don’t need to be a DPS Enterprise subscriber to take advantage of these features. You can use all of these features with a Professional subscription.

Download ScratchOff.zip

And here’s the image flip source code.

Download ImageFlip.zip

Here’s the source code for resizing text in an HTML article.

Download ResizeText.html

Here’s the source code for the spinning wheel of fortune. You’ll need to create your own articles to jump to.

Download SpinningWheel.zip

Oh, and here’s a sketch pad example.

Download Sketch_Pad.zip

Other HTML5 examples such as image drag-and-drop in DPS Tips have links to external sources. When I add more HTML5 examples to DPS Tips, I’ll post the source files here.

If you have HTML5 source code that works well with DPS, please share!

I used the social sharing feature to make all of the folios available in most computer browsers. If you click the following links from an iPad, you’ll jump to the first article of the issue in the DPS Tips app. Click any of these links on a desktop or laptop computer (or a new Surface tablet), and you’ll see a “Web Viewer” version of the articles in each issue.

Folio Basics

Overlay Basics

Advanced Overlays

Effects

Single Edition

What’s New

In Web Viewer, click the icon in the lower left corner to switch to a different orientation. Click the icons in the bottom center to view different articles. Click the icons in the lower right corner to view different pages in the article.

Article displayed in Web Viewer. (Click to view larger image.)

Note that not all features are available in Web Viewer. For example, panoramas are not yet supported. You’re better off using DPS Tips on an iPad or another mobile device, but if you’re away from your iPad, use these links.

Again, here’s the new DPS Status page.

How do you create Sections?

Simple. Go into the Folio Producer Organizer and open a folio in the Folio Producer Editor. Specify a section name for each article. Make sure that you specify the same section name for at least two articles. Section names are case sensitive, so take care when adding values. Copy/paste is a good idea.

If you don’t specify a section name for an article, that article gets downloaded when any other section is downloaded. You might want to leave the section name blank for articles such as covers and tables of contents.

Specify section names in the Folio Producer Editor. (Click to view larger image.)

You can also use the sidecar.xml file to specify section names for articles in a folio.

Once you specify sections for the folio, you need a v24.1 or later viewer to see the sections.

What do Sections look like?

[Note: I originally set up Sections in the DPS Tips app, but I removed it because it just didn't make sense for that app. Giltedge Travel and dailies are much better examples.]

Here is the library of Giltedge Travel (free), which uses the v24 library. The library has a different appearance in v25 and later.

The top two folios have Sections enabled. (Click to view larger image.)

Once you tap View Sections, the set of sections defined in the Folio Producer Editor are displayed. You can tap any section to download only that section, or you can tap Download All.

Users can tap the sections they want to download. (Click to view larger image.)

When you tap the TOC button in the navigation bar, the table of contents shows only the folio’s sections—not the full list of articles.

Sections not downloaded are dimmed. (Click to view larger image.)

What are best practices for sections?

• Avoid using sections unless you have a compelling reason. This feature works well for newspaper apps or huge folios with clearly divisible content. For typical magazine apps, you’re most likely better off just letting users download each issue when it comes out.
• When users tap the TOC button, they see only section names. Consider creating a table of contents page with navto links for the folio. For large sections, you might want the first article in the section to be a mini-TOC with navto links to each article.
• Applying sections to a folio does not change the order of articles in the folio. For best results, keep all the articles in the same section together.

(This article was written in October 2012. As the Android platform evolves, I’ll try to update this article.)

Differences Between Android and iOS Devices

You should be aware of a few key differences between how folios are displayed on iOS and Android.

Scaling

In iOS viewers, content is scaled up to fit in the screen. For example, a 1024×768 folio is scaled up to fit in the 2048×1536 iPad HD screen. However, on Android, viewers never scale up the content. A 1024×600 folio is displayed on a 1280×800 device with big black bars on all sides. Furthermore, on iPad viewers, only folios with a 4:3 aspect ratio will appear. On Android, any folio of practically any size will appear.

In this example, a 1024×600 folio is displayed on a 1280×800 Nexus. Instead of scaling up the content, the viewer adds black bars. (Click to enlarge.)

Although viewers can scale down content on Android devices, it’s a good idea to avoid it for performance reasons.

Unsupported Features

In Android viewers, panorama overlays, and inline (non-fullscreen) videos are not supported. (Starting with v26, articles with PDF image format are supported.) Also, be careful with HTML articles and Web Content overlays. HTML content that works great on an iPad may be sluggish or unresponsive on Android devices.

System Bars

In many Android models, the system navigation bar cuts into the folio view area, causing the content to scale unless you plan ahead, as I discuss later. To make matters more complicated, the system bar has a different size on different devices and on different platforms. For example, the Motorola Xoom and the Galaxy Tab 10.1″ devices have a 48-pixel system bar, while the Google Nexus 7 has a 75-pixel system bar in portrait view and a 64-pixel system bar in landscape view. These system bar sizes can change whenever Google updates the OS.

Note that viewers on Kindle Fire models do not display system bars. Also, older Android devices that still use Froyo (OS 2.2) do not display system bars.

The folio view of a Nexus 7″ has a system bar, while the folio view of the Kindle Fire does not. (Click to enlarge.)

Unsupported Devices

On iOS, all iPad and iPhone devices are supported. On Android, only Large and XLarge tablet devices are supported. Android phones are not supported. DPS viewers do not appear in the Google Play Store of Small and Normal Android devices.

Matching Folio/Article Aspect Ratios

One key similarly between iOS and Android viewers is that the aspect ratio of the folio and its articles must be identical (unless the article is Smooth Scrolling). You cannot add 1024×768 articles to a 1024×600 folio. However, you can add 480×320 articles to a 1200×800 folio, because they both have 3:2 aspect ratios. While the viewer does not scale up content on Android viewers, the DPS tools can scale the content of source files to match the folio size. This ability to scale content allows you to take a single-source shortcut, which I’ll discuss later.

Android Operating Systems

DPS viewers support Android OS 2.2 (Froyo) and later. Beginning with OS 3.x (Honeycomb), the system bar is displayed at the bottom of all apps. The newest Android devices use OS 4.0 (Ice Cream Sandwich) or OS 4.1 (Jelly Bean).

Note that Kindle Fire models use a modified Android OS. The first Kindle Fire SD (1024×600) uses a modified version of Froyo. The Kindle Fire HD (1280×800 HD) and the Kindle Fire HD 8.9 (1920×1200 HD) use a modified version of Ice Cream Sandwich. What’s particularly significant about these Amazon devices is that the system bar does not affect the folio design area. A 1024×600 folio displays on the Fire SD and a 1280×800 folio displays on the Fire HD without being scaled for the system bar. When users are viewing an article, they can exit the viewer app by returning to the library and then tapping a button in the system bar.

It would greatly simplify matters if we could remove the system bars from Android devices or add a “safe zone” to the source files, but as my English Lit teacher would say, “Alas, ’tis not to be.”

Popular Android Device Sizes

As of October 2012, manufacturers appear to have settled on three model sizes for Android devices: 1024×600, 1280×800, and 1920×1200. In addition, manufacturers are creating HD 10″ devices which have double the resolution of SD 10″ devices (2460×1600).

1024×600 devices include the Samsung Galaxy Tab 7″, Kindle Fire 7″ SD, and Acer Iconia Tab.

1280×800 devices include the Samsung Galaxy Tab 10.1, Samsung Galaxy Tab 8.9, Motorola Xoom, Nexus 7, Kindle Fire 7″ HD, and Sony Tablet S. With the 1280×800 devices, the XLarge SD sizes (e.g. Xoom) include a 48-pixel system bar in folio view, while the Large HD devices (e.g. Nexus 7) include system bars that are 75 pixels in portrait view and 64 pixels in landscape view. Again, the Kindle Fire models do not display the system bar in folio view.

When manufacturers want to display HD content on the newest XLarge devices, they appear to be using 1920×1200 dimensions. The Kindle Fire 8.9″ HD device has 1920×1200 dimensions. The Asus Transformer Pad Infinity and the Acer Iconia Tab both include XLarge screens with 1920×1200 dimensions. Unfortunately, I don’t have access to either of these devices, and I haven’t been able to locate the size of the system bar on these devices. (Please leave a comment if you have info.)

As I mentioned, 2560×1600 Android devices are starting to come out. These devices are not yet fully supported. The maximum size of folios is the HD iPad size (2048×1536). Yes, we’re shooting at a moving target. I’ll update this paragraph when these larger 10″ devices are supported.

I’m not aware of any popular Android models with a 1024×768 resolution. I heard rumors that Sony was offering a 1024×768 device, but the Sony Tablet S is 1280×800.

Folio Rendition Sizes

With the DPS tools, you can create different folio renditions so that the viewer on a particular device displays only the folio that best matches the device dimensions. If you’re unfamiliar with renditions, please read this Folio renditions article, and then come back.

What folio sizes should we create for the Android devices, and what’s the easiest way to create them? I wish I had an easy answer to that question. Unfortunately, the answer depends on several variables, including the design of your content, the amount of time you’re willing to spend on creating renditions, and which folios you’ve already created for iOS. So let’s discuss a few different workflow scenarios.

Which rendition is used?

Before we get into different scenarios, I wanted to point out a system bar-related issue that confuses publishers who create the basic renditions. Let’s suppose you create two renditions: 1024×600 and 1280×800. On the Kindle Fire devices, everything works as expected. The 1024×600 rendition shows up on the SD device and the 1280×800 rendition shows up on the HD device.

But what about Android devices such as the Xoom or Nexus 7? On those 1280×800 devices, the 1024×600 renditions are displayed, not the 1280×800 rendition. That’s because the system bar causes the 1280×800 rendition to be scaled, which reduces performance, so the viewer chooses the smaller folio that doesn’t require scaling.

That’s why we recommend creating special renditions that account for the system bar in the following scenarios.

Scenario 1: Lazy Susan

You created a 1024×768 folio for the iPad, and now you want to make that same folio available for Android devices. Will this approach work? Sure, it works if you avoid features that aren’t supported on Android (panoramas, inline videos, certain HTML content), and if your interactivity is basic enough to handle the extra processing that occurs when the viewer scales down the folio. You’re basically slapping 4:3 content onto 16:10 / 16:9 devices, so you’ll get the black bars from letterboxing (top and bottom) or pillarboxing (left and right), or both. This is an option, but the folios look amateurish in most cases. If you take this route, you can now use any image format—including PDF—for your one-size fits all folio.

What if you created both 1024×768 and 2048×1536 iPad renditions? An odd thing can happen with the HD 10″ devices such as the Nexus 10. Because of the system bar in landscape view, the 2048×1536 folio needs to be scaled, so the 1024×768 rendition is used instead, and it looks ridiculously small in the middle of the black screen. One workaround is to create a slightly smaller rendition than 2048×1536 that still has a 4:3 aspect ratio.

Scenario 2: The Whole Hog

With this scenario, you’re going to do everything you can to maximize screen space and avoid making the viewer scale down the folio content. With unlimited time and resources, you would create the following folio renditions for Android devices:

• 1024×600 – This rendition works on the Galaxy Tab 7″ and Amazon Fire SD.
• 1205×725 – This dual-orientation rendition works well on the 1280×800 7″ HD devices with the 75/64-pixel system bar. For a single-orientation rendition, use either 1280×736 for landscape (64-pixel system bar) or 1205×800 for portrait (75-pixel system bar). If you’re wondering whether you can use both 1280×734 and 1205×800 articles in a folio, you can’t. The aspect ratios of folios and articles need to match.
• 1232×752 – This dual-orientation rendition works well on the 1280×800 10″ SD devices with the 48-pixel system bar. For a single-orientation rendition, use either 1280×752 for landscape or 1232×800 for portrait.
• 1280×800 – This rendition works well for the Kindle Fire 7″ HD.
• 1920×1200 – This rendition will work well for the Kindle Fire 8.9″ HD. You can use the same source files you use for the 1280×800 folio. Both 1280×800 and 1920×1200 devices have the same aspect ratio (8:5).
• 1820×1100 (?) – I’m not sure about this one, so I’m leaving room for a 100-pixel system bar for the 1920×1200 devices. I’m not even sure whether DPS viewer apps will work on these devices. I’ll come back and edit this once I have more information.

If you’re combining your Android renditions with iOS renditions for entitlement reasons, you could end up with as many as ten renditions for each folio. Ugh.

Here’s a table in progress:

Scenario 3: Sensible Shortcuts

First, I recommend that you stick to a single-orientation design for Android viewers. A lot of designers believe that it’s not worth the extra effort to create both horizontal and vertical layouts for every article of every folio—at least not until we have access to liquid HTML articles. While I prefer landscape orientation for larger devices such as the iPad, I think portrait orientation works better for one-handed devices such as the iPhone and Kindle Fire. If possible, pick a single orientation that works for your design and stick with it.

Second, take advantage of single-sourcing files. If you structure your folders properly, it’s easy to import the same set of files into multiple folios. The key thing to remember is that the aspect ratio of the source files must match the aspect ratio of the target folio. Some publishers take an existing set of source files and create multiple renditions based on that one set of files. While the content doesn’t end up filling the screen in all cases, you can get pretty close, and you limit the amount of redesign.

For example, let’s suppose that you already created a 960×640 portrait-only rendition for the iPhone. This 3:2 aspect ratio might translate well to Android devices. If you use those same source files to create a 1200×800 portrait-only rendition, you’ll be in good shape for the 1280×800 devices. You might want to copy and edit the source files to change font sizes and tweak the layout, but you have a good starting point. You would also want to create a separate 1024×600 folio rendition. With InDesign CS6, new features such as Alternate Layouts help simplify the layout conversion.

Here’s another example. Let’s suppose that you start with 1024×600 source files. Rather than creating new source files for the larger renditions, just stick to one set of source files, and import them into a larger folio that has the same aspect ratio. For example, you could create an 1152×675 folio and import the 1024×600 articles. You would end up with both letterboxing and pillarboxing on tablets such as the Nexus 7 and Xoom, but the appearance—while not ideal—might be passable. Here’s an 1152×675 folio displayed on a Nexus:

The 1152×675 folio displayed on a 1280×800 device includes letterboxing and pillarboxing, but no scaling.

Another approach focuses on the Amazon Fire devices as the primary target and the Android devices with the system bar as secondary targets. In this workflow, you would create source files for 1024×600 and 1280×800, and use the same source files for both 1280×800 and 1920×1200  folios, which both have an 8:5 aspect ratio. The folios you create from these source files should look great on the Kindle Fire. To avoid scaling on Android devices, you would then use the same source files to create a folio rendition that matches the aspect ratio without causing scaling. For example, the 1280×800 source files you created could be imported into an 1160×725* folio. This rendition might be passable on the Android models that have system bars.

* If my Math teacher asked me to show the math, 1280×800 factors down to an 8:5 aspect ratio. Multiplying both 8 and 5 by 145 gives us 1160 and 725. By the way, if you wanted to use the same 1280×800 source files for the 1024×600 devices, multiply both 8 and 5 by 120 = 960×600. That would leave 32-pixel black bars on two sides.

Strict Renditions

With the v22 release, the DPS App Builder included a new option called “Strict rendition for 7″ Android devices.” This option is useful if you’re using the same Application Adobe ID (Title ID) for your iOS and Android apps, and you want only 1024×600 or 1280×800 folios to appear on 7″ Android devices. Selecting this option prevents folios designed specifically for the iPhone or iPad—especially folios with PDF articles or elaborate web content—from appearing on Kindle devices.

While we’re on the subject of using the same Title ID for both iOS and Android apps, I suggest that you do it only if you’re an Enterprise customer and you’ve set up a custom entitlement server. That way, you can make sure that customers who purchased a subscription on an iPad are entitled to your content from Android devices as well.

In my experience, I’ve found it’s better to use separate Title IDs for iOS apps and Android apps. With DPS Tips, I got tired of having to create dummy Android folios for content that worked only on the iPad. With my newest version, I fixed that problem by re-creating Android-only folios using a different Title ID. If you download the newest version, you’ll see there is no longer a dummy version of the “Single Edition” folio in the library.

What about the Nook?

The Nook doesn’t have the equivalent of an open App Store where publishers can submit their apps. If you’re interested in making your app available on the Nook, you need to contact Barnes & Noble directly.  Adobe provided Barnes & Noble with an SDK that allows them to build custom DPS apps and fulfill folios to which customers are entitled. If Barnes & Noble is willing to work with you, create 1024×600 folios, use Folio Producer to export the .zip file, and send the .zip file to Barnes & Noble. At this time, Barnes & Noble is using the v21 SDK.

The bottom line is that if you want to publish a DPS app for the Nook, contact Barnes & Noble.

What about the Surface tablet?

Adobe DPS does not yet support the Surface tablet. Full support for the Surface tablet is on the roadmap.

_____________________

Did I miss anything? Please leave a comment.

• To import articles, re-create folios, or create folio renditions for multiple devices.
• To transfer files from one computer to another.

Structuring Files for Import

The Folio Builder panel offers two methods for creating articles: using the Add button to create an article or layout from the current document, or using the Import option to import one or more articles. When you use the Import method, the folder structure determines how the article is imported. This is all explained in the Structuring folders for imported articles help topic. Here is a quick summary of the article:

• If you’re importing multiple articles, create a parent folder with article subfolders.

• For articles based on InDesign source documents, create InDesign files with _h and _v suffixes such as kayaking_h.indd and kayaking_v.indd. Be consistent with your orientation: each article folder should have either one InDesign file (horizontal or vertical) or two InDesign files for dual-orientation files. Although we recommend that you include all your image files and overlay assets in the article folder, it isn’t required. Files you link to can be anywhere on your system.
• For articles based on HTML files, include only the HTML assets you’re using for the article. Unlike InDesign source files, all HTML assets in the folder are uploaded, sometimes resulting in folio bloat. For single-orientation folios, make sure that the HTML file includes a _h or _v suffix, such as index_h.html.
• If you want to use a special icon that appears when users tap the Table of Contents icon in the viewer, add a .png file to the article folder. Make sure that you use a small, 70×70 image for this TOC file — it doesn’t get resampled. Also, keep other image files inside a subfolder so that an image isn’t accidentally used as the TOC file. The above screen shot shows TOC images in each folder. These images appear when you open the Folio Basics issue in DPS Tips and tap the TOC icon, as shown here:

• When importing multiple articles, you can include a sidecar.xml file that brings in article metadata, such as the article author and description. Again, see the Structuring folders for imported articles help topic for tips on working with the sidecar.xml file.

Structuring Files for Overlays

Some DPS overlays require the source files to appear in their own folder. These overlays include Image Sequence, Panorama, Audio controller skins, and local Web Content files.

For Web Content overlays based on local HTML assets instead of URLs, make sure that the HTML file you specify appears in its own folder. All content in the HTML folder gets uploaded with the article, so this folder should include only the HTML assets used in the HTML file.

These overlay folders can appear anywhere on your computer, but we recommend that you keep your overlay files in the article folder to keep things tidy in case you need to transfer files.

Moving Folio Files to a Different Computer

If you need to transfer the source files for InDesign CS6, simply use the Package feature (in InDesign, choose File > Package) to package the InDesign file and transfer the packaged contents. InDesign CS6 includes all the assets, including overlay assets. Overlay assets are stored in an “Overlay Assets” subfolder. When you transfer the packaged contents to a different computer, the files maintain their links.

Transferring the source files for InDesign CS5 and CS5.5 is a different matter. When you package files, the overlay assets are not included. For best results, follow these steps:

1. Open the InDesign CS5/CS5.5 source document and package it (for best results, do this early in the process to avoid having to relink overlays). You’ll end up with a folder that includes a Links subfolder, a Fonts subfolder, and instructions.txt. You can delete the instructions.txt file.
2. If the article is part of a dual-orientation folio, add the alternate layout document to the packaged folder. Use the appropriate naming conventions for the document: article_h.indd and article_v.indd.
3. Add all image and resource files — especially overlay assets — to the articles folder. I like to keep all assets, both interactive and non-interactive, in the Links subfolder.

When you transfer the files from one computer to another, you should be able to relink all the image files without a hitch. However, you (or the person receiving the files) will most likely need to select each overlay that links to local files — Image Sequence, Panorama, Audio skins, and local Web Content files, and use the Overlay Creator panel to point to the right location. You’ll likely see a yellow triangle above the assets icon. If you try to import an article before relinking the overlays, you’ll get an “Invalid assets” error message.

Which Files Are Uploaded?

Finally, let’s talk about which files get uploaded when you create an article. Understanding this will help you to determine which type of files to use in your layout and how to reduce folio size.

Non-interactive text and images – Each text frame, object, shape, or overlay poster that is not part of the actual overlay is resampled and included in part of the background image generated for each page of the article. This background file’s image format — PNG, JPG, or PDF — is determined by the Image Format setting when you create the article. For each page, a 72-ppi image is created using the same dimensions as the folio size (such as 1024×768).

The takeaway here is that you can use large PSD, AI, and TIFF files for non-interactive content in your InDesign layout. For best results, use images with at least 144 effective ppi.

Interactive source files that get resampled – Any image or source file that’s part of a slideshow (multi-state object), scrollable frame, button or hyperlink, is resampled as a 72-ppi PNG or JPG file.

Pass-through interactive source files – When you create an article, the source files for certain image formats are uploaded to the server without being compressed or resampled, even if the frames for these overlays are resized.  These overlays include Image Sequence, Panorama, Pan & Zoom, Audio controller files, local Web Content files, and Audio and Video files.

The takeaway is that you should compress and resize certain overlay files to keep folio size to a minimum.

Let me know if I missed anything.

OPEN DPS TIPS

NOTE: If you click this link from a computer browser, you get an error message. Similarly, if you tap the link on an iPhone or iPad on which DPS Tips is not installed or updated, you get a “Cannot Open Page” error message. It’s useful only when you tap this link on an iOS device that has the newest version of DPS Tips installed.

Here’s how it works. When you’re building your app in Viewer Builder, you specify a scheme. Apple recommends that you use the reverse domain format such as com.publisher.publication. For my app, I used com.bringhurst.dpstips.

Now that I’ve specified the URL Scheme, I can refer to it from a Web page (like this one) or from a DPS article. Use the same format with a “://” trailer (com.publisher.publication://). Here’s what the HTML looks like on this page:

<a href=”com.bringhurst.dpstips://”>OPEN DPS TIPS</a>

Here’s what the Buttons panel looks like in a DPS article.

When users tap the button, they exit the source app and open the target app. Make sure that you select “Open in Device Browser” in the Overlays panel. If you leave “Open in Folio” selected, you don’t let users leave your app.

If you want to test this for yourself, create a button that links to your app’s URL Scheme (or link to mine). Then preview the folio in the Adobe Content Viewer. If the target app is installed, tapping the link should open the other app.

I should probably mention that this URL Scheme feature shouldn’t be used to get customers to install your app. You’ll want to use the publication URL for that, such as “http://itunes.apple.com/us/app/digital-publishing-suite-tips/id436199090?mt=8.”

The DPS team is currently working on other “deep linking” features that let publishers link between apps, folios, and articles.