Managing project files and good old file folders

We have just covered naming, storing and locating reference files such as academic articles. There are also completely different files, for example draft papers, project plans, budgets, reports, minutes and contracts. I  handle such ‘project files’ differently from reference files: instead of tagging and automatically sorting them into date-based folders I manually save them in hierarchical folders with meaningful names. In this post I explain why such system works and what to do with files in the ‘grey’ zone which are both project and reference files.

A project file, such as a memo, a budget, a plan or a student assignment which needs to be checked:

  • is used in a specific ‘project’, an activity which has a beginning and an end;
  • may be very intensely used under the project duration and not needed after the project is over;
  • may be ‘work in progress’ that is modified, edited, renamed, deleted etc.;
  • may need to be shared with other project participants.

In contrast, reference files may be not used as often, many of them are kept ‘just in case’. You may need a particular reference file tomorrow or in 2 years. You are unlikely to modify a reference file. And while you may need to occasionally send a reference file to a colleague, you are not likely to want someone to have access to your reference library on a continuous basis.

This explains the difference in handling these two types of files. Project files can be kept in a few dozen of folders (that’s how many active projects you are likely to have at any given time). Since projects are well defined it is not difficult to decide where a particular file should go. Because you work with your projects on a daily basis your short-term memory will easily remember where the files are. There is enough place for the most intensive projects in your Finder’s sidebar so that you can quickly access them from any application. Moreover, it’s easy to ‘teach’ the LaunchBar (or Spotlight) to open your project folders with a keystroke (see how I open my COSUS project by typing “cosu” in the LaunchBar). Project folders can be shared with other project participants through the Dropbox, if you’ve already made it part of your Ninja Kit.

In contrast, reference files are best organized by OpenMeta tags which should make sense to you in a year or more from now. Handling reference files is ‘fuzzy’ precisely because they don’t belong to well-defined projects. One file usually has several tags and your tag system might not (and probably should not) make sense to other people whose brains work differently. Remember, tags are designed to fit your own unique memory patterns.

So what do you do with the files which are both project and reference files? For example, a student’s thesis which has been completed and now became a great reference? Or a paper which you reference in a project report but which can also be used in other projects? There is no universal solution for such grey zone files, but here are some options and tips:

  • You may keep your file in both places the reference files directory and the project folder. this is not particularly elegant: who wants to have two copies of the same file? I must confess I do it from time to time.
  • You may keep such files in your project folder while the project is under way, but as soon as the project is finished, tag and move them into your reference file system. I often don’t remember or don’t have time to do it, but sometimes it works.
  • You may keep such files in project folders but tag them as reference files; if your search software looks inside your project folders (which makes sense) you will be able to quickly locate your files anyway. I am experimenting with this solution and sometimes it works better than others.
  • You may do the opposite: keep you files with your other reference files and tag them with a special project tag or create aliases in the project folder. Neither method has worked for me – it’s just too complex;
  • For writing projects I keep all the reference material (often hundreds of files) with my reference files rather than in the writing project folder. When I want to know which references I cited in a specific publication and I use tools in Sente my bibliographic manager. This is a whole different topic which I plan to cover in a separate post.

So tags or folders? All in all, I agree with J.Eddie Smith that tagging is a tricky business and you should really need it before you introduce it. On the other hand, sorting files in folders is a good old method you can always rely on in handling your mission-critical project files. Losing a reference files might mean that you need to download it again from the Internet or ask your friend to resend it. However, losing the latest draft of your article … well you know what this might mean!

Having hesitated between tags and folders and having tried both systems I have chosen both. Tags – for reference files, folders – for project files!

About these ads

About Aleh Cherp

Aleh Cherp is Professor of Environmental Sciences and Policy at Central European University and Associate Professor of Lund University. He is also the coordinator of MESPOM, an Erasmus Mundus Masters course operated by six Universities in Europe and North America.
This entry was posted in Files, Projects and tagged , . Bookmark the permalink.

2 Responses to Managing project files and good old file folders

  1. Pingback: Note-taking on a Mac revisited | Academic workflows on Mac

  2. Pingback: Note-taking with Ulysses: beside NValt and Byword | Academic workflows on Mac

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s