[UX advise] Key navigation in ValueSet controls

[Matteo Casalin]

Hi Cor, all

On 03/21/2012 01:23 PM, Cor Nouws wrote:
> Hi Matteo, Stefan,
>
> Great that you care for this, Matteo!
> And of course that you helped with discussing, Stefan.
>
> I'm a bit late: trouble to keep in track with the various topics in the
> community, but found this important enough to read and try to add some
> thoughts. Sorry if it is a bit too late.
>
> Matteo Casalin wrote (03-03-12 18:54)
>> On 03/03/2012 04:07 PM, Stefan Knorr (Astron) wrote:
>
>>>> * 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.
>>>
>>> Makes sense to me. Although, of course the decision depends on whether
>>> we want to make it fast to go to an arbitrary position without much
>>> exactitude or whether we want to make it fast to go to the exact
>>> start/end. Your proposal seemingly aims for goal #2.
>>
>> Well, in this case my goal is to let the user see the content of
>> not-full rows without explicitly looking for it, and to move rapidly
>> from an item to another without too much corrections.
>
> OK for me.
>
>>>> * 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.
>>>
>>> Makes sense. I guess, modifiers should be allowed (but not modify
>>> anything), in all cases where that's possible without unintended
>>> consequences.
>>
>> I don't know the original goals of that features: currently it seems to
>> me that if you use modifiers than nothing happens.
>
> One could say, that because in other locations using modifiers do make a
> difference, it is good to have that here too, thus that unintended use
> of the modifiers, while no specific function is linked to that use,
> indeed results in nothing happening.

Sorry, I think I made a little confusion here saying "nothing happens": 
in my previous mail those words meant "if page up/down are pressed while 
holding a key modifier, then the highlighting box is not moved but stays 
on the previously highlighted item", but it could also be understood as 
"cursor is moved but no special action is taken".
So: should the current behavior (highlighting box does not move) be kept 
or should the modifiers be neglected and the highlighting box move one 
page up/down as if the unmodified page up/down where pressed? My feeling 
is that the first solution is the desired one, but I would prefer to 
have a final confirmation on this.

>>>> * 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.
>>>
>>> Makes sense.
>>
>> I'm less sure of this, now. If a wrap around for up/down is desired, the
>> current behavior of always passing through the "none" item probably
>> makes more sense. Unless we find a dedicated key to select that item,
>> which could solve the situation. Any idea?
>
> I agree with always passing through the "none" item.

I think we should split this point in two:
* Should top/bottom wrap-around behavior be allowed? This is the
   current solution, but honestly I find it somewhat confusing (columns
   can be long and scrolling can be involved) and, from my understanding,
   Astron already agreed to remove this "feature". If this wrap-around
   should be kept, then passing through NoneItem is required (unless we
   find a specific key combination to select/deselect it).
* If we do not want this wrap-around, what should we do for NoneItem? My
   original proposal involved moving first to the first item, from where
   the NoneItem could be accessed (with up/left key-presses). This may be
   too tricky. Better approaches could be:
   * NoneItem is accessed from:
     * any item in the first row by pressing "up"
     * the first item also by pressing "left"
   * NoneItem can be exited by pressing
     * "down", which move to first item in the last selected column
     * "right", which moves to the first item of the first column
   This would allow to alway move in nearby locations, with full control
   on what is being done. I would exclude page up/down because NoneItem
   cannot be considered part of a page and, moreover, I wouldn't be able
   to say what's the correct target position for page down when in
   NoneItem. For consistency with this, I would also exclude "home" and
   "end", but I'm less strong biased on this.
   This proposal is of course arguable and my approach is biased by my
   programmer side (I prefer to avoid special cases).

>
>>>> * 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.
>
> Not sure which window you are looking at (Tools > Options > General ->
> Colors -> Edit ?) and what behaviour is odd.

Correct, the window is the one you pointed to. I find odd that pressing 
"return" key while moving through the ValueSet items closes that window, 
especially because during key-navigation items are highlighted with a 
different border than the one used for selected ones: this would lead me 
to press the "return" key to perform a selection, but that also closes 
the window. Using TAB to move to the next widget could be a solution, 
but it's not straightforward, IMHO, since in other instances of ValueSet 
(color selection menus) return is a better choice for selection. While I 
expect a menu to close on selection, I do not expect a window to do so.
ValueSet key-navigation code seems to offer two different ways of 
handling return keys, depending on WB_NO_DIRECTSELECT configuration 
flag, but I didn't investigate it deeply, yet.

>>> Not entirely sure about this one, although probably most people would
>>> want to use Return and Tab the same way (i. e. to get to the next
>>> widget and select a colour).
>
> When there is some select+close behaviour, I never expect the Return to
> move to another widget.

My point is if "select + close" is right for e.g. the configuration 
window. I would expect that window to close if any of its exit buttons 
were selected and return was pressed, but I just verified that it's 
closed on "return" key-press almost independently on the selected 
widget: the only exception found so far is when the "RGB/CYMK" dropbox 
is expanded, in which case return is used for selecting the highlighted 
item and close the drop down.
What's the correct/desired behavior?

>>
>> Wow. Too many things I didn't consider!
>> Honestly, my plans were to simplify code and provide a more consistent
>> behavior than the current one, that I find somehow confusing.
>> I guess we should wait for some hints on the desired up/down behavior
>> and then see how to proceed (if there's need to).
>
> More: there is different (Alt) Return-key behaviour sometimes in various
> windows. Sometimes Space selects an item, sometimes Return and space can
> do. etc. etc.
> Is this included in your current investigation too ?

As pointed out earlier, I have no clear idea about this but I find that 
current behavior is not very "consistent". This is something that has a 
wider scope than the ValueSet widget itself and should be addressed on 
its own.

> Regards,
>
>

I currently have made some modification to the navigation code, 
according to the action list validated by Astron. I plan to play with 
this code at least until I feel comfortable with the results and I also 
get some more feedback about the points discussed in this email. Since 
real usage is showing me that some of my original proposals are not so 
user friendly, so we will probably need to refine this behavior after 
some tests in the field.

Thanks and best regards
Matteo