Developing a standardized directory naming system for art drops

Hi, everybody! I’ve been using a system of directory naming for years for tracking all incoming\outgoing files with outsourcers I use, and I’m tweaking it and trying to standardize it. The goal is to be easy to understand and simple to sort. I’d love to get input and feedback on this. Here’s the way I do it now:

/(2012-03-22) INCOMING – SUBMISSION – STUDIONAME (character art for milestone 002)/
/(2012-03-22) OUTGOING – FEEDBACK – STUDIONAME (feedback on characters)/

The syntax is [date] [droptype] [studio] [description]

Date always comes first for easier sorting. The date is written year-month-day to adhere to the ISO 8601 information interchange standard. It sorts perfectly alphabetically so months don’t get mixed up between years. For example, you could write March 22, 2012 two different ways:

2012-03-22
or
03-22-2012

What if, a year from now, I make another directory with the date?

2012-03-22
2013-03-22
or
03-22-2012
03-22-2013

The more directories get dumped in there, the more confusing it’ll be trying to sort out which year which drop came from since it’s not sorted well.

Droptype comes second so I can easily sort out what kind of drop it is. Is it something I sent to the contractor? Is it something they sent me? Or is it a reference or information drop of some kind that doesn’t really count as incoming\outgoing?

There are the different droptypes and subtypes I’ve set up so far:

INFORMATION
    ASSET DUMP
    TECH DOCS
    REFERENCE
INCOMING
    ESTIMATE
    SUBMISSION
OUTGOING
    RFP
    ASSIGNMENT
    FEEDBACK
    REFERENCE

RFP means “Request for Proposal,” by the way. This means I’ve sent the studio a batch of work, reference and tech docs so I can get the work priced and scheduled out so we can decide whether or not to sign a contract.

I have everything capitalized for easier readability. I don’t like lower-case or mixed-case for important information. And I think all of these droptypes and subtypes encompass pretty much every type of standard communication I have with outsourcers. It’s a short list.

After that I include the studio name, which helps a lot with filtering alphabetically if I’m working with a lot of art studios or artists for a single client. I used to include the studio name in the description, but I prefer this for sorting, especially as projects scale.

From there, I include a short written description of what’s in the drop. It’s a lot more casual than the rest of the naming conventions. I don’t care about capitalization as much and I don’t have a very standard syntax for it. It’s just a brief description of what’s in the directory and why it exists.

That’s the best system I have so far. I’d love for people to pick it apart, though, to see if there’s anything I could be overlooking or doing better. I’ve gone back and forth before on whether or not to put STUDIONAME before DROPTYPE as a means of sorting more easily. It came down to being purely a matter of preference, as I’m personally more focused on seeing at a glance the actual inflow and outflow of information on a daily basis, and the ratio of in vs out. That’s more important to me than sorting first by how many times I interacted with an individual studio on a certain day.

Because of this, I’m better able to assess how productive my artists are and how productive I am, and helps me see relationships with regards to the amount of time I’ve invested on art drops and feedback and how quickly it comes back and from which studios. Again, that’s just a matter of preference.

Seriously though, any and all feedback is appreciated! :)

