Does it need structural options?

At work, I'm supposed to change a lot of our existing websites over to "Wordpress CMS" because it'll make it easier for the admin staff to modify the website, for updates and such.

The problem is, they need to locate the login then they need to remember their account info, then they need to find the right page they want to modify, then they have to do a bunch of other clicks to get what they want.

Unfortunately, this tends to go woosh right over a lot of heads, and therefore stuff simply doesn't get updated - they send the 'update' via email to IT.

The cool thing about this createjs thing, is that you design the website, you put up the content and you have a simple login form. Everything is editable by clicking and typing directly from the site you're looking at.

I'm sure it'll help in situations like mine, for sure.

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.

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.

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

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.

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.

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

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

Same problem here. The admin site structure of the typical CMS is an abstraction that makes obvious sense to us developers, but not necessarily to the content managers. Inline is the future.

Couldn't agree more. For the past year or so I've been building sites for clients using Concrete5 (an open source php CMS), and it has this concept at its core -- you edit the site on the actual pages themselves, which much more closely matches the mental model of non-technical users. Furthermore, it provides a lot of flexibility for the developer to customize the editing interface -- you edit content as smaller "blocks" on a page instead of one monolithic WYSIWYG editor for the entire page. In this way, you can have a small little custom interface specifically tailored to that one spot on the page. It's a really elegant system that is unfortunately not as well documented as it could be (I'm hoping to do something about this in the near future though), and since it's a relative newcomer to the php CMS world (open-sourced in 2007 or 2008?), it doesn't have as much name recognition as Wordpress/Joomla/Drupal. But as you point out, inline is the future, and C5 is way more mature than any other similar CMS I've seen, so I think it's an ideal solution for many CMS needs.

Most of the expensive CMS products have edit in place, so a user can just click and edit. This does come with quite a large overhead in pageweight in my experience.

Email is actually a perfectly valid web publishing protocol. We've done quite a lot of systems where clients can publish news items by just mailing them to a certain mailbox.

And http://www.deathmonkey.org/ was completely produced by sending emails from (old, pre-iPhone) smartphones on the road.

Ditto. I update my blog via email.

I love posterous for this reason. I find email is a natural interface for a lot of things and only wish I could do more just through email (like, I dunno, email social network interface perhaps?)

Since 3.2 (I think... maybe 3.1) WordPress has had an admin bar. The practical application of this is that once you're logged in, you can navigate to the page you want to edit (on the front-end of the live site), and then click "Edit Page" in the persistent bar at the top of the screen.

Author of Create here. The demo uses a minimal configuration of the Hallo editor. You can also enable block-level formatting, and there is a quite nice image and link plugin coming soon from the nice people at Liip.

Aside from Hallo, Create also supports Aloha Editor (http://aloha-editor.org/)

Looks like you're right about the i/b/u/s options. Definitely needs a few more (link for one), but looks like a cool start at least. I like that it's client-side and works with a simple Backbone.sync back end.

Take a local checkout of https://github.com/bergie/hallo and try the example there. You'll have a lot more formatting options.

We will have a hack weekend on Create in January in Zurich, and hopefully after that I'll update the demo setup with a lot more features enabled (formatting, images, workflows, etc)

Sweet! Looks like it's skinnable too, is that true? That would be awesome.

What would also be awesome is a simple way to add options yourself via callbacks in JS.

Looks like you can write plugins :)