Posts tagged "DPS"

Displaying Office Documents in Adobe DPS on an iOS Device

Many of my Enterprise customers use Adobe Digital Publishing Suite as a means to privately distribute marketing and sales enablement materials to their employees on iPads. Often, they have existing libraries of documents that they want to use as reference material in their folios, but they don’t want to convert them to InDesign documents. The DPS help page for Hyperlinks suggests that you can use the HTMLResources folder to display PDF documents in your folio, and this works well. On iOS, DPS uses an embedded Webkit overlay to display HTML content, so I decided to look at what else I could display there. Clearly PDF was supported, but what about Office? (If you have my DPS Examples app installed on your iPad, and you’re reading this blog on your iPad, then tap here to see examples of OfficeDocuments and how they appear in a DPS folio.)

Digging around in the Apple documentation for Webkit Overlays in iOS, I discovered a Technical Q&A Note that says you can display a wide array of document types, including Word, Excel, Powerpoint, Keynote, Pages, and Numbers as well as PDF. All of these work in DPS when the folio is used on an iPad or iPhone. Be aware, though, that the Webkit preview doesn’t perform precise layout on Word documents that use advanced layout features, and some spreadsheet appearances might get wonky. Test, and if necessary, convert to PDF using Acrobat, of course.

Let’s see how all this works.

I have a folder of documents that I would like to display in my folio. The HTMLResources folder is a handy place to put these documents, since I will have a common location I can reference from anywhere in my folio, including buttons, hyperlinks, and hyperlinks in Web Content Overlays. To make an HTMLResources folder, all you need to do is to select the files you want to use in HTMLResources and zip them up. DO NOT put these files in a folder and zip the folder, unless you want to organize your references in a subfolder of HTMLResources. Also remember that it is an HTML Resources folder, so that all of your file names must be HTML friendly, or you need to escape the special characters when you write your hyperlinks. Notice in my example that all of the spaces are underscores so I know the filenames will be OK.

Once you zip up the files, rename the archive to HTMLResources.zip.

Now, we need to add it to our Folio. In the Folio Producer panel, navigate to the top level of the folio and choose Import HTMLResources Folder from the flyout menu and browse to your new HTMLResources.zip archive.

Now, let’s make some buttons to display our files. While I will make buttons, you can also use hyperlinks to display the documents you have in your HTMLResources folder. Note: follow the guidelines in the help documentation for proper pathing to your assets, though. The path is different for hyperlinks vs anchors in HTML files.

In my example, I have included files of the following types: PDF, xls, xlsx, doc, docx and Keynote. The Webkit overlay also supports Numbers and Pages, and you can explore those on your own. I made a series of buttons as normal, and I assigned the “go to URL” action to them with the target URL being “HTMLResources/<name_of_my_document.xxx>” In the example below, I have the button called “docx iPhone” on my iPhone layout that points to “HTMLResources/1_Statement_of_work.docx”

