Often surprising to digital asset management (DAM) newcomers is that it can be easier to lose files inside a DAM than it is to lose files that aren't inside the DAM. Worse, the ways in which your content can become “digitally lost” in a DAM don’t require such notable events as equipment failures, thefts or destruction. This article covers some less obvious DAM considerations that lead to DAM users not being able to find the content they need.
First, let’s define “digitally lost” as referring to a digital asset that is inside the DAM but is not findable. The common search methods and terms users would use to find the asset don’t work. The content, though visible on system reports, is virtually invisible to users.
If you, as a DAM manager, can’t find a specific asset you know is in the DAM, you might do the administrative work needed to recover it. But an asset that is less remarkable — perhaps one shot from a photo session of hundreds — can remain digitally lost forever because no one notices it missing from search results.
You might have already guessed that this has something to do with metadata. In fact, it has everything to do with metadata. But maybe not in the way you might think.
Mandatory Field Fights
Enforcers of policy think mandatory metadata fields are great. They reckon that by making a field mandatory, users will always provide the required metadata. You know, the same way drivers always stop at red traffic lights and obey posted speed limits.
In some cases, mandatory fields make sense; but one could also argue that mandatory fields are little more than an uncreative (and possibly most inefficient) way for metadata schema designers to extort values from users. And as we've seen in so many Hollywood torture scenarios, sometimes the poor victim really doesn’t know the required information. Ultimately, they’re killed or they make up some plausible lie just to save their DAM records … uh, I mean their lives.
Do you really need all those mandatory values? Is the value of your DAM lost because certain metadata values are missing? Likely not. It just means that the system could become even more usable once all those values are provided.
And therein lies a more humane solution to the mandatory metadata field: the optional metadata flag. Offer users a means for flagging content that lacks a policy-required value. Let users admit when they don’t know the best answer. Don’t force them to guess or make things up just to be able to save the record.
To make sure things don’t fall through the cracks, use automation to check your system for missing values. Let someone who can provide the best information be the person to provide it. If need be, keep the asset offline until the policy-required values are there.
Mandatory fields discourage users from contributing to their DAMs. They invite users to keep files on local storage, and they do nothing to offer users an honest means for alerting DAM managers when the uploading user is not the best source to provide the required metadata.
In most cases, the actual goal for mandatory metadata fields is DAM integrity, not user punishment. If this describes your use of mandatory fields, consider carefully how this metadata coercion affects your ultimate goal.
If you decide that mandatory fields are the only way, please let me know. You can reach me via my properly formatted, schema-required phone number: (111) 111-1111. You can also try firstname.lastname@example.org because that’s a nice, legal metadata value too.
Bad metadata looks a lot like good metadata. Don’t encourage your users to provide both.
Metadata Fatigue (In Session and Over Time)
Another weapon in the battle against asset “findability” comes in the form of too many metadata fields. As with mandatory fields, this is another example of how a DAM designer’s good intentions can go horribly wrong.
As a design goal, the metadata you track should serve at least one of three purposes:
- Enable users to find content using the means most intuitive to them
- Store a value required for reporting
- Control or route the asset through your pipeline
Metadata values that don’t serve one of these purposes are schema hitchhikers that do little more than distract drivers. If these fields are not made mandatory, no one will populate them; if they are made mandatory, no one will use the DAM. That’s easy math.
As a matter of a Global Rule of Metadata design, make sure your entire metadata schema makes sense to everyone who will use the system. If a field exists, be able to demonstrate how its value benefits your organization today — not maybe someday.
Another invisible hazard of fatty metadata schema designs comes from user enthusiasm. At first, you might find that users do populate the optional “Mood I Was in When I Uploaded This” metadata field. Over time, though, users learn to ignore metadata fields whose benefits are not clear. This inconsistent application of metadata skews search results and can render some assets digitally lost.
- Office 365 is a Disaster Waiting to Happen
- Don't Hold Your Breath: SharePoint Release Delayed
- Does the Apple Watch Signal a Post-Browser World?
- Who Leads in Multichannel Campaign Management?
- Hey Cloudera & MapR: Open Data Platform is the Real Deal
- 8 Tips to Spring Clean Your Digital Work Life
- 11 Ways to Ruin Your CMS Project Without Even Trying