Why don't all Content Management Systems work this way?
The edit-in-place model as demonstrated in this post makes so much sense. It seems crazy to have a CMS with a separate backend when the backend can be the frontend.
I've found that new WordPress users are confused as to why, for example, the text they type in the post editor is set in a serif typeface when their site is displayed in sans-serif, or when their H2 tags are larger in the post editor than on the site itself. And those are only tiny examples -- I'd guess that a large proportion of new user (dis)orientation is related to the enforced disconnected backend that the majority of content management systems adopt.
I think WordPress et al could hugely benefit from a pure edit-in-place model, with overlays or sidebars for any non-visible configuration like permalinks, draft posts, and email settings. WordPress 3.1 moved the admin bar onto the front page; perhaps this is a sign that more of the backend is to follow?
In our first prototypes we were experimenting with inline editing, but we actually decided against it.
The really good thing with allowing editing right on the site is that it matches non-technical end-users conceptual model of a website far, far better than some abstract admin backend for their content.
This is a big deal, since for many users even something as seemingly simple as Wordpress can be really hard to explain. They just don't intuitively understand that there's a database somewhere with content that are then sucked into their website and displayed. And when they want to edit something on their site, they don't want to go somewhere else to look for it.
The bad thing, in my opinion, with actually doing inline editing, is that the end users conceptual model is actually wrong. There really is a difference between content and design. The same content can often be displayed in many different places and used in different ways.
Sometimes you have an article with a long text and big photo, but choose to only show the first paragraph of the text as an excerpt on the front page together with a thumbnail version of the photo. Or you truncate the title to a short version to show a teaser for the article in a small box in the sidebar, etc, etc.
If the user clicks on the excerpt of his long text to edit it, inline editing starts getting problematic. Do you allow him to edit only the first paragraph inline, leaving the user unaware that he might make the next paragraph in the article sound really weird if he change it? Or do you expand it to the full text with the risk that the design will get completely mangled?
Some of these problems are solvable if you limit how the designer can use the content and what HTML/CSS he can write (CSS can really mess with inline editing as well - just think about overflow: hidden or white-space:nowrap).
That's why we went for a small miniform triggered by clicking directly on the content you want to edit, but with a link to the full form for that content. We want to gently guide the user towards the right mental model of how their website works, without forcing them to go search for the right content in a backend interface whenever they want to edit something.
>The edit-in-place model as demonstrated in this post makes so much sense. It seems crazy to have a CMS with a separate backend when the backend can be the frontend.
Absolutely. In my experience "normal" users are much less confused - and more likely to actually manage their content - when they can edit their content in context instead of in an entirely separate interface.
Concrete5 CMS is pretty good at this - though the code behind the scenes is a bit wonky. This UI looks quite nice as well, but again behind the scenes... And I've yet to see a Rails CMS implement this at all (though I'm keeping my fingers crossed - please HN prove me wrong).
This allows you to still communicate with a separate backend, just implement Backbone.sync in the way you need. There is even a guy implementing this system for Jekyll (a static HTML blog generation tool)
Perhaps that's why WordPress doesn't do it yet. To offload CMS functionality onto theme designers (and to make it a requirement to be able to use WP) might prove disastrous; the editing experience could become inconsistent between themes.
I would guess it is in part because a lot of them carry around far too much baggage that adding this in afterwards is too much work.
I am having a shot at it with django. Rather early yet, but doing something like this is the goal. It only really exists on svn right now http://codefisher.org/svn/djangopress/
WordPress 3.0's default theme applied the same CSS to the backend post editor as well as was used on the the front page. Well, that was the idea, anyway. It sounds like it didn't work out so well.
That's interesting -- I didn't know that. I've just logged into one of my sites, and the editor is using the 'content.css' stylesheet from tinymce, rather than inheriting styles from the homepage.
The edit-in-place model as demonstrated in this post makes so much sense. It seems crazy to have a CMS with a separate backend when the backend can be the frontend.
I've found that new WordPress users are confused as to why, for example, the text they type in the post editor is set in a serif typeface when their site is displayed in sans-serif, or when their H2 tags are larger in the post editor than on the site itself. And those are only tiny examples -- I'd guess that a large proportion of new user (dis)orientation is related to the enforced disconnected backend that the majority of content management systems adopt.
I think WordPress et al could hugely benefit from a pure edit-in-place model, with overlays or sidebars for any non-visible configuration like permalinks, draft posts, and email settings. WordPress 3.1 moved the admin bar onto the front page; perhaps this is a sign that more of the backend is to follow?