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

fix unified search for long field inputs #166024

Merged
merged 16 commits into from
Sep 11, 2023

Conversation

timductive
Copy link
Member

@timductive timductive commented Sep 7, 2023

Summary

Fixes #166019

long-field-name-input

Checklist

Delete any items that are not applicable to this PR.

For maintainers

@timductive
Copy link
Member Author

@andreadelrio looking for your thoughts here for expanding the input fields for long field names.

@andreadelrio
Copy link
Contributor

andreadelrio commented Sep 7, 2023

@timductive Thanks for putting this together! We actually explored this route back in December but I didn’t make a formal proposal because I wasn’t convinced the layout shifts worked well. I understand this is still a UX debt. I'm sharing some of those explorations here to give you context which might be useful as we try to solve this.

[Background] Exploration done in code by one of our contractors

Screenshot 2022-12-07 at 10 31 57 Con: It completely hid the values in the two fields not in focus

[Background] Exploration in Figma

idea
This exploration also hid the buttons (Delete | OR | AND) when one input was in focus state. This generated a bigger difference between the two UI states (1) when an input has focus, buttons were hidden and (2) when no input has focus, buttons were shown. I think its better to try to minimize the differences between the two UI states as much as possible.

Going back to your proposal, is it possible to automatically remove focus on an input after a user has made their selection (whenever the input only allows for single selection)? This would make the transition between the two states smoother like so:
Frame 513

@timductive
Copy link
Member Author

Thanks @andreadelrio I didn't realize we had so much prior research. I also played with how much to hide and show and landed on the same outcome as you, to try and minimize how much the layout shifts and leave the other values as visible as possible.

I also considered if we could auto-blur the input after selection and I agree that would minimize the stutter and shift for the user. I'm sure it is possible, although I'm less sure if that would require a new prop on the EUI side. I can experiment with that a bit tomorrow and see if we can add in that behavior.

Copy link
Contributor

@nickofthyme nickofthyme left a comment

Choose a reason for hiding this comment

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

So since you forced me to look at this code I had to fix some things that were bothering me.

First was just come cleanup of naming, types and react code - 3963550.

Secondly, this input is a single selection, yet once you select the input remains focused. I think this is an issue/feature enhancement for the EuiComboBox on their side. Should be simple for an explicit prop or even automatic for single selection mode. But I forced this in d20ef3e but it only applies to the first field selection and not the third filter input box to select the value. This could and should be added like the first one, I can do that tomorrow if you want but there are a few components to apply that behavior to.

Just saw I was not the first to see this as an issue/improvement.

The last part is the animation of the width change, I think doing so extraFast is quick enough to occur before the options list appears, any slower and the list will flicker to the full width. See 6155757.

All in all the final result looks something like...

Screen Recording 2023-09-07 at 05 43 30 PM

You welcome to revert any changes and sorry for pushing to your branch 🙂

@nickofthyme
Copy link
Contributor

Added blur on single select for phrase values on the third filter input in e8895bf. I'll create an issue in EUI tomorrow to add this as a feature on the EuiComboBox.

@timductive
Copy link
Member Author

Thanks @nickofthyme I am grateful for all contributions 🙇 I will test it out later this afternoon. I noticed when I tried applying animations that the truncatedlabel seemed to calculate the width of the label inconsistently while the animation was occurring but I didn't try it at extra fast. All of the other typescript cleanups are great and I appreciate the example for passing the ref, I was trying to figure that out yesterday.

@stratoula
Copy link
Contributor

I find it very cool tbh and def an improvement in comparison with the current state.

@andreadelrio do you want to take a look? I feel that it works pretty well.

@timductive timductive marked this pull request as ready for review September 8, 2023 16:13
@timductive timductive requested a review from a team as a code owner September 8, 2023 16:13
@timductive
Copy link
Member Author

timductive commented Sep 8, 2023

The blur works really well. It looks like the animation is still causing label truncation issues though. I would propose we take the animation back out.
long-field-name-animation-issue
Then it seems ready to merge to me.

Here it is without the animation:
long-field-name-no-animation
So slightly choppier doing the grow/shrink but the truncation is much more stable.

@andreadelrio
Copy link
Contributor

I think this is a solid improvement given all the constraints we have. While testing I noticed that we don't show the Preview unless the user has chosen an operator. Can we change this? I think it's important to do so particularly when super long field names get truncated in the input.

Frame 11

@timductive
Copy link
Member Author

I think this is a solid improvement given all the constraints we have. While testing I noticed that we don't show the Preview unless the user has chosen an operator. Can we change this? I think it's important to do so particularly when super long field names get truncated in the input.

This is harder than it seems as the preview is doing a lot of logic to build a full filter semantically. I think we can do this but maybe move it to a separate PR, maybe take it on with the updated design for the Preview together.

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. Thanks for the improvements!

Copy link
Contributor

@stratoula stratoula left a comment

Choose a reason for hiding this comment

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

Changes LGTM, as I said above is a significant improvement from the current experience

@kibana-ci
Copy link
Collaborator

💚 Build Succeeded

Metrics [docs]

Async chunks

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

id before after diff
unifiedSearch 214.8KB 215.2KB +396.0B

History

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

@stratoula stratoula merged commit c6770af into elastic:main Sep 11, 2023
@kibanamachine kibanamachine added v8.11.0 backport:skip This commit does not require backporting labels Sep 11, 2023
@timductive timductive deleted the fix-long-input-166019 branch September 11, 2023 18:07
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 release_note:enhancement v8.11.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Unified Search] Improve input fields in filter modal for long field names
6 participants