[Libreoffice-ux-advise] [UX advise] Key navigation in ValueSet controls
oolst at nouenoff.nl
Fri Mar 23 16:31:23 PDT 2012
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?
> 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
* 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
(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).
More information about the Libreoffice-ux-advise