Posts tagged "questions"

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:

Learn more about building Enterprise Signed Viewer Applications with DPS:

Version Cue and Adobe Creative Suite 5

From time to time, customers ask me how to use Version Cue with Adobe Creative Suite 5. Version Cue is not a platform that Adobe will support going forward, but for now, there is at least a means of using Version Cue CS4 with Creative Suite 5. Drive 2 is available now and is out of beta. Get it here.

Most recently, I had a customer ask about how to migrate their Version Cue CS2 workflow to a Version Cue CS4 and Creative Suite 5 workflow.

To migrate, you’ll need to go from VC CS2 to VC CS3 and finally to VC CS4. There isn’t a direct migration path from CS2 to CS4. You can migrate from CS2 to CS3 from the server administration panel’s Advanced section, and this is best done on the machine where the new server is running.

Once you’ve done that, install Drive 2 on your CS5 machines. Browse to your VC CS4 server and log in to your projects. You will be able to check content in and out from the desktop and from within CS5 apps. In addition, if you would like to use Bridge with VersionCue CS54 then you will need to enable VersionCue support in Bridge. After you install Drive2, you’ll see the following message when you start Bridge:

You can enable or disable Drive2 in Bridge later if you want to. Go to Bridge’s preferences, and disable the Drive 2 Startup Script. Once installed, you will have access to the inspector Panel. The metadata explorer is off by default, but you can enable it in the preferences as well.

Having done that, you will now have a new panel in Bridge that lets you access projects through Drive 2. Click on Drive 2, then click the Connect To.. icon in the Content panel.

Then, enter the URL and credentials for your server.

Once you’re connected, then you can then browse your Version Cue CS4 projects in Bridge CS5. In addition, you can show versions, examine metadata, check out files and check in new versions. You’ll be able to use Version Cue directly from within InDesign, InCopy, Photoshop, and Illustrator. You’ll also be able to view versions and check files in and out from Bridge and the desktop.

To open/check out project files from within CS5 applications, simply browse to them in the Drive 2 folder that will appear on your desktop when you log in to your server.

It is interesting to note that Drive 2 allows you to check any file type into and out of a project, not just Design application files. You can manage versions of Flash Builder files, for instance, or even your Office documents. It’s a very versatile solution for small workgroups.

Color Management in a Nutshell

A friend of mine, Margie Dana, runs a group called Boston Print Buyers. On occasion, she forwards questions from members. Here’s one that I thought I should share.

Recently we had 2 incidents where our designers’ monitor did not match ours or the vendor’s proof. This was discovered at the proofing stage of our printing process. The proof obviously did not meet the expectation of our designer since it did not match their monitor. With that said, I have been assigned the task of finding out more about calibrating our monitors so we are all looking at the same thing.

Can you answer the questions below or point us in the right direction of finding a source that can help us?

  • Should we have our Mac monitors color calibrated?
  • If so, how often?
  • Is there a preferred method across the industry?

We do have technical support for our Macs. Should we let them do it or is this something we can do ourselves?

You’ve cracked a complex issue here. It’s not just the monitors, it’s the entire proofing workflow. In short, each stage of the proofing process, from scanner/camera to monitor to proof to press needs to be in sync. This happens through two mechanisms: linearization and characterization.

Linearization is the process where we ensure that a press or proofing device gives us what we expect. Our RIP will have a lookup table that says something like: when you ask for 30% cyan in my file, I need to put down 33% cyan on my plate because the press is off a little bit and we’ll compensate.” OK, it’s really a matrix of numbers without personality, but you get the idea. The RIP looks in the table to see how it should adjust each color in order to get output that matches the expectation.

Characterization is the process of determining what happens when we ask a device to produce a certain color. For instance, if I ask my monitor (an RGB device) to produce a CMYK mix of (2,57,33,5), what happens. Using this information about devices, I can make color transformations that allow me to simulate one color and how it will appear on a specific device on a completely different device. We encapsulate characterization in ICC profiles.

Now, let’s make this into a proofing workflow.

First off, not everyone linearizes. While I’d recommend it as a best practice for any printer, they don’t all linearize on a regular basis. There are at least two variables in the linearization process: the plate maker and the press itself. As you can imagine, it’s difficult to guarantee that press conditions are the same every day and on every sheet of paper. For this reason, most presses will linearize once or infrequently and depend on characterization.

Every device in the design to print workflow should be characterized. Cameras often have embedded ICC profiles that they will attach to images when they take them, but other devices need to have some measurements taken in order to get a profile. There are many different devices on the market to help produce an ICC profile. I am partial to Xrite’s family of devices, including the i1 and the Pulse. The Pulse is out of production now, but the i1 is current. These devices can make ICC profiles of monitors and printers, and provide very good results for representing color. These are not the only devices that do this, and I’ll leave it to the reader to explore more options for devices that can make ICC profiles.

Tube-based monitors used to go dim after a few years of continual usage. Also, the color would shift as the electron guns in the set would decay over time. Modern LCD monitors do not suffer from color degradation, but they do dim over time. In a working environment, it remains a best practice to set the monitor’s brightness to lower than maximum, so that you always have somewhere to go when the monitor begins to dim. Some shops measure their monitors daily. Others do is less frequently or once and forget it. I tried to adhere to at least monthly measurements, once I moved to LCD monitors.  I would try to measure Tube monitors weekly.

We characterize a monitor by using a device like an i1 to measure how the monitor presents colors. The characterization process is a mixture of manual steps and automated steps. The manual steps might be steps like : set your monitor’s brightness and contrast settings to specific targets. Having done that, the machine can take over and make measurements. The user hangs the measuring device against the screen and the profiling software reads hundreds of color combinations directly off of the screen. Knowing the colors that the monitor does produce allows a profile to be created. The profile shows how the monitor responds to specific requests and allows your proofing software (Acrobat? Photoshop?) to accurately display color by using the profile.

Knowing how the monitor responds isn’t the end of the story.In addition, we need to ensure that the environment in which you will view electronic proofs also meets a standard. There are many schools of though on color viewing, but the IDEAlliance and IPA have been working on getting ISO standards for viewing conditions and lighting. Currently, there is no standard viewing condition, but a rule of thumb is neutral gray surroundings with shielding to prevent reflections off of the monitor.

Once we have all of our devices profiled, we can now begin using them for proofing. You need to think about proofing in the following way: I want to use my X to show how my document will look when output to Y. X is usually a desktop proofer like an inkjet printer or a monitor, and Y is usually a printing press. Of course, we can put any device whose characteristics I know (for which I have an ICC profile) in place of X and Y, but these are the most common.

Let’s look at the whole picture.

To proof a file electronically, you need to open it in an application that understands soft proofing. These include Photoshop, Illustrator, InDesign and Acrobat as well as some other applications. In Creative Suite, you need to tell the application what monitor you are using by ICC profile. Then, with your file open, you need to tell the application about the press and the proofer. The statement goes like this: I want to use my monitor to view how a file will print on a Heidelberg press with dull coated paper and the proof is printed on an Epson proofer with semigloss paper. Getting all of the menus chosen correctly varies between applications, but when done right, it’s a great workflow.

So, to answer the questions, yes, you should characterize your monitors at least monthly if they’re LCD and more frequently if they are tubes. You can do it yourself with an i1 or other device, but all the characterization in the world will do you no good if you don’t take into consideration the entire proofing workflow and get all the pieces in sync. If you have a consultant available, use them to help set up the applications for proper proofing and get everyone in your group on board with proper proofing practices.