Is Your DAM System A Place Where Assets Are Sent To Be Lost And Never Found Again?
David Diamond has written an article for CMSWire this week about digital assets getting lost in DAM system. The basis of the article is a surprisingly common scenario where users upload digital assets and then either they or their colleagues can never find them again. David cites five reasons that contribute to the problem:
- Overusing mandatory fields
- Metadata fatigue (excessive metadata fields)
- Inadequate methods for users to report faulty metadata
- Scheduled metadata QA reviews
- False sense of security (by asset supplier users)
From the metadata fatigue point:
“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.” [Read More]
I have witnessed all the above – both in solutions I had a position of responsibility for delivering and those I have been asked to review later where I was not participating in the original initiative. It seems to be very easy to make these mistakes by degrees and without realising exactly what you are doing. Other people who are not directly involved in an implementation can often spot them far more easily as a result.
The causes of these effects are numerous, but no doubt, internal politics can play a big part (in enterprise DAM especially) where different stakeholders insist that a given field has to be referenced or the asset metadata will not reflect their needs. Each act like independent fiefdoms and are duty bound to see their interest adequately represented, with the result that lots of fields which only a segments of the users care about get included. The answer with this is to modify or adapt the metadata schemas to suit what each group of stakeholders cares about, but not every solution can offer that and even if it can, some groups still have more clout than others (and, therefore, ability to make their fields mandatory for everyone).
One further item not mentioned in David’s list is where the DAM solution’s search and selection capabilities are unsatisfactory for user needs. For example, a keyword search alone works great up to a certain volume of assets, beyond which (especially if the assets have similar subjects) there are still too many to sift through. DAM solutions frequently have filtering tools and what gets loosely referred to as ‘advanced search’ but on more than a few occasions, you find these don’t offer any useful options to effect the required filtering. I suspect this will become an increasingly acute problem as the volume of assets held inside DAM systems increases. During specification and implementation, advanced search tends to get ignored because the test system contains very small numbers of assets. The obvious solution to that problem is to test systems with many assets (e.g. post-migration) before they get signed off for wider use.
There are some other simpler tools which can help, for example, something that shows the last x assets uploaded or edited. I don’t know if I am alone on this (I doubt it) but I make extensive use of the ‘recent files’ list in desktop applications like Word, Excel etc. One of the bigger unreported issues with many DAM systems is how they can make you less productive with assets you recently worked on than saving them to a shared drive, your desktop or some other frequently accessed location. These are not difficult features for vendors to implement, someone just needs to think of it and either specify it in RFPs, or just ask to add them to an existing product.
Apart from giving your metadata strategy a lot of forethought and thinking through the implications of it carefully before you make it manifest in any given DAM system, my other tip would be to get as many different people to review it as possible, especially those who have had nothing at all to do with the original discussions. There is no ‘silver bullet’ fix for these problems, but getting a wide range of feedback about what you plan to do does seem to increase the odds on assets not getting lost inside your DAM system in the manner David has described.Share this Article:
Thanks to David for a great post. Again, well done.
My feeling has always been to keep schemas clean and lean so as not to overwhelm the annotating users. In the discovery process we need to find the usual information that would normally be applied in asset documentation(job ticket). Users can then apply the most pertinent of those details to the asset during critical points of its lifecycle.
Limiting the number of power users that upload assets, such as digital librarians or asset managers, is also important to help maintain the integrity of the system and the assets within. Asset documentation can be provide to these end users for final metadata review and input.
Metadata fatigue can be a pitfall to a DAM. The metadata and schema planners may turn out to be only intermittent users making the system too cumbersome. Making annotation too complicated can lead to a user skipping fields or putting in wrong information just to get through the process. Key stakeholders, the end users should play an important part in the metadata and schema development.
A search engine can only return the asset you make sure it can find.
Leo Burnett USA