[Discover] URL does not change when user switches data views after opening a saved search

[jughosta]

Kibana version: upstream

Elasticsearch version:

Server OS version:

Browser version: Chrome 101.0.4951.64

Browser OS version: Mac 12.3.1

Original install method (e.g. download page, yum, from source, etc.): source

Describe the bug:
When user switches data views from A to B, URL and a saved search title stay the same as for A. This results in a visual inconsistency and also for any selected field from B grid column gets empty after a refresh as URL still points to A although B was chosen in Data views dropdown. This can be confusing for users.

Steps to reproduce:

1. Open a saved search in Discover

2. Switch to a different data view via the dropdown

3. Notice that title and URL have not changed for some reason

4. Next, select a field and observe that Document Explorer shows data for its column

5. Refresh the page

6. Notice that data is not visible for that column in Document Explorer and data view got changes back to the initial one

Expected behavior:
Page title, URL, data view name and data are in sync. They get updated when user switches data views.

[elasticmachine]

Pinging @elastic/kibana-data-discovery (Team:DataDiscovery)

[jughosta]

Turns out that it is an intended behaviour for a saved search as of now: this way users can edit the current saved search and save it.

I think there is still an issue here. It might be that users opened a saved search but they now are not aware of it. There is "New" link in the top navigation to reset the state but it could be that it's not visible enough and users got stuck forever with the same saved search URL (unless they pressed "New").

Steps to reproduce:

1. Bootstrap a new Kibana instance
2. Add sample data
3. Press "View data" > "Discover" from Sample data page
4. Notice that user was redirected to a saved search
5. Try to navigate away from Discover and back => the same saved search and URL stay on Discover

[timductive]

Possible solutions:

1. We could do an alert popup when the user switches dataviews, "Do you want to discard changes to your current search?"
2. We could silently save (or discard) the saved search and start a new one when the dataview switches, assuming that a new dataview inherently implies a new search.
3. We could always update the current search to match the current selections.

I don't love any of these, maybe 1 is the most explicit.
@ghudgins @VijayDoshi

[kertal]

I'd suggest replacing bug with discuss, since technically it ain't a bug ... more a UX bug, adding @andreadelrio @ryankeairns , because one of the things we might / should do is make it more clear that its a saved search being displayed in the described case

[ghudgins]

I lean towards 2 with silent discard because changing data views is a two step action anyway but I also see how that is inconsistent to what @MichaelMarcialis is proposing to do with text based languages. Might just be me but I think the UI would be easier to use with fewer disruptions and that’s more worth it then the destruction/state loss caused by changing data views. UI is easier to get back what you lost than text languages to me

[ryankeairns]

+1 to revisiting the Saved Search UX, generally speaking. The additional capabilities (e.g runtime fields, Unified Search features), elevation of Data Views as a concept, and consideration for shaping (Author persona) as a first-class use case are likely to place a greater need on this experience.

It has always felt a bit clunky and hidden. Both the seamless initiative and Alex M's research will provide us with greater context on deciding what to do next.

As for the specific suggestion made by Tim, my instinct is to lean towards the notion of 2 - make it possible, but don't force it/get in the way too often.

[MichaelMarcialis]

I lean towards 2 with silent discard because changing data views is a two step action anyway but I also see how that is inconsistent to what @MichaelMarcialis is proposing to do with text based languages.

@ghudgins: Right. Our approach to the forthcoming text-based query languages feature assumes that the data view will be included as part of the saved search (as it is declared as a part of the query itself). For the sake of consistency and the usability concerns @jughosta raises above, my first instinct is to say that it would be ideal to take the same approach with the currently existing functionality (meaning data view selection should be reflected in both the URL and saved search, and not operate independently).

Assuming others agree and based on what I'm hearing above, it sounds like there are some problems that should be addressed in the saved search UX before considering the inclusion of data view selection in Discover URLs and saved searches:

• It's not plainly obvious to users whether a saved search has been loaded/opened in Discover (beyond recognizing the contents of the query input and accompanying filters) or whether the user is working with a new/unsaved search. This could be improved to make it clearer when a search has been loaded (and perhaps when changed from its saved state).
• Saving a loaded/opened saved search as a new search is a bit hidden in Discover. At the same time, saving a loaded/opened saved search as an update to the original saved search is a bit cumbersome (opens a modal rather than a single button press). Perhaps this could be improved by splitting the currently singular save flow into two: a "Save" and "Save as" flow.
• Discover currently offers no ability to overwrite an existing saved search when attempting to save a new search.

