Posts tagged "workflow"

I’ll be speaking at Adobe MAX this year!

I will be presenting a session on Variable Data Design at Adobe MAX this year. While I’ve presented at MAX previously, recently it’s been all DPS or AEM-related discussions. This talk digs deep to my roots in Data Driven Marketing and Variable Data Publishing. From the abstract:

Learn how to take personalized communications beyond email. Before email, there was data merge, which enables you to create personalized print materials using the design tools you already know and love. Whether for mailing campaigns, photo books, directories, business cards, or even t-shirts, you can use data merge to personalize your projects.

In this session, you’ll discover how to:

  • Unlock the potential of personalization in InDesign
  • Use Illustrator and Photoshop to generate personalized assets to use with InDesign
  • Manage personalization on a large scale with popular third-party variable data printing (VDP) solutions
Share on Facebook

Considerations for using Secure Content with DPS

In Release 30 of the Digital Publishing Suite, Adobe introduced a feature for Enterprise customers that lets a publisher encrypt folios. This feature arose out of many requests from Corporate customers who wanted to use DPS for sensitive content but believed that the DPS Service did not offer robust content protection for folios in the Distribution Service or in flight between the Service and a Custom Viewer. While Device Content Protection is an effective method of protecting content on the device, it does not offer protection for content in the DPS Service. In Release 30, a publisher can now opt to publish encrypted folios to the Distribution Service, which satisfies many customers’ requirements for using DPS to deliver sensitive content to their tablet-enabled workforces. Enabling encryption impacts the content creation, publishing, and reading experiences, however. This article will explore the changes to each of those experiences.

Enabling Secure Content

The DPS Help Document for Secure Content provides instructions on how to enable encrypted folios. It’s not just about folios, as you’ll discover when you read that article. Your app must be built to enable the device’s Secure Content mechanism, which means that you will need to rebuild your existing app. My Protecting content on an iOS Device with DPS article in DevNet outlines the hows and whys of enabling secure content on your iOS device. Of course, your custom Viewer needs to be at R30 or higher to use encrypted folios, so you can use this as an opportunity to update your Push Notification tokens as well as add in some other App features like the Welcome Screen.

In conjunction with updating  your Viewer to R30, you also need to enable Secure Content in your Application Account. This requires administrative access to the Account Administration tool.

Enable Secure Content in DPS Account Administration

Enable Secure Content in DPS Account Administration

Once enabled, the account will now have some limits applied to it, which we will explore in some detail.

Limits enhance security for content creators

Secure content has some important implications for workflow. From the content creation side, customers expect that it should be hard for content to escape the control of the Enterprise. For content creators, it means that they will be restricted in how they can proof or share secure articles.

Preview options for Secure Content

Preview options for Secure Content

Proofing

Proofing folios in a Secure Content account is limited to either desktop or tethered proofing. This means that in order to proof a folio, you need to either test it on the desktop from InDesign or connect your iPad to your Mac and turn on the Content Viewer. Once connected, you can click on the Preview… menu in the Folio Builder panel and choose your iPad. For customers using the Media Publisher in Adobe Experience Manager or another Web CMS for managing folio content, this presents a unique challenge.

When publishers use Media Publisher or other CMS, the expectation is that all folio creation is done in a browser and that InDesign is not usually part of the workflow. It is not uncommon for there to be hundreds of contributors in a large organization, and those contributors tend to be business users or knowledge workers with no access to InDesign. For accounts without Secure Content enabled, this presents no problem, since content creators can always push their content to the Folio Producer, turn on their iPad, open Content Viewer, and sign in with the Application Account credentials to proof content.

One potential workaround is to create content using a “dummy” account that does not have Secure Content enabled. This “dummy” or staging account can be an Application account or an individual contributor account that will never have an App associated with it and will only be used as a staging account for the Secure Content. As a best practice, the Enterprise should develop a policy around these staging accounts so that content will be auditable by appropriate regulatory or brand authorities within the Enterprise. In addition, the Enterprise should establish review and approval workflows within these staging accounts and a workflow for migrating content from the staging account to the deployment (Secure Content) account. Authors will create and proof their content in the staging account. Once ready for review and approval, the author would start the review and approval workflow and reviewers can review content on their iPads with Content Viewer. In cases where the Enterprise does not want any content to be viewable unless on a tethered iPad, then authors and reviewers will need access to InDesign on their desktop machines in order to proof their folios.

