Thanks for all of these (and to the original poster, too). As it happens, I just started looking at editors for a mobile application.
Some instant thoughts:
Create seems to work fine on the iPad. Mercury sort of works, but kept switching out of edit mode for some reason. Aloha didn't seem to work at all.
As with some of the other commenters, I'm not wild about having the editor tied to a Rails backend (I didn't explore what kind of backend requirements Create has, though they seem to imply on the front page that it's at least somewhat portable).
The only other editor I've found that appears to work on the iPad out of the box is CKEditor. My old standby, TinyMCE, is supposed to support it, but I didn't have much luck (it may be that this isn't in the release yet -- I'll go back and explore the source tree later).
Granted, Apple has only had proper support for contenteditble on iOS for a couple of months, but I urge editor teams to please try to make their stuff work on the iPad. There's a huge unmet demand for that, and there's a first-mover advantage here. :-)
If they can do something clever with the UI to make the editor also usable on a device with a smaller screen (e.g. the iPhone), they'll really be cooking with gas.
Create actually is not a WYSIWYG editor, but instead provides the CMS framework around it (objects, persistence, workflows).
Currently we support Hallo (as used in the demo) and Aloha Editor, but I'd love to have Mercury there too. Take a look at the editable widget to see where it could be added:
Inline editing is quite nice. I wonder if I am missing something about this: it seems to only offer italic/bold/underline/strike-through and no structural options?
Plug-and-play inline editing for various CMSs would be nice. If this had more features, I could see using it with a structured, lightweight CMS like Perch [1] to edit structured content inline with the published pages.
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 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.
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...
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.
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.
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)
There is precisely nothing new about this idea, even though this code might be fresher.
It would be interesting to hear how this thing addresses some of the shortcomings of the other inline editing components out there and how this is better.
It is certainly not a new idea, even we did our first implementation years ago. The main new thing here is that Create is completely backend-agnostic, only using RDFa to communicate content structure from server to editing interface, and Backbone.sync to communicate changes back to the server.
But apart from that, what sort of shortcomings are you particularly concerned about?
Rewording: Would be nice to have a list of CMSes or content stores which already provide plugins, themes, gizmos to insert RDFa attributes into the content.
It's obviously in its early stages, but I like the idea. Seems obvious that editing websites in the website itself is much more straight-forward than using some kind of backend (for small-scale CMS).
I've already posted this link in reply to others' comments but I'd love to hear your feedback on our fledgling project "designer platform" which allows you to deploy structured editing interfaces from your HTML: http://www.decalcms.com/page/Take_the_Decal_4_minute_challen...
It requires Firefox (I don't want to go back to FF), but I would consider starting it just for your site.
It requires signing up. I'm out. I have more than enough accounts already. If you want me to have a look at something, make it easily accessible. Sorry. :)
Thanks for taking a look anyway! If you'd like to email team@workingsoftware.com.au I'll configure a demo for you with a dummy email that doesn't require you to create an account.
It is obvious once you start using something like this (and especially when you see how happy non-technical users are about how much more in control they feel with their website because they actually understand what they're doing). I've had a lot of success over the past year or so using Concrete5 (an open source PHP CMS), which works in this way.
Scenario:
A single backend, providing content for an ever growing set of front ends (desktop, tablet, mobile in various permutations). Content editors need to ensure things look good in all output formats.
Solution:
Content editors get a button to preview draft content in all front ends. This opens up a tab for each front end. Front end uses the backend session to get permission to retrieve the draft content and loads up create.js during the rendering.
Using CORS the frontend is configured to send back any changes to the backend directly. Title width optimization can be done inline, all related pages can be updated right away.
All the front ends need to be able to do is identify an admin and to be able to pull the draft content and then include create.js. That is it. Booom, the front end supports inline editing. All your front ends support inline editing this way!
I was working on something similar to this (sorry, no showcase). There's a jQuery extension included for working with contentEditable text selections and formatting text with tags. I think it does a better job with overlapping tags and it merges anchor tags with same hrefs correctly. It does not work on IE < 9 (I think IE9 supports the gecko contentEditable api). You might find the code useful .
To me the novelty appears to be the backend agnostic RDFa communication with the content server rather than the inline editing.
Would be nice if more CMS backends would support this, followed by more and more editing frontends and tools. Thereby everyone could pick the component of their choice. Even different editing frontends for different unsers on the same system would be possible.
many people already suggested that the idea is not novel. this implementation doesn't add what i wish we had in a modern inline content editing framework: structure.
wikis had it for a while now. [[newpage]] anyone? i am wondering how difficult it would be to take wikis out of their textareas.
Yes - the problem of structure! That's the problem we're trying to solve with Decal. I've posted this link above but I'll stick it here as well so you see the reply: http://www.decalcms.com/page/Take_the_Decal_4_minute_challen... it's a pretty early prototype of how our "designer platform" will allow you to deploy structured, editable websites. I'd love to hear your feedback.
Structure is not in the demo, but Create does support relations. So if you for example have a collection of resources (say, an event list or list of blog entries), it knows how to add/remove them.
As for linking, there is a group within the project working on that. I hope we'll have something to show on that in Jan.
Can you explain what this is besides setting contenteditable to true on an HTML element container? I see some other dotted lines around certain sections when you focus on them but I'm not sure how this is really powerful past just setting contenteditable.
I would love to have this system for documentations and articles. Imagine if you let people easily improve texts, fix spelling mistakes, or translate pages, for documentation you wrote.
More generally, this would be awesome to use on a wiki.
The idea is to use versioning for this. Our backend-integrated version pulls version history of each item into a menu in the top bar, and there should be ability to switch between "Your version" and "Server version" there.
I've seen Thoughtbot do this with Copycopter (https://copycopter.com/) as well as Plone and others. It's a great way to sell user-editing features to your clientele, but I would always start with actual copy prior to enabling it as real copy is just as important as functionality for product design.
Yes, the marketing folks will just send you a bunch of disjointed word docs and expect you to assume that they'll fill in the blanks at a later date. Something that never happens.
That's too bad. I too found Plone's in-page editing to be a little too far beyond the reach of the average client, but then again, I used to send static website "versions" of a website on zip disks to a client in the mail. They knew not of FTP.
http://jejacks0n.github.com/mercury/
other notable and far more advanced (over create):
Aloha Editor http://www.aloha-editor.org/