In regard to CMS interfaces I would say we could split them in 2 main branches [*1]:

  1. the ones with a control panel, where you go and usually see a list of pages (blog articles/ecommerce products), then you can update/modify each page, by filling form fields. More like: WordPress, Joomla...

  2. the ones where you look at the page, you click on the section you want to change and it appears a small editor where you do the changes. More like: Jimdo, Google sites (i think, not sure of this one), Many others.

Besides the pros and cons of both approaches [*2]: in some way I think the ones based on control panels (forms to fill) seem to work better when you have many contents to manage, like big blogs, big eccomerce sites, while the other approach (click and change) seems better for small websites.

But at the end of the day, which one is easier to understand/use/interact for the non-tech-geek final user? (I.e. my mother)

UPDATE: are there any researches/tests about this subject?

[*1] I know there are platforms that try to give you both approaches, example in WordPress after you logged in you see directly in pages small icons to modify the page, but I still think WP's control panel is more a form based interface, I mean if I have to change an article in my blog I use the control panel filling the forms.

[*2] feel free in your answer to explain what other pros and cons you see

  • @Vitality Mijiritsky: thanks for the editing, it's more clear now. Commented Aug 26, 2011 at 11:08
  • In-place edit all the way, specially for texts, images and titles. Normally a convination of both, for further complex conents. Commented Dec 28, 2011 at 20:39
  • As you indicate in your side note #1, your dichotomy is somewhat flawed, I think, since most CMS's handle a mixture of structured data and widget content as well as more freeform content. Thus, on some occasions WYSIWYG is preferable, and in others form-filling is the best approach.
    – agib
    Commented Dec 30, 2011 at 13:39
  • Joomla CMS also has an option of editing content "inline" on a frontend if user is logged as administrator/editor
    – shershen
    Commented Jul 8, 2012 at 18:35

5 Answers 5


In my experience, most WYSIWYG editors are too limited even for the non-tech-savvy users, and at the end of the day are more confusing than their dashboard counterparts.

When a novice user sees a WYSIWYG editor, they expect it to display exactly what they'll see on the published page. However for all but the most basic of elements this is usually not the case, and non-tech-savvy users get confused—either because the editor does not allow them to create what they want, or shows one thing in the editor itself and something entirely different after the page is published.

Dashboard interfaces may have a slightly steeper learning curve in the beginning, but they won't limit the novice users for longer, and don't set false expectations.


Direct manipulation / WYSIWYG interfaces (your #2) are easier for the novice user. This way they don't need to understand the hierarchy or the internal structure of the website, and they don't need to guess which category of the dashboard contains which settings, etc. They just locate the item they wish to change and work on it directly. They might take the very long and inefficient way to get there (e.g. browse and page rather than search), but eventually they do. The learning curve for this type of interfaces is not as steep as for the dashboard-type one.

  • I think there is a difference between Direct Manipulation and WYSIWYG. The former is more 'edit this bit of content that you see here' while the latter is more 'pretend you know HTML even though you don't and make a mess of this entire web site'. ;)
    – DA01
    Commented Dec 28, 2011 at 20:23
  • I wouldn't say that DM/WYSIWYG interfaces are necessarily easier for novice users. A well-established usability guideline is to constrain the number of possible interactions and for that purpose structured form fields are better. In a true WYSIWYG interface the lack of help provided by the form fields may leave the novice users confused as to what they are expected to input.
    – agib
    Commented Dec 30, 2011 at 13:34

1 is much more CONTENT management. The content is separate from the presentation and the tasks are dealt with from a content-centric perspective.

2 is much more about PAGE DESIGN management. The content is intertwined wholly with the presentation and you modify it as one.

In general, I find the biggest failing of most Content Management Systems is that they suck at managing content because they waste effort on trying to manage presentation, and typically fail at that as well cough SharePoint cough.

Most of the time, I suggest #1 is the way to go. This is for large organizations with multiple authors, multiple channels, multiple sites, multiple presentation layers, etc. In those situations, presentation should really be handled by those that understand it, and content should be handled by those that understand it.

That said, there are cases for #2...typically smaller, marketing-centric sites where one is editing more of a brochure than an enterprise content repository.


I think we need to differentiate the content the CMS is managing. When we talk about "CMS" everybody thinks of WordPress, SharePoint, and the like, which normally manage: page hierarchy, posts, categories and tags in the meta area, and title, text, and comments in the content area. But more complex CMS exist, such as e-commerce sites.

In the simple cases, I feel a mixed approach is better. Page hierarchy needs to be managed in a control panel (option 1), but title, content text, images, and even tags or categories would be easier to manage directly in-context (option 2). Both novice and experimented users would have a good user experience if they could edit pages in a true WYSIWYG manner (I hate how WordPress doesn't apply my custom CSS in the WYSIWYG).

Ideally, the front-end content should be editable in-context: texts, images, and even blocks and widgets. The meta content should be managed in a control panel, because of its back-end character.

Other more complex CMS, such as e-commerce sites, would have a hard time giving a both rewarding and efficient experience if they were to manage complex data from the front-end, thus, complex CMS will normally rely heavily in back office —or control panel— management.

StackExchange uses a kind of in-context editing. And a very good CMS that also uses in-context editing is Concrete5:

concrete5 in-context editing

To answer your question, in-context editing is easier to understand and interact with, both for novice and advanced users. This applies to simple CMS that normally handle copy-writing, images, some meta data and widgets. As a caveat, complex content is more efficiently (thus better for the advanced user) managed in an ad hoc control panel, such as e-commerce products, hierarchical or relational data, etc.

  • One major caveat is that in-context only makes sense if there's only one context for the content to exist in...ie, one location on one page on one site. This is often the case, of course, especially with small business brochure-type sites, but many sites wouldn't fall into this category where content is shared amongst pages and sites and localized and etc.
    – DA01
    Commented Dec 29, 2011 at 16:09

You might find useful this article: In-context vs back-end authoring, by Step Two Designs. It's not based on research, but this company has a lot of experience in this field.

This is an extract of the article:

For these reasons, in-context editing is often seen as the more usable authoring option. It is also commonly seen as a more ‘modern’ option for updating the site.

In-context editing is not without weaknesses. The very simplicity of the interfaces makes some tasks harder, or at least, less obvious.

  • Interesting article. Commented Dec 29, 2012 at 12:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.