Forgot your password?
New user?
Document Actions
#238: Disable inline editing by default
- Contents
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
- in-progress
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
small edit icon
Posted by
David Bain
at
September 30, 2008 - 01:24
I agree with using edit icons the way Salesforce.com implements it, it will minimize the "accidental" edit screens.
edit icon
Posted by
Wichert Akkerman
at
September 30, 2008 - 08:18
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.
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.
Very sensible
Posted by
Jon Stahl
at
September 30, 2008 - 14:09
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."
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."
Framework team vote
Posted by
Martijn Pieters
at
October 26, 2008 - 16:53
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
Framework team vote
Posted by
Danny Bloemendaal
at
October 27, 2008 - 15:51
+1 and please let's propose a fix for the UI to make it work as it should have worked since day one.
Framework team vote (for Plone 3.3)
Posted by
Andreas Zeidler
at
October 27, 2008 - 16:13
hmm, i think we shouldn't change the default (re UI changes in minor releases; again see http://lists.plone.org/pipermail/framework-team/2008-October/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.
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.
PLIP a proper fix for Plone 4.x
Posted by
Andreas Zeidler
at
October 27, 2008 - 16:14
and yes, please someone plip the approach Jon outlined above for Plone 4.0
Framework Team vote
Posted by
Tom Lazar
at
October 28, 2008 - 10:12
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.
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.
framework team vote
Posted by
Raphael Ritz
at
October 28, 2008 - 15:07
+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.
@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.
+1
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.