[Libreoffice-ux-advise] [UX advise] Key navigation in ValueSet controls

Matteo Casalin matteo.casalin at gmx.com
Wed Feb 29 12:09:58 PST 2012


Hi all,
     lately I've been working on ValueSet code, which is used in several 
controls (e.g. color selection, color configuration, columns selection 
in writer...), doing some cleanups. When the code will be more 
manageable I plan to fix some little bugs (selection/focus).

Looking at the (not so clear) key-navigation code, I think that some of 
its behaviors are not so intuitive. Here what I understood (and sorry 
for the long mail):
* Right key allows to move from one item to the one on its right and,
   when the beginning of a line is reached, it moves to the end of the
   previous line. If the beginning of the first line is reached, it moves
   to the end of the last line (eventually moving through the "none"
   item, if present). Its behavior is not affected by Shift/Alt/Ctrl
   modifiers. Left key has symmetrical behavior.
* Up key allows to move from an item to the one above it. When the first
   line is reached, it moves to the same column of the last line (unless
   its a partial line which doesn't have that column, in which case the
   line is skipped and, if not visible, not shown at all), eventually
   moving through the "none" item if present. Its behavior is not
   affected by Shift/Alt/Ctrl modifiers. Down key has symmetrical
   behavior.
* Page Up key moves up of a number of lines equal to those visible (a
   "page"), maintaining the column. If in the middle of the first page,
   it moves to the "none" item (if present) or to the last item in the
   same column (last page). If the last line is partial, it's selected
   only if it has an item in that column, otherwise it's skipped.
   If any of Shift/Alt/Ctrl modifiers are pressed the selection does not
   move and the KeyStroke is passed to the handler of the base Control
   class (I didn't give a look at it yet).
   Page down has symmetrical behavior.
* Home key move to the "none" item if present, to the first element
   otherwise.
* End key moves to the last item.
* Return key selects an item (unless a flag does not disable this).
   If you press it in "Color configuration" UI, it closes the
   configuration window.

Is this behavior the expected/commonly accepted one?
I would like to propose:
* left/right motion should not wrap around from first to last (or last
   to first) item. Moving through lines is fine (behavior similar to
   moving through text), although we can also just stay on the same line
   and stop at its borders.
* up/down should not wrap around. If pressing up on a middle column of
   the first line, then it moves to the first item. If pressing down, it
   should move to the column below if present, to the last item
   otherwise.
   Please note that this is not similar to up/down navigation in text in
   writer (since I propose to move to first/last item if we cannot move
   of a whole line), but other application (e.g. thunderbird) behaves in
   this way. At least it allows to display (and make the user aware of)
   partial final lines.
* page up/down should mimic the behaviour of up/down keys: move in the
   same column when possible (even if the distance is less than a page)
   and, when pressed again and no motion in the current column is
   possible, reach the first/last element. I don't know if disabling
   navigation when key-modifiers are pressed makes sense.
* If "none" item is present, then it could be accessed only from the
   first item by pressing any of left/up (also page up/home ?) keys.
   When selected, it can be exited only by pressing right/down (also
   page down/end?) keys, but always lead to the first item.
* Return key behavior: at least it should not close the color
   configuration window, but my guess is that's a misconfiguration of
   the specific instance of ValueSet.

Although this behavior is consistent (allows to move/view all of the 
items, without special cases if "none" item is present), I'm aware that 
it imposes some more keystrokes in corner cases. If we decide to change 
the current behavior and there's no clear idea on what to do, then we 
can eventually give the proposed solution a first try and then evaluate 
possible improvements.

Please let me know your opinions/suggestions!

Cheers
Matteo

PS: sorry for "spamming" but I missed the ux-advise list in my previous 
email.


More information about the Libreoffice-ux-advise mailing list