The Principles
A principle, in the context of a naming convention, is a fundamental value through which a rule or standard is ascribed. This list should function as a sort of thinking rubric from which to derive, and even modify, your naming guidelines.
Communication
The main goal of any naming convention in media post-production is to improve communication across a team, by minimizing the need for interaction to obtain information from collaborators.
When working individually a good naming convention can help you quickly make sense of your projects, your exports, and all other assets—saving precious time that adds up. When working in a team, it minimizes the time spent emailing and messaging as you search for clarity on what files or assets to use, assessing the content of an individual file, or distributing updated information as materials change to keep the whole team aware.
Communication is the base of the pyramid of any efficient naming convention. It is the ruler by which all other principles are measured. The ultimate benchmark question for any naming convention rule should always be: “Does this help communication in my team?” If it doesn’t, then it is better dropped.
Consistency vs Flexibility
All media assets should be named using a consistent, structured naming convention regardless of their type or format.
When working in a large team, with competing needs, and varied skill sets, a stringent naming convention can soon find itself becoming irrelevant if it doesn’t account for every possible scenario and contingency in a project. On the other hand, a naming convention without some strictness will be useless and provide no actual help in communicating or searching for the files needed. Therefore, a good balance must be found. Where that balance lies will depend greatly on the particular needs and workflows of you and your team.
In my experience, the best balance is usually found where consistency is given a greater weight than flexibility. The best approach to finding that balance is to have ongoing conversations within the team, imagining every plausible scenario, and creating a naming convention that covers most of them, while allowing a bit of flexibility here and there, and documenting/reporting any exceptions.
Repetitive Logic
A good naming convention follows a clear repetitive logic that can be easily understood by anyone in the team. Anyone joining the team midway through a project, should be able to discern a lot of the rules of the naming convention simply by looking at the files and folders where the project is stored. With practice, that repetitiveness will become second nature to anyone using it.
Note that a repetitive logic doesn’t equal a repetitive pattern. Sometimes, depending on the type or use of a media asset, its naming parameters might be different from another file type, but the thinking or logic of how that pattern is derived should be relatively easy to discern.
Brevity vs Verbosity
A media file’s name should be easy to read and easily convey its contents, so that anyone working with it can quickly make sense of it. This includes using descriptive, unambiguous names that accurately reflect the content of the asset. However, depending on your viewing environment or resolution constraints, if a filename is too long it is likely to be truncated. Therefore, filenames should also aim to convey that content in as brief a description as possible.
A file name such as RY01_STR, though brief, is highly codified and its content would be unclear to anyone unfamiliar with its naming convention; while a file named adjustments-assistant_side_button-tablet-1440×1440-30fps-enNZ-screenrecording would be shortened by any browser, and the viewable portion of said file name might be adjustments-assistant_power_bu… instead.
The best naming practices pack as much discernible information with minimal characters, abbreviating or codifying where needed while ensuring that the file’s content remains understandable and without creating unnecessary obstacles.
Search Accuracy
Another key goal of any naming convention is to be able to find the exact assets and files that you or your team need through a search engine, with minimal added noise (files that you’re not searching for). The better your naming convention, the quicker and more accurate your results will be.
In one such instance of added noise, if project names begin with a sequential number, and you search for such a number, you could get results of files that match that number, but have nothing to do with your project. For example, if you search for project 1520, but get a “Clip1520.mov” in your results.
You should also consider what platforms you’ll be using to perform searches, and how keywords and characters would be parsed, as you want results to match across them. What you search for in a Finder/File Explorer/CLI search, might be different from what you get in a media editing or design program. So consider things like the use of symbols and sequential patterns, and how they affect your queries. For example, searching for * in Mac OS Finder, will provide results with the actual asterisk in their name or content–it does not function as a wildcard. While the same search in Premiere will provide no results.
For best results, you should test your naming convention across all platform and program searches in your workflow.
Scalability
As projects grow in size, complexity, and longevity, it becomes increasingly important to have a naming convention that is scalable. Whether you’re working on a one-off project, or in a team with frequent projects, your naming convention should be able to accommodate a large number of media assets within and across projects, while also remaining organized and easy to manage.
For example, if you create a naming guideline that file names begin with a month and day portion in MMDD format, you will have some trouble if your project extends past the end of the year.
Similarly, if your project names begin with a 3 digit number in a high-volume agency, you may one day reach more than 1000 projects, and those 3-digits will not be sufficient.
Another aspect of scalability is versioning and iteration. Iteration is the different snapshots of your deliverable as it moves through rounds of feedback and improvement. Versioning, on the other hand, is the different variations that the same content (or a portion of it) can be configured–such as a 30-second cutdown of your 2-minute video, or 1×1 and 16×9 versions of the same video. The file’s version or iteration should be easy to read by anyone in your team.
Scalability is ultimately a question of the future, so as you develop your naming convention you should consider what might become of your files and your content–if they might be input into a new process, or if your projects or deliverables could be expanded, revisited, or forked.
Alignment & Lifecycle
Just like a relay race, post-production workflows involve passing a file through different stages. Teams hand off the file smoothly following certain rules and parameters, called “alignment.” This journey of the file through all stages is its lifecycle.
Your naming convention should consider what might happen to your files as they move through their lifecycle, and how a file’s name will align through the different processes, programs, and practices of the same.
Will the files be shared, updated, media managed, or archived at any point? Will your deliverables or assets need versioning? And what will happen if a file is ever removed from its original location? Could its naming lead to any confusion depending on where it might be stored? Will its lifecycle bring it back to an earlier team after it has been edited? Will its naming convention cause issues in another process or program of the file’s lifecycle? Will adding new staff affect your naming? etc.
As the term suggests, all teams in a post-production workflow should be aligned on a naming convention that meets as many of their stage’s needs without harming the processes of other teams in the lifecycle.
Interrelationships of Deliverables (the Spiderweb)
A naming convention’s needs can be further complicated when you consider projects where different types of assets are deliverables unto themselves, with their own lifecycles, teams, platforms and processes that may run simultaneously. A classic example is a logo that is still going through a revision process that also needs to be used in an intro for a 30 second animation that is currently being animated, or a placeholder clip in an highlights edit version that will later be replaced with recorded and colored footage from a longer video.
I call these splits of simultaneous processes/deliverables, bifurcations; and their eventual completion and rejoining of a deliverable’s lifecycle, convergences.
The many bifurcations and convergences in a project or deliverable will often feel like a spider web of relationships that need to be carefully tracked, and if not, will cause plenty of headaches and possible mishaps.
These interrelationships between deliverables, and how they’re tracked, needs to be carefully considered as you develop your naming convention, especially when your team has little control on the processes of one or more of your assets.
Compatibility
In this digital age, a file’s lifecycle might take it through many different platforms (operating systems, programs, or web portals), processes (a client feedback round, or a shell script that distributes updated copies), and protocols (an SMB connection to a shared NAS, or syncing through a cloud service/WebDAV).
Your naming convention should take into consideration what constraints, if any, are necessary to maintain compatibility of your files through every platform and process it lives through and the protocols used to access them.
For some examples, your platform’s readability might require that your filenames only contain a maximum number of characters; or your programs might not parse special characters like % or & very well, and would need escaping to be handled by a CLI program; or a character could cause issues if you trade files between a Windows or Mac system through a SAN (such as the backslash \ ); or you might want your filename to match a URL for a web proofing platform.
Each program handles characters differently, and you should experiment with your filenames and programs to create a naming convention that will get similar handling of characters across all platforms, processes, and protocols, without causing any issues.
Another aspect of compatibility is expectation consistency. I’ve created workflow automation scripts that distribute deliverables to their respective project folders, but this could only work thanks to a reliable pattern (such as the filename beginning with a 4-digit number, or the second word of the name being the project’s name). In a sense, the technology elements in your workflow are another member of your team, and your naming convention should take into consideration the expectations of those elements to function properly.
Recorded
Last but not least, your naming convention should not remain a spoken lore among your team. It should be recorded in an easily accessible document or resource, and kept up to date with any changes.
An online document is the most common solution to this, though I’ve also used desktop wallpapers on workstations as an easy reminder.
As you review the different ideas that will potentially be implemented in your naming convention, you should explore how each one is affected by the different principles in this document. Some of these principles may not be applicable to your workflow or project, and can be ignored–considering the principles that do, you’re certain to arrive at the “best” practices that fit your specific workflows.