Standardized focus handling
Closed, ResolvedPublic

Description

The following is a proposed description of focus should work in Kube.

Focus handling

This section lines out how we deal with focus throughout the application.
The aim is to have consistent behaviour across controls and other elements.

The focus handling needs to take into account:

  • Mouse navigation
  • Keyboard navigation
  • Touch input

The primary indicator for focus is the "activeFocus" property (or if available, "visualFocus"). The "focus" property is used for requesting focus and thus not what should be used for detecting focus.

There are the following different focus states:

  • An element can be selected (if selectable). This includes i.e. a text editor that has focus, or a selectable element in a list view.
  • An element can be hovered. This is only available with mouse pointers and indicates that the element can be clicked.
  • An element can have keyboard focus. This is only available with keyboard navigation and indicates which element currently has keyboard focus.

With touch input only the selected state is relevant.

The following indicators are available to visualize selection:

  • Highlight: A blue overlay over the item.
  • Glow: A blue glow around the borders.
  • Underlined text

It is important that a selected element can still show focus, otherwise the focus during keyboard navigation simply disappears if it moves to the selected element.

The following controls need to deal with focus:

  • Buttons, IconButtons
  • ListView, TreeView, GridView
  • TextFields
  • Copyable elements

We're indicating focus as follows:

  • Active focus is indicated with a glow. This is used for both hovering and keyboard focus.
  • A selected element is highlighted.
  • Keyboard focus is additionally to the glow indicated with underlined text.

FocusScope

In order to be able to deal with focus on a local scope (which is important for reusable components), a FocusScope is required to establish a border for focus handling. Internally you can set the focus as required within the focus scope, and externally you can just give focus to the FocusScope, ignoring what's going to happen internally. The FocusScope will automatically forward focus (when it receives it), to whatever element requested focus internally.

Tab focus chain

Set "activeFocusOnTab: true" on all elements that should be included in the tab focus chain.

cmollekopf updated the task description. (Show Details)Jul 21 2017, 8:35 PM

The following indicators are available to visualize selection:
Highlight: A blue overlay over the item.

We could be color agnostic here.

Glow: A blue glow around the borders.

glow might be the wrong word. currently it is just a colored frame and I'd like to keep it that way.

Underlined text
It is important that a selected element can still show focus, otherwise the focus during keyboard navigation simply disappears if it moves to the selected element.

The following controls need to deal with focus:
Buttons, IconButtons
ListView, TreeView, GridView
TextFields
Copyable elements

what about Flow Layouts?

We're indicating focus as follows:
Active focus is indicated with a glow. This is used for both hovering and keyboard focus.
A selected element is highlighted.
Keyboard focus is additionally to the glow indicated with underlined text.

We chose the underline in addition to the colored border for color buttons because the blue frame alone was not strong enough next to the green. Button will never have active focus without having keyboad focus I guess. so we should be fine.

I am not sold on underline for keyboard focus because it is fairly weak indicator but I don't have a better idea at the moment.

I wonder I we can get away with keyboadfocus = selected element

The following indicators are available to visualize selection:
Highlight: A blue overlay over the item.

We could be color agnostic here.

It'll just call it highlight color.

Glow: A blue glow around the borders.

glow might be the wrong word. currently it is just a colored frame and I'd like to keep it that way.

Fine with me.

Underlined text
It is important that a selected element can still show focus, otherwise the focus during keyboard navigation simply disappears if it moves to the selected element.

The following controls need to deal with focus:
Buttons, IconButtons
ListView, TreeView, GridView
TextFields
Copyable elements

what about Flow Layouts?

If we need keyboard navigation at least regular flow layout won't cut it, that's why I switched to the grid layout for the peopleview.
We could of course implement it, but I'll avoid that as long as possible (that doesn't mean we cant use them at all, in small flow layouts
you can just tab through the individual items, it just means the flow layout doesn't really matter for focus).

We're indicating focus as follows:
Active focus is indicated with a glow. This is used for both hovering and keyboard focus.
A selected element is highlighted.
Keyboard focus is additionally to the glow indicated with underlined text.

We chose the underline in addition to the colored border for color buttons because the blue frame alone was not strong enough next to the green. Button will never have active focus without having keyboad focus I guess. so we should be fine.

Yes. Right now iconbuttons get a blue background though instead of a border.

I am not sold on underline for keyboard focus because it is fairly weak indicator but I don't have a better idea at the moment.

I think it at least doesn't hurt a lot (visually) and might also help for people with colorblindness or alike.
But we can experiement wheter we really need it or not, I'll add it for now.

I wonder I we can get away with keyboadfocus = selected element

I don't think we can. I.e. selecting a folder triggers a sync, just skipping over the folder list shouldn't trigger a sync on all folders.

we could trigger the sync with a delay

I thought about that but I'm not sure if it is a good idea or generally applicable. It would mean that you have to switch sufficiently fast (A delay of at least 1s would be necessary, perhaps longer?), and i.e. in the case of wanting to get to your latest mail (or if the list is empty, any mail), you would always have that extra delay that is somehow not explained to the user... Perhaps worth an experiment, but I'd like to go with explicit selecting for now.

I thought about that but I'm not sure if it is a good idea or generally applicable. It would mean that you have to switch sufficiently fast (A delay of at least 1s would be necessary, perhaps longer?), and i.e. in the case of wanting to get to your latest mail (or if the list is empty, any mail), you would always have that extra delay that is somehow not explained to the user... Perhaps worth an experiment, but I'd like to go with explicit selecting for now.

fine with me

what about Flow Layouts?

If we need keyboard navigation at least regular flow layout won't cut it, that's why I switched to the grid layout for the peopleview.
We could of course implement it, but I'll avoid that as long as possible (that doesn't mean we cant use them at all, in small flow layouts
you can just tab through the individual items, it just means the flow layout doesn't really matter for focus).

We "need" a flow layot for email attachmetns in the mail viewer.

what about Flow Layouts?

If we need keyboard navigation at least regular flow layout won't cut it, that's why I switched to the grid layout for the peopleview.
We could of course implement it, but I'll avoid that as long as possible (that doesn't mean we cant use them at all, in small flow layouts
you can just tab through the individual items, it just means the flow layout doesn't really matter for focus).

We "need" a flow layot for email attachmetns in the mail viewer.

If we assume few attachments we could just ignore the layout for navigation purposes, meaning you can just tab through the attachments. Otherwise the options are:

  • Implement custom handling in the delegate (might work, but I'm not sure how well)
  • Implement keyboard navigation in the flowlayout
  • Use a gridlayout and dynamically adjust the rows/columns, effectively turning it into a flow layout that requires equally sized delegates.

I'm inclined to just ignore it for now, meaning you can just tab through, and otherwise try to implement keyboard navigation for the flowlayout.

cmollekopf moved this task from Backlog to Done on the Kube (0.4) board.Jul 27 2017, 5:03 PM
mbohlender closed this task as Resolved.Aug 23 2017, 12:21 PM
mbohlender claimed this task.