[andyking]

I have similar issues - our website is in WordPress and despite the ease-of-use of this particular package, a lot of people just don't seem to get it.

Some staff and volunteers pick it up quite easily, if they haven't already seen or used it before, but several people just don't do it, and instead I get a phone call or email saying "can you put this on the website?".

Incidentally, do you find a lot of people simply can't be arsed? One of our presenters (we're a radio station) is tech-savvy, has an iPhone, a Macbook, uses Facebook daily and so on. She's also one of the worst offenders for emailing me stuff to put on the website. I wonder if some people just plead ignorance to avoid having to do it themselves...

Anyway, back to the topic at hand, it would be one less excuse if we went to a solution like this - where it's simply a case of navigating to the page, clicking a button and editing it.

[bobfunk]

We're also aiming to solve this with Webpop (http://www.webpop.com).

we dont do inline editing, but on-site editing where you navigate to the page you want to update and click edit, we then highlight all dynamic content on the page and bring up the relevant form when clicked.

In our first prototypes we were playing around with inline editing, but ended up concluding that it causes more problems than it solves when you're dealing with a real website with dynamic content.

One example: you have a news section, and on the homepage the last 3 stories are pulled in, but with the body text truncated to 100 characters since more would break the design. Inline editing here will be problematic. There are plenty of other cases (just think text-overflow: ellipsis;) and there's also the contextual problem of how to communicate to the end user that he is editing structured content that might be reused in different places on the site, with an interface that pretends to be completely WYSIWYG.

We think our way of on-site editing is the best compromise between making updates easy and making the conceptual model clear.

[ishi]

The text in the black area of your homepage is ridiculously dark. Everything looks "disabled", including the top navigation bar.

[franzmaruna]

we actually had the same experience with early versions of concrete cms. Everything was on the page and it was a hard experience. We then pulled things more into overlays and it made a lot more sense for people, and was easier/more consistent to develop with.

Generally the promise of in-context editing is you can fix a typo from the same place you see it. I think trying to make it a pixel perfect "edit looks EXACTLY the same as view" deal is too literal.

http://concrete5.org is doing quite well with the overlay approach, and no one says our software isn't intuitive enough because the editor is in a window.

[bergie]

Typically with Create we simply don't make "generated" content editable, so in this case the truncated body text would not be available in the editing UI.

In this situation user would need to go to the article page to edit the actual contents.

[dools]

This is exactly the problem we're solving (well, trying to) with Decal CMS. I've been holding off on trying to drive traffic to our initial demo because it's still a little rough around the edges but if anyone wants to check out our early prototype/demo we'd love to hear your feedback http://www.decalcms.com/page/Take_the_Decal_4_minute_challen...

[lux]

Also trying to solve this problem in a new minimalist open source CMS that just hit 1.0:

http://www.elefantcms.com/

I'm also tired of fixing Wordpress malware issues for friends and clients that host themselves...