[UX advise] Key navigation in ValueSet controls

[Matteo Casalin]

Hi all,
     I just pushed my rework of ValueSet key navigation to master. Main 
differences from the old one are:
* No more vertical wrap-around
* Last item can be easily displayed also when on a shorter row
ALso, the general behavior should be more consistent. NoneItem, if 
present, is still selected by normal key navigation (no special keys).
Next steps: fix the code that handles item selection.

Looking forward to your feedback
Matteo

On 03/24/2012 12:31 AM, Cor Nouws wrote:
> Matteo Casalin wrote (23-03-12 21:30)
>
>> On 03/21/2012 01:23 PM, Cor Nouws wrote:
>
>>> 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.
>
> I agree with you.
>
>>> 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".
>
> OK for me.
>
>> 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?
>
> OK..
>
>> 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.
>
> Current behaviour (from your 1st mail) does not remind me of
> difficulties while using:
> * Home key move to the "none" item if present, to the first element
> otherwise.
> * End key moves to the last item.
>
>> Better approaches could be:
>> * NoneItem is accessed from:
>> * any item in the first row by pressing "up"
>> * the first item also by pressing "left"
>
> I would prefer the current behaviour. I associate Home & End with that.
>
>> * 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
>
> I agree with that.
>
>> 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.
>
> So that opens the door to an agreement ;-)
>
>> 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.
>
> I agree that it is confusing. Quite often (always?) when in a
> list/control where items can be selected, Alt-Return is needed to start
> the OK button.
> In other situations, just Return is sufficient.
>
>> 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.
>
> OK, looks as in indicator in the direction of what users experience ;-)
>
>>>>> 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?
>
> I am not completely unhappy with the current behaviour (as I wrote out a
> bit before).
> (But that might be because I just add some random modifier when hitting
> a certain key does not give the desired effect ;-) )
> But ... for me it would be logic that
> - selecting an item from a combobox, is done with Tab or Enter
> - selecting an option or checkbox is done with space
> - OK is always Enter
> Or do I miss situations?
>
> [ skipped some other thoughts on ALt-Return behaviour ]
>
>> 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.
>
> Yes, good idea.
> When part is available in master, I would like to play with it (and
> other prolly too).
>
> Cheers,
>