As consumers, we experience a non-stop barrage of messages; from watching television and surfing the web, to checking our smartphones. While many of these messages are from friends, colleagues and acquaintances, we’re also being marketed to; enticing ads popping up (a sunny beach when we’re trudging through the rain), designed to make us spend our hard-earned money.Ever thought about these messages? TV ads, flyers, radio spots, banner ads…probably not, because you may feel as I do (that they’re annoying) or you just ignore them completely.
But if you’re in marketing, there’s a good chance you’re thinking about a clever turn of phrase, eye-catching headline or amazing graphic. You might even be thinking about the process of creating, managing, storing and distributing these assets (only if you’re a die-hard marketer). And if you’re thinking about this process, there’s a good chance you’ve experienced the good, the bad and the ugly.
Nowadays it’s something we take for granted — only really thinking about the process if something goes horribly wrong. Generally, though this process is made possible by a number of factors, primarily the use of a digital asset management (DAM) solution.
The benefits of using DAM software are well documented — cost savings, streamlined operations, increased revenue and better productivity. It effectively brings together assets in one place making it easier and more effective to keep track of them, search for them, find them, and see where and how they’re being used.
DAMs have existed in some form for a while now, and with the addition of semantic or graph databases (this is what Google and Facebook use to make them so effective) life as a marketer, studio manager or creative, has become even easier.
Taking a step back, I think in order to understand where DAM is heading, we can learn a lot from where it came from. The origins of DAM software are humble, file sharing and hierarchical folder structures. In this first of two blogs, I’ll take a look at how DAM has changed and the value that it adds today.
Most agree that the catalyst for DAM as it stands today was the advent of desktop publishing in the 1990s. But it actually goes back to the 1980s. Along with bad hair, neon clothing and pretty decent rock, the decade was also the time when a lot of assets were being created in printing, publishing and advertising.
At the time, these assets weren’t being managed and were mainly created and saved to a physical disk. This disk (remember those dinosaurs?) was then physically passed around departments until it reached its final destination in a newspaper or magazine. In the mid-1980s DAM was effectively just file sharing. Things changed a little with the introduction of folder structures, where users could easily find what they wanted, access and use it.
But as time passed and more assets were created, the simple hierarchical file structure wasn’t enough. There was a need for more information about the asset and be able to better manage it. At the same time, the type of digital assets increased, too — branching out into text, documents, page layout files and Illustrator files, even though they were used for a single purpose.
However, as time went on the industry saw the value in reusing and repurposing these assets, which made their management a little more challenging. It was around this time the first systems started to emerge, such as Xinet and Cumulus. But the need remained for us to be able to manage and, importantly, share asset information across systems and multiple projects. It was here that one of the main limitations of hierarchical file structures became blatantly obvious: in order to share these assets across systems and projects, they needed to be replicated. With replication, came the need for more space to store the files and a powerful need to ensure we were working on the right version, and properly managing the change process.
Metadata was a great, if not fairly simple way, to link assets. This enabled us to search for files using more than just a file name. The natural progression from here was to devise a way to link assets together beyond the standard hierarchical structure.
So, in this way metadata allowed us, as users, to build reference information and tag assets with data not necessarily in the file. In the early days this would have included simple yet meaningful data such as keywords, job ID, creator, and copyright information to name a few. This expanded to include more relevant information as adoption and asset libraries continued to grow. The next phase was then to build links between the assets themselves — allowing us to manage, search for and locate files using common information.
This wasn’t all smooth sailing; there were challenges. Especially around how we referred to things. For example, what I might call a car, others might call a vehicle, while someone else is more specific and calls it by its brand name, like a Toyota. While not really an issue in real life, when it comes to searching, terms had to be standardized to get the results.
Once compositing and layout software, like Photoshop, Illustrator, Quark and PageMaker (now InDesign) hit the shelves, using metadata and linking files became even more important because multiple files were being used to create a single asset. Here, for example, users didn’t necessarily know what the original file was for a composite image, so searching using metadata was a better bet. Soon systems started to support this level of information – so you could track what files were linked without having to even open the document.
The next phase for metadata brought with it even better functionality — we were able to track where assets were being used across systems. The evolution of DAM doesn’t stop here. We’ve moved beyond metadata… and toward semantic relationships and where we are today, which is all covered in our follow-up blog.
To learn more about improving your digital asset management and increasing the efficiency of your processes, download our free guide: Future-Proofing Your Digital Asset Management and Creative Production.