But it’s time to stop using DAM to manage images because you could be doing so much more.
Lose the Legacy
Unfortunately for DAM users, DAM developers were weened on operating systems. This means that despite our best efforts to make digital asset management software something that’s leaps and bounds better than what we get with Mac OS, Windows or Linux, DAMs remain too influenced by the ways in which things are done on the OS.
For example, consider data storage. In the early days of computing, word processing documents got their own folders; spreadsheets got theirs; images got theirs and so on. You might even have Videos, Pictures, Music or Documents folders on your hard drive today. After all, if Microsoft and Apple put them there, they must be useful for something.
Though I can’t think of a single professional DAM that provides out-of-the-box video or picture categories or tags, these are among the first things new DAM users create. In fact, you needn’t look far to see DAM vendor screenshots that include file-based examples because they tell a simple story.
But that simple story is confusing the truer story of Digital Asset Management. Worse, most DAM software today does nothing to improve the situation.
Mental Metadata Tags
The reason I say that “images” don’t belong in your DAM is this: the fact that a given file contains an image is of virtually no value to those using the DAM. Sure, when we need an image to place into an InDesign layout, we don’t want a spreadsheet. But if 90 percent of the assets in your DAM are images, what’s the point of categorizing them as such?
When we search, we don’t search first by file format, we search by content. For example, when searching for screenshots for a new product release, we think screenshots not images. Or when we need a copy of last year’s annual report, we think in terms of report attributes -- the year, the business unit or maybe even the title “annual report.” If we've exhausted all search options to the point where we have to start browsing some “PDF” folder to find the report, something has gone horribly wrong in the DAM.
Depending on our professions, we use different mental tags to describe what we want. Marketers think about collateral and advertising; salespeople think about pipelines and reports; and technical writers think about documentation and release notes.
At the core of all of these terms are file formats, but those formats are not what matter most to us. They are, in fact, simply attributes of “boxes” in which the content has been stored.
Sure, one format might be more suitable for a given purpose; but if we need a PNG photo of a daisy and we can’t find one, we’re not going use a PNG photo of a 747 instead, just because it was in the right format.
The only people who seem to think in terms of file formats today are those who build DAM software. “Look at how many file formats we support! Download the PDF here and marvel at all the formats we support that you’ve never even heard about, let alone use …”
When searching for something we need, we think first about the content before we think about the file format. If you don’t believe me, ask yourself the last time you added a file format designator to a Google search.
Content Focused DAM
If your DAM enables you to think in terms of content instead of files, you can provide users with a much more natural search/browse experience. Some examples of content focused DAM are:
- Taxonomies that are subject-centric instead of file-centric. If you’re unsure of what a subject-based taxonomy looks like, visit a brick and mortar library. In these buildings, you will not find book stacks categorized by “Paperback” and “Hardcover,” you will see them categorized by topic. Before you insist on using “PDF” and “Word” tags or format based taxonomies, make sure your DAM doesn’t already do this work for you. Some systems already offer built-in mechanisms for making clear the format of each digital asset without you having to do a thing. What the DAM doesn’t know is what’s inside those files. That should be the basis of your metadata schemas.
- Metadata schemas that are defined by content class. The metadata you need to track for an employee headshot will differ from the metadata you need to track a licensed image of the Golden Gate Bridge. Even though both might be images, and both might even be in the same file format, their purposes, limitations and originals are different. Images you license from iStockphoto don’t need metadata fields for Employee Name or Department. Likewise, the use of your employee headshots isn't likely restricted by iStockphoto licenses. You need metadata fields that are relevant for each content type, not just each file format. (Isn’t making a decision based on file formats the same old school thinking we’re trying to avoid with content focused DAM?) And you certainly don’t want a one-size-fits-all metadata schema that spans your entire collection. A good metadata set is about describing the nuances between your digital assets. That’s tough to do when your metadata schemas don’t respect the content of your assets.
- Lifecycle based metadata schemas that are always current. An earnings report that has not yet been released will have dramatically different metadata requirements than one that was archived 10 years ago. Approval workflows mean nothing if there’s no way inside the DAM to know what has or has not been approved, when it was approved, and by whom. These indications, like everything are, are metadata. Content focused DAM means you have the fields you need at every stage of the content life cycle. You have the due dates you need during development and you have the restrictions you need during the content’s active period. And when it’s archive, you have the archive date and offline location too.
These example describe a DAM that has been set up to manage content, not just static files. I’ve said it a hundred times and I’ll say it again: files are just the shipping containers we use to send and receive content. They are boxes -- nothing more. Stop managing boxes.
Content Defined by Purpose
If the notion of classification by content class confuses you, think in terms of content purpose. How will your images be used?
For example, if a JPEG file is a display banner for AdWords, classify it as such. Who’s going to look for an advertising banner under the Images category? The same goes for screenshots, x-rays and everything else.
Next, make sure each asset gets the metadata schema it needs. If your DAM doesn’t permit you to define asset classes that, in turn, permit your metadata schemas to adapt, the try to come up with a metadata field naming convention that conceptually defines content classes. For example, you might call one field, “(Advertising) Campaign” and another field, “(Product) Name.” This isn’t nearly as graceful as having the DAM handle this for you, but a least your users will be less likely to confuse the purpose of each field.
A side benefit of content focused DAM is that content classes often parallel rights management schemas. For example, an earnings report that has been assigned the “SEC Filing” and “Draft” classes, is not likely something that’s ready for public access. Eventually, the report will leave the “Draft” class and be assigned the “Released” class. All the while, it remains an “SEC Filing” and contains all that relevant metadata, but the access rights have changed throughout the content lifecycle.
A content focused DAM goes a long way toward making digital asset management more manageable for administrators and more palatable to users.
Think content, not file formats, and get those “images” out of your DAM. After all, if there’s nothing more to say about a given JPEG than that it’s an Image, it doesn’t belong in your DAM in the first place.
Title image by pio3 (Shutterstock)
Editor's Note: David's take on DAM is never dull. Read more in Cloud DAM vs. On Site: There is No Real Contest