[kde-guidelines] Styleguide: Inline editing

[Thomas Pfeiffer]

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.
Are there any other existing examples of inline editing?

> * Change appearance of cells when switching from viewing to editing.
> Editable cells have a lowered bevel; they look like they can be filled.
> * Mark currently changed cells with a red corner.

Wouldn't it make more sense to apply the changes instantly when the editing 
mode is left? In that case, we wouldn't need to mark them.

> * Define keyboard navigation within the list since the control receives
> focus as a whole. By pressing arrow-down key the next row is focused;
> respectively arrow-up for previous row. The arrow-left or arrow-right key
> navigates to adjacent columns if available.

What if we have controls that take arrow keys as input (such as combo boxes or 
sliders)?

> * Use the appropriate control for constrained input. Show the control’s UI
> (e.g. arrow for drop-down list) not until the cell is in edit mode.
> * Distinguish editable cells from those that are read-only.

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?