Version Cue: Balancing Simplicity, Functionality in CS Workflow Tool

Mark Walker

1

For more information about The Seybold Report, click here.

---

Perhaps the hardest software challenge in the graphic arts today is to invent a workflow-support tool for creative professionals. The obstacles are many: Creative people are notoriously individualistic and resistant any prescriptive approach to managing their daily tasks. The majority of artists and designers work solo or in very small teams, making it hard to cost-justify any of today’s database-driven workflow or content-management products. They perform a wide range of tasks, address the needs of many graphic specialties and form ad hoc business relationships of astonishing diversity. For many creatives, the only organizational support they get from their computers comes from the hierarchy of the file system and the sorting that’s implied by file names. There ought to be a better way.

Finding that better way is the challenge that Adobe has taken upon itself in the development of Version Cue, which is a new, under-the-hood technology in the Adobe Creative Suite. Aware that a “one-size-fits-all” approach will appeal to no one, Adobe has opted for a versioning/workflow tool that is flexible and non-coercive, yet offers functionality that can benefit almost any professional. Aware, too, that there’s a fine line between user education and hype, Adobe has so far been content to let Version Cue keep a low profile.

Version Cue does what its name suggests: It tracks the evolution of a digital asset — an image, drawing, layout, etc. — as a series of versions. It gives the creator various cues about each asset’s state of development. It makes sure that external applications get the latest version of each asset. And it does these things without relying on file-naming conventions or other error-prone hacks.

For the past several weeks, we have run Version Cue at the Seybold Report office. We have tried several configurations — strict and permissive access controls, inside and outside the firewall, Mac and Windows servers and clients — within a print-first design workflow. (Version Cue also supports Adobe’s GoLive Web-site development package, but we did not investigate that aspect of the system.) What we have found is that Version Cue wields some impressively strong technology to attain excellent ease of use. But it also leaves us wondering why a few additional capabilities aren’t there.

Design considerations. A partial answer, we’re told, is that Adobe’s target market for Version Cue is creative professionals — the same folks who are likely to be users of Photoshop, Illustrator, InDesign, and GoLive. That implied certain constraints in designing Version Cue. For instance, although Adobe could assume that all the members of a design team were sharing files over a network, it could not assume that the shop had a central file server; the users might be relying on the basic peer-to-peer file sharing available in Windows or Mac OS. Adobe could assume that the members wanted some sort of structured workflow, but it knew that many designers loathe the “process Nazi” mentality that many systems impose. Perhaps most important, Adobe had learned in earlier experiments that many of its customers had no experience with formal asset-management tools — indeed, many had probably never considered whether they might benefit from one.

Adobe therefore decided to proceed incrementally, building in small steps and making maximum use of its existing technologies, such as the Photoshop image browser and XMP metadata. It would begin with a version-tracking product of limited capabilities and then, depending on what the customers requested, add features and functions. In this way, it would simultaneously build the tools that its users really wanted, even as it helped them get acclimated to using a database instead of the file system to keep track of their files and projects. The current Version Cue is the first step along that road.

Version Cue In Operation
Version Cue has two components: The first, which Adobe calls the Workspace, is the version-serving process that manages the asset repository; the second comprises a set of elective capabilities in each Creative Suite application. These capabilities, which add options to the file opening and saving steps, are by default not active in a newly installed copy of Photoshop, Illustrator or InDesign, but they are easily activated by a check box in the Preferences dialog of each application. Even after they are activated, the capabilities need not be used; the standard file-opening and -saving functions remain available at all times. Likewise, the version-serving process is nearly invisible, making itself known only when a client application requires its services.

Most shops that need a versioning tool will want to configure their workspace processes to start automatically each time the computers boot up. We say “computers” because each workstation can run its own versioning workspace, which may or may not be accessible to other users on the network. All the workspaces are autonomous peers, whether they are running on laptops or on central file servers, and there is no central administration or synchronization point for the system. In fact, as we shall elaborate below, the Version Cue architecture allows version servers to join and leave the network more-or-less at will.

Adobe provides a system control panel to handle the basic version-server configuration parameters — whether to start automatically, amount of system RAM the server may use, whether to allow connections from the network — and optimization settings for the number of users and types of media to be supported. All other server controls — for creating and retiring projects, setting access permissions on a per-project basis, importing and exporting assets, etc. — are managed by a Web-browser interface or by the Version Cue plug-in within the Creative Suite applications.

Degrees of control. The basic unit of control in Version Cue is the project. A project can contain any number of assets, each of which has its own version history, but all assets in the project follow the same sharing model. The model is defined by three yes-no decisions:

