Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Controls] [PresentationUtil] QoL improvements to control creation form #162067

Merged
merged 16 commits into from
Aug 4, 2023

Conversation

Heenawter
Copy link
Contributor

@Heenawter Heenawter commented Jul 17, 2023

Closes #162697

Summary

This PR adds a few tiny UI improvements to the control creation elements, including...

Data view picker:

  • Made the Data view form title respond to focus as expected

    Before
    After
    Jul-28-2023 15-55-13 Jul-28-2023 15-56-24
  • Switched to use EuiInputPopover rather than EuiPopover

  • Removed the redundant popover title

    Before
    After
    image Screenshot 2023-07-28 at 4 16 18 PM

Field picker:

  • Made the Field form row title respond to focus as expected for all of the inner form elements

    Before
    After
    Jul-28-2023 16-06-01 Jul-28-2023 16-07-00
  • Switched the FieldTypeFilter to use EuiInputPopover rather than EuiPopover

  • Removed the redundant title from the FieldTypeFilter popover

    Before
    After
    image image
  • Made changes described in (Accessibility) [EuiSelectable] Unable to make selections when second interactable element in focus eui#6627 (comment) so that, when the field type filter is closed (either via Esc or through the natural tab order), the focus returns to the search field

    Before
    After
    Jul-28-2023 16-12-58 Jul-28-2023 16-13-54
  • If provided, the initial selected field is now brought to the top of the list

    Before
    After
    image image

Controls display settings:

  • Surrounded the Minimum width row with a div so that it can receive the id passed down from the EuiFormRow and respond to focus as expected

    Before
    After
    Jul-28-2023 16-31-56 Jul-28-2023 16-31-20

Checklist

For maintainers

@Heenawter Heenawter added Team:Presentation Presentation Team for Dashboard, Input Controls, and Canvas loe:small Small Level of Effort release_note:skip Skip the PR/issue when compiling release notes impact:low Addressing this issue will have a low level of impact on the quality/strength of our product. labels Jul 17, 2023
@Heenawter Heenawter self-assigned this Jul 17, 2023
@Heenawter Heenawter changed the title [PresentationUtil] Improve UI of DataViewPicker and FieldTypeFilter [Controls] [PresentationUtil] Minor UI fixes to control creation form elements Jul 17, 2023
@Heenawter Heenawter force-pushed the fix-controls-form-props_2023-07-14 branch 2 times, most recently from ae3d46c to 78c3a6f Compare July 17, 2023 16:40
@Heenawter Heenawter added loe:medium Medium Level of Effort and removed loe:small Small Level of Effort labels Jul 17, 2023
@Heenawter Heenawter force-pushed the fix-controls-form-props_2023-07-14 branch from 8fdff2d to 476a6be Compare July 17, 2023 21:57
@Heenawter
Copy link
Contributor Author

Heenawter commented Jul 17, 2023

In my attempt at implementing the fix from elastic/eui#6627 (comment), I found a bug where the FieldTypeFilter popover's focus trap was interfering with my ability to manually set the focus back to the search input without a ~300ms delay - to resolve this. I worked with @cee-chen to discover a fix for this by allowing the popover to have control over its own returnFocus on close.

Therefore, this is blocked until elastic/eui#6955 is merged and available in Kibana 👍

Edit: Blocked on #162209

@Heenawter
Copy link
Contributor Author

Unblocked now that #162209 is merged.

