Naming Convention for Blonde+Co

The Problem: Lack of naming standards created daily issues with version control in everything from assets to client deliverables, which created an additional layer for full-time vigilance in quality control and added obstacles in locating needed media.

The Solution: Creating a strict naming convention that adhered to the best practices of naming standards; and provide users with easily accessible documentation to help adoption.

The Details: Some time after joining the Blonde+Co agency in 2013, I moved on to tackle one of the most pervasive issues plaguing modern digital file-based workflows: lack of naming conventions.

Like in many other institutions dealing with digital file deliverables, issues and confusion were rampant in the usage of Blonde+Co’s asset repository. Everything from a collection of inconsistently named exports that caused confusion when delivering to client (e.g. “ClientName_Campaign_V9”, “ClientName_Campaign_Version8Final”); to difficulty locating a project because the client’s naming reference differed from what was used internally (e.g. Client’s “Ultra Sun Protection” vs Agency’s “Sunblocking Creamy”); to a duplicated client asset causing the wrong logo version to be used (e.g. ClientNameLogo_New.PNG vs ClientNameLogo_New Copy.PNG).

I sat down with all stakeholders of the post-production pipeline–Editors, VFX Artists, and all the way to the Client Managers. Through multiple sessions, I began to develop a naming convention which followed best naming standards, and tried to address the most common pitfalls that each stakeholder ran into when dealing with digital filenames.

This culminated in the development of the Blonde+Co Naming Convention.

Every staff member and freelancer involved in post-production was then trained in the usage of the naming convention. The guidelines were easily accessible through the agency’s website subdomain hosting a google doc, and a stylized summary of the rules set up as a wallpaper in every workstation in the agency. This helped the naming convention be quickly adopted and become an integral part of the workflow.

The Results: Many issues of deliverable confusion and quality control in digital file workflows can be easily resolved with a strict naming convention; and this was the case at Blonde+Co.

Since there was a specific number attached to projects (which was replicated in the agency’s project management platform), the client’s marketing team could change the name of a campaign or product halfway through the post-production process and it would not cause further confusion. The account managers simply needed to add any alternative names into the project management platform, and the project number would essentially function as an index tool.

Thanks to the benefits of the naming convention, there was never again confusion on which client asset was the correct one to use when exporting final outputs, and what deliverable was the latest.

Drive Library

The Problem: Ad agency hosted all media relating to its projects in a mixture of drives with non-sequential naming, and without backups; leading to issues locating assets, with the occasional irrevocable loss of media.

The Solution: To create a library of hard drives named sequentially, with mirrored backups of equal size, all maintained through a check-in/out system and strict usage rules.

The Details: In 2013, I joined the team for an up-and-coming ad agency with major clients in the cosmetics and fashion industry. Their existing technology infrastructure was a source of constant issues and problems that often got in the way of creative focus. Namely, their storage system at the time consisted of a roster of 2TB RAID0 G-rives; all named after major international cities (e.g. Chicago, Salt Lake City, Paris, etc), without backups, and with no accounting of where things were located aside from the lead editor’s memory.

To exacerbate the issues, in this system a project and its media would be placed on whatever drive was readily available, and if the drive filled up, the next available drive would be used on the project too. This led to situations where a project and its media could be spread across multiple “cities”; or a “city” would have many different projects.

Often times, when memory failed, the post team would have to go through every city (i.e. plug in every drive and explore its contents) to identify if what they needed was inside. Since there were no backups, storage mishaps led to complete loss of media.

This mixture of issues happened often, even more as the company tried to grow and take on bigger projects, which consequently wasted many labor hours.

We began to call these situations “Olympic crises”.

When we began discussing plausible solutions, media servers were not in their immediate budget horizon, so I needed to work with the resources available. 

Enter the drive library.

I gathered all the drive resources, bought a handful of 4TB and 6TB drives for the largest projects, and created a drive “library” shelf with a checking in/out system, and  established a few rules for its use.

Each drive followed a three-digit sequential number and was paired with a mirrored copy, which would be reconciled at the end of each day. 

Any one project could only exist in one paired drive (which was manageable as none of their media collection for any specific project surpassed 4TB). Furthermore, only projects who had overlapping use of shot media could ever co-exist in the same drive pair. 

The whole drive library was kept in an appropriately maintained shelf, organized sequentially. 

To keep track of the drives, I set up a google spreadsheet with an easy-to-remember link redirection, and set up a recycled computer next to the library shelf that could only access said spreadsheet.

With the spreadsheet, we manually maintained an inventory of each drive’s sequential number, its pair, what projects were hosted on what drives, the current location of each drive, the last person to use it, and its reconciliation status.

The Results: As with any new system, adoption met with some obstacles and resistance, but soon enough the drive library’s advantages began to be relied on, and the team kept each other accountable on compliance. 

The Senior Editor was able to free his time otherwise wasted on fielding questions of media location; and what’s more, no project was ever again irreparably lost.

Though the “drive library” can be considered an immature or rudimentary set-up, it is definitely a good first step on the road to more complex/pricier solutions. Such was the case for this team, as this drive library paved the way for a more efficient team, that was able to expand their creative work and handle more/bigger projects.