#238: Disable inline editing by default

Contents
  1. Definitions
  2. Motivation
  3. Assumptions
  4. Proposal
  5. Implementation
  6. Deliverables
  7. Risks
  8. Progress log
  9. Participants
by Wichert Akkerman — last modified Jan 21, 2010 07:28 AM

The current inline editing behaviour as introduced in Plone 3 was a mistake: it is a cool technology to show off, but in practice accidental clicks very frequently lead to unwanted edit-screens.

Proposed by
Wichert Akkerman
Proposal type
User interface
Assigned to release
State
completed

Definitions

 

Motivation

I suspect that by now most of us have realized that the current inline editing behaviour in Plone 3 is not very practical. It has two main problems:

  • it is very easily triggered by default, which causes unwanted edit fields to be opened which have to be manually closed. This happens because many, if not most, people click accidentily, select text to keep track of the reading position, try to select text to copy&paste it or for other reasons. Since every single click activates inline edit this happens all too often and becomes very frustrating over time.
  • as Alexander mentioned in his new UI proposal what you really want is a quick option to go to a full edit-mode. Editing a single field is a much less common operation than we were expecting.

I can't think of a single Plone deployment I have been involved in for the last 6 months where we have not disabled inline editing, which strengthens my believe that the current default is wrong.

 

Assumptions

 

Proposal

Current Plone releases have a simple toggle to enable or disable inline editing. I propose that we change the default for newly created sites to disabled.

Please note that I do not propose to disable inline field validation in edit screens: that is a very useful and desirable feature.

Implementation

 

Deliverables

 

Risks

 

Progress log

 

Participants

 

Comments (15)

Jon Stahl Sep 27, 2008 10:32 PM
Our users *hate* inline editing as currently implemented. Field-at-a-time editing sounds good on paper, but (as Wiggy says) we've rarely found it useful in practice.

One note: if the consensus is that inline, field-at-a-time editing really is desirable, then there is a much better way to design the UI. Salesforce.com has inline field-at-time-editing that works like this:

-- when you mouseover the field a small "edit" icon (looks like a pencil" appears to the right of the field.
-- you have to click the edit icon to actually trigger editing on the field.

this prevents accidental clicks and is not too annoying.

If we keep inline editing in any way, I'd strongly encourage us to adopt this UI paradigm. It really does work nicely for average users.
David Bain Sep 30, 2008 01:24 AM
I agree with using edit icons the way Salesforce.com implements it, it will minimize the "accidental" edit screens.
Wichert Akkerman Sep 30, 2008 08:18 AM
I agree that the pencil-icon approach is much better, and it has been discussed before Plone 3.0 was released but apparently it was either too difficult to implement or mistakenly thought not to be an improvement. Ah, the joys of hindsight..

From a procedural point of view I would like the pencil-icon proposal to be a separate PLIP with a separate champion. I can not implement it, and I do not want to see this PLIP not be accepted due to that. Lets disable the current behaviour first and then work on a better approach.
Jon Stahl Sep 30, 2008 02:09 PM
Wichert-

This is very sensible. I wanted to inject the idea of "what good looks like" back out there, fearing it had been lost, but definitely don't want to hold "disabling" hostage to the greater work of "fixing."
Martijn Pieters Oct 26, 2008 04:53 PM
Although we have a concensus to not remove, change or move major pieces of the UI, the inline editing feature is currently so confusing that I certainly feel this is an exception. +1 on this proposal
Danny Bloemendaal Oct 27, 2008 03:51 PM
+1 and please let's propose a fix for the UI to make it work as it should have worked since day one.
Andreas Zeidler Oct 27, 2008 04:13 PM
hmm, i think we shouldn't change the default (re UI changes in minor releases; again see http://lists.plone.org/[…]/002228.html). so i'm -1 on changing the default.

however, i'm +1 on adding a boolean field in "site_properties" (ZMI), which would automatically give us GenericSetup support and make adding an option in "site setup" rather trivial. the latter should also be part of the PLIP, imho.

anyway, i'm +1 on accepting the PLIP itself — the "default" question can still be discussed.
Andreas Zeidler Oct 27, 2008 04:14 PM
and yes, please someone plip the approach Jon outlined above for Plone 4.0
Geir Baekholt May 20, 2009 11:39 AM
I don't think a "proper" fix for this is needed now that we are revamping the UI for Plone radically anyways. I'd rather see new effort going towards improving Tiles/Deco than adding icons to inline-edit :)
 
Andreas Zeidler May 20, 2009 12:55 PM
+1
Tom Lazar Oct 28, 2008 10:12 AM
my users first go 'oh cool!' when i show them the new feature and then, as time passes, ca. 50% find the default behavior more annoying than beneficial. the rest doesn't seem to care much either way.

so, IMHO the current state is a usability bug for many folks and remedying it would help *them* while the others would only miss a feature which they could then activate. i.e. the current state does more harm than the scenario the plip proposes.

i'm therefor also +1 on this.
Raphael Ritz Oct 28, 2008 03:07 PM
+1 on just changing the default.

@Andi: we do have that switch already or what do you mean.

And while we are at this: personally I do like inline editing for simple fields like title, description, a date and such. But where I really HATE it is when it comes to text fields as they often contain a large body of text that you want to scroll through, that has links embedded that you want to click etc.
Tom Lazar Jan 24, 2009 11:36 AM
As stated previously, I'm all for this one :)

Re: "No UI changes in 3.3", I'd say, that most people who care about this, would consider this a UI bug fix, so I think it can be argued to be included into 3.3.
Bryn Hughes Jun 30, 2009 12:55 AM
There are some cases where I really really really like the current behaviour. The biggest one is after batch uploading content - IE uploading a folder full of pictures and then going through and editing name/description afterwards. With the new next/previous folder navigation this becomes a very powerful tool for editing a lot of content types very quickly.

What I'd like to see though is a bit more control over when it is enabled and when it isn't. For instance on "Images" I pretty much always want it enabled, but for other content types I'm not so interested. If it could be enabled/disabled on a per-content-type basis that would rock.
Laurie Cooklis Nov 15, 2009 12:46 AM
My thought is that if permissions were more exposed/obvious for inline editing behavior, it could be controlled via workflow. Then we could turn it on/off at any level on the fly.

Power to the people! ;)