Wednesday, January 30, 2013

CMS deconstructed: is user experience all that remains?

In the last couple of years, more and more functions that are typically part of a bigger product have been "extracted" from such products and released as service available on the web, often for free. Take for example video publishing. No longer is it strictly necessary to have your own infrastructure to publish videos on the web – services like YouTube or Vimeo can be utilized, often for free. The same is true for  much of  the functionality found for example in a content management system or web experience management suite:
  • Video publishing: Youtube, Vimeo…
  • Image editing & publishing: Flickr…
  • Task Manager: Remember the Milk
  • File Sharing: Dropbox
  • Document Management: Google Apps
  • Analytics: Google Analytics
  • Comments:  IntenseDebate
  • Project Management: Basecamp
  • Publishing: tons of hosting providers
  • … uncounted others for every aspect you can imagine
Photo ©Boris Kraft. All rights reserved.

So you could say there is a trend to deconstruct content management (there is also an opposite trend, building suites that try to do everything you ever need, but I'll discuss that in a future blog post).

One very recent example is the real time web. There actually are cloud services that do nothing more than allow your content to be refreshed on the client without the user reloading a page (remember the Push web?). Great for instance for live coverage of events. This functionality clearly should and will be delivered by any good ol' CMS worth its salt sooner or later. Still it apparently is an urgent enough business objective to have spawned companies that do nothing else (not a long term viable business proposition I'd assume, but I digress)

If you take that trend to the extreme, all functionalities that you find in a software like Magnolia could eventually become individual web services provided by a host of companies. Maybe we have a company that offers workflow on the web (been waiting for that for at least 10 years), companies offering JCR storage, services to write rich text snippets and others to publish them. You get the picture: theoretically we could move all the individual bits and pieces of a product into cloud services. 

For the sake of pleasing our imaginative minds, assume that a vendor like Magnolia follows suite and keeps reducing the functionality provided by the product, opting instead to integrate a web service. To some extent, that has already happened – for instance, Magnolia uses CampaignMonitor to run email campaigns, IntenseDebate for commenting (we additionally provide our own commenting module), and Google Analytics for analytics and A/B testing. 

Continue down this road and all that eventually remains is a shell for the various pluggable web services. And what is a shell but a user interface?

So, provided one day a CMS is only a UI on web services, wouldn't that mean that the user interface is the most important part of the product? If every CMS is using the same web services (or allows you to pick from the same such services), the only difference between them will be the user interface.

Not that I believe that will actually happen (otherwise we'd no be developing so much functionality for Magnolia Five), but either way our focus on providing the best looking and best working user interface in the industry certainly allows me to sleep well even if it would.



  1. Well, this is something that's been going back and forth over the years... But I suspect the reality of it is, that no matter how cleanly we try to separate code, logic, business rules, design, and content; the UI tends to codify parts of it.

    So if you like a CMS' UI, you'll have to deal with its particular architecture. And the other way round; you may like an architecture, and then have to deal with the UI it requires (and it may not be the most usable thing ever).

    Since perfect abstractions of concerns are a fata morgana, this is exactly why there are so many CMS available... my perfect balance may not be yours. And mine will change from project to project. There is always a compromise.

    But if only for aestheticism, I'd like to think of it as separate, distincts aspects, and it's probably a good way to move forward with a CMS. Even though it's a pipe dream to run a Magnolia UI with a Hippo front-end on a cloud JCR while managing assets in Adobe CQ -- and you probably wouldn't want to even if you could.

    Because Frankenstein can be worse than the sum of all parts. Looks matter, and so do UIs -- they reflect what's underneath ;)

    1. Thanks Adriaan. The abstractions topic is a big one – especially in context of a CMS. We have for a long time discussed e.g. how to do inline editing, which is so loved by editors and so far haven't found a solution that would not break the abstraction rather sooner than later. The web is not a word document. Trying to abstract the web part will simply not work, at least not for anything beyond a simple blog post.

      But a good UI could certainly abstract from many of its underlying architecture decisions. If the UI has an underlying layer that abstracts the external services, you could achieve a lot in terms of abstraction and usability. However, the more logic you pack into the abstraction layer, the more maintenance it will need. It would be fairly easy to do a UI that allows you to enter API calls directly and do something with the result, but that wouldn't be satisfying for business users, and probably not very efficient to manage online campaigns ;-)

  2. Nice thought experiment!
    You take it to the extreme in your post, but its clear that the trend of using web services will continue to grow. People gravitate towards good tools (web services), even if they are not a part of a suite that they currently use. Using a “socialized” web service like YouTube has other advantages, the likes, shares and views in it’s community. It’s clear with Magnolia 5 that an entire category of m5 app will be web service integrations.

    Your post is on UI, but another interesting topic is the organization, presentation, “management” of the content from these services. A CMS must have its own data structures which, in the most basic case, store how the “views” of the web service items are presented on a page. (The page editor in Magnolia) Searching across items in disparate services could also be useful. Could there be another category of app which facilitates the combination, mixes or remixes of the items of the web-service content apps?
    The idea of a CMS as web service integration reminds me of mashup tools like

    Another line on your proposition - if a CMS was pared down to just a UI system - could one subscribe to a UI as a service?