Article Sharing

All article sharing from a Secure Content account will be disabled. This means that if you currently share content between accounts, you will need to consider the flow of that content. It is possible to share an article from an account that does not have Secure Content enabled to a Secure Content account, though, as described in the previous paragraph in the staging account workflow. The expectation is that content in a secure account should remain in the secure account, and limiting sharing from that account reduces risk. As stated above, customers may need to adjust their workflows to consider the secure account as an endpoint for content rather than a source of content in situations where folio sharing is common.

In order to publish shared content in the secure account, a person with appropriate authority will need to log into Folio Producer and copy the shared article. Once copied, the original folio can be deleted from the Secure Content account, which will break the sharing relationship with the staging account. Unless there is a reason to keep the original shared folio in place, it may be best to remove the shared folio to reduce confusion and clutter in the Folio Producer.

Publishing encrypted folios

Enable encrypted folio upon publishing

Enable encrypted folio upon publishing

Once approved, it’s time to publish the folio. Once all of the required metadata is in place, you can push the Publish button in Folio Producer. You will notice a new checkbox: Encrypt Folio. This needs to be enabled for your folio to be encrypted in the Distribution Service.

In addition, there is an expectation among Enterprise customers that secure content needs to reside behind authentication. As a result, readers need to be entitled to any secure folios in order to view them in a Custom Viewer. This means that all encrypted folios need to be Retail folios, and the Custom Viewer needs to leverage Direct Entitlement or, more granularly, Restricted Distribution. The Enterprise will need to manage the relationship between the authenticated reader and published folios in its Entitlement solution. Once you configure the folio as Retail and enable Encrypt Folio, you can Publish the folio.

Reader experience for Secure Content

Having reviewed how Secure Content constrains the content creation workflow, let’s turn to the reader experience. From the reader’s standpoint, they should not be able to tell the difference between an encrypted folio and an non-encrypted folio. While this is generally true, there are a few differences that readers may notice when using Secure Content.

Complete download required

In a traditional workflow, DPS offers progressive downloads for content. This feature allows a reader to begin reading an article while other articles are loading. In a Secure Content workflow, the entire folio needs to be present on the device in order for it to be decrypted. As a result, secure folios may appear to take longer to download. You may want to adjust your strategy with respect to folio organization if you routinely make very large folios if the download experience is disruptive. For most Enterprise customers implementing Content Protection, this delay should be communicated to users so that they are prepared for longer wait times when they first download a folio.

Once downloaded, the folio is ready for reading and will behave like any other folio, with the exception of Social Sharing.

Mitigating social sharing risk

One of the ways that content can escape the control of the Enterprise is through a reader socially sharing the article. When you enable Secure Content, any encrypted articles will not be able to be socially shared, regardless of the settings in the Application Account. This also means that no Web renditions will be created from any articles in encrypted folios, regardless of whether they are Protected, Metered or Free. It is a best practice, therefore, to disable Social Sharing in App Builder when making apps for Secure Content accounts. For many Corporate use cases, social sharing is inappropriate, since the content in the app is usually intended to be viewed in the secure context of the Custom Viewer. If it is necessary to mix Socially Shareable articles with encrypted articles, then the user may be able to generate a “dead” URL for the encrypted article by tapping on the Social Share button, which would be a jarring user experience. In that instance, it is best to warn the reader that an article is protected and that it is not intended to be Socially Shared.

Use cases for Secure Content

Secure Content is inappropriate for most traditional publishing use cases, and it was not designed as a Digital Rights Management (DRM) scheme for folios. It is intended to offer Corporate publishers a method of protecting sensitive content while that content is in the Folio Distribution service and to limit the pathways for that content to escape the control of the Enterprise.

Common use cases for Secure Content include manuals, Board of Directors packages, regulated content, proprietary documentation, sales material, and other sensitive materials. Knowing that all encryption is susceptible to attack, Adobe uses very powerful encryption technology to protect the folios in the Distribution Service. Nevertheless, each Enterprise needs to evaluate whether its content requires this level of protection. For many customers, unencrypted folios are perfectly acceptable. For others, encryption will be a requirement. Encrypted content expands the reach of the DPS service for Enterprises and offers those customers a pathway to distribute sensitive content to tablets.

 

Share on Facebook

Sending email and email attachments from DPS publications

