Digital Asset Management Value Chain – Search
This is an article in our series of ongoing discussion of Digital Asset Management Value Chains.
Search is another functional area within DAM which is growing in sophistication. In recent years, attention has focussed on simplifying search capabilities and making them easier for new or casual users. This has been prompted by a new generation of DAM users, especially those from marketing disciplines who now probably constitute the largest single user group.
That endeavour is ongoing – and needs to continue, but as both the widespread use and scale of digital asset libraries increases, more efficient and adaptable search tools will be required too. It is not sufficient to offer a search capability which is just simple to use, it needs to be able to cope with an ever widening range of users and also the increasing volume of assets being stored. As I will discuss below, however, ironically, it’s the lack of assets that poses the first problem.
The Asset Time/Volume Growth Curve
In a good number of corporate DAM systems at present, one search problem that is not widely commented upon is the lack of assets and a general under-supply of source material for end users. This is a function of end users realising the need for a Digital Asset Management strategies but then not possessing either the motivation nor manpower to complete the ingestion task. This is further exacerbated by the challenges administrators of the system face in persuading their colleagues to upload relevant material and then catalogue it too. As a result, many of the complex filtering and Boolean logic capabilities in DAM systems do not get fully used at present because the queries are too specific to yield adequate results with the limited material available. Over time, that will begin to gradually change, especially as more data is obtained from integrated systems, however, the period over which that transition occurs is hard to accurately predict and will change on a case-by-case basis.
There are two opposing short and long term search needs as well as an interim period where users go from complaining about not enough results to being swamped with too many. This could be represented by an asset time/volume growth curve which will be different for each asset repository. It is important to make some informed predictions about the shape this might take before implementing solutions so funds are not wasted building unused features that might not be used for years, nor impairing productivity by failing to provide search tools that have the required power and versatility.
Many vendors assume that this is another ‘solved problem’ they have already dealt with by having a ‘simple’ and ‘advanced’ search option but they may need to prepare to have those assumptions put to the test.
In many of the systems I have both seen and personally worked on, the advanced features tend to be neglected by end users in the early days because the aforementioned volume issue means there is rarely the volume to make advanced searches worth using. The most common usage pattern often seems to be that they are used by administrators when they want to prepare a pre-filleted selection of results (to go into a shared lightbox or shortlist, for example).
When end users start to utilise these more sophisticated facilities to filter results for a real world task, they find they are inadequate or have some functional limitation that was not fully anticipated during the design phase. Many developers reading this will be familiar with scenarios where they build a feature, deploy it and then hear nothing until it eventually gets used (sometimes years later) when the real usability issues get reported. At this point (long after sign-off) the problems are often several orders of magnitude more complex to solve than if the adjustments were made earlier on – but that didn’t happen because there weren’t enough assets back then for anyone to appreciate the potential implications.
Similar circular effects to those described are going to be taking place with search features across the whole Digital Asset Management sector, irrespective of vendor size or the cost of the system. A search ‘day of reckoning’ may well be in prospect for many current DAM applications which is likely to spark off a round of disagreements between vendors and their clients as the former cannot understand why the latter think there is a problem which they can do anything about. That might also generate a number of replacement evaluation exercises as clients wonder if there is a better option to be had elsewhere.
End User Competence And The Impact Upon Search
As well as overall asset volumes and the impact of that on search requirements, each user’s own expertise with the system and knowledge of it is different. This can be more complex to address since individuals will be progressing at different speeds depending on many factors such as how long they have worked at the organisation, job role and how much of their working day involves using digital assets etc.
When users start out, they want simpler features that operate like the internet search engines they already know, use and understand. So they expect to type in a single keyword and get optimal results back which they manually assess via a cursory visual inspection (i.e. browse thumbnails and click on a few). Later, they start to get more specialised and want to locate a more limited range of results. The effort of sifting through all that metadata to find the one key item of significant data is something they should reasonably expect the system to do for them.
In many DAM applications, the versatility of the search capabilities provided is unsatisfactory. It seems like there are two levers: loads of results or hardly any. Many DAM applications end up needing to choose one group of users and orientate themselves around them to the detriment of anyone else. As such, either the search tools are either over-complicated and fiddly or over-rationalised and more like children’s toys in terms of what they let you do.
It is difficult for analysts and developers to reconcile these two apparently contradictory requirements for both simplicity and power. They will tend to build what the majority of their clients and customers appear to be asking for (which as can be seen, is far from clear cut). The result is a trade-off search capability that aims to do no worse than occasionally mildly irritate end users. As I have described, however, this is a far from static scenario and mild irritation can quickly convert to vehement contempt if the search feature consistently fails to deliver what the user considers relevant results.
Resolving The Search Problem With The DAM Value Chain
The solution to this is a recurring theme in our series. If digital objects (files) and metadata are disentangled from the rest of the system using a DAM Value Chain concept then it means the search capabilities can be worked on independently by those who decide to specialise in that field. If there are a sufficient number of end users, it would be possible then to develop the missing intermediate search capabilities that are currently uneconomic for many vendors to support if they have to assume responsibility for delivery of the complete solution (as they do now).
This would mean end users can select a search tool that best suits their current needs based on both the scale of their asset repository and their own level of experience with it. Unlike the current ‘DAM island’ model, this doesn’t need to be a one-time decision that you are forced to live with (and maybe regret) for the next 5-8 years that the current system is deployed. You can try alternative search options as necessary and see which one works – then still change your mind later.
There is a lot of work already taking place in optimised search interfaces usually by information scientists with an interest in usability. The challenges of being able to integrate those innovations into a DAM implementation are such that many vendors probably won’t be prepared to take the risk until there is proven demand from end users for any radically re-designed interface model. Many may consider that with scarce development funds already being spread very thinly that they could continue to make do with whatever search features have already been provided. As discussed, however, they won’t be able to keep to that position for long as their users might abandon them before they have had a chance to make the necessary changes.
If those producing search tools were integrated with, but separate from others offering DAM features via DAM Value Chains then it would be an easier proposition for them to develop these independently and experiment in a manner that was lower risk than is possible with the current aggregated mono-vendor model that characterises the DAM industry in its current form.
Conclusion
As with many other concepts in our discussion of the DAM Value Chain, search is an entire universe of complexity in its own right and the circumstances where one search interface could be recommended over another change depending on the size of the library and the experience or expertise of the user.
Searching and the ability for end users to find suitable assets is the primary use case for Digital Asset Management and the reason most users realise they need a DAM system to begin with. It is essential that such a core and integral feature is handled competently and with an open mind about how to continuously improve the results (literally and metaphorically). There is a considerable risk for the DAM industry that search innovations will get ignored because of an assumption that the problem is either already resolved or not worthy of further consideration.
The growth in asset volumes and wide range of user experience with DAM will be contributory in making search a more complicated challenge for DAM system developers. The DAM Value Chain offers a distributed method to help alleviate these issues by encouraging more creative and radical search interfaces that end users can flexibly combine in a way that better suits their own unique needs.
Share this Article: