[Unified search] Sort the dataviews on the picker alphabetically

[stratoula]

Describe the feature:
At the moment the list of dataviews on the dataview picker is unsorted. The dataview picker appears in Lens, Discover and agg-based visualizations.

There is a request for sorting the SOs alphabetically.

[elasticmachine]

Pinging @elastic/kibana-app-services (Team:AppServicesSv)

[stratoula]

@ghudgins @cchaos any objections on this?

[cchaos]

This one is harder to say what's more valuable to a user because it all depends on types and quantities of data views. I'd love to see an advanced setting (since Unified Search doesn't have a settings menu) that allows users to swap between two options:

1. Alphabetical
2. Recently used

[twanva]

Hi, being able to sort the data views alphabetically is something we are looking for. Are there any more developments on this issue?

[stratoula]

@twanva we haven't figured out yet which is the best approach here. I agree with Caroline that this needs to be a setting somewhere. Not sure where though:

• An advanced setting is a good idea but it is quite difficult to be discovered. Also in which section should this belong?
• A settings menu on the unified search bar is also a good idea and easier to be discovered. But does it make sense? What else could be added on this menu in order to justify its existence?

cc @ninoslavmiskovic @ghudgins maybe something I can bring to our sync to discuss?

[ninoslavmiskovic]

Do we know how many customers/users have some many data views that they need to sort them ? Just trying to figure out if this is a big user problem or are we solving for edge cases.

[stratoula]

No unfortunately we don't have this information. I have seen it to come as a feature request but not very often

[twanva]

I think the advanced setting could be a good MVP with the two options mentioned previously (by @cchaos): Alphabetical and Recently Used with an ascending/descending option. This allows the users to try/use it and provide feedback about whether they like or dislike it.

[MichaelMarcialis]

• An advanced setting is a good idea but it is quite difficult to be discovered. Also in which section should this belong?
• A settings menu on the unified search bar is also a good idea and easier to be discovered. But does it make sense? What else could be added on this menu in order to justify its existence?

Placing data view sorting options in advanced settings means that the sorting is determined at the space-level, not the user-level. Controlling this sorting behavior at the space-level doesn't seem as useful to me as individual user-level control.

If we were to instead place sorting options within the unified search interface, can that choice be controlled at the user-level (either via the user entity or cookies/localStorage)? If so, I prefer including these sorting options in the unified search interface for the sake of discoverability and a better user experience.

[stratoula]

@MichaelMarcialis yes we could store it on the localStorage as we are doing with other settings. I second Michael's point. I would prefer this to be located on the unified search interface.

[AndrewMcQuerry]

Do we know how many customers/users have some many data views that they need to sort them ? Just trying to figure out if this is a big user problem or are we solving for edge cases.

Even a relatively small list of 6-8 data views can be confusing when you open up the drop-down and the views are not in any logical order.

I believe the old Index Pattern list was sorted alphabetically by default.. so, having the default for Data Views be ?random?, it just feels like a backwards step.

I would argue that "random" sorting is actually more useful when you have more than 10 data views, as the default user behavior would probably be to use the filter as more and more data views are added.

We admin an enterprise view into aggregated logs (single Kibana, with Spaces, with CCS to remote data clusters). As such, we expect some Kibana Spaces to eventually have 50+ data views, depending on which data the users of that space need access to.

[elasticmachine]

Pinging @elastic/kibana-visualizations @elastic/kibana-visualizations-external (Team:Visualizations)

[stratoula]

Use this design #140174

[MichaelMarcialis]

@stratoula, @andreadelrio: I had two quick thoughts I wanted to share regarding the design shown in #140174, before we take the same approach here:

• Rather than having to repeat each sort option twice (one for ascending, one for descending) in the context menu, would it be possible to split the menu by sort and order selectables, as shown in the old wireframe example below? I think doing so makes the experience a little easier to understand and avoids the redundancy.

• Are there any concerns about context menu inception (i.e. launching a new context menu from an existing one)? Rather than triggering a new popover, would it be less messy to instead treat the sorting/ordering interface as a nested context menu panel (thus keeping the experience contained to the single originating context menu)?

[stratoula]

++ Michael. I prefer this approach better

[andreadelrio]

@MichaelMarcialis that's a great suggestion Michael, thank you. We will update the implementation in Controls to use this as well.

[ninoslavmiskovic]

++ @MichaelMarcialis

[nlatipov]

@MichaelMarcialis could you please give a little feedback on your suggestion?
Should we display the list of sort settings as the list you showed above, or can we use the sort settings as currently on the Dashboard? (drawing take from issue)

Also, what criteria do you think the user should use to sort the DataViews? At the moment we have options - by date of creation and alphabet

[stratoula]

About the criteria we have decided for now:

• Sort by the dataview name (alphabetically) and
• Last created.

[MichaelMarcialis]

@MichaelMarcialis could you please give a little feedback on your suggestion?
Should we display the list of sort settings as the list you showed above, or can we use the sort settings as currently on the Dashboard? (drawing take from issue)

If that's ultimately what was decided and implemented for how sorting should be handled in the Dashboard controls, I suppose it would make sense to follow for the sake of consistency. That said, it's not exactly what I was envisioning. For one, I'm not a fan of the nested popover-in-a-popover. In my earlier comment, I suggested avoiding that issue by housing the sort/order controls in a second context menu layer (which would take the user one level deeper into a single popover to make their sort/order changes, rather than overlaying another popover on the original). Additionally, I'm on the fence about the discoverability of the icon-only button group for order options in the top-right of the popover. My original suggestion was to have a second selectable after the sort options that I feel may be more easily discoverable. CCing @andreadelrio, as she may have insights on the Dashboard controls sorting decisions.

[stratoula]

@MichaelMarcialis personally I am fine with your suggestion.

@nlatipov let's go with this proposal

[andreadelrio]

@MichaelMarcialis could you please give a little feedback on your suggestion?
Should we display the list of sort settings as the list you showed above, or can we use the sort settings as currently on the Dashboard? (drawing take from issue)

If that's ultimately what was decided and implemented for how sorting should be handled in the Dashboard controls, I suppose it would make sense to follow for the sake of consistency. That said, it's not exactly what I was envisioning. For one, I'm not a fan of the nested popover-in-a-popover. In my earlier comment, I suggested avoiding that issue by housing the sort/order controls in a second context menu layer (which would take the user one level deeper into a single popover to make their sort/order changes, rather than overlaying another popover on the original). Additionally, I'm on the fence about the discoverability of the icon-only button group for order options in the top-right of the popover. My original suggestion was to have a second selectable after the sort options that I feel may be more easily discoverable. CCing @andreadelrio, as she may have insights on the Dashboard controls sorting decisions.

Just to provide some context as to why we ended up going in a different direction in Controls. We started implementing @MichaelMarcialis 's proposal as shown above. However, we weren't 100% happy with how it looked with actual EUI components (it was related to the return keys showing up + the fact that EuiSelectable always highlights one option).
See:

So we started iterating and we came up with the version that got merged for Controls. For the particular use case of this PR, I would +1 on Michael's suggestion to use a second context menu layer. For controls, we just didn't think that was a good fit so we went the popover-in-popover route which we don't love either but for our case, it felt better than a second context menu layer. Also, we have not tested discoverability for the icon-only button group housing the sort direction options so if you want to be on the safer side you might be better off with Michael's proposal.