“For controls, focus refers to which control has first claim on any non-
pointing input, such as input from a keyboard…” <https://goo.gl/oZlhEU>
(currently Canonical-only link, sorry). That is the only reason for
focus to exist, so there should not be any difference between “focused”
and “I accept keyboard input”. (Text fields used to, as Christian says,
change background color distinct from their focus ring. It’s good that
they no longer do, because it made unfocused fields look disabled. So
now they should have a focus ring instead … but that’s a separate
problem.)

Apart from that, I think any of three changes to the reported behavior
would make it unsurprising. But each would have other consequences:

A. Give the switch a focus ring. But this would be too distracting,
because — especially on a phone — you hardly ever toggle controls with a
hardware keyboard. Furthermore, as “5) … tap on the list item, not on
the switch” implies, the switch isn’t (or shouldn’t be) focused anyway.
Space is toggling the switch not because it is focused, but because it
is the only control inside the selected list item. (Lists of checkbox
items should behave the same way: select with arrow keys, Space to
toggle.)

B. So, make the selected list item look selected then! But this would be
distracting too, because this screen isn’t really a “list” of anything
in the non-technical sense; on many other platforms it wouldn’t be using
a list control at all. So there’s a larger question about whether System
Settings should be using a list control on screens like this. But even
in the “Keyboard Layouts” or “Wi-Fi” screens, which do have genuine
lists of things, once you tap any of the items it still shouldn’t be
visibly selected, because which one you happened to tap on most recently
is either not interesting or indicated in some other way. So, this isn’t
a System Settings bug.

C. Make tapping not select the list item at all, so Space doesn’t do
anything inside the item. Selection inside a list has similarities with
focus outside a list (which is one of the reasons people often confuse
the two). One similarity is that sometimes it’s appropriate only when
you’re actively using an external keyboard. A focus example: If you have
a password field focused, you should be able to Tab to the “Show
password” checkbox, but for tapping the checkbox to focus it would be
annoying, because it would unfocus the password field. So text fields
should take focus on tap or Tab, but checkboxes should take focus *only*
on Tab. Similarly with list selections: sometimes a list always has
exactly one item selected at a time, and in that case selection should
always be visible, but in other cases selection is interesting *only* if
you’re using a keyboard to navigate through it.

Unfortunately, neither of these subtleties have been specified yet. The
focus subtlety should have been part of the recent “focus states” design
project, but that project got sidetracked. No-one has yet specified the
behavior of lists, as opposed to list items. And the spec for list items
uses the word “select” only to refer to activation, not selection.

So, I’ve proposed a change to “General behavior for all controls” to
define three classes of control, with examples of each: pointer-
focusable, non-pointer-focusable, and unfocusable.
<https://goo.gl/LCxiWO> (Canonical-only link, sorry) Basically, this
removes the “thus” from Christian’s statement above, “any
(Abstract)Button can be clicked, thus have activeFocus”. For example,
click-to-focus should be true for text fields (pointer-focusable), but
not for normal buttons (non-pointer-focusable) or scrollbar buttons
(unfocusable). Eventually the spec for each type of control should say
which of the three focus behaviors it has. Most control types will only
ever have one behavior … except for lists, because of the variety of
ways they’re used.

So, I’ve then defined three analogous classes of list: pointer-
selectable, non-pointer-selectable, and unselectable.
<https://goo.gl/fscyyx> (Canonical-only link, sorry) All the lists in
System Settings currently should be non-pointer-selectable, which
suggests that that should be the default. Therefore, tapping an item in
the “Language & Text” screen should not select it. And therefore,
pressing Space afterwards should not activate the switch in that item.

** Changed in: ubuntu-ux
       Status: In Progress => Fix Committed

** Changed in: ubuntu-system-settings (Ubuntu)
       Status: Incomplete => Invalid

** Changed in: ubuntu-ui-toolkit (Ubuntu)
       Status: Confirmed => Triaged