Many of my customers have asked how to send an email from within a DPS publication. For instance, in a sales enablement situation, it’s often necessary to share documentation after the salesperson has discussed the products or services with their clients. In an earlier blog post, I detailed how to display PDFs and other document types directly in your DPS applications. While this is good, it’s not a leave-behind that many sales people require. I wanted to explore some ways to send email from DPS publications, and here are a few of the ways I concocted this afternoon. (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 sending emails from a DPS folio.)

Just send it!

Often, it is necessary to just send an email to a specific address. This is easiest to achieve with a hyperlink or a button with a URL destination that uses the mailto: tag. For instance,

mailto:someone@example.com?cc=someoneelse@example.com&bcc=andsomeoneelse@example.com&subject=Summer%20Party&body=You%20are%20invited%20to%20a%20big%20summer%20party!

is a URL that will fire off an email in the device email client. This email will be addressed to someone@example.com with CC to someonelse@example.com and BCC to andsomeoneelse@example.com. Its subject will be Summer Party and the content will be You are invited to a big summer party! It will be sent by the default email account on the device’s email client. Copy that URL into a button URL action in InDesign, and presto, you have an email button.

You can get creative with the content, of course. You can include links to files, so long as the link is a fully formed URL path. For iOS Mail, use the <br> tag to go to a new line. For other mail clients, you’ll have to experiment. Here’s how I set up my email button.

The URL destination:

mailto:someone@example.com?subject=Tax%20Time&body=Pay%20your%20taxes!<br>http://www.irs.gov/pub/irs-pdf/fw4.pdf

sends an email to someone@example.com with the subject Tax Time and

Pay your taxes!

http://www.irs.gov/pub/irs-pdf/fw4.pdf

as the message. Most email clients will interpret the link to the PDF as a hyperlink and will allow the reader to click or tap on the link and view the tax form.

Let’s get a little more sophisticated with this now. In InDesign CS6, we can insert HTML directly onto our layouts via the Object>Insert HTML menu. I have created a little form that has two inputs: email address and a menu to choose which file to include as a link in the body of the email message.

Copy and paste the following into your InDesign layout using Object>Insert HTML and preview on your iPad. If you have InDesign CS5 or CS5.5, you can save this as a .html file and point at it in a Web Content overlay.

<style type="text/css">
.emailform {
 height: 100px;
 width: 350px;
 font-family: Verdana, Geneva, sans-serif;
 font-size: 16px;
 font-style: normal;
 text-align: center;
 white-space: normal;
}
</style>
<script>
function sendMail() {
 var link = "mailto:"+document.getElementById('emailAddress').value
 + "?cc=myCCaddress@example.com"
 + "&subject=" + escape("Pay your Taxes!")
 + "&body=" + escape('Use this form to start the onboarding process.<br><a href="'+document.getElementById('chooseFile').value+'">Download your W-4 form now</a>')
 ;
window.location.href = link;
}
</script>
</head>
<body>
<div class="emailform">
 Email address:
 <input type="text" name="emailAddress" id="emailAddress" />
 </br>
 <select name="chooseFile" id="chooseFile">
 <option value="http://www.irs.gov/pub/irs-pdf/fw4.pdf">Federal W4</option>
 <option value="http://www.maine.gov/revenue/forms/with/2012/12_w4me.pdf">MAINE W4</option>
 </select>
 <button onclick="sendMail(); return false">Send email</button>
</div>
</body>

 

Of course, you will need to modify it to meet your use case, especially whether you want to include the CC line and which files you want in the menu.

Set the InDesign CS6 will automatically create a Web Content Overlay for you, and you need to configure it to your taste. Since I set my background color in CSS to match the background frame color in InDesign, I have set mine to transparent and to autostart with a slight delay so that it will only fire when the user actually views it. You must enable user interactions if you want the user to be able to fill out the form. Note that with iOS Mail, you can use HTML formatting in your message, so have fun with the message body. I believe that this technique only allows about 2000 characters in the body, so you might need to keep your messages short. Also, this javascript method will force the user to agree to be sent to the Mail application from the folio, while the direct URL method won’t. Nevertheless, this is a very flexible and robust solution for creating email forms within your DPS application.

Here’s what my example looks like on the iPad.

Now I tap the Send Email button…

Now I return to my folio and enter some info in the email form…

Pretty neat, eh?

Links to files are OK, but what about attachments?

