Picturepark Add “Ports” Features


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.

Share this Article:

One comment

  • Thank you for the write-up, Ralph! I wanted to confirm that you are correct about the uploads. Currently, we don’t support this via Ports. (But for the record, it’s a hack that’s currently possible.) ;) We will make it official, however, in the next Ports upgrade.

    Embedded ports, like the one that’s seen on our Ports page (http://picturepark.com/ports), are encased in iFrames, as you mentioned. But standalone “branded” ports are directly accessible like any other Web app. You might have guessed there is absolutely no difference between the two other than the size of the template and, of course, the content in the port. You could, in theory, put a branded port inside an iFrame too, or you could directly access an embedded port without the iFrame. (This makes it possible to reuse embedded ports in any many different locations as you need. So, for example, the very same port could appear on a company’s own website, and on the websites of its partners.)

    This brings me to the comparison with “DAM Lite.” I think a key difference here is the perspective of the asset owner. In our case, ports are extensions of a Picturepark. They enable the Picturepark customer to publish content in multiple locations using different interfaces. Ports are not intended to be “DAM Lite” interfaces to sign up new customers who aren’t interested a complete DAM.

    That said, because Picturepark is based on a true multi-tenant architecture, the Picturepark admin could configure the system so that each tenant had its own port that served as their primary “DAM Lite” interface. This will become much more feasible, though, once we officially support upload operations via ports.

    So I do see your “two sides of the same coin” argument. In the case of Picturepark, however, the “DAM Lite” factor comes into play really only when Picturepark is used to host multiple tenants. (Or, in the case of private Cloud providers, multiple Picturepark instances.) I know that sounds confusing, but if readers are interested in the differences between “tenants” and “instances,” they’re described here: http://picturepark.com/resell-dam

    Again, thank you very much for this article!

    David Diamond
    Director of Global Marketing
    Picturepark

Leave a Reply

Your email address will not be published. Required fields are marked *