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

[Cor Nouws]

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,

-- 
  - Cor
  - http://nl.libreoffice.org