[kde-guidelines] Styleguide: Inline editing

[Aurélien Gâteau]

On Thursday 04 July 2013 13:28:43 Thomas Pfeiffer wrote:
> On Thursday 04 July 2013 12:41:10 Heiko Tietze wrote:
> > Unconstrained input
> > * For complex views with direct input provide inline editing.
> > 
> > http://techbase.kde.org/Projects/Usability/HIG/inline_editing
> > 
> > Purpose
> > Inline editing is a feature of some controls. For example, list views are
> > controls that can be used for editing purpose as well. When the user
> > accesses an editable cell, usually by clicking the cell, its behavior (and
> > appearance) is changed from viewing mode to an editing control. The input
> > control can be applied as an unconstrained edit or as constrained input,
> > e.g. selection from a predefined set using a drop-down list. The advance
> > of
> > direct input is a concise layout since no additional control is needed for
> > input. The approach is usually less error-prone because a list with direct
> > input has no dependency to other controls (in contrast to the combination
> > of a list with an edit which needs to be enabled or disabled appropriate
> > to
> > the list entry the user clicks). The drawback is reduced discoverability
> > for lists with restricted editing function, at least when only a few cells
> > can be changed. User does not know which cell is editable and which is
> > not.
> > Furthermore, native access via tab or access key is not available within a
> > list which means keyboard navigation needs to be implemented.
> > 
> > Guidelines
> > * Switch from viewing mode to edit mode after single click on the editable
> > cell.
> 
> The only implementation of inline editing in KDE applications I'm aware of
> is in Kontact's To-do List. Here, it is activated via "slow double-click".
> I suppose that's custom-build though, so we can define a different behavior
> in the HIG.

This is actually the standard "rename" behavior of a list when single-clicking 
it does not trigger an action.

You can see it in action with Dolphin or Gwenview: select a file and press F2 
to rename it.

> Are there any other existing examples of inline editing?

Not that I know of.

[snip]

> I guess we'll need to define how that distinction should be visualized.
> Otherwise every developer comes up with a different visualization.
> 
> Other than that, I'd love to see more inline editing in KDE applications, so
> this guideline is very welcome! The question is: Will we see widespread
> adoption without a ready-made component to implement it?

I don't think it makes sense to have a guideline for it without an existing Qt 
or kdelibs class.

Don't get me wrong: I too would love to see more inline editing, and I am 
willing to implement the necessary classes, but it feels disconnected from 
reality to recommend something which cannot easily be done (again, we need to 
keep in mind the HIG is in use right now).

What about keeping the guideline outside of the HIG, and move it when the 
relevant widgets are ready?

Aurélien