Hello all.
This is A Very Long and Boring Email Text File about File Versioning and Servers.
Please feel free to point and laugh, but this is all stuff that I've learnt the hard way, and that we should start to do as we get bigger. It doesn't take long for all this to become a habit; something you don't even think about doing. When it's working properly, it offloads a load of organisational stuff from your brain, too - which is nice, and what computers should help you do.
I've also tried to explain why you should do things like this: I always find it easier to blindly follow rules if I know there's a good reason behind them.
Other people may have their own systems, so we may end up in a holy war about a few things, but I wanted to get this out of my head. My way isn't any more rightererer, but I've thought it out and finessed it over 20 years (!) of computer. On the whole, I'd rather not endlessly argue semantics, but some people love that shit, right?
Also, as they say on b3ta, apologies for length.
Think about your hard drive. You know where to find stuff, right? But I bet there are a couple of folders that are.... well, if there was a little folder with 'here be dragons' on it, that would be the icon, right?
If someone else were to go in to your hard drive to find a file... could they? For that matter, say I got hit by a bus, and you absolutely HAD to find that picture of a kitten for a presentation on my mac... Could you?
If you work somewhere that's just got its first shared server - or even just a shared DropBox folder - that means you have a big fat shared harddrive for all of you.
Now imagine my here-be-dragons folder meets your here-be-dragons folder in a dark alley and has vigourous and slightly yowly congress, and produces a litter of tiny mongrel subfolders, all unalike. Now try and find the cute kitten pic in that lot.
Yeah.
This is why we all have to pretend to be librarians when we use the server. It is very dull, but a little bit of time and effort in naming files and saving them in the right place stops those moments when you're working at midnight and need to find a really important budget and it all goes wrong because someone saved it as 'trousers are funneh.doc' in a folder called 'gerald' in the place where all the MP3s are.
I used to hate doing this kind of stuff, but over time I've found having a system I stick to really helps - because I can just look at filenames and know what's what.
Everything about this isn't about making me happy - it's about being digitally polite to everyone in the company, and your clients, and about adding meaning and value to your stuff.
Also, Librarians are HOT.
So... here goes. SFW Sexy Librarian Cosplay time!
Punctuation marks in file names mean things to the computer that aren't the same thing they mean to you. Different OSes choke on different punctuation marks, so it might be fine for you, but crash someone else's machine (particularly web servers). Especially, AVOID &ersands, /slashes, :colons and @atsigns, as they have reserved meanings in many file systems, and someone accessing the server from a PC may not be able to see them.
I will allow you to use spaces in normal files that aren't going to be on a website, but they slightly worry me.
Macs sometimes consider ThisFileName and thisfilename to be different, but most other computers think they're the same - so you might accidentally overwrite an important file.
Web addresses also translate uppercase to lowercase, so MyAWeSoMeWebsITEfile.jpg is the same as myawsomewebsitefile.jpg - EVEN IF YOU AND YOUR MAC THINK THEY'RE DIFFERENT.
Ever seen one of those URLS that%20looks%20a%20bit%20like%20this? The %20s are spaces that have been 'escaped' by the browser - turned in to a special code so they don't break the internet. Don't use spaces. use_underscores_perhaps - and lowercase only.
If you have a bunch of files with the same name, but dates done as year-month-day at the end they'll sort in date order in your filesystem. If you do 12 August 2010, they'll sort with all the 12ths of the month next to each other, then with the months in alphabetical order. Not as useful!
Besides, as @chutzimir pointed out in a comment, that's actually the correct way to write dates according to ISO 8601 and not in fact backwards at all, no matter what you might think. Although I think for bonus points we should stop to consider a world where everyone writes dates on the sides of angry cats.
Have you made changes to the file? Then increment the version number. You can also apend your initials, or increment a date on a file. There's more about versioning files below - some simple rules that will help.
It's useful to get in to the habit of using project codes to refer to things. If you've got a whole load of files in a mess somewhere - you can tell what project each one is part of, or refers to. Also really polite if you send it outside the company - your client can tell it's to do with project SHARK, for instance.
If it's a budget, use the word budget. If it's a functional spec, use that. If it's an RFP Response, use that. If it's an image of a certain size, maybe put the pixel dimensions in the filename.
Go from the broad to the specific in order - so project details first, then specific document, then version of document
That way, you don't have to read the whole filename to get the gist of what it is quickly, and you don't have to spend your life opening and closing files to work out what they are.
If you send a file to someone, they'll know what it is in their untidy mess of files too - and it will be easier to search for, too.
This is particularly important for CVs. If you've ever been on the recieving end of a lot of job applications, you'll be familiar with a folder that looks something like this:
01.pdf
CV.doc
CV.pdf
cv.doc
jakeizawesomLOL.doc
final FINAL FINAL (1) Cv.pdf
MYCV.doc
NONE OF YOU. I WILL HIRE NONE OF YOU, BECAUSE YOU MADE ME OPEN YOUR CV FIFTEEN TIMES TO WORK OUT WHOSE IT WAS AND WHAT THE FUCK IT WAS IN CONNECTION WITH. That's nearly as bad as the time someone posted me their CV with a packet of polos in the envelope and it got crushed and caused an anthrax security alert in the BBC Post room. NO YOU DID NOT GET THE JOB, and those nice men with automatic rifles and gas masks are not from BBC HR.
Consider instead the more elegant CV - Joe Awesome - 2015-07-22.pdf
PDFs are usually more useful than .doc files, too - because these days, random doc files are a really common vector for unpleasant viruses. I mean, yeah, so are PDFs, but the opportunity for incompetence or just plain ignorance is a bit lower. Don't die of ignorance, folks. Or using contaminated masonry tools.
If it's a file that mustn't go outside the company, make sure it's obvious from the file name. Put INTERNAL or CONFIDENTIAL in the name.
I mean, when you get your intern to clean up your files, they'll totally read those first, but you're keeping an eye on them, right?
Macs let you save files without the .doc or similar on the end. Major ballache for PC users, that one. Always add the extension if you're on a mac (there's a tickbox when you save the file, and in your Finder Preferences, go to the advanced tab and select 'always show file extensions'.
eg
shark - internal budget - v0.1 2010-12-07 KP.xls
A first pass at a budget for project shark, that shouldn't be sent outside the company. Kim made it on 7th December.
shark - budget for lovelyclient - v1.xls
A later version of the budget, that's ready to go to the client, lovelyclient.
shark - rfp response - v2.3.doc
A document for Project Shark, that's an RFP response. This is the third set of amends to a file that's been to the client twice.
shark_cards_closeup_150x101.jpg
A picture for the website. It's a closeup of some cards from project shark, and it's 150 by 101 pixels in size.
Just like file names, good email subject lines mean that you can easily search or sort your inbox, and they really help the person you're sending mail to - it's kind of polite. They should be just as useful to a recipient outside the company as within.
My preference is roughly
Name of Project - area of project - specifics of mail
eg
SHARK - Postcards - File for proofreading by 5pm on Tuesday 2nd
You almost don't need to write the email for that one! Like file names, go from wide to more specific as you progress. Sometimes you won't need a full three part thing, but it's still useful to have the code at the front. If it's not a project, take a guess at a sensible thing to start with.
The principle - make it easy for someone to scan a big jumbled inbox of emails to find the right one, or make them appear in a sensible order if they sort by subject line.
If it turns out that you really don't need to do anything other than writing a subject line, consider adding (NNTR) or (EOM) to signal that there's no need to reply, or the end of message if that's all you needed to send. Or even consider using slack.
99u have collated some useful email etiquette tips for the super busy (I don't approve of emotive subject lines, however!). You might also want to read http://five.sentenc.es or Channel4/PeopleWhoDo's Email Manifesto for more tips
It's useful to apply the same principles to Basecamp Posts, too - they end up as emails, and it's horrible trying to find things in there. In basecamp you should also assign a message to a category when you write it.Try and standardise categories in basecamp so they agree with your top level server folders, too. That would make me really happy.
Consider: video-final-reallyFINAL-finecut-needsamends-FINAL.mp4
Is that an approved video? Is the one you can send to the client? What's IN it? Can you remember, two years later when you've got an urgent request when the person who made it has left the company? For that matter, which project was it from?
Yeah. That guy? Don't be that guy.
Firstly - putting FINAL in any filename is basically asking the gods of work to curse you. It will never, ever be the final version. You will look like a tit.
Think instead - major and minor versions. Major versions are ones that are 'done' in some way - perhaps they're the one that's sent to a client. Minor ones are fixes and changes. Here's how it works
version number - what happend to the file
v0.1 - first pass, draft file
v0.2 - changes to that file - a minor version
v0.3 KP - more minor changes, by Kim
v1 - Major release version - probably sent to the client
v1.1 - small changes again
v2 - a new version is sent to the client
Worried you might get many more changes? Think about doing minor minor changes, eg
v0.3.1 KP - Kim proofreads a version
v0.3.2 SS - Sophie proofreads the version kim Proofread
If you deliver a batch of files to a client for a milestone, it might be worth saving copies in to their own folder - eg 'delivery to c4 2010-12-07/(files here)' - so you have a permanent record of the versions sent. That makes it easier to create a zip file too.
If you're working on a major document, make sure the version details are captured inside the document itself, close to the top of the document: and make sure the number in the file name and the number inside the document agree. For things like Funcitonal Specifications, this becomes a special little document history table that records changes to the document.
(Yes, sometimes it's actually a good thing to write functional specs. INORITE?)
Also - turn on track changes. If you can see the changes, that's great - and it means you can compare documents in word if versions get out of sync with each other.
Note - for code or websites, you'll hopefully be keeping files in something like Subversion, Git or Mercurial. These are special systems called CVS - code versioning systems - that handle file versioning for you, so you don't need to add version details - but they involve using the command line/special software and that's a whole different email.
Dropbox will save versions of your files, but you need to have a paid account to access them. This has got me out of holes a couple of times.
In Basecamp, it's possible to reupload new versions of files under the 'files' tab. Sometimes it does this automagically if you upload a file to the same message thread, but it seems a bit unreliable and I've never figured out its internal rules.
Generally, I treat a message thread on Basecamp like a folder: if I've done a new minor version, I'll add it in a comment on the original thread. If it's a big important change, I'll add it as a new message thread (sometimes including a URL to the old one.) This means that you don't get hundreds of messages with roughly the same content when searching in basecamp, too.
Generally, working directly on the server as if it were your local HDD is a bad idea. If anything happens to disrupt your connection (eg, wifi goes down, as it does about 40 times a day), you can loose masses of work.
Also - if two people have the same file open at the same time, all MANNER of bad can happen.
Generally - open a file from the server, and immediately save-as it locally to your harddrive, and increment the version number as you do this. When you've done all your changes, copy your new version back in to the right place on the server.
The principle is: The server contains nice, clean master documents, and your local drive is your 'scratch'. The process of opening and saving files is when you do your librarianship to keep everything nice for everyone.
I'm always working on the best folder structure for project folders on the server - like the suggested file naming process, the idea is to make folders meaningful and consistent, so if you're new to a project, or looking back on it months and months later you can find stuff by reading the names of the folders. You don't have to remember - the file system remembers what's what for you, and acts as its own index.
If you're being super awesome, the top level folders should correspond to the categories you set up in basecamp for the project, too...
More thinking to be done here. But here are some examples
Complex version - this is really detailed and contains more folders than you'll probably need. It's for a big project.
PROJECT CODE - project name
archive
audio
papers
video
assets - incoming
audio
client brief
client documents and guidelines
code
fonts
games
images
logos
video
audio
code
design
flash
illustrations
images
logos
motion graphics
page design psds
documentation - editorial
editorial specification
handover document
internal brief
post project review
rfp response
documentation - technical
functional specification
migration specification
personae
technical specification
testing reports
user journeys
wireframes and site maps
final delivery - for client
final audio
final code
final design
final documentation
music cues
p as c
production bible
technical documentation
functional spec
migration spec
technical spec
final video
finance and contracts
budgets
additional budgets
budget and overages summary
final approved budget
working budgets
cash flow
contracts
contributors
production
suppliers - companies
suppliers - freelancers
talent
cost monitors
cost reports
credit card
floats
heads of agreement
insurance
invoices
supplier invoices recieved
petty cash
purchase orders
outstanding purchace order log
quotes
scope of work
staffing
new starter forms
staff contracts
marketing and pr
ads
artists press shots
copy
press clippings
promo images and video
screenshots
stats and metrics
post production
credits
edit schedule
facility quotes
schedule of deliverables
presentations
programme as complete
project management
clearances
archive
music
stills
contact list
contributors
audience
guests
feedback
health and safety
production risk assessments
suppliers health and safety
locations
venues
meetings
ob
release forms
contributors
location
schedule
call sheets
final approved schedule
transport
research
articles
questions
scripts
scripts
video
edits
final copies
rushes
viewing copies
A Personal / Freelance business filing system
personal filing structure
personal-documents
personal-projects
presentations
yyyy-mm-dd client topic
templates
work-admin
accounts
YY-YY
bankstatements
YY-YY
cashflow
expenses
YY-YY
expenses-receipts
YY-YY
invoices
YY-YY
legal
client
contract
proposal
statementofwork
taxreturn
YY-YY
work-projects
_client
project
archive
client
project
pipeline
client
pitch
work-reference
project name
I sometimes use underscores to force a folder to sort to the top in mac Finder. It's a useful way of flagging my 'live' working folders, too.
When you've finished a thing, and it's all done and dusted, spend an hour creating yourself a little timecapsule. Copy key files in to their own little archive. Consider including things like:
- A final project report with facts and figures
- Screenshots and links to reviews, good mentions on social media etc
- A record of any social media accounts you set up, software licenses you bought etc
- a contacts list
- A document with usage / rights notes: does stuff need to be cleared? Does it need to be taken down after 6 months? Does the client need to approve stuff?
- Key publicity images and screenshots, at the highest resolution you have them
- A small selection of clips that can be sent out to people /reused
- Original, editable versions of any logos (yours, the clients)
Then, in 3 years time, when something happens, you don't have to trawl through 3 years of accumulated cruft to find the info.
Try and find a secure way to store the various passwords, though, and remember not to retain user data (that's against the Data Protection Act)
Ends, For Now
Kim Plowright @mildlydiverting
The date section can benefit from a reference to ISO 8601, to indicate there are people who do not consider it "reverse" 😄 .