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] Field first control creation #131461

Merged

Conversation

Heenawter
Copy link
Contributor

@Heenawter Heenawter commented May 3, 2022

Closes #129791

Summary

In the old way of creating controls, users had to first select the type of control they wanted to create, which would then filter the list of available fields to those that were supported - this is what we will call type-first control creation. However, in our user testing, we found that users were more likely to have a field-first control creation in mind - that is, they knew what field they wanted to create a control for, but they didn't know which control type to pick and they were confused about why their desired field wasn't showing up in the field list.

Field first creation

This PR introduces a new field-first control approach - when creating a control, the user simply needs to select a field and the corresponding supported control type will be automatically picked for them. Note that, because only options lists and range sliders are supported and they have no crossover in field types, there is only ever one available control type for each field - however, if more control types are introduced in the future that allow for an overlap in supported field types, we will need to allow users to select one of the supported control types as a secondary step.

2022-05-09_FieldFirstCreation.mp4

Field first replace

As a benefit, when combined with the ability to change the types of controls that was introduced in this PR, the overall user experience for both creating and editing existing controls is significantly improved.

2022-05-10_FieldFirstReplace.mp4

Flaky Test Runner

image

Checklist

Delete any items that are not applicable to this PR.

For maintainers

@Heenawter Heenawter added release_note:enhancement Feature:Dashboard Dashboard related features Feature:Input Control Input controls visualization Team:Presentation Presentation Team for Dashboard, Input Controls, and Canvas loe:medium Medium Level of Effort impact:high Addressing this issue will have a high level of impact on the quality/strength of our product. backport:skip This commit does not require backporting Project:Controls v8.3.0 labels May 3, 2022
@Heenawter Heenawter self-assigned this May 3, 2022
@Heenawter Heenawter changed the title Field first control creation 2022 05 02 [Controls] Field first control creation May 9, 2022
@Heenawter Heenawter force-pushed the field-first-control-creation_2022-05-02 branch 6 times, most recently from 5df9bae to afbbb78 Compare May 12, 2022 23:50
@Heenawter Heenawter force-pushed the field-first-control-creation_2022-05-02 branch 3 times, most recently from 35c6160 to 826b447 Compare May 16, 2022 16:54
@Heenawter Heenawter force-pushed the field-first-control-creation_2022-05-02 branch 5 times, most recently from 0852350 to a4d516a Compare May 16, 2022 17:54
@Heenawter Heenawter marked this pull request as ready for review May 16, 2022 18:44
@Heenawter Heenawter requested a review from a team as a code owner May 16, 2022 18:44
@elasticmachine
Copy link
Contributor

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

@Heenawter Heenawter force-pushed the field-first-control-creation_2022-05-02 branch from a4d516a to e9e175e Compare May 16, 2022 18:59
@Heenawter Heenawter force-pushed the field-first-control-creation_2022-05-02 branch from e9e175e to 2e7d2ef Compare May 16, 2022 19:00
@andreadelrio andreadelrio self-requested a review May 17, 2022 04:53
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.

Overall, this is pretty much exactly the way we spoke about it, but with a really elegant implementation. I left a few tiny nits, and one change for readability / efficiency with the react state management.

I tested this locally as well and everything works great!

src/plugins/controls/common/types.ts Show resolved Hide resolved
@@ -56,6 +64,10 @@ export const ControlGroupStrings = {
i18n.translate('controls.controlGroup.manageControl.widthInputTitle', {
defaultMessage: 'Control size',
}),
getControlSettingsTitle: () =>
i18n.translate('controls.controlGroup.manageControl.controlSettingsTitle', {
defaultMessage: 'Control settings',
Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder if we should use the friendly name of the selected Control Type here, so it would read Options List settings or Range slider settings

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Great point! @andreadelrio what are your thoughts?

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm thinking if we need to show that label at all? Label and Width are settings too right so no need to have a separate section for (other) settings? or are you trying to keep the toggle for width under Minimum width and so you need a heading for the rest of the settings?
image

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@andreadelrio Yeah, it seemed to me like grouping the type-specific control settings with the Minimum width settings was confusing - so either the type-specific settings should go above the Minimum width (which would cause shifting when switching between Options list and Range slider fields) or I think these type-specific settings should have their own label.

What do you think, though?

Copy link
Contributor

Choose a reason for hiding this comment

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

I think we could either group them under something like Additional settings? or give each toggle its own title so something like:

  • Multiple selections

Allow multiple selections in dropdown

  • Timeout

Run past timeout

What do you think @KOTungseth ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I like Additional settings but definitely interested in hearing @KOTungseth's thoughts! :)

src/plugins/controls/public/types.ts Show resolved Hide resolved
@andreadelrio
Copy link
Contributor

I'm not a big fan of starting the form in a warning state. I would like to hear what folks think about auto selecting the first field in the field list instead.

image

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.

This is a huge improvement! My feedback UI wise is to add an EuiSpacer above Delete control. We usually keep "dangerous" actions a bit separated from the rest. It looks a bit tight down there at the moment.

image

@Heenawter
Copy link
Contributor Author

Heenawter commented May 18, 2022

I would like to hear what folks think about auto selecting the first field in the field list instead.

I actually thought about that, but ended up going with not for now just to make it super transparent on how the control types are being controlled. @ThomThomson What do you think?

My feedback UI wise is to add an EuiSpacer above Delete control

@andreadelrio I added <EuiSpacer size="l"/> right before the Delete control button as part of fixing some merge conflicts yesterday, so that should already be covered! Possible you had a slightly old version where I forgot to add it :)

image

@andreadelrio andreadelrio self-requested a review May 18, 2022 22:56
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.

Thanks for making those changes. 🎉 LGTM

@Heenawter
Copy link
Contributor Author

Heenawter commented May 18, 2022

Just for the sake of a public follow up, these are the final changes that were made with @andreadelrio's feedback:

  1. The default state when creating a new control was improved to no longer include an "error" state:

    image

  2. The type-specific control settings are now called "Additional settings" instead of "Control settings":

    image

@Heenawter Heenawter enabled auto-merge (squash) May 19, 2022 15:35
@kibana-ci
Copy link
Collaborator

💚 Build Succeeded

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id before after diff
controls 169 167 -2

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id before after diff
controls 207 199 -8

Async chunks

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

id before after diff
controls 424.1KB 426.6KB +2.5KB

Public APIs missing exports

Total count of every type that is part of your API that should be exported but is not. This will cause broken links in the API documentation system. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats exports for more detailed information.

id before after diff
controls 6 7 +1

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id before after diff
controls 31.9KB 28.7KB -3.2KB
Unknown metric groups

API count

id before after diff
controls 213 205 -8

History

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

cc @Heenawter

@Heenawter Heenawter merged commit 8de3401 into elastic:main May 19, 2022
@Heenawter Heenawter deleted the field-first-control-creation_2022-05-02 branch May 19, 2022 16:18
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 Feature:Dashboard Dashboard related features Feature:Input Control Input controls visualization impact:high Addressing this issue will have a high level of impact on the quality/strength of our product. loe:medium Medium Level of Effort Project:Controls release_note:enhancement Team:Presentation Presentation Team for Dashboard, Input Controls, and Canvas v8.3.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Controls] Field-first control creation
6 participants