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.
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.