When you’re a one man band, it is just fine to name files with silly names, or to be careless, or have “your own system”. For a while, it can work. It’s like when you live alone. You could have a mess in your house, and if your chaos makes sense to you, you could make it. But if you have roommates, or a family, it’s just a matter of time for your mess to create problems for everyone.
There’s nothing worse than working with colleagues and stakeholders that name files “composition”, or “picture”, or completely vague names. And I don’t even want to start to talk about files named “presentation final”, and then “presentation final definitive this one”.
Naming things it’s a discipline on it’s own, called “Taxonomy”.
What are taxonomies?
Taxonomy is the practice and science of classification. Each industry and sector will have its own universe of tags and keywords to classify references.
The history of taxonomy dates back to the origin of language. It is no surprise. The ability to name things is a pillar of communication. At first we used it to recognize poisonous plants from edible ones. And back then different tribes had different ways to name the same thing. The very evolution of mankind is binded with the ability to survive, and therefore share knowledge to collaborate better and avoid unnecessary deaths.
It is interesting to notice that along with the evolution of men, the evolution of taxonomy systems became more articulated. From Aristotle on, the trend to create categories and name system based on those categories is present in human knowledge. That is because by creating those systems, just like in a language, the name withholds more knowledge than the one expressed by the name itself.
When we have a system, it is easier to infer more information from the position, the prefix and the suffixes that names have.
The art in science and the science in art
Just to give an example from science, the International Union of Pure and Applied Chemistry (IUPAC) has established the rules of nomenclature of all chemical compounds.
That’s how they created conventions to name the most important compounds, and build up from them.
As you can see in that example, there is lots of different information about the properties of a compound in a string of words.
Creative projects can be as complex as chemistry. Ok, maybe not that complex, but complex enough to get inspiration from this method.
As a matter of fact, using prefixes and suffixes is already common practice in the creative world.
When you deliver a TVC, a film or a series for a broadcast company, there are lots of naming requirements in order to comply with their specifications. It makes sense, they receive hundreds of files a day, so it is paramount for them to know unequivocally which is which.
Combining inspirations: Creating a taxonomy
It is hard to push a standard, and we don’t need to become chemists. We can and do inspire in those taxonomy systems to create naming conventions in order to make them useful. A simple method can also be rich and robust.
Another great inspiration when creating taxonomies is the developer world. When programming, developers must name things, and those things must be easy to read and understand. According to different languages, there are different styles to create names. Mainly four:
camelCase
PascalCase
snake_case
Kebab-case
As you can see in the text, each style combines capitalization and hyphens to combine elements. That same thing can be done with your names, to make it easier to combine names, or strings. Simply combining strings, or attributes that the file has not originally in a file is a game changing habit that can simplify and accelerate collaboration.
Here are some characteristics that a filename can have, and can be very useful for most creatives.
Naming specific assets: Useful fields for naming
Project Name or number
The easiest and most effective way to recognize on a glance where a file belongs is if its name includes in some way the project name. But project names can be long, wasting a lot of real state in a name. That’s why agencies, studios and creative companies use a proxy for a project name. This can be a number defined somewhere else, when the project kickstarts, and agreed upon beforehand. It can also be an acronym, or a combination of letters and numbers that give more information about the project.
TV networks and streaming services usually provide a code to define the project that has to be applied to the deliverables. This name is known as “Showcode”. Having an own system to shorten project names is a good idea, but remember that everybody has to be on the loop with this convention. Explain your convention to all the participants.
Client name
Associating files to clients is a fast way to recognize the context of a file and its origin. If you’re creating new media for a client, including the name of the client in the file can be a good idea, specially if you have many clients, and very similar projects.
Imagine a wedding media agency, that has different weddings. The deliverables are always the same, so a very unique trait of files is the client. This is the perfect case to use client names on files. Just like project names, you can create a convention in order to avoid confusion and save space.
Location
When projects are location sensitive, including the location of a file can be useful. This can be useful for example when creating localizations of assets, and elements of the file change if the country or city of destination is different. For tourism or travel projects, knowing where a video or a picture was taken can be the fastest way to recognize a file. Locations can also be indoors. It can be a room name, a lab name, etc. Whatever makes more sense for you and your collaborators.
Scene, take, shot
When working with scripted material, it could be useful to include the name of the scene, shot and/or take of the file.
This is useful for example when providing services for a film. Imagine a visual effects company. They work on a shot-by-shot basis. They receive a file, work it, and that file becomes a shot on an edit, that probably needs to be combined into a final piece, like a TVC, an episode or a film.
Including the scene, take and or shot can be useful for the parts involved to understand very quickly where does that file belong. Remember though, this information can also live in the metadata, so use it wisely.
Creation Date
When dealing with raw files, that is files that were created on a device, including the creation date on a name is very useful, specially when the material comes from consumer or amateur cameras and or devices. This files can lose their creation date quite easily, or the creation date can be mixed with the modification date, so defining clearly when a sound was recorded, a clip was filmed, or a picture was taken, can be very useful for everyone.
Version
This is one of the most difficult habits to take, and be responsible for. Creating version numbers on files can be a mess. The best possible advice here is to use numbers, and never, ever, name files using terms like “FINAL”. It always seems that it is final, but trust me, it isn’t. There’s always that late night email, that person in the bottom of the chain of command that realized he made a mistake, and nobody else noticed it until then. And that means you start the painful chain of unfortunate events that becomes reading “final final” or “final definitive” in files, and not knowing which one is the definitive.
It is better to just write down “v7 is the final version” somewhere, than naming and renaming files.
Naming recursive assets
Depending on the type of recursivity, when you create a library, the taxonomy to make this library useful differs a lot from case to case. Let’s get into some examples to understand some use cases.
Object
The most useful element in this case is to define the object of the file. That is, what that file is. Is it a template? Is it a sound effect (SFX)? Is it an overlay? A light leak? A marquee? A Logo?
Using a word that defines the most basic element that a name must contain.
Origin/destination/Language
Where does the object come from is another useful information that can differentiate a file. Think about a package cover. Imagine a designer creating milk cardboard. The same cardboard can have different information according to where it’s sold. Adding this information on the name is very useful to recognize one for the other, specially when assets look very similar but have differences.
Attributes
The attributes of that object are a way to create differences between common objects.
A sound library becomes useful when the name defines the context of the recording and some characteristics of the sound itself.
Attributes can be very subjective in order to become useful. A good example are references. When you find a reference there are several ways to classify it.
A very useful method is to think about the why, the how, the when and the what. Think about the reasons that make that reference useful. Why did you choose it? What did you like about it? What moment in time represents? How is it made? How does it work? What does it portray? What feeling conveys? Many people use this as a method to name references, but it’s not always the best way. For us, the best way to name references is by quoting its origin.
Try to find a curation tool that allows you to use keywords or tags, and be generous with the tagging. Create a keyword tree that you feel comfortable with. Something memorable, something that makes sense to you and preferably to your colleagues.
Should I name it or should I tag it?
One very valid question is where to stop. Names can become very complex and long if we use attributes, and sometimes these attributes can become useless. There’s no unique answer to this. As a rule of thumb keep the attributes on the filename to the minimum, and enrich the metadata with the rest of the attributes as much as possible. That will make the file easy to find using tools and easy to understand at a glance.
One last criteria
Remember when we talked about folder structures and think about access? This criteria is also valid for file naming. You can have two types of conventions, one for working files, that can be more elaborated and complex, since it is meant only for your team, and another convention, easier to read, for deliverables, more verbose and easier to understand for anyone that’s not a part of your system.