If you need to send attachments to your email, then you are out of luck with a URL. You will need to implement another method. I’ll describe two of them here.

The easiest to make is a web form with an emailer server-side application as its action. Remember that you can insert HTML forms directly into InDesign CS6 with Object>Insert HTML or by putting the form in an iframe and copying and pasting the iframe code into InDesign CS6. Like my example in the previous section, include a few text fields for To: and From:, and perhaps even a menu to choose which file to attach. You can get fancy and have check boxes or menus that attach multiple files to the email, too. Then, in your emailer server-side application, compose and send an email using the information in the form. I have done this with PHP and MySQL hundreds of times over the years, and it is a rock solid method for sending email attachments. Of course, you should obfuscate that URL or put it behind some kind of login, ideally attached to your company’s LDAP or Active Directory, if you need security.

While I usually turn to PHP and MySQL, there are myriad ways to implement this on your server. Check to see what server-side capabilities are available to you and give it a whirl.

Thinking outside the (Mail)box…

So, what happens if you are offline? The online form won’t work, and you’ll need a different solution. On iOS, you can write a custom app with XCode that can leverage Custom URL schemes to transmit information between apps. The mailto: tag above is an example of one that’s built into iOS. Also included are sms:, tel:, and http:. You can build an app that can respond to a custom URL scheme and deploy that app to all of the users who need to send emails. Here’s an example of XCode projects that, when built, communicate with each other. http://mobile.tutsplus.com/tutorials/iphone/ios-sdk-working-with-url-schemes/

Let’s say the app named Enterprise Email that has an ID of com.adobe.jameslockman.emailsenderapp has the registered the custom URL scheme sendemail: in its plist. I can then construct a URL using either of my methods shown above in DPS that will tell iOS to communicate with Enterprise Email using URL encoding, such as: sendemail://someone@example.com&from=me@mycompany.com&file=filename.pdf This URL is easy to populate as the result of a form with or without javascript in a web content overlay.

It’s up to you to determine how to parse the incoming string in your custom app. In addition, you should probably have the app check in to a central file repository from time to time and pick up the list of available files and store them internally. The app should also have the ability to cache email sending requests so that it can wait until it gets a network connection to send its emails. This method completely bypasses Mail and will require the app to enable its own email sending methods. I do not have an example of this in action, but I’m considering building out a simple XCode example. If I do, I’ll post it as another entry and link to it here.

This method will only be applicable to an Enterprise who can manage deployment of apps to its installed base of devices through a Mobile Device Management (MDM) solution or other deployment method such as manual sideloading.

It’s in the mailbag

Remember that your ability to actually send email is dependent on your reader actually completing the email task in Mail. Also, the email will always be sent from their default account. They can always choose not to send the message, but in a sales situation, the sales rep will definitely want to send the message. Also, this provides an offline protection, since Mail lets you cache emails until there is an active network connection. If you need to send attachments, then you will need to look at an always online solution or the helper app solution. Your use case will dictate how far you need to go down the development road, but start simple with a URL or an embedded form. It just might be the all you need.

Share on Facebook

Using InDesign CS6 Server with CQ5.5

Many of my customers have learned that CQ5.5 DAM can be used in conjunction with InDesign Server to extract content from InDesign documents and make them available for use in web pages in CQ. This worked great with CQ5.5 and InDesign CS5.5 Server, but failed with InDesign CS6 Server. I have an easy fix that enables InDesign content extraction for CQ5.5 and InDesign CS6 Server workflows.

First, start up your CQ Author environment and log in. Open CRXDE and search for spaceUnit. It will show up in one of the InDesign scripts.

If you don’t want to search, here’s the link to the jsp.

http://localhost:4502/crx/de/index.jsp#/crx.default/jcr%3aroot/etc/dam/indesign/scripts/XHTMLExport.jsx

Direct path here: /etc/dam/indesign/scripts/XHTMLExport.jsx

Right under spaceUnit is another variable called marginUnit. Comment out those two lines of code from the script, and you should be all set.

Apparently spaceUnit and marginUnit were supported in CS5.5 and earlier, but not in CS6.

Also, Adobe Drive 4 is required for DAM integration with CS6 applications. If CS5.5 is in play, then you will need Adobe Drive 3. As of August, 2012, the download link is halfway down the right hand column of the Adobe Drive Product Page. Drive 3 and Drive 4 can coexist if you need to have CS5/5.5 and CS5

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