A dirty little secret in the CMS industry is that, while in-context editing is often what sells a CMS, the “power user” interface is usually what winds up getting used after implementation. This phenomenon obviously creates problems in the selection process because, when the sales demo focus on an interface that users will quickly grow out of, any usability impressions are irrelevant. This is also part of a bigger problem: the importance of in-context editing for sales has caused many CMS vendors to neglect their power user interface.
It is easy to understand why the sales demo gravitates to the in-context user interface: the audience finds it more intuitive. What is less obvious is why. In a typical CMS sales demonstration, the audience has the perspective of a site visitor. After all, this is not their site. They have no responsibility for it. As a site visitor, we think of editing the content that we see: “I see a typo;” “that sentence is hard to read;” “I would prefer to see another picture here.” The user just wants to go in and fix it — like a Wikipedia article. Until it’s fixed, that content issue is going to bug the user so directness and immediacy are critical. Like with a wiki, the in-context is ideal for solving these kinds of problems.
The content manager, however, has an entirely different perspective. The content manager is thinking more about the whole web site than any one page. The content manager has to solve problems like re-organizing the website and making global content changes. Needing to manually change every single page of a website is not acceptable so content reuse should be top of mind. From this perspective, the appearance of a page is less important than the actual content, which also includes information you can’t see on the page but drives the behavior of the site. You can even go so far as to say that the visible page (what the visitor sees) actively hides information that the content manager needs to see. The visitor shouldn’t know where else a piece of content is featured on the web site or what caused the personalization logic to show this item in this particular case — but the content manager does. Incidentally, this is why you should make product demos focus on scenarios. Scenarios force you to think about what the content manager does – not just dream of being able to edit somebody else’s web site.
Yes, you can make the argument that the occasional content contributor (who 80% of the time experiences the site as a visitor) needs a simplified user interface to fix the issues that they notice or keep a few bits of information up to date. But, as an organization gets more sophisticated with managing content, those cases of simplistically managed pages (with no reuse and no presentation logic) get less frequent. At that point, you are just talking about the “about us” page and some simple press releases. Are you surprised that this is what your basic generic CMS demo shows? Furthermore, I am beginning to believe that the occasional user is a myth (another blog post).
In-context editing interfaces are steadily getting more powerful by exposing functionality like targeting and A/B testing but there inevitably comes a point when the content manager wants the full power of the application at his fingertips. As the in-context editors get better, that point gets pushed further out. But adding complexity and power to the in-context editing interface will no doubt steepen the learning curve for the occasional user and minimize the wow factor of the demo. And no CMS vendor will do anything to reduce the wow factor of their product demo.
Related posts:
- New web user interface coming for Alfresco If you have been disappointed with Alfresco’s web content management...
- The Myth of the Occasional CMS User Not long ago, a university hired me to evaluate their...
- Website Product Manager I often tell my clients that every website needs a...
- Boston PHP User Group Meeting Last night Optaros hosted the Boston PHP Users group. Zend...
- CMS Architecture: Managing Content Type Configurations Warning: this post is highly technical. Non-programmers, please avert your...
Yes a CMS that focus on the editor is for me a failed CMS for sure. In fact, a CMS should not have any “editor” attached or bundled but provide interfaces in order to add content. Moreover I agree that a content should never ever be a page (unless special case).
I’m working on a CMS that is not web oriented but to manage all the contents you might have at home/work and might publish on the web (but not as a ultimate goal). The goal is more to indeed manage those contents in order to be sure you don’t *loose* them.
Some really good points here, Seth.
Another reason why an in-context interface might not be the best differentiator for enterprises is that with a few exceptions, many of the features that vendors provide in this area are highly commoditized. Organizations should be looking beyond – with an eye on the specific objectives of their web presence – to what each vendor can truly do to drive the results they need.
I disagree, though, that adding advanced or powerful features to an in-context demo lessens “wow.” Many of the more advanced features a real WCM provides are very wow. The power of allowing a marketer to designate content for a specific viewer, and weigh other content to segment that visitor, directly in-context is pretty wow. Being able to pull in content from a social channel such as Twitter, automatically create content items in your system, and reuse those where they will most drive conversion or engagement – that’s wow. A vendor should be able to translate the value of that functionality into a pretty compelling demonstration. Although, admittedly, we need to get better about that ourselves.
Incidentally, look forward to your “occasional user is a myth” post – I have some thoughts about that myself. Maybe a double-post?
Chris
Percussion
“occasional content contributors” – as you put it, are very common in the world of intranets. I’d agree, though, that especially for Internet sites, in-context editing is a “nice-to-have” feature.
As a Tridion specialist, I find that the click-and-type features of SiteEdit are very cool as demo-ware, however, the killer feature of SiteEdit is being able to navigate from the page directly to the “power user” interface. Don’t get me wrong, the click-and-type stuff has its uses, and can be very nice, but you could live without it.
I’d suggest that there is not only room for both, but a necessity for both. One should consider associating an interface to the task, rather than the user. I suggest the Content Manager needs both. The interface is task oriented.
- A user wants to test a few different images on a page. In-context editing is the best tool for this
- A user wants to see how a title may wrap within a template, In-context is the best place to do this.
- This same user wants to then approve the page and the image, clearly the power user interface is best for approving more than one item at a time.
- This same user then wants to see who is ‘next in the workflow’, and in that case the power user interface fits.
- The user decides to change the nav for the new page, go with Power UI
In the end, I think that In-Context is very useful for the purpose it serves. The Content Manager has a variety of tasks within a day and shouldn’t have to pick one UI over another if they are easily accessible. If folks are misinterpreting or misrepresenting that in demonstrations that is a separate topic.
I agree, Seth. I’d also add that there’s a good case for keeping the occasional user away from the in-context editing option as well. They’re most likely to succumb to the temptation to “design” their content in the WYSIWYG to pretty it up. A simplified, structured entry form helps that user focus solely on the content itself.
Nate also makes a good point. I just met with a client this week who is a power user entering highly structured articles into a CMS through the form-based interface. This content has potential to appear in several different places and formats. Unfortunately, she has no way to preview her content (in any context) before publishing. In her case, title lengths, paragraph breaks matter. For now, she has to publish, check the site, go back and edit, republish and check again. Ideally, the power user interface would have in-context previews for various places the content may appear.
Whilst I agree with your point that the “correct a typo” demo is a poor example, and that scenarios are hugely important, I think part of the problem is that most CMS’ have a distinction between a “power UI” and an “everyday UI” in the first place.
Good user interfaces do not work like this. Can you think of a single example of an application – CMS or not – that is considered to have an exceptional user interface that relies on such a distinction? I can’t.
Good user interfaces employ a single (or at worst a few), consistent metaphor that encourages progressive discovery and makes affordances for the most important features. A user’s role may control how much power they have, but the UI metaphor should not change fundamentally when one day you graduate from “casual” user to “power user”.
For most of the work I do, in-place works better, even for power users, because they don’t have to constantly guess what the end result will look like or flip between “editing” and “preview”. But more importantly, giving someone the label “power user” is not an excuse to give them a less intuitive user interface. Less advanced users need a good UI to avoid being confused. More advanced users need a good UI so that they are not slowed down. And there’s a big spectrum in-between the two that cannot be taken seriously if you make a binary decision between whether someone sees the “back end” (a term I’ve come to hate) and “front end” editing environment.
Martin