Assuming these issues were addressed, would that make the inclusion of data view selection in Discover URLs and saves searches viable? Or are there other concerns that would need to be addressed as well (such as sharing the saved search with a space that doesn't have access to the referenced data view)?

[kertal]

I lean towards 2 with silent discard because changing data views is a two step action anyway but I also see how that is inconsistent to what @MichaelMarcialis is proposing to do with text based languages.

also lean towards 2

my first instinct is to say that it would be ideal to take the same approach with the currently existing functionality (meaning data view selection should be reflected in both the URL and saved search, and not operate independently).

This would also mean: option 2.

Given a persisted saved search is loaded, and the data view is changed, a new saved search (not persisted) is initialized, and this change is also reflected in the URL

Assuming others agree and based on what I'm hearing above, it sounds like there are some problems that should be addressed in the saved search UX before considering the inclusion of data view selection in Discover URLs and saved searches:

• It's not plainly obvious to users whether a saved search has been loaded/opened in Discover (beyond recognizing the contents of the query input and accompanying filters) or whether the user is working with a new/unsaved search. This could be improved to make it clearer when a search has been loaded (and perhaps when changed from its saved state).

+1, this is currently not obvious, and leads to confusion

• Saving a loaded/opened saved search as a new search is a bit hidden in Discover. At the same time, saving a loaded/opened saved search as an update to the original saved search is a bit cumbersome (opens a modal rather than a single button press). Perhaps this could be improved by splitting the currently singular save flow into two: a "Save" and "Save as" flow.

So it work like Dashboard, right? but not like in Visualize / Lens. Think we should align here for consistency

• Discover currently offers no ability to overwrite an existing saved search when attempting to save a new search.

think this is the same case in Lens?

But yes, given that switching the data view creates a new, ephemeral saved search, one use case would no longer be possible: If someone would like to change an underlying data view of an existing saved search on purpose. You know a use case like ... I've selected index-2021, damn, it's already 2022, change data view to index-*

[MichaelMarcialis]

my first instinct is to say that it would be ideal to take the same approach with the currently existing functionality (meaning data view selection should be reflected in both the URL and saved search, and not operate independently).

This would also mean: option 2.

@kertal: Somewhat, but not exactly. I suppose what I'm suggesting is an alternative option for a kind of dirty state for loaded saved searches. Rather than silently saving or discarding anything and forcing a new search, I'm proposing that we make it clear to the user that they are in a dirty/changed state when a saved search has been loaded and they change the selected data view. From there, the choice is placed in the user's hands to 1) save the data view change as an update to the originally loaded saved search, 2) clear or alter their query, or 3) save it as a new saved search.

[kertal]

How about handling it like Dashboards? #135887

[stratoula]

Working on the text-based languages there is another scenario related to this problem that I would like to mention here.
Let's assume that a user is on the text-based languages mode and loaded a saved search.

We would like everytime a user navigates to the dataview mode (by clicking a dataview) this saved search to be unloaded. The same should happen when the user is on a dataview mode with a saved search selected and goes to the text-based languages mode.

Why do we want this? We don't allow the users to create visualizations (agg based) with a text-based language saved search. But a user can do the following scenario:

• Create a dataview saved search
• Create a visualization based on that
• Edit the saved search and go to the text-based languages mode and update the search with the new query
• The visualization is going to fail

We looked into this with @kertal and we can't find an easy fix because we fall on this problem again (the url doesn't change). So I am mentioning here to also take this scenario under consideration!

See here #136950

[jughosta]

I think it's working correctly now with the current state of things and we can close the ticket.

If a saved search (Discover session) is loaded and user changes from data view A to data view B, then URL changes accordingly. After a refresh I can see data view B and data appears in its columns.

What is also nicer is that we now show "Unsaved changes" badge and users can decide to revert or to save as is.

@stratoula Do we need a separate ticket for the issue you described in #132620 (comment) or it's handled now?

[stratoula]

@jughosta the problem persists so yes lets create another issue to track this 👍

[jughosta]

@stratoula Created here #208196

Please update it if necessary.

[stratoula]

Thanx ❤️