@Heenawter Heenawter force-pushed the fix-controls-form-props_2023-07-14 branch from ebc5266 to 332e87d Compare July 28, 2023 17:01
@Heenawter Heenawter force-pushed the fix-controls-form-props_2023-07-14 branch from 8467c96 to f3af677 Compare July 28, 2023 21:07
@Heenawter Heenawter force-pushed the fix-controls-form-props_2023-07-14 branch 2 times, most recently from 15997e1 to fb5508d Compare July 28, 2023 21:43
@Heenawter Heenawter force-pushed the fix-controls-form-props_2023-07-14 branch from fb5508d to bb9c0c4 Compare July 28, 2023 21:44
@Heenawter Heenawter changed the title [Controls] [PresentationUtil] Minor UI fixes to control creation form elements [Controls] [PresentationUtil] QoL improvements to control creation form elements Jul 28, 2023
@Heenawter Heenawter changed the title [Controls] [PresentationUtil] QoL improvements to control creation form elements [Controls] [PresentationUtil] QoL improvements to control creation form Jul 28, 2023
@@ -259,7 +259,7 @@ export const ControlEditor = ({
<EuiFormRow
label={ControlGroupStrings.manageControl.displaySettings.getWidthInputTitle()}
>
<>
<div>
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Switched this to a div so that it can receive the id passed down from the EuiFormRow component - not sure why, but the React fragment ignored it 🤷

@@ -50,7 +54,7 @@ export const FieldPicker = ({
.filter((f) => typesFilter.length === 0 || typesFilter.includes(f.type as string))
.filter((f) => (filterPredicate ? filterPredicate(f) : true)),
['name']
),
).sort((f) => (f.name === initialSelection.current ? -1 : 1)),
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This brings the selected field, if provided, to the top of the list on load.

Comment on lines +74 to +77
focusTrapProps={{
returnFocus: false, // we will be manually returning the focus to the search
onDeactivation: setFocusToSearch,
}}
Copy link
Contributor Author

@Heenawter Heenawter Jul 31, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the important change in this file - it ensures that, as described in elastic/eui#6627 (comment), the focus returns to the search field when the field type filter is closed (either via Esc or through the natural tab order).

@Heenawter Heenawter marked this pull request as ready for review August 1, 2023 14:36
@Heenawter Heenawter requested review from a team as code owners August 1, 2023 14:36
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-presentation (Team:Presentation)

Copy link
Contributor

@ThomThomson ThomThomson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ran this locally and looked through the code. Presentation team changes LGTM!

One small a11y / design question though:

I noticed that having the focus on the search input and using the arrow keys is the only way to select a field via the keyboard. If I have focus on the filter by type button I cannot use the arrow keys.

Focus

This seems strange to me? Is it at all possible to make the arrow keys work correctly when either element is focused?

If not, I wonder if we should swap their positions so that the filter by type button comes first? This might link the search input more obviously with the field selector. @andreadelrio do you have any thoughts on this?

@kibana-ci
Copy link
Collaborator

💛 Build succeeded, but was flaky

Failed CI Steps

Test Failures

  • [job] [logs] Investigations - Security Solution Cypress Tests #1 / Alert details expandable flyout right panel overview tab insights section should display threat intelligence section should display threat intelligence section

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id before after diff
presentationUtil 155 145 -10

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id before after diff
controls 199.8KB 199.9KB +93.0B
presentationUtil 129.8KB 127.7KB -2.1KB
total -2.0KB

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @Heenawter

@Heenawter
Copy link
Contributor Author

Heenawter commented Aug 2, 2023

@ThomThomson

Is it at all possible to make the arrow keys work correctly when either element is focused?

Unfortunately, to my understanding, it's not - this is what @cee-chen had to say about it (from this issue that I raised with the EUI team):

In theory, what would be a "complete" fix would be to also prevent the up/down arrow keys from changing selection if the searchbox or listbox isn't the current focus [ ... ] I'm just not really certain there's a way to implement that while also implementing a way to ignore keydowns on children that shouldn't trigger selections.

With respect to,

I wonder if we should swap their positions so that the filter by type button comes first? This might link the search input more obviously with the field selector.

I am definitely interested to see what @andreadelrio thinks :)

@andreadelrio
Copy link
Contributor

e search input and using the arrow keys is the only way to select a field via the keyboard. If I have focus on the filter by type button I cannot

@Heenawter @ThomThomson I wonder if joining them like in Discover would solve this issue? As an added bonus, I think it would look better and we'd be re-using a existing pattern.
image

@ThomThomson
Copy link
Contributor

ThomThomson commented Aug 2, 2023

That's a great call!

@cee-chen
Copy link
Member

cee-chen commented Aug 2, 2023

Visually I agree it looks nice, but I'm not sure EuiSelectable yet supports a custom append/prepend option for the searchbox. We'd need to build that functionality into EUI.

I wonder if joining them like in Discover would solve this issue?

It would not solve the keyboard UX/a11y issue that Devon mentioned above. Here is the issue: the main search input needs to trigger several important keyboard shortcuts - pressing enter/space to select and up/down arrows to navigate through selections being the major ones. That is the defining standard of a W3 combobox spec.

However, EUI cannot easily extrapolate those keyboard shortcuts to any other custom nodes being rendered. We simply have no idea what their intention is and whether they want that behavior. In this instance for example, you want the enter/space key to toggle a popover, not toggle a selection. Why should the arrow keys behave differently? And if you did want it to behave differently, how would EUI be able to pass our keyboard event behaviors to you?

@Heenawter
Copy link
Contributor Author

Heenawter commented Aug 2, 2023

I'm not sure EuiSelectable yet supports a custom append/prepend option for the searchbox. We'd need to build that functionality into EUI.

Looks like searchProps does indeed support a custom append/prepend:

image

That being said, as @cee-chen suspected, it suffers from the exact same keyboard UX/a11y issues that @ThomThomson brought up.

However, EUI cannot easily extrapolate those keyboard shortcuts to any other custom nodes being rendered. We simply have no idea what their intention is and whether they want that behavior.

That is definitely fair - even in our specific case, assuming we got the following to work:

Is it at all possible to make the arrow keys work correctly when either element is focused?

What, then, is the behaviour when hitting the enter key? When the search box has the focus, pressing the enter key selects an item - but, if the field type filter button is in focus, what should happen? Should the popover be opened, or should a field be selected? It gets.... weird 😆

With all this in mind, I feel like we're still left with two options if we stick with EuiSelectable for this:

  1. Keep the elements in the current order - follows the common pattern that searching is given priority over filtering (this is true for both Discover and Lens with respect to their field pickers), but makes keyboard controls a bit awkward
  2. Reorder the elements - changes the typical search > filter pattern we see elsewhere, but makes keyboard controls feel more natural

@Heenawter Heenawter closed this Aug 2, 2023
@Heenawter Heenawter reopened this Aug 2, 2023
@cee-chen
Copy link
Member

cee-chen commented Aug 3, 2023

Looks like searchProps does indeed support a custom append/prepend:

Nice! I love it when our components are more flexible than I remember 😆

What, then, is the behaviour when hitting the enter key? When the search box has the focus, pressing the enter key selects an item - but, if the field type filter button is in focus, what should happen? Should the popover be opened, or should a field be selected? It gets.... weird 😆

Yep, this is the exact conundrum :) Personally, my 2c is that it's not an accessibility issue, and it's not a huge UX friction point and is probably fine as-is.

When on the search input, EUI includes clear screen reader instructions as to how to interact with the component (arrow keys to navigate and enter key to select). If a custom interactive/focusable component is included within the EuiSelectable, it doesn't inherit those instructions, and therefore the keyboard shortcuts aren't expected - so at the very least, the behavior isn't confusing to screen reader users. And for non-SR users, the append option is IMO great and helps a lot with visual hierarchy.

Copy link
Contributor

@andreadelrio andreadelrio left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Design changes LGTM. Nice improvements @Heenawter !

@Heenawter Heenawter merged commit 3763a5a into elastic:main Aug 4, 2023
@Heenawter Heenawter deleted the fix-controls-form-props_2023-07-14 branch August 4, 2023 17:07
@kibanamachine kibanamachine added v8.10.0 backport:skip This commit does not require backporting labels Aug 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:skip This commit does not require backporting impact:low Addressing this issue will have a low level of impact on the quality/strength of our product. loe:medium Medium Level of Effort release_note:skip Skip the PR/issue when compiling release notes Team:Presentation Presentation Team for Dashboard, Input Controls, and Canvas v8.10.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Controls] Make focus on the selected field when editing a control
8 participants