• Share this project with others. If not, the project will be visible only on the local computer, i.e., the one that’s running this instance of Version Cue. Sharing is based on standard TCP/IP (using port 3703) and SOAP protocols; absent any firewalls, a shared project can theoretically be visible worldwide.
• Require users to authenticate . Turning this switch off creates a workflow in which every user is blindly trusted. Obviously, this is not a good idea if the project is visible to the Internet, and whether it’s a good idea within the walls depends greatly on the security needs of the project contents. (For example, a public company may have a legal obligation to restrict access to financial information prior to its formal publication.) With the switch on, you can determine which users will have access to the project and can limit each user to read-only, read-write or full administrative privileges (see Figure 2). There is no provision for finer-grained discriminations, such as trusting all users within the firewall but requiring passwords for connections originating outside the firewall, or granting different rights for different assets within a project.

  

  Figure 2: Access rights. If authentication is turned on, you’ll need to set up users and give them rights. Unlike the Novell or Microsoft enterprise-scale permission models, Adobe has but four classes of users, shown here, and three capabilities (read, write and administer).

• Enable lock protection. Turning this switch off allows multiple users to use (and even to edit) an asset concurrently. The server will issue a warning, but it will allow you to proceed. There are times when this is perfectly reasonable (e.g., grabbing an image to reserve space on the page) provided your users understand the ramifications. With the switch on, the system simulates a “check-out, check-in” workflow in which only one user at a time can create new versions of the file. There is an administrative tool to break a lock if necessary (e.g., if the user checked the file out to his laptop and went home), and, when the user whose lock is broken tries to check the asset back in, the system will give notice that a reconciliation may be needed (see Figure

  

  Figure 3: Enforced locking. Larger workgroups, or those with remote clients, should probably opt for the stricter form of access control. Users who see this message can still save locally, or they can create a new asset within the project if immediate uploading is important.

Working with files. Within a Creative Suite application, Version Cue makes an appearance only at three times: when you open a file, when you close it and when you ask for its version history. At file-opening time, Version Cue adds one new option: A button switches between the catalog of Version Cue-managed assets and the usual directory hierarchy that your computer’s operating system offers. Version Cue displays a list of projects, within which there are folders and files. It does not matter if projects are on different servers; Version Cue presents an integrated list. It also gives you a variety of “cues,” in the form of tool-tips or popup info boxes, about each item (see Figure 4). For files, it displays the lock state, the current version number and the version comment, among other facts, so you can have a pretty good idea of the state of the asset that you are opening.

When you select the file you wish to open, Version Cue responds by downloading a working copy from the server to your local disk (see Note 1 at left). The working copy is what Photoshop actually opens or InDesign actually places on the page. Version Cue also sets up a folder structure for the project on your local disk. If you then disconnect from the network (or restart your computer with the Version Cue workspace turned off), you can still work with the file, saving it from time to time or attaching it to e-mails or whatever you need to do (see Figure 5).

It’s important to understand that saving a file updates only your working copy. Changes to your working copy are not visible to other Version Cue users (see Figure 6). If you want to update the shared repository, you have to “save a version,” which uploads the changes to a new copy of the asset, which has its own version number. There are two ways to do this. One is by an explicit Save A Version menu command. The other is simply to close the file; Version Cue will then ask if you want to save a version.

Working with locks. As noted above, Version Cue offers two ways of preventing users from clobbering each others’ work. One is a permissive “users know best” approach; Version Cue will issue alerts if multiple users try to edit the same asset, but it won’t stop them. The other is a strict “traffic cop” approach; Version Cue will grant full access to the first user who takes the file and read-only access to all subsequent users.

In either approach, Version Cue does not lock the file when the user first opens it. After all, the user’s intention might be merely to examine the file and then close it. Locking only kicks in when the first edit is made to the file — when the server can legitimately anticipate that a new version might be in progress. For instance, three users might all open the same image, unaware that their colleagues are doing the same. But as soon as one of them changes a single word or pixel, the other two get a notice that they may no longer have the most current version.

In a permissive workflow, the latter two can still proceed with their own edits. This need not be a dangerous activity: They might be planning to print a throwaway copy, or to create a new rendition — different resolution or color space — which, in the Version Cue approach, would be given a new name and thus become a separate asset. Nevertheless, if the users attempt to do something that could cause confusion, such as save their files as new versions of the same asset, Version Cue will allow it. The system will merely issue an alert saying that manual reconciliation might be needed (see Figure 7). There are no tools within Version Cue to identify the nature of the differences.

In the strict workflow, the system behaves almost the same way: It allows multiple users to open the file and (with warnings) to make changes. However, Version Cue remembers who was first to open the file, and it will allow only that user to save new versions. Other users can save changes locally, but if they try to upload a version, they will get a stern denial.

Cleaning up.Keeping lots of interim versions of an asset is valuable — for a while. Eventually, though, it becomes necessary to clean up the workspace. Version Cue provides a few tools to manage old data.

• Backup. A compressed copy of the entire Version Cue repository can be made. It initially resides on the version-server’s local disk (the backup program doesn’t offer a choice here), but you can manually move it to offline media. The backup includes all versions of all assets.
• Export. An uncompressed copy of a single project, replicating its file and folder structure, can be written to the location of your choice. Only the current version of each asset is written out.
• Bulk deletion.Version Cue allows you to remove old versions of all the assets, either in a single project or in all projects at once. You can wipe away all versions prior to a chosen date, or you can wipe all but the most recent n versions. Or you can do both — and, although these options might be contradictory, the system gives you no clue which takes priority. Ah, well, you did make a backup first, didn’t you?
• Selective deletion. Each Creative Suite application can delete specific past versions of a single asset while it is open for editing. There is no system-level tool for deleting individual versions, however. To selectively delete old layout versions, you must run InDesign; to delete older TIFFs, you must use Photoshop.

Deleting old versions removes them from the repository, but it does not remove any of the working copies that users may have downloaded (although those copies will almost always be the current version, and thus unaffected). Likewise, deleting an entire asset or project has no impact on any local copies. It is up to each user to police the leftover junk on his own disk. This is only a minor nuisance, in our view. There is no harm in keeping old assets around, because as soon as you start to work with one, the system will update you if a newer version exists. (If it can — you’ll get no update if the workspace server has gone offline.) Likewise, erasing your local copy simply means that you will automatically download a fresh version from the repository the next time you start to work with it.

InDesign limitations. Version Cue manages InDesign documents exactly as described above; a layout is an asset like any other. However, Version Cue does not take quite as active a role in managing the images and drawings that have been placed on the page. At the time you execute the Place command, the server makes sure you get the most recent version of the asset. But once it’s on the page, InDesign takes a low-profile approach to version updates that may be occurring as you work. It periodically queries the server about updates, but it displays them only as a status icon in the Links palette.

Adobe took this tack because many designers use FPO (for position only) graphics during the layout-building process, and the last thing they need is popup alerts for new versions. These users can simply close the Links palette to work undisturbed. On the other hand, as deadlines draw nigh, it might be very important to update the layout as soon a graphic has been modified, which is easily accomplished by clicking the graphic’s icon in the palette.

In any case, when you print the InDesign document, Version Cue will be consulted and you’ll see a warning if you don’t have the latest version of each asset. (You can ignore the warning and print with the older version, if you wish.) Likewise, you’ll be warned if any text files that you imported have been updated. Version Cue does not manage text — doing that would require integration with your word-processing application — but (as it has always done) InDesign checks the timestamps of the files that were imported (see Note 2 at left).

In addition, each time you open a layout, InDesign checks its links to external graphics and warns you if any have been changed. For graphics that you imported via the file system, it checks timestamps. For graphics that came from a Version Cue repository, it queries the appropriate server. (Servers that have gone offline tend to cause lengthy delays here, which can be a nuisance.) The Links palette combines the results of both procedures and gives you the opportunity to update objects from either source.

For most workflows, you can use InDesign’s automatic link-fixing functions to bring you the latest versions of your images. However, if you are working with a document that requires a specific, earlier version, you must be careful not to let InDesign automatically fix links for you. That’s because if you inadvertently get a too-new version, there is no going back; Version Cue cannot give InDesign older versions of its graphics.

In Version Cue 1.0, past versions of assets are accessible only to the application that created them. Thus, InDesign can call up past versions of its layouts, just as Photoshop can call up previous versions of a TIFF image. But InDesign cannot place or link anything but the latest version of a TIFF. If you want to protect a layout from future updates to a graphic, you should embed it (via an option in the Links palette) after you have placed it on the page (see Note 3 at left). If you elect not to do this, you must forever make sure never to automatically update the links. Because there is no way to turn off the update prompt, nor to undo an automatic update once saved, we see the potential for inadvertently introducing version errors, even in a small workgroup, if multiple people collaborate on a set of layouts for a single project.

We view Adobe’s application-specific approach to accessing versions as entirely appropriate behavior for Photoshop or Illustrator, which are primarily used for creation of new assets. But we think it’s a flaw for InDesign, whose function is to integrate text and graphics from external sources.

Conclusion
“Version” is a broad concept in common speech. But within the context of Version Cue 1.0, Adobe means something quite specific: A version is a snapshot of the state of an asset at a particular point in time (see Figure 8).

What Version Cue does not tell you or keep track of (aside from the comment field) is the nature of the versioning change. For example, it does not differentiate:

• Renditions of a single asset in various color spaces, resolutions, encodings or output media;
• Relatives within a family of similar assets, such as a series of photos of the same object with different lighting;
• Forks in the development path, by which assets with a common ancestor take on separate identities.

In Version Cue 1.0, past versions of assets are accessible only to the application that created them.

Adobe has forthrightly stated that if your workflow requires any of these concepts, Version Cue is not going to be a solution — at least, not in the first release. Rather, you will have to continue managing your assets the old-fashioned way, with careful adherence to a set of file-naming conventions and judicious use of the Save As command, or invest in a digital asset management (DAM) system. Adobe believes that, although a DAM system that could track renditions, derivatives, relatives, forks and version snapshots might be ideal for some purposes, it would surely be over-complicated for others. In particular, it would miss the market that Adobe is targeting for Version Cue, namely small design studios and small production teams. What’s more, Adobe says, even the current, embryonic versioning capability can bring considerable benefits to its users — especially if the alternative is no automation at all.

What it has. Version Cue provides several of the asset-management functions that a small design shop needs. It offers:

• Multiuser workflow.Version Cue reduces the hazards when project team members seek to contribute to each others’ efforts. It offers either gentle or draconian access controls and supports a variety of project types and workflow practices.
• Development history of each asset.You can retrace the milestones along the way, examining the state of the asset and, via the version comments, the rationale or environment for which the asset was versioned. While the project is active, the version stack helps new contributors get up to speed and quickly locate previous versions when clients change their minds. After the project is archived, the records can be used for artistic post-mortems, to help justify the size of the artist’s invoice, as evidence in copyright disputes, etc.
• Low cost.Version Cue is bundled with the Adobe Creative Suite. Owners of earlier versions of Photoshop, Illustrator, InDesign and GoLive may or may not be sufficiently impressed by the new features of each product to pay full price for its upgrade separately, but we think that the collection as a whole justifies its price. With Version Cue, the upgrade is almost a no-brainer, even in a one-man shop.

What it lacks. However, it’s clear that Version Cue lacks many functions that would be desirable even to firms within Adobe’s target market of small studios.

• Text authoring. Version Cue is an Adobe-only product, and Adobe does not have a text-authoring tool in its arsenal. (We admit an exception for InCopy, but it isn’t part of Creative Suite and it isn’t widely used.)
• Version searches. It is possible to search for a specific past version based on text strings within the version comments, but only in a limited way: You can only search within a specific project, and you will always be shown the current version, even if the search pattern was found in an older version. This would obviously be more useful if you could search across projects, and if the search result told you which version(s) met your criteria.
• Business support. A logging function that recorded the time spent on each project would be well received, we think, especially if it could export its data to some of the popular small-office billing systems.
• XMP integration. We’re told that Version Cue stores its version comments (and other version facts that exist but aren’t visible in the 1.0 release) as XMP metadata within Photoshop, Illustrator or InDesign files. However, the tool for searching the text of the version comments (a tab within the file-open dialog) is entirely separate from the file browser that lets you search the other metadata. Adobe clearly needs to work on a unified presentation of all XMP metadata.
• Client grouping. Version Cue tracks projects, but it lacks the larger concept of the client (for which a shop might have several projects in motion). We’d like to be able to archive projects, set access controls and prepare reports on both a per-client and per-project basis.
• API. Perhaps the most important thing for Adobe to add is a software developer kit and an API. This would allow third parties to write interfaces to word processors (notably Microsoft Word), external DAM systems, and the like, and also to extend the functionality of the Version Cue database. We’re told that an SDK is in the works, but no timeline has been announced; it may be intended to accompany a future release of Version Cue.There are, of course, any number of other functions that we could ask for, such as user-defined fields for Version Cue to manage and a general-purpose user interface for viewing all versions of all assets in a project. In terms of the current 1.0 version, the one oversight that we think ought to be fixed is the inability of InDesign to see previous versions of objects as you select and place them on the page.Where does PDF fit? We should also note that Acrobat 6 does not (yet) support Version Cue. In print production, where PDF is primarily a container for final-form documents, this is hardly a material omission. But in a design shop, it would be very useful to marry the comps and proofs — which are likely to be PDFs — with specific versions of assets. And in the broader office environment, Adobe continues to push PDF as an all-purpose data format, and to play that role well, it will have to be integrated with Version Cue. Interestingly, PDF has its own internal mechanism for preserving past versions, including text changes, and we will be curious to see how Adobe melds the two approaches.Stay tuned. Adobe has tried several times to develop a simple yet powerful approach to workflow automation and digital asset management — something that would have the same impact upon the DAM world that PageMaker had on typography. Its past attempts came to naught in the marketplace. So this time, Adobe is proceeding very cautiously, offering a basic piece of the workflow-automation puzzle and waiting to learn how its users put it to work and what features they request as a result. Only thus, it believes, will it truly be able to serve its target markets. It will be fascinating to see what the next release of Version Cue looks like.© 2001–2004 by Seybold Publications. All rights reserved. Reproduction in whole or in part without written permission is strictly prohibited.