Many Web CMS products tout "in-context," wiki-like content editing as an important feature or enhancement. In-context means letting contributors create or edit content from within the context of the site, without actually having to retrieve a content item from the back-end and filling in long forms.

Not all vendors offer in-context editing, and many do so only partially.  You can find more about different vendors' support for in-context editing in our Web CMS Report.

To be sure, many products have allowed you perform in-context editing for some time now. However, the difference is that in the past, clicking on "edit" in the site would open up the back-end form, whereas now, you can typically make in-place changes right on the page.

From the point of view of usability and convenience, this is certainly useful. In fact, I see in-page editing actually becoming a "preferred content contributor interface" rather than just a "casual business user content contributor interface" of yesteryear.

The main problem I have with this approach, if used exclusively as recommended by some vendors, is that it goes against a basic tenet of Content Management -- to separate content from its presentation. Basically when you create content based on how it looks, you tend to think about only those fields that appear on that specific page. Consider the implications:

• What happens to those extra fields that do not appear but exist because of other reasons - administration, reporting, analytics, personalization, search and so on? They would either take default values or be ignored. Or perhaps someone else will enter those values later.
• When you enter content in context of a page, what happens if the content appears at different destinations with a different look and feel - say an intranet and public website? Even worse, what if the fields that appear on the Intranet are different from those that appear in the public website?
• Similarly, if an article appears on the home page with a few fields and on a detailed page with many other fields?
• And then what do you do if the look and feel is changed due to a redesign?

There are many other implications that we detail in our research reports.  Like everything else, there are obvious work-arounds as well as trade-off here, and the trick is to maintain a balance between in-context content contribution and more traditional content contribution.

Make sure that the WCM products you are evaluating support different mechanisms of content contribution: from form based, to in-context authorship, to integration with external products and automated ingestion. Also consider very carefully the scenarios and then enable appropriate roles with the right corresponding content entry mechanisms.  Not all contributors will require in-context editing.