I use a similar technique, but just duplicate the InDesign document and give it a suffix like ProjectName_a or ProjectName_b. When I'm done, I package, copy all the linked files I might want to edit again at some point to an _Assets folder within the new packaged project folder, and tend to adjusting, finalizing and flattening all the links.

I use an offsite Subversion repository and SmartSVN to manage my project versions. The beauty of something like Subversion is that it basically does the process you described automatically. You can roll back to any specific version of a file and it will only take up extra disk space for changed files. Also, if you ever have to work with a team, it makes collaboration MUCH easier.

There is a small learning curve, but it is well worth the effort.

While I use my own servers for SVN hosting, you can find inexpensive hosting starting at $2.50/mo (http://www.projectlocker.com/scenario/startup).

Here's a good article on the benefits and a basic howto on Subversion for Designers: http://www.thinkvitamin.com/features/design/subversion-for-designers

While this service isn't publicly available yet, DropBox looks like a GREAT user-friendly alternative to both of these methods. Check out the video preview @ http://getdropbox.com . IF you get a beta invite, please send one my way.

Though I don't duplicate ALL the files in the folder, just the ones that change. I also suffer from the same problem with Version Cue. I know what it's supposed to do, but there's no clear-cut directions on how to use it. From all I've heard, it really is for design studios with multiple designers working on the same files.

-----------
Visit The Graphic Mac for graphics and Mac OS tips, reviews, tutorials and discussion.

I have a New Project folder on my desktop. Inside this New Project folder are 3 empty folders, each prefixed with a bullet. The bullet insures that these will always be easily-assessable at the top of the list when viewing the contents of the project folder.

• Finals: This is where the files that go to press are saved (if it's a print job).

• Originals: This is where all the crap they give me to work with goes as well as files I build in developing the project.

• Proofs: This is where the (you guessed it) Proofs go.

When a new project comes in, I copy this folder into my "Active Projects" folder and simply rename it to whatever the project is called. It keeps me organized and consistent, project-to-project.

As for versioning, I just do the save-as V1, V2, V3 thing.

Terry Thornhill

e-zign Design Group

Our team is using Version Cue and it's been working great. I quickly realized when the team went from one (just me) to about five people needing to access the creative assets that a better solution had to be put in place. Version Cue does very much the same thing Ivan does with his versioning strategy but behind the scenes. Much like subversion, Version Cue does implicit check outs of files when you open them from your Version Cue folder (either through Bridge or your file system). Once a file is checked out, other Version Cue users who browse to that file or attempts to open it up will see that you have it checked out. They can opt to keep working on the file but they know full well they're working on the same file as you.

Once you're done with your changes or feel you reached a good milestone, you save it as a version. Most Adobe apps have Version Cue support built in. Older, Macromedia apps do not (like Fireworks). You'll have to use Bridge to check those in. You can keep locally saving your work to a file but when you want to share your version with others in your team (or you want to have the version to revert to), then you'll want to save it as a version.

Behind the scenes, Version Cue is doing pretty much what Ivan is suggesting to do manually. It saves the file in a nested (hidden) folder and promotes your latest, checked in file as the most current and appends the version number in the details. You can easily view past versions of your files in Bridge and promote them as new versions if needs be. It can totally save you as well, since you can accidentally save over your local file and ruin the file but then revert back to your previously save Version Cue file. This totally happened to me last week when I accidentally cropped a Photoshop file the wrong dimensions.

Version Cue may seem too much overhead for someone working on their own who just wants an easy way to save "back versions". But I have to tell you it's great when you have a team that needs to share assets and keep track of various versions. The integration in many of the Adobe apps and being able to visually view them in Bridge makes it a no-brainer for this sort of situation too.

It's sad to think that many creative professionals either don't know about Version Cue or can't figure out how to use it. I know Adobe struggled to make the concept of checking in and out as simple as possible for users (thus the implicit check ins). But being someone who contributes to developing software, it's tragic to think you spent all this time on a product to find out your general audience doesn't even use it. I know the whole point of them continuing to develop Version Cue was to eliminate the very thing that many designers tend to do for their versioning scheme. I don't know what the answer is to all this but if Adobe is listening, they should see what they can do to fix the situation.

I agree that Adobe needs to step up its promotion and explanation of Version Cue. I've made half-hearted attempts to figure it out as well and always thought that it must be a third party add-on since it's barely mentioned.

Since most clients want to see multiple options for each stage of the project, I've integrated a file name system that incorporates my version system. I give the client a two or three letter acronym code and use rounds and versions. The adobe files just get rounds with layers that contain the elements of the different versions. The pdf/jpeg proofs get version numbers. So for example, if I were working on a website for CorporationABC, the third round of 4 or 5 proofs would be called ABC-WebsiteR3V1.html or ABC-WebsiteR3V4.html

If they're print files, I usually give them pdf proofs, if they're web files, they get an html jpeg proof. Using FireFTP (best firefox addon out there!) I drag them all to my ftp site and send them links, often embedded right in the text of the email.

By the time I'm finished a project I have a folder for the client, a folder for the project inside that, an a folder for each round of proofs/revisions, with a master Adobe file and the pdf or html/jpeg proofs. Upon completion of the project I usually go back and delete all but the final masterfile (which usually has all the required layers etc.) and a few of the proofs. For really important ones I save more of the originals on my external HD just in case I ever need to reference them in a discussion or dispute.

Using Rounds and Versions is also a good way for the client to get a sense of how much work you're putting into the project. If they see that they're choosing from five version for the 4th time, they're hopefully less likely to keep asking for changes.

One thing I haven't nailed down yet is the concept of a limited number of rounds on a project. I ultimately want each client to feel like they're getting exactly what they want and not something I've forced on them because they've run out of rounds, but too many options and unlimited changes can devalue my time, create even pickier clients who start to feel like they want more creative control, and drag on projects much longer than expected.

j.

I also add a "-s" (for screen) or a "-pb" (for print w. bleeds) at the end of the pdf file name to indicate whether the document has bleeds for print or not and what quality it's saved at. I like to show a screen version without bleeds to clients so they can see how it will look after it's trimmed. For print files that don't have full bleeds, the suffix is "-pnb"