I created buttons for each of the file types shown and made both iPhone and iPad layouts. The results are shown below (the .doc and .docx files are the same content, so I’m only showing one of each (tap images to show full size):

Starting state:

 

PDF

Word doc

Excel

Keynote

Neat, eh? Oh, if you’re wondering how I got the two devices in one screen shot, Reflection allows you to display two devices at a time simultaneously. Please remember that the ability to show these document types is a function of the Webkit implementation on iOS, and these documents will not display on your Android devices.

I hope that this set of files will continue to be supported in future versions of iOS. The ability to include these document types is a huge time saver for companies that need to include supporting documentation in their DPS apps, but don’t want to have to convert them all to folios.

Share on Facebook

Single Issue vs Multi Issue Viewers for Enterprise customers

DPS customers have access to tools for creating and managing custom versions of the Adobe Content Viewer that can be distributed through iTunes (like the Wired or National Geographic apps). Additionally, Enterprise DPS customers can build apps for private distribution using an MDM service like MobileIron or Air-Watch. Only Enterprise DPS customers can build apps for Enterprise distribution models, and I have provided an earlier post about that process.

One of the options for the custom viewer is a Single Issue Viewer, in which one folio is embedded directly into the viewer. Single Issue Viewers have no library mode, so they are used by many of our customers who want to use MDM solutions to manage the distribution of specific folios to specific people. However, we have other customers who use MDM to distribute Multi-Issue Viewers to their managed devices, and then use our Restricted Distribution infrastructure to leverage LDAP or other authentication to control access to specific folios in that one viewer app. There are IT advantages to either approach, and I’d like to explore the differences.

In order to use an MDM system to manage apps on an iOS device, each app needs to be created using a specific unique identifier known as a mobileprovision file. Customers make these in the iOS Provisioning Portal, which is part of Apple’s iOS Developer Portal. In the Single Issue approach, each Single Issue Viewer needs a new, unique mobileprovision file from the iOS Provisioning portal. MDM solutions leverage a property of iOS whereby each app must have its corresponding mobileprovision file on the device in order for the app to run. MDM solutions can remove a mobileprovision file on a managed device, rendering the app unusable. When a customer makes a new Single Issue viewer, it must repackage this app to include the new, unique mobileprovision file in a process called resigning. There are several ways to do this, but a popular method is to use iresign from Google. This workflow is very effective because it gives IT fingertip control over each and every app on a managed device, and it allows IT to move DPS Folios in and out of circulation by wrapping them in Single Issue Viewers.

Let’s face it, though. Managing all those apps and mobileprovision files is annoying IT overhead. In the Multi-Issue approach, there is only one mobileprovision file because there is only one Viewer. Content delivery to the Viewer’s Library is based on credentials and is managed by a business user, not IT. The business user can associate content to users or groups in a portal without having to call IT to issue a new mobileprovision file. This portal can be built and managed by corporate IT using sample code from our Developer Center. Derek Lu, for instance, provides detailed instructions and sample code for integrating LDAP with Restricted Distribution. There are also commercially available servers such as Portico from MEI to enable Restricted Distribution workflows in an Enterprise without IT having to develop a backend solution from scratch.

Which method is right for your company? That depends on how you want to manage content. If you want IT to manage everything, then the Single Issue approach might be just what you need for DPS. If you want to reduce the burden on IT and shift content management over to the business users who file the IT tickets in the first place, then Multi-Issue with Restricted Distribution fills the bill. DPS is flexible: your designers create their engaging tablet content in InDesign, IT puts the apps on the devices, and either IT or business users manage the flow of those folios to users. Either way, you can use your MDM system to manage DPS viewers on your company’s tablets.

Share on Facebook

Using Mobile Device Management systems and DPS

Many of my Enterprise customers ask how to use DPS with their Mobile Device Management (MDM) Solution. An MDM Solution is a set of tools that allows an Enterprise to deploy software to employees on managed devices. For instance, if the company has a sales enablement app that they want all of the sales force to use but they do not want to require all of the sales force to bring their iPads in to have the app installed, then they could use an MDM system.

There are many MDM systems available, and this post is not intended to be a tutorial on how to implement DPS in a specific offering. It is intended to explain the current state of affairs and offer some guidance on how to get your DPS app deployed with any MDM solution.

What is a Mobile Device Management Solution?

Mobile Device Management (MDM) Solutions provide Enterprise customers with a means of managing deployment of apps to mobile devices such as phones and tablets.

How is MDM different from DPS with Restricted Distribution?

An MDM solution allows IT to manage the deployment of the Viewer App, while the DPS service allows business users to deploy content to that managed app. These systems work together, based on the business requirements. For example, an Enterprise customer would use an MDM system to deploy the Viewer App and use a Restricted Distribution server to deliver specific content to an authorized user who uses that app.

What is the difference between a Viewer App and a folio?

Viewer apps are the apps that a user taps to view content on their tablet. Folios are the content that those Viewer Apps display. DPS users make Viewer Apps with the Viewer Builder, and they make folios with InDesign or as HTML.

How can DPS and MDM solutions co-exist?

If a company makes a single-issue Viewer App that has the folio content “baked” into the app, then an MDM solution can push the app (with content embedded) to the managed devices. If a company makes a multi-issue app, then the MDM solution will push the app to managed devices, but the DPS service will deliver the content to those managed apps.

How can DPS folios be integrated with Mobile Device Management solutions (e.g. AirWatch, Mobile Iron, etc.)?

MDM solution can manage deployment of Viewer Apps to mobile devices. At this time, the Viewer Builder requires that the administrator who makes the Viewer supply a wildcard Enterprise mobileprovision file at build time. Most MDM systems rely on app-specific Enterprise mobileprovision files to enable or disable an app on a device. It is necessary to re-sign the app with an app-specific Enterprise mobile provision file after building the Viewer. Google’s iResign is a common utility to help with this process.

Update: The DPS App Builder now supports app signing with mobileprovision files that are tied to a specific AppID, so wildcard in-house mobileprovision files are no longer required to build an Enterprise DPS app. As a result of this change, it is no longer necessary to re-sign an app for use in an MDM solution if the app was built with the proper mobileprovision file. In the case where an agency creates an app using their own Enterprise iOS Developer Account and hands it to an enterprise for deployment via MDM, then re-signing may be necessary. iResign is now a GitHub project and is not Google Code project.

 

Can an MDM provider manage the app but allow DPS to update the folio files?

Yes, this is the only way that a multi-issue app can work today. Single-issue apps can be managed in their entirety by MDM systems.

Could an MDM provider distribute an app without DPS involvement?

MDM providers can distribute single-issue folios without DPS involvement, aside from the necessity to build the Viewer itself using the Viewer Builder and an Apple Enterprise certificate.

Does DPS provide analytics on privately distributed apps?

Yes. DPS will provide analytics for single issue and multi-issue apps. Applications can also bind to Adobe Site Catalyst.

Can MDM solutions distribute apps made with a DPS Pro license?

No. MDM solutions require Enterprise Signed Apps in order to circumvent the Apple App Store. Only Adobe Enterprise DPS licenses allow customers to create Enterprise Signed apps.

What is an Enterprise Signed App?

Apple Enterprise Developer Accounts are special agreements with Apple, and an Enterprise Signed App (.ipa file) is one made under this special agreement. Apple allows the Enterprise to make and distribute apps within the Enterprise, and the Enterprise agrees not to allow these apps to be acquired outside of the Enterprise. Customers need Apple Enterprise Developer Accounts in order to make and distribute any app, DPS or otherwise, for internal consumption.

Is there a list of MDM systems that work with DPS?

Any MDM solutions that can distribute Enterprise Signed Apps can distribute applications created by DPS Enterprise Edition. However, some additional steps may be needed to properly sign the app for use in the MDM system. Google’s iResign is a common utility to help with this process.

Below are two diagrams that illustrate the DPS to MDM workflow, with and without Restricted Distribution. 

 

  

 

Additional Info

Learn more about the Apple iOS Enterprise Workflow:
http://developer.apple.com/library/ios/#featuredarticles/FA_Wireless_Enterprise_App_Distribution/Introduction/Introduction.html
https://developer.apple.com/programs/ios/enterprise/
http://www.apple.com/iphone/business/integration/mdm/

Learn more about building Enterprise Signed Viewer Applications with DPS:
http://www.adobe.com/devnet/digitalpublishingsuite/articles/distributing-enterprise-ios-viewer-apps.html

Share on Facebook

Using Twitter feeds in Adobe DPS

Edit: 7/19/2013  Twitter once again updated its APIs, so this article is inaccurate. I am working on a solution, and will update this article when I have one that works. There is a suggestion over in the DPS Forums, but the results seem to be spotty.

Recently Twitter changed its widgets so that they will no longer run outside of a web site. This presents a problem for folks who have relied on embedded Twitter widgets in their DPS publications. There is a workaround which should present no problem to readers, since they need to be online in order to read Twitter content in the first place.

First, post your widget to a web site, then either refer to it directly from your web overlay or embed an HTML file in your folio that contains an iframe that displays your widget. Here’s a more concrete example.

I have a widget called dpstweets.html, which displays all of the tweets that reference @adobedigitalpub. It resides at http://www.jameslockman.com/dps/jamestweets/dpstweets.html, and it consists of the following code:


<!DOCTYPE HTML>
<html>
<head>
<meta charset="UTF-8">
<title>DPS Twitter Feed</title>
<style>
 .body
 {background-color:transparent}
</style>
</head>
<body>
<div>
 <script charset="utf-8" src="http://widgets.twimg.com/j/2/widget.js"></script>
 <script>
 new TWTR.Widget({
 version: 2,
 type: 'search',
 search: '@adobedigitalpub',
 interval: 30000,
 title: 'Adobe DPS',
 subject: 'See what\'s trending',
 width: 180,
 height: 187,
 theme: {
 shell: {
 background: '#8ec1da',
 color: '#ffffff'
 },
 tweets: {
 background: '#ffffff',
 color: '#444444',
 links: '#1985b5'
 }
 },
 features: {
 scrollbar: false,
 loop: true,
 live: true,
 behavior: 'default'
 }
 }).render().start();
 </script>
</div></body>
</html>

That in itself is pretty plain vanilla. However, if I were to embed this file into my DPS app as a web overlay, I would get a blank white rectangle. The easiest solution is to make my web overlay point to http://www.jameslockman.com/dps/jamestweets/dpstweets.html. I set it to auto play, allowed interactions, and made it transparent. Of course, that’s hard to see unless you preview the folio on your desktop or on your tablet.

The other solution is the iFrame, and it’s easy to implement.

I made a second HTML file that I called dpsiframe.html, and in the body tag, I put this:

<iframe src="http://jameslockman.com/dps/jamestweets/dpstweets.html" width="200" height="312" frameborder="0" marginheight="0" marginwidth="0">Your browser doesn't support iFrames</iframe>

You can look up how to stylize iFrames with CSS and with their own tags, but once I put this new html file into my web overlay in my folio, it worked like a charm.

CS6 users have an additional bonus feature, though. In InDesign CS6, you can just copy and  paste the <iframe src-” … /iframe> line of code into InDesign, and InDesign will make a nice poster frame of the page for you when you paste. It makes it much easier to figure out how the widget will fit into your layout. Give it a try with my iframe code above, and tell me that’s not awesome. You can’t, can you? Unless, of course, Twitter changes its widgets again and makes them unusable in iFrames.

Share on Facebook

Nested Overlay conundrum and solution for DPS

One of my customers’ favorite aspects of Adobe’s Digital Publishing Suite is how new features appear every 6 weeks or so. This rapid pace of development means that the DPS team can respond to customer requests for new functions in the Overlay Creator and the Folio Producer parts of the solution. One of the recent changes was the addition of what are known as Nested Overlays.

Nested Overlays allow you to combine multiple overlays into one object. For instance, you can now include a buttons, videos or a Pan and Zoom Overlay in your slide show. This is very handy when trying to create an interactive slide show like you see on popular news sites: there’s a photo with some text under it and six dots along the bottom, and when you touch a dot or swipe across the image, it takes you to the image or video that’s in the slide show.

I have heard from customers that while this seems to work on the desktop Content Viewer, it often fails on the iPad. I was surprised, so I did some investigating and here’s what I learned.

When you build a slide show, you need to create a Multi-State Object, or MSO. This MSO is a container for all of the different slides you want to present, with each state in the MSO representing a slide. Inside of each state, you can include DPS overlays. In my example, I have three slides in my slide show, so I have three states in my MSO. On the second slide, I have a Pan and Zoom Overlay, because the text is too big to fit in the space I’ve allowed. When I preview on the desktop, this works as expected. When I preview on the iPad, however, it doesn’t work.

The solution is easy, and I came upon it after following some of my own advice. When I first began teaching about interactive features in InDesign CS5, I exhorted my students to “think like a developer!” This meant that they needed to start naming their design elements if they wanted to have a productive relationship with the Flash developer who would take their comps/projects and turn them into full-fledged apps. This reduced guesswork and established a workflow that fostered collaboration between the two. Until InDesign CS5, designers all worked in Photoshop and sent layered PSDs with layer comps and written instructions to the developers, who chopped them up and added interactivity. This Photoshop-centric is still prevalent today, and it is fraught with errors in communication. I promote the idea of using InDesign as an interactive comping tool, however, and make judicious use of the layers panel to name my design elements. The key here is how InDesign names objects when you don’t.

By default, InDesign names all of its objects with the name of the primitive surrounded by brackets, like <rectangle> or <graphic frame>. If you place a graphic, the name becomes <nameofthisgraphic.psd> or whatever the graphic’s file name is. If you type some text, the first few words of the text frame become the name of the object, plus those surrounding brackets. It turns out that these names look suspiciously like HTML tags, but as tags, they have no meaning. I think (and I expect to get either some dope slaps or back slaps for this) that the webkit part of the iPad Content Viewer gets confused when it sees these names in the nested overlays. If you change the name of the overlay from InDesign’s default to something without brackets, your overlay will work as you expect.

In my example, I drew a box and pasted my text into it in order to make the Pan and Zoom overlay. InDesign named the box <graphic frame>. We can see this in the Layers panel. One of the great features of the Layers Panel is that we can use it not only to reorder the objects within a layer, but we can also use it to change the names of the objects. When I change the name to More Than Professors and update my folio, my overlay works as expected. It is not necessary to adhere to a strict Action Script naming convention, which would have a name like moreThanProfessors. The Content Viewer doesn’t seem to be bothered by spaces in the name, but if you’re going to be working with a Flash developer, then you should consider talking with them about how they want objects to be named.

On the left, the result with InDesign's default name. On the right, the result with my custom name.

Changing times require changing workflows. For interactive design and DPS specifically, it is time for designers and developers to share best practices. While naming conventions have never been a concern of a print designer, they are critical for a developer. In InDesign, these two worlds collide, and the collaborative workflow I have been preaching for the last two years is now paying off.

Share on Facebook