I’ve used Opera on my BB, and it really sucks. By far the biggest problem is they seem to have stubbornly refused to use a UI which is consistent with *every* other BB app, which gets my heckles up immediately. It’s crashed to the point of completely locking out my BB several times too, forcing me to reboot. Not something I ever want to happen; I could get an important call at any time. Nothing else I’ve used on the BB has ever done that (except for a few things which have *suggested* a reboot, upon installation).

I’m steering clear of Opera.

Apart from the additional complexity of the system described above in terms of integration points, etc, it adds many more points of failure – a huge no-no for mission critical publishing systems – and, presumably, a significant cost implication with all of the extra licenses. So, while I do agree with the panacea view in you post for most organisations, I think that the publisher’s DAM approach is more pragmatic for many publishers.

Editorial systems are tailored towards print professionals for the creation, management and publishing of print-oriented (and sometimes electronic) content. They need to have features, data fields, and functionality to support those processes. DAM systems generally are tailored to serve graphics professionals. They are often deployed in order to help manage and transform these assets with interfaces and functionality tailored towards graphics professionals.

Take an average user who are not deeply involved with these two functions in an organization and turn them loose in either of these systems. The workflows, buttons, labels, etc. are likely to be confusing at best to the untrained user.

To me, it is important to carve out a new category of software in an organization to serve as a content hub. This should have a very straightforward interface, straightforward workflows, and straightforward functionality so that anyone in an organization can find and distribute content regardless of its origin. In this way, you keep novices out of systems that necessarily are focused on the needs of a technical group in the organization. Users of a content hub should not become lost in the arcane tactical details of creative, print or Web professionals. This also makes the overall IT infrastructure more management. You do not have to implement complex, error-prone “views” on tactical systems suitable for untrained users.

If you try to drop all of your users into a tactical production system, you usually find anyone not directly involved in that tactical process eschewing the system because there is too much “noise” between them and the content. A content hub creates a lower-common-denominator version of assets in tactical systems that should be readily accessible by anyone in the organization, preferably with a simple, clear interface that requires little or no training to use.

@Martinbrousseau
> “The best “maintenance” tool will be the winner. ;-) ”

Great point.

Guy