Create - A new kind of web editing interface(createjs.org) |
Create - A new kind of web editing interface(createjs.org) |
http://jejacks0n.github.com/mercury/
other notable and far more advanced (over create):
Aloha Editor http://www.aloha-editor.org/
Aloha uses jquery-based selectors to identify editable content areas as opposed to Create's more standardized and semantically accurate RDFa.
(This is based on all of 3 minutes of poking around so I don't claim complete accuracy.)
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.
* Your web system has to publish content with RDFa annotations * You need to have some API you can connect to Backbone.sync
...and even the latter isn't so bad, as Backbone.sync can be overridden in your local implementation. For example, we use the same stuff with Socket.IO instead of REST: https://github.com/IKS/ViePalsu/blob/master/js/contentmanage...
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:
https://github.com/bergie/create/blob/master/src/jquery.Midg...
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.
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.
But apart from that, what sort of shortcomings are you particularly concerned about?
(it looks well done and it's interesting, but it's not a 'new kind of editing interface')
jQuery('something').create({editor: 'aloha'});
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. :)
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!
Link to jQuery extensions: https://github.com/skid/wimp/blob/master/js/jq-extensions.js
*disclosure: I released this project
Maybe Etch you also run with VIE's Backbone models? http://viejs.org/
Then you could basically swap between Etch and Create with the same mark-up and server-side implementation.
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.
But first you have to have one nice editing interface as a carrot so CMSs start supporting the needed features.
I think this can be altered by calling stop() before animate()? But it's been a bit since I worked with jQuery.
wikis had it for a while now. [[newpage]] anyone? i am wondering how difficult it would be to take wikis out of their textareas.
the other concern is naturally security.
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.
More generally, this would be awesome to use on a wiki.
This makes editing even more accessible.
which shows the problem of managing something like this through a third party anyway!
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.
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.
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.
And http://www.deathmonkey.org/ was completely produced by sending emails from (old, pre-iPhone) smartphones on the road.
Aside from Hallo, Create also supports Aloha Editor (http://aloha-editor.org/)
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)
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.
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.
In this situation user would need to go to the article page to edit the actual contents.
I'm also tired of fixing Wordpress malware issues for friends and clients that host themselves...