** Description changed:

  Nexus7, rc-proposed, r373
  
  Ubuntu UI Toolkit version r1795
  
  How to reproduce:
  1) Connect bluetooth keyboard
  2) Open system settings
  3) Open Language & Text view
  4) Press tab until the n-th switch shows its focus frame
  5) Now tap (using touchscreen) on the m-th list item, with  m < n (tap on the 
list item, not on the switch of that list item)
  NOTE: It is important that m < n, the bug will not trigger on listitems that 
have not been focused at least once!
  6) At this point the focus frame around the n-th switch has disappeared
  7) Now press Space on the keyboard
  
  Expected outcome:
  Nothing, because there is no focus frame anywhere on the screen
  This is confusing for the user as he can never be sure about which item will 
be actioned by the keyboard keys
  
  Actual outcome:
  The switch of the m-th list item is triggered, even though that list item or 
switch were not showing any focus frame
+ 
+ <https://goo.gl/LCxiWO>: “To avoid errors from unintended focus and
+ distraction from irrelevant focus rings, there should be three classes
+ of control: … • Non-pointer-focusable: Focusable only by Tabbing or
+ other non-pointer input, not by using a pointing device.”
+ 
+ <https://goo.gl/fscyyx>: “To avoid distraction from irrelevant
+ selection, there should be three classes of list: … • Non-pointer-
+ selectable: Any enabled item in the list can be selected using Up or
+ Down keys, or by other non-pointer input, but not by using a pointing
+ device … Any list that is non-pointer-selectable should be non-pointer-
+ focusable.”

-- 
You received this bug notification because you are a member of Ubuntu
SDK bug tracking, which is subscribed to ubuntu-ui-toolkit in Ubuntu.
https://bugs.launchpad.net/bugs/1549733

Title:
  SystemSettings Language&Text view: hitting Space on HW keyboard
  triggers switch even when it (or its list item) does not show any
  visual focus frame

Status in Canonical System Image:
  Confirmed
Status in Ubuntu UX:
  Fix Committed
Status in ubuntu-system-settings package in Ubuntu:
  Invalid
Status in ubuntu-ui-toolkit package in Ubuntu:
  Triaged
Status in ubuntu-ui-toolkit package in Ubuntu RTM:
  Confirmed

Bug description:
  Nexus7, rc-proposed, r373

  Ubuntu UI Toolkit version r1795

  How to reproduce:
  1) Connect bluetooth keyboard
  2) Open system settings
  3) Open Language & Text view
  4) Press tab until the n-th switch shows its focus frame
  5) Now tap (using touchscreen) on the m-th list item, with  m < n (tap on the 
list item, not on the switch of that list item)
  NOTE: It is important that m < n, the bug will not trigger on listitems that 
have not been focused at least once!
  6) At this point the focus frame around the n-th switch has disappeared
  7) Now press Space on the keyboard

  Expected outcome:
  Nothing, because there is no focus frame anywhere on the screen
  This is confusing for the user as he can never be sure about which item will 
be actioned by the keyboard keys

  Actual outcome:
  The switch of the m-th list item is triggered, even though that list item or 
switch were not showing any focus frame

  <https://goo.gl/LCxiWO>: “To avoid errors from unintended focus and
  distraction from irrelevant focus rings, there should be three classes
  of control: … • Non-pointer-focusable: Focusable only by Tabbing or
  other non-pointer input, not by using a pointing device.”

  <https://goo.gl/fscyyx>: “To avoid distraction from irrelevant
  selection, there should be three classes of list: … • Non-pointer-
  selectable: Any enabled item in the list can be selected using Up or
  Down keys, or by other non-pointer input, but not by using a pointing
  device … Any list that is non-pointer-selectable should be non-
  pointer-focusable.”

To manage notifications about this bug go to:
https://bugs.launchpad.net/canonical-devices-system-image/+bug/1549733/+subscriptions

-- 
Mailing list: https://launchpad.net/~ubuntu-sdk-bugs
Post to     : ubuntu-sdk-bugs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-sdk-bugs
More help   : https://help.launchpad.net/ListHelp

Reply via email to