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

>  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.

> Anyway, ...
>
>> 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.
>
> 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.
>

>
>> * 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.
>
>  From my Western perspective that does make sense. However, I fear,
> such behaviour might be unexpected in some cultures (that use
> top-to-bottom scripts). Any experts?
>

>
>> * 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.
>

> Hi Matteo,
>
>> 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.
>
> I see.
>
>
>> Good catch. Also speaking from a Western perspective, I find it somewhat
>> confusing to be brought at the opposite side of the one I was moving to (and
>> columns can be long and involve scrolling, while rows don't scroll). My
>> point is that currently left/right let you navigate through all the items,
>> while up/down keys can leave a row "hidden".
>
> This again makes lots of sense to me. Also, we didn't hear anything
> about wrapping around from top to bottom being necessary behaviour, so
> I guess, just doing it should be fine.
>
>
>> I don't know the original goals of that features: currently it seems to me
>> that if you use modifiers than nothing happens.
>
> As I said, I /think/ you should keep that behaviour.
>
>
>>>> * 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.
>>
>> 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?
>
> Hrm. Extremely wild idea: use backspace..?
> More conventional idea: use Tab to go the normal items, use Shift-Tab
> to go to the "None" 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.
>>>
>>>
>>> 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).
>
> I just noticed that wrote that this is used for both both colour
> configuration and selection ...
> * for the configuration what I wrote makes sense
> * for selection, less so – I guess, pressing Return there should
> indeed close the popup
>
>
> Astron.
>

>>> * 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.

>>> * 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.

>>> * 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?

> 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.

>>>> * 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.

>>
>> 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 ?

>> 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.

> 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.

>>>> 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?

> 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,
>