Forgot your password?
New user?
Document Actions
#122: Edit-in-place mode for all basic field types
- Contents
- Proposed by
- Alexander Limi
- Seconded by
- Martin Aspeli
- Proposal type
- User interface
- Assigned to release
- State
- completed
Motivation
Right now, changing a single attribute on an item requires much more work than it should. The edit screen is good for content creation and making substantial changes, but very often you just want to correct a spelling error in the description, add a few words to the title, etc.
There should be a better way to handle this.
Proposal
After a content type has been created, and you have a view, it should be possible to edit the elements by double clicking them.
When double clicked, the static area representing the attribute you want to edit turns into the editable version of that widget.
This of course won't let you be able to manipulate items that are not in the view, or create items — but that's not the goal of this implementation either.
Saving is performed by clicking outside the widget, and canceling is done by pressing the Escape key. We could of course attach "OK" and "Cancel" buttons to every widget, but I think this introduces too much clutter. This is an advanced feature that is off by default, and we can make it less verbose and more efficient because of that.
Validation should use the AT validation machinery.
Implementation
- Decide which widgets should support QuickEditing (hopefully as many as possible, the feasibility of this is still undetermined, though)
- Decide if there should be a marker that indicates that the item is clickable when editing
- We have to make sure that there is some text saying "You are now in quick edit mode, make your changes directly on-screen, and click outside the editing area to save. Press the escape key to cancel the editing" - or similar. User testing of this is key.
- It should be possible to turn QuickEdit on/off on a per-user basis - and on a site-wide level.
Risks
- We need to make sure that it is usable with the different widgets it is applied to. We have used this on a couple of internal projects, and it works well - but invoking Kupu on a double click might be a bit heavy.
Progress log
Bling currently has this implemented generally for all basic field types, both editing and validation.
Use the widget in view mode
implementation with KSS
There is demo implementation for this AJAX pattern in KSS. This is accessable live at http://azaxdemo.ree.hu/azax_instant_edit.html .
This demo does not include support for AT itself. We plan to implement this at the KSS sprint in September.
usability
BUT may this behaviour would confuse users, who are used to click on "save". or may the possibility that they forget to click on "save" in edit-view would increase. someone i know uses mac os and forgot sometimes to click on save - getting strange results.
another implication of double clicking on content and clicking outside is a more excessive use of javascript ("onmouseover, onmousedown" or whatever) which slows down things, especially on slower systems.
but i'm sure, i will like these new features, as i was surprised when i accidentally discovered the drag-n-drop reordering of contents in plone.
Turning in-line editing off...
1. For some reason, Plone doesn't detect that my Firefox browser supports Javascript, so I get a message telling me to turn it on. It's on. This is new to RC2 - RC1 detected javascript on Firefox just fine.
2. SO many times I have been showing someone a page and accidentally click on the text. It switches to quick-edit - I click outside the box, it switches back. It's too disruptive. A bit annoying.
Turning in-line editing off...
me too...
solution here
http://plone.org/documentation/how-to/how-to-setup-and-use-kss-on-plone-3.0/
Hmm
This adds obvious immediate value to basic archetype content types (ie base plone ATContentType types). But any serious applications I've worked with or built that are built on top of plone never use the standard views for custom content types and rarely use AT widgets on their custom views. I guess these would remain unaffected by this plip.