CMS interfaces: forms based vs click and change?

Question

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

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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:

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.

Answer 5

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.