#122: Edit-in-place mode for all basic field types

Contents
  1. Motivation
  2. Proposal
  3. Implementation
  4. Risks
  5. Progress log
by Alexander Limi — last modified Jan 21, 2010 07:26 AM

A lot of the time you just want to change a single attribute on an existing item. We want to enable an "advanced users" feature to make this quicker and more efficient.

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.

Hmm

Posted by Rocky Burt at Mar 13, 2006 01:10 PM
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.

Use the widget in view mode

Posted by Alexander Limi at Mar 16, 2006 10:17 PM
What I want is that we invoke the widgets in view mode, so they get all the necessary behaviour attached for QuickEdit functionality. You can still construct your view with lovingly hand-crafted HTML, but whenever you want to print a value, you do it by calling the view mode of the widget.

implementation with KSS

Posted by Balazs Ree at Aug 27, 2006 02:04 PM
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

Posted by johannes raggam at Oct 30, 2006 03:32 PM
its a good idea to auto-save content - when clicking outside -
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...

Posted by Jim Baker at Aug 14, 2007 02:18 PM
OK, where do I go to turn this cool feature off? Two reasons:

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

Posted by Mahesh at Dec 15, 2007 02:03 AM
Have you got any solution for this? Please let me know I'm looking for a solution to this problem. Thanks in advance

me too...

Posted by Ivan Price at Jan 14, 2008 12:18 AM
the in-line edit should be able to be turned off for certain widgets for the above reasons, plus edits made this way don't appear in the history tab as they should. does anyone know where the function is called to load the editor so i can comment it out in the meantime ?

solution here

Posted by Ivan Price at Jan 14, 2008 01:12 AM
plone rocks !!! here is the very easy way to disable inline editing... although i couldn't get 1.5 to work 1.4 did the trick.
http://plone.org/[…]/