4 thoughts on “Developing a standardized directory naming system for art drops

  1. brackets AND spaces in the directory names? Oh man, at my company that’s reason for a public flogging. Use underscores and uppercase letter structures instead. This whole practice of allowed users to put whatever characters they want into filenames has been propagated by M$ and apple long enough and it’s a giant make-work program for system administrators that have to deal with this stuff when it inevitably ends up on a *nix based server.

    The fact that you are using forward slashes and not backslashes tells me that you are on a mac, which I imagine is even more lenient about these sorts of things than windows but that beings said your shiny GUI is running on FreeBSD, an even more hardcore OS than linux and nonstandard chars dont’ fly in that OS in the real world(coming from a 10 year bsd administrator) so do the real OS powering your GUI some justice and replace

    /(2012-03-22) OUTGOING – FEEDBACK – STUDIONAME (feedback on characters)/
    with

    /2012-03-22_OutgoingFeedback-STUDIONAME_Chars/

    We’ve almost cut down the length be half to boot

  2. Hi Ryan! Awesome, you’re the first person to give feedback on this, and I appreciate it!

    What problems are generated by doing it this way on *nix-based systems? Not sure I understand the implications.

    Actually I’m not on a Mac. Hadn’t considered my usage of slashes, really. That’s a little lazy of me since it’s purely arbitrary why. I use them the way they need to be in context, but when it’s not mapping to a directory or website, but when I don’t, the backslash on my keyboard is easier to hit than the forward slash and it keeps my typing speed up. Silly, I know…

    What’s the purpose of alternating underscores with hypens? Is there a technical reason? I’ve always been irked by it because it seemed sloppy, so I’ve always tried really hard to use it consistently.

    The reason I use parenthesis and spaces is simply for ease of visually bracketing information and filtering it without text running together and needing to spend more time parsing it. I always tend to work very quickly and scan through information at a high speed and I feel like it saves me time. Filename length has never been a factor, but if there’s some backend issue I’m creating for someone else, I want it to be easier to deal with.

  3. Hey Jon,

    Sorry for the delay in reply here, I didn’t get an alert and it was only when a colleague of yours mentioned your name in passing today that I was checking out your site again and thougth ‘why the hell does this site feel so familiar’ :)

    Soo let’s talk *nix here. Any CTO worth his weight in salt is going to be setting up a *nix based server(s) when dealing with backups or anything that can be a purely hands-off automated process and especially anything that is making direct contact with the outside world.. So the chances of these files ending up there are good in larger operations and the whole purpose of it, outside of the added security and stability, is how awesome *nix handles automation with things like find, sed, grep, etc etc.. All built in system commands that allow you to make extremely powerful scripts(or batch files in a DOS context) to automate processes like backups with incredible control and precision.

    So for example, let’s take all images that have to do with cars, and lets say that we want all of the car images submitted every day to be separated from the rest, packaged up all by themselves and indexed based on things like car color and manufacturer. Let’s assume the images look something like this ‘C_Red_Nissan_Car001.jpg’ or C_Blue_Audi_Car002.jpg’ what the script would do would be to look for any file that had a 4th value(using underscores as a value separator) containing the word ‘car’ and make a copy of it into a ‘Cars’ directory. Then ti would look at those files and find all of the files with ‘Audi’ as the 3rd value and move them into Cars/Audi and then find all files in there with ‘Blue’ as a second value and move it into the Cars/Audi/Blue directory. Etc etc. So this would be done using something called regex, or regular expressions. Basically symbols that aid linux in pattern recognition. An example is something like ^.*djdj*$ . The ^ means start of line, the . means any one character in that spot, the * means any amount of characters until the next symbol which is $ which means end of line. There are tons of these symbols that mean all sorts of things in the scripting languages of *nix and when you start using them in filenames what happens is it makes the job of the scripts that will be interacting with these files a nightmare. It seems C_Blue_$$$(Audi)_car.jpg and it thinks that $(Audi) is referencing a variable and will go haywire when you try to run an automated process that involves that file.

    Spaces are equally frustrating because if you have even a simple copy command like copy file1.jpg /path/to/new/home/ and file1.jpg is actually called file 1.jpg what happens is that *nix see’s the command like this copy the files named ‘file’ to the path “1.jpg” as any space indicates an additional command or variable on the existing command entered.

    The only reason I used a slack instead of a backslash is that slash is a *nix standard and a backslash is a windows standard. In terms of directory paths that would be dependent on the OS using it but clearly both should never be used ina filename itself lest a script thing you are referring to a directory.

    Mainly what all of this boils down to is how *nix based systems execute commands and the basis of regex in scripted automation. A good rule to have is to try to figure out how to accomplish all of your naming needs with only alphanumeric characters, underscores or hyphens.

    Sometiems I feel like it’s a loosing battle I’m waging trying to teach people the value of stuff like this.. We do a lot of work in unity and even unity’s official guide on animation has the directories named Car@Animation01 , which I guess is pretty standard for animators but is a vomit inducing offence for those us that serve as the admins of servers :)

  4. Wow. I did not know any of this. Is this pretty universal\common on the IT side of standard dev environments? I only see the front-facing side with network drives, P4 and SVN, and I know that’s merely the tip of the iceberg. But if I’m making someone’s life worse…

Leave a Reply