When one compares the user experience of something like Mail Chimp to digital asset management software, it’s easy to see why people complain that DAM software can be cumbersome to use.
And while DAM vendors scramble to repaint their UIs and, in at least a few cases, turn their backs on their legacy apps in favor of flavor-of-the-month “DAM Lite” variants, it’s clear that DAM vendors might not really understand the problem. The issue isn’t that DAMs are ugly, the issue is that the very paradigm upon which we’ve built these systems has become obsolete and, therefore, cumbersome.
A Little Too Far Off the Beaten Track
No matter how pretty the UI, a DAM remains a place people must go to get what they need. We place digital assets in a repository that is almost certainly not where we are when we actually need those assets.
A quick visit to the DAM might seem reasonable but actually it’s not. Not long ago — and in some parts of the world still — if you wanted water, you had to visit a well. Today, we have faucets. Even better, we have faucets throughout our houses, each located where the need for water is expected most — at the point of consumption. When we leave our houses, we also find faucets at work and virtually wherever else we go.
Imagine how different life would be if every time you left the house, you had to take with you the water you’d expect to use throughout the day for drinking, washing and flushing.
Through the advent of plumbing, we discovered that by delivering water to the point of consumption, we could change the world. Better yet, by ensuring that all faucets worked in pretty much the same way, they could be used without training. (Unless you’re an American in a European hotel room.)
This is the paradigm upon which the next generation of DAM must be built. We want digital asset access, not from some random website location, but from within our apps and anywhere else we happen to be — Google plus, a Disqus comments thread, Facebook, Twitter, etc. We don’t want to go to a DAM well to get what we need, and we certainly don’t want to have to learn a bunch of UIs that vary with each consumption point.
But this is exactly what today’s DAMs have been bred to be. Rather than part of the infrastructure, DAMs are pieces of furniture. They sit above the core of what makes a business a business and they’re ultimately expendable. What we see going on now, as ever more vendors claim to have the most beautiful or user-friendly DAM system, is not a reinvention of that failing paradigm; we’re seeing DAM vendors reupholster DAM software to hide its Avocado Green and Harvest Gold origins.
The DAM News team’s Ralph Windsor has suggested that DAM vendors are running low on ideas or that we’ve perhaps slammed into the limits of what we know how to do. I say he’s correct, particularly on that second part. DAM evolution has stagnated because we’ve slammed into the limits of this asset-from-a-well paradigm. Unfortunately, no DAM vendor has stepped forward to introduce a true alternative, and that’s where Ralph is correct on his first point.
And I think we’re all starting to realize it.
There is evidence that DAM vendors understand what’s going on. The flurry of DAM integration announcements we’ve seen in the past few years suggests that vendors have discovered life outside the DAM ghetto. Vendors are plugging DAMs into everything, and then displaying those product logos on websites, like they’re the stuffed heads of game conquered bare-handed. (It’s like we've traded taxonomy for taxidermy.)
This is a step toward point-of-consumption asset access but there is still one problem: each DAM integration is different. In some cases, the differences are forced by API limitations, leaving integration developers with limited options. But I think that in most cases, the problem is simply that integration developers are lazy — and this includes DAM vendors who create their own. Rather than see each integration as another road leading to the Rome called DAM, they think “press release” first and they think “user experience” … well, maybe in the 2.0 version. You know, if enough copies sell.
Consider how difficult your computer would be to use if the Open and Print dialogs behaved dramatically different across applications. We have had UX standardization here for so long that we no longer even notice it when we see it. And when we don't see it, we consider the program we’re using to be garbage.
Hiding the Ugly Step-Child
Then you have the vendors that have started to hide their DAM components behind the premise of larger marketing operations or user experience suites.
On the one end of these “integrated solutions,” you have work-in-progress apps; on the other end, you have distribution and analytics apps. Connecting everything is the unloved DAM that has been renamed into something so inconceivable that I assume no one even bothers to ask about it. I’m sorry Adobe — I love you dearly — but “Experience Manager” is such a confusing name for a DAM, that you should have just called it Fred.
- Told You So: Ektron is Merging with EPiServer
- Where Document Management Went Wrong
- Five Hot HR Tech Trends for 2015 [Infographic]
- Who Wins, Loses in Ektron-EPiServer Web CMS Merger?
- IDC: 10 Predictions For Emerging Technologies In 2015
- EMC Documentum Group Changes Its Name and Leader
- 8 Companies Leading ECM Into 2015