Following last week’s discussion about more DAM vendors either bringing out ‘lite’ versions of their products or asset portal add-ons designed to provide some simpler methods to gain access to assets, yesterday, one our featured DAM vendors, Picturepark, announced a new feature called “Ports” to their DAM system:
“Use embedded ports to provide pre-filtered asset collections anywhere you need them. Provide a list or thumbnail grid of press releases in the sidebar of your News page, or provide a scrolling list of customer-related files on the Account pages of your CRM. If your organization uses an internal wiki or intranet, Picturepark Ports offers you a convenient way to make images, spreadsheets, forms, presentations and general employee materials available to everyone, right from within the intranet location that makes the most sense.” [Read More]
The “Ports” look like iFrames (windows within a webpage to other websites) and each gets linked to a user and asset collection, the user determining the features, assets and capabilities available. The Picturepark method seems to be to use their main system as the base and then enable this functionality to be applied rather than a fully separate product. They have various features to enhance each port and an interface to control templates as well as more advanced options for those with HTML/CSS skills. A key motivation appears to be to enable simplified WCM integration without needing to go as low level as an API (with all the development effort implications that implies).
The main difference between this and a stripped down DAM is the absence of an upload feature to introduce new or modified assets. I might have missed this in the supplied details, but this feature appears to be for asset retrieval only. I’m guessing this probably would not be impossibly complex to add as a feature, more of interest will be if Picturepark get any demand from their users to provide it (I suspect they will). The ‘DAM Lite’ limitation by contrast is that it sits independently of other products and is not integrated unless you want to get into APIs and other more sophisticated implementation work.
The distinction between ‘DAM lite’ and Portal route seems to be partly motivated by the autonomy of the target users and how much control they either want or can get. The former look like DAM users who might hitherto not have bothered with a DAM system because the cost and/or complexity of setting it all up and learning the functionality etc wasn’t worth it. Those appear to be offered by vendors who are targeting direct end users – those who want to go it alone by providing a ‘Dropbox+’ alternative. The latter seem to be the vendors who target more enterprise oriented clients with larger groups of users – or those intermediaries that need to manage assets on their behalf. As some might have grasped already, these are two sides of the same coin.
As such, I expect to see further cross-integration from both these segments. The end users of the ‘DAM Lite’ products (especially agencies) will start to offer this to multiple clients and gain greater control over a series of portals, they won’t want to keep paying out for separate instances nor the hassles of managing each of them independently (in other words, their users will incrementally want to progress from ‘DAM Lite’ to ‘DAM Heavy’). As alluded to earlier, the DAM Portal users will face demands to allow end users to contribute assets directly back into the core system.
Right now, these two may well co-exist. I don’t know how long that uneasy truce will last though as more end users have to decide how in-depth they want (or need) to go.