I have been involved in moving 2 institutions to Google Apps. I love and fear what I am seeing as we enter a new era of Digital Asset Creation. It is so easy to creat documents and digital assets that the volume becomes overwhelming.
I love the collaborative nature of these tools and all the other advantages, but we do create an awful lot of….stuff. I have written on this issue before and thought it was time to update my discussion of file naming best practice suggestions,
First I will repeat my disclaimer from the original post:
“ I am organizationally dysfunctional by nature.”
I have forced myself to make some adaptations to that natural state so that I could remain gainfully employed. This post is one of the ways I have adapted to working in the very fast paced world of IT management.”
The importance of this discussion came together for me a few years ago while still employed in Oklahoma. On one particularly busy/hectic morning, I received at least a half-dozen emails with attachments all named “Kent” There were a few Word documents and couple PDF’s and maybe even a spreadsheet or two. I was in a hurry and I was frustrated that I had to open each and every doc to find out what it contained.
Normally, it wasn’t that big of a deal to just open the doc to see the contents, but on this particular day, we were “getting hammered” as things weren’t going as well as I would have liked. I was in a hurry and didn’t need the hassle of opening each document to see what it contained. It was at that point I began researching a document naming scheme which would provide a means for communicating key document information to the user at a glance. It was also helpful that we were beginning to research Document Imaging systems and really I got the basis for this from that world. If this were a recipe I would also say add a dash of Digital Asset Management whose roots really come from the. This makes a lot of sense as on day-to-day basis department or project staff is constantly sharing documents via online cloud-based storage, network storage, email and portable media storage devices and as a result, it can be easy to lose track of what a document contains and which version is which. This brings us to
It probably sounds like I have spent a little too much time reading Dilbert and just for the record Dilbert’s advice on this issue is:
“The committee decided that the file naming convention will start with the date, in the order of month, year, day…then a space, then the temperature at the airport, and the hat size of the nearest squirrel…”
File Naming Best Practice Rule #1
“You should be able to figure out what the file is about with a simple glance”
Consider file names such as:
-
- DSCN0619.jpg
-
- C-1956.jpg
-
- IMG0006.png
- 819.eps
These file names convey very little information about the images within and thus make them difficult to categorize. The impression made with the above example can be compared with this example below from Onison, a company which works in Digital Asset Management:
070329_YVR_boardmeeting_onison_BW.jpg
Their specific focus is on images but contains two features which should be included in any file naming convention/rule for any type of system and any type of environment
Best Practice Rule #2
Always Include the date
Best Rule #3
Always Include a description
Rule # 4 The only permitted characters in your file naming scheme are a-z, 0-9, underscore, dash, and the period before the extension.
Putting the key document information in the title has several benefits, (1) it will assist your project team members to quickly identify the project, department/function, document title and version/revision number without having to open the document and scan for updates and (2) this information will assist in the development, management, security, storage/retrieval and the eventual deliberate destruction of the document.
Implementing a document naming convention in a project/department/organization goes a little further than just sending out an interoffice memo or ‘All Staff’ email. Project staff need to be trained (ideally as part of their induction into the working group) and a focal point (usually the project administrator) needs to be appointed to advise on how to implement the project filing when questions arise with a resource document for reference.
Rule #5 Include all pertinent info, but not too much.
I got the following note from my original post on file naming and thought it important to tell that there are real world implementations where this concept is especially important.
“It is especially relevant for me / us in TWR program distribution, as we get myriads of files for distribution and need to handle them at a glance. In addition, about 4 years ago we began research on a DAM/MAM system which we desperately needed. The first release of that can be seen on: http://www.linguadms.com/ We are / will be using this internally for our worldwide distribution “backbone”, for partners to provide programs to us and make them available, then as SaaS for other Christian organizations. The filename structure is absolutely critical to correct functioning and allowing automation.”
Back to filenames: a brief excerpt backs what you discussed, from our documentation to producers:
=====
- File name structure (needs to be in the following order):
- Language ID (Example: FRN for French)
- Dialect ID after Language code (Example: EST for Armenian – East dialect)
- If there is a dialect, use the language ID as the first 3 letters
- followed by the dialect
- ID (second 3 letters) without space or any other character in between.
- Please make sure that all language, dialect, and program name abbreviations
- match the ones TWR-Europe is using.
- Language and dialect codes are given to the producer by the TWR Broadcasting
- Correct: GER_TTB_1205_210698_0845_Gen1.MP3
- Example: HYEEST_TTB_016_250203_1925.MP3 for Armenian language with
- Eastern dialect.
- Department and are taken from the Ethnologue language code index.
- Program Name ID as assigned to the producer by the Broadcasting Department.
- (Example: use TTB for “Thru The Bible.)
- Program Number
- Date of airing (format: ddmmyy) The year should be written in
- 2-digit format based on
- the last two digits of the year. (Example: 2003 = 03, 2000 – 00)
- Starting time of airing in UTC (format: hhmm)
- their information
- The scripture passage, transmitter, frequency, etc
All of the above is a long example but it certainly was great reinforcement that I was on the right track with this concept
What we want:
- Consistency
- Include the date every time
- Save you and your employees some time
What we don’t want:
- Complicated titles which are overly time consuming to create.
- If users need to refer to a manual just to name an asset, there’s a good chance the convention will not be adopted.
- Also keep in mind that local acronyms and abbreviations may not make sense to all users that access the system.
- Spaces in filenames are bad
A Note on Digital Asset Management
In the modern world, many geeks will tell you a file naming convention is so 2004. They will say you need to think about Digital Asset Management (DAM) Even with metadata, filenames can also be critical in differentiating things like color space or resolution. While the DAM can easily differentiate between these objects via metadata, humans have a little bit more difficulty.
Humans name things. That’s how we’re built. While DAMs do reduce the necessity for encoding metadata in filename/path (thankfully!) there is it is still useful to have some differentiation between similar objects. Also, some Mac users have a terrible habit of putting bullets, percent signs, and other punctuation in their filenames (Smith).
Is this worth doing?
I know this method saves me time on a personal basis, but some people want a more detailed summary of the benefits. Ed Smith in a Sept 2011 post shows a great way to determine ROI for implementing DAM but minus the purchase of a Digital Asset Management.
For this example, I’m going to consider how much time and therefore money is saved by DAM. You can also do ROI calculations based on:
-
- Spending less on stock photo purchases
-
- Decreased licensing fees or fines
-
- Selling or licensing asset collections
-
- Avoiding print overruns
- Spending less on desktop software and hardware upgrades
Let’s say we have 5 people that each make around $50,000 each year and waste 1 hour each week searching for images. We’ll consider an investment of $3,000 into DAM ($2,000 for software and $1,000 for hardware).
First, we figure out how many hours are wasted each year:
5 people x 1 hour wasted searching each week x 52 weeks in the year = 260 hours wasted each year
Next we determine how much money that time is worth:
$50,000 average salary / 2080 work hours in the year = about $24 dollars an hour
260 hours wasted each year x $24 dollars an hour = $6,240
Now we know that it “costs” $6,240 annually to find images. Let’s figure in that DAM cuts the time it takes to find images by 75%:
$6,240 x 75% = $4,680
In this case, we can save $4,680 a year with DAM. Now, let’s see how that compares to what we spent on DAM in the first year:
$4,680 savings each year – $3,000 invested in DAM = $1,680 net savings in the first year.
In this case DAM saves $1,680 in the first year, and potentially even more during the following years when little to no additional money is spent on the DAM.
We’re almost done! We just need to turn these numbers into a percentage, which is the ROI. The ROI is calculated as the difference between the savings and cost of the investment, divided by the cost of the investment. If that last sentence hurts your brain when you read it, here’s what the calculation looks like:
(Savings from DAM – Investment in DAM) / Investment in DAM = ROI
Let’s plug in the numbers:
(4,680 – $3,000 ) / $3,000 = 56%
In this scenario, our DAM system provides a ROI of 56% in the first year. If this DAM was a savings account, I’d put all my money in it (especially in this economy!)
Of course, there are other intangible benefits from DAM like brand consistency, improved customer service, and improved morale. Combining a solid ROI with the intangible benefits can help you make a good case for DAM in your organization.
A Practical Example:
For example, If I created a Word file about creating a file naming policy on February 15, 2012, it would look something like this.
20120215_planning_DoIT_filenaming_policy_creation_kdb.doc
- A) yyyymmdd-B) Document-Imaging–C) DepartmentD) filenaming-policy-creation-E) kdb-F) v01-G)H) doc
- A) Reverse Creation Date-B) ProjectTopicalArea-C) department-D) document-name-E) creator intitals-
Possible Add ons for further depth if your going to have multiple versions of a doc. You may want to rely on the versioning capabilities of tools such as Google Docs for this
- F) version number-G) revision number-H) file name extension as shown below:
20120215_planning_DoIT_filenaming_policy_creation_kdb-v01-00.doc
When document version number is final I usually add the word FINAL if it is the final version of a document
One other thought on this issue:
I read somewhere recently that in a file naming convention where you want to consider Search Engine Optimization (SEO) you might wish to substitute a period for an underscore. I need to do some more reading on this, but the basic concept is:
20120215.planning.DoIT.filenaming.policy.creation.kdb.doc
Sometimes I have a second date reference if the document references another date or document with a specific or important date as shown in the example below:
20120215.planning.DoIT.20120115filenaming.policy.creation.kdb.doc
Notes on Some of the Components
- Reverse Creation Date
Computer filing systems such as Window XP sort numerically and alphabetically, as such, using the reverse creation format “yymmdd” will ensure the file automatically list in order of creation. Some people may not like to use the “yyyy” format, as in “2006″ but I think it easier to see the year in four characters although some may say, “why add more characters to your file name than you have to?”
Project Topical Area Name
Obviously, there are millions of combinations and permutations for project name abbreviations and I have read a six letter code has proven to be quite effective. The first 3 letters in this scheme are for the client organization and the second 3 are for the project abbreviation. However, I have decided to simply come up with a list of topical areas and I do usually spell it out as again I want something I can reference at a glance without having to convert in my head what it means. However, if saving characters to a person then creating appropriate abbreviations such as shown below may be important.
Example: Project Topical Area or Category
BU- Budget
PL – Planning
PM – ProjectManagement
TRG – Training
SCRC -Screencapture (Note: This may not make sense for some, but I use it all the time)
Example: Department Acronyms
HR – Human Resources
SEC – Security / Risk Management
LEG – Legal
VEH – Vehicle Fleet Mgt
LOG – Logistics
DOIT – Department of Information Technology
PRO – Procurement
FIN – Finance
FAC – Facilities Management
INV – Inventory / Material Management
INF – Information Management
Document Name
This is pretty straight forward but a word of advice, try to keep it brief to prevent your file name from becoming too big. A way to do this is to not use spaces instead use capital letters to distinguish between words.
If you want to have some other options for identifying documents you may look at something like the following suggested method for version and revision numbers. I don’t use these, but often in many systems this or a similar scheme are often used.
0.01 – 0.89 = DRAFT
0.90 – 0.99 = REVIEW
1.00 = FINAL (client version)
1.01 – 1.89 = DRAFT for second version)
1.90 – 1.99 = REVIEW for second version)
2.00 = FINAL (re-released client version)
There are obviously many ways of doing this, however, I’ve found this document naming convention to be quite useful in keeping track of what I am working on. When you get hundreds or thousands of documents you must sort through to find a specific single doc you have created you will appreciate having some sort of organizational system
References
Smith, Edward. “File Naming Best Practices for Digital Asset Management.” DAM Learning Center | Digital Asset Management Knowledge and Inspiration. Dam Learning Center, 25 Apr. 2011. Web. 16 Feb. 2012. <http://www.damlearningcenter.com/street-smarts/file-naming-best-practices-for-digital-asset-management/>.
Background Reading and Resources:
http://sethearley.wordpress.com/2009/07/07/naming-conventions-for-digital-assets-how-much-is-too-much/
http://www.imagimation.net/articles/874
http://duckdigital.com/DAM/?p=23
http://www.oreillynet.com/digitalmedia/blog/2007/04/folder_and_file_naming_convent.html
http://teaching.uncc.edu/articles-books/best-practice-articles/web-accessibility/file-naming-guidelines
http://www.43folders.com/2006/10/23/file-naming
http://www.exadox.com/en/articles/file-naming-convention-ten-rules-best-practic
http://www.imagimation.net/articles/874 Onison
http://www.damlearningcenter.com/street-smarts/how-to-calculate-roi-for-digital-asset-management/
Leave a Reply