29 January 2013
Familiarity with basic DPS terminology.
Today, many organizations want to distribute tablet publications using the Adobe Digital Publishing Suite. Some customers may wish to engage advertising or design agencies for assistance creating the content and building DPS applications.
Customers often have long-standing relationships with their agencies for print and web projects. These traditional publishing workflows have been refined and perfected over many years of practice.
DPS projects, however, present a different set of problems and possibilities. If you are a licensee of DPS Pro or Enterprise, you need control over your content but want to maintain the option to work with multiple agencies for your creative and technical needs.
In this article, I will discuss general concerns that I have encountered with the DPS customers I support and present some workflows—including diagrams—to address them.
Access to the Digital Publishing Suite is controlled by log-ins and the role associated with them. It is important for customers to understand these roles since some or all of these roles may be passed on to agencies.
When you subscribe to the Digital Publishing Suite, one account from your company is assigned the Administrator role or Master Account. The owner of the Master Account uses the DPS Account Administration Tool to create other roles and IDs (Application and App Builder, see below).
Like the Master Account, the Admin Account can use the DPS Account Administration Tool to create Application and App Builder accounts. However, the Admin Account cannot be used to delete other accounts.
The Application Account is tied to a specific viewer app (single or multifolio). Organizations need to create a new, unique Application Account for each viewer required by the organization. Use a different Adobe ID for each custom viewer you create.
A DPS App Builder account is used to create custom viewer apps. A DPS App Builder Account may be used to build viewers for any of the Application Accounts associated with the Master Account.
Note that an ID may have both Application and App Builder privileges.
Adobe Digital Publishing Suite allows you to create two kinds of applications:
In a Single-issue viewer, a single folio is rolled into a viewer.
A Multi-issue Viewer App is essentially a shell. The Folio Producer Organizer is used to publish folios to the Adobe Distribution Service which then are served to the Multi-issue Viewer App.
In either case, the DPS App Builder tool is used to create the Viewer application. The resulting app file (e.g. .ipa for iOS devices) may be downloaded and distributed publically via application marketplaces or privately within the enterprise. To build the Viewer app, your organization’s digital certificate is required. Digital certificates are created and downloaded from a device developer portal (e.g. Apple Developer Portal). A digital certificate is unique to an organization, much like a passport is to an individual.
Organizations with a trusted, long-term relationship with their agencies may be willing to share their digital certificates with their partner. However, since a digital certificate uniquely identifies an organization, some customers are uncomfortable sharing them. In the hands of expert hackers, a digital certificate potentially could be used to gain access to private content or to publish an application without the knowledge of the organization.
With more traditional (non-DPS) app development processes, agencies could hand off an app to go through a re-signing process which replaced the agency’s certificate credentials with their own. With DPS, this workflow is not currently supported. During the app building process, certain DPS-centric properties like analytics reporting suites are embedded. While it is technically possible to re-sign a DPS app, analytics and perhaps other functions may not work properly in the app.
For this reason, organizations that do not wish to share their certificates will need to use the DPS App Builder to create their apps to ensure correct functionality.
Once a multi-folio viewer is created, the Folio Producer Organizer is used to publish the content to the viewer. Indeed, once the Publish button is pressed, the content will be immediately available to anyone with the app.
Good communication is necessary to ensure that content isn’t published before it is ready or before the target release date. In some regulated industries—such as bio-pharma organizations— a government penalty could be incurred if incorrect or misleading content is published. For this reason, regulated industries need to be especially mindful about their publishing workflows.
The best workflow for your organization will depend on the trust you have in your agency relationship, risk tolerance, security concerns and regulatory requirements.
Below, I’ve outlined four different types of workflows. The nomenclature is my own and not “Adobe official”:
The DPS End User License Agreement allows customers to pass on their credentials to others to do work their behalf. Thus, there is no prohibition from giving your agency Application and App Builder account credentials and having them “go to town.” From the DPS Master account, simply create a new ID with both privileges and share it with the agency.
With Application and App Builder account access, your agency can create content, build a viewer, and publish content to a viewer. To build a viewer, the agency would need access to your digital certificates.
Given the reality that many customers consider this a security risk, this workflow is not common. However, one workaround is to only make the certificates available on a supervised app building machine. Essentially, someone stands over the shoulder of an agency staffer who comes to your building to create the app. The agency does not have ongoing access to the certificates.
Another possibility is to use a web conferencing tool such as Adobe Connect to grant screen sharing privileges and allow the agency to “drive” the remote machine.
In this workflow, the customer gives an Application log-in for the agency. This allows the agency to build and publish content to a viewer, but not to create the viewer itself.
In this workflow, the customer takes on the burden of building the app, sometimes with the assistance of the agency who may provide HTML and other assets for the custom viewer.
This workflow allows customers to work with multiple agencies each of whom may handle the content for a different application.
For regulated industries such as those in the bio-pharma industry, this workflow may be of concern since the agency has the ability to “push the publish button”.
For regulatory compliance, particulary in the bio-pharma market, controls are often put in place to ensure that only the correct level person can publish content. To accommodate this need, the content creation and publish functions need to be separated.
During development, a folio may be shared so that others may contribute articles to it. Customers may take advantage of this to maintain control over the Publish process.
In the diagram below, I cover how this can work. The customer creates a “shell” folio in InDesign and then shares the folio with the agency. Once shared, the agency can add multiple articles to the folio and make ongoing changes during the content development process.
Since publishing is only possible from the Application account, only the customer can decide when folios may be published. Further, via the Folio Producer online, customers may lock the folio so that content cannot be updated without their approval.
Good coordination is required for this workfow since the customer needs to create and share the folio initially using InDesign using the correct settings:
Once this is complete, the agency may add cover thumbnails and create content.
Some customers, generally those in regulated industries, wish to totally separate the content creation/review process from the publishing workflow. No content should be in the system that isn’t already approved and ready to publish. It is possible to accommodate this requirement with some extra work and coordination.
In the diagram below, content creation and review takes place using the agency’s DPS installation. Later, final folios are shared to the customer’s enterprise DPS account for publishing.
In this workflow, if the agency does not yet have a DPS license, it is not necessary to buy one. The agency can create an AdobeID on https://digitalpublishing.acrobat.com/ and login using a free ‘Designer Account’. All the functionality to support this ‘Agency Share Workflow’ is available.
In this workflow, the agency shares the final folio with the customer. The customer creates a new folio and copies articles from the shared folio to the final folio. Note that article content is copied statically (not linked) assuring the customer that changes made later by the agency do not impact the final published folio.
To copy an article from one folio to another:
This workflow has some challenges:
Many of the workflows I have documented here have been in response to customer regulatory concerns. The FDA—for example—does not have specific rules related to DPS and much is open to interpretation. It is not possible to engineer all human error out the digital publishing process.
As you add complexity to the publishing process, you also add cost and time and make it harder for your agency to do their job.
Even in regulated industries, the best way to approach customer-agency workflow is to have a good understanding of DPS and document how you will use the system. The creation of Standard Operating Procedures (SOPs) helps to ensure that the publishing process will go smoothly and meet regulatory requriements.
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License. Permissions beyond the scope of this license, pertaining to the examples of code included within this work are available at Adobe.