File names & file systems

Most days, we use digital files. We create, view, find, edit, share, collaborate, store, etc.

Some days we do this a lot. Other times we use files without really noticing and don’t have to consider file names – think phone photos.

And sometimes we use files and there is frustration; frustration that appears when we can’t find something, or when we aren’t sure which is the right version.

By focusing on ways to avoid friction, here are some approaches and standards that I’ve found help in most organisations.

What is being stored and why

Start with a mindset of purpose: what is this file, how might it be used and why keep it? This will inherently lead to knowing where to put it and, later on, where to find it.

Files generally fall into two categories:

  • references that are static
  • living documents that evolve

Sometimes a file that was evolving can at a certain point become a reference (see versions).

Consider data security and protection. Is there sensitive information involved? Where possible, don’t handle these files as the the most secure solution is when there is no sensitive data to be compromised.

Agree on expectations

There should be an agreed way of working with files and folders – a standard that is appropriate for ourselves. It’ll likely include where files are stored, how to name them and who is responsible for each realm.

The _Archive folder

This humble technique allows us to focus and avoid mess by moving what isn’t “current” out of immediate sight.

Anywhere in your folder structure, have a folder named “_Archive” and put files and folders in there that are no longer active, are superseded or just surplus. Have as many _Archive folders as you want through your file system, but only create them when you need them.

Example structure with some _Archive folders

  • Admin
  • Finance
  • Marketing
  • Projects
    • _Archive
      • WS1887 Main Street
      • WS1892 High Street
    • WS1955 Clapton Pond
      • _Archive
      • References
      • Drawings
      • Proposals
    • WS1979 The Plough
      • _Archive
      • References
      • Drawings
      • Proposals

Filenames

Good filenames are human readable, structured and unique within their context.

Depending on where the file will end up, there may be constraints on what characters can be in them. Anything on for use on the web (see images) needs to stick to: lowercase letters, numbers, and hyphens (no space, no other characters). While elsewhere you have more flexibility to use uppercase and spaces, I’d nearly always avoid using special characters – eg: £ & ’ ” @ : etc.

Versions

When it comes to creating new files, first ask yourself: Do we need another copy of this file? What purpose does having another file serve?

Could we instead discuss and work together on it at the same time (in-person or remote) to evolve our file? Google Docs, and other cloud files, allow us keep a single file evolving by effectively editing a webpage.

Version naming options:

  • Incremental: the numbers go up each time you make a new copy by appending “…-02.txt” or ”…-v2.txt”.
  • Semantic incremental: a numbering system with more meaning. Semantic Versioning, is an approach used by many software companies to structure what each place in the version number refers to.
  • Date: put the date and even the time in the filename. Bonus points for ISO date format – YYYY-MM-DD – as it’s less confusing to internationals and can be sorted easily by a file browser.
    • e.g. “…-1955-11-05.txt” for 05 November 1955
    • e.g. “…-1955-11-05-T1325.txt” for 05 November 1955 at 1:25pm

Never, ever, use the word “final”. Without predicting the future, how would we know if it’s the final version?

! Remember to put outmoded files in the _Archive folder.

Access & permissions

Who can access a file or folder (and everything within that folder)? What are they allowed to do with those files and folders (read-only, suggest / comment, edit, delete, organise, etc)?

File services allow a variety of controls for this. Google Drive, for example, offers various options for sharing including adding an expiry date for the permissions.

When we login and access something, two critical steps are taken to determine whether this is allowed:

  • Authentication: the identity of the individual
  • Authorisation: what that individual can do

Project completion phase

When a project has seen its course, there is value in closing out that project’s file system. This may involve tidying up or curating, or simply moving the folding into the _Archive folder.

It may also be a good opportunity to reflect on any salient points to derive some ‘project learning’ which could be useful for other current or future projects (see standards). A debriefing session could be the opportunity to zoom out and capture some discussion from those involved in the project. Be sure to set a reasonable timeframe for when this should occur (eg: within 1 week of the project completing) and define whether anything should be prepared in advance such as financial summaries or the latest scope of work list.