search

elastic / kibana

Your window into the Elastic Stack
https://www.elastic.co/products/kibana
Other
19.74k stars 8.14k forks source link

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

Open jughosta opened 2 years ago

jughosta commented 2 years ago

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

    Screenshot 2022-05-20 at 15 22 11

  2. Switch to a different data view via the dropdown

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

    Screenshot 2022-05-20 at 15 22 22

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

    Screenshot 2022-05-20 at 15 22 45

  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

    Screenshot 2022-05-20 at 15 22 55

May-20-2022 15-12-19

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

elasticmachine commented 2 years ago

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

jughosta commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

+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 commented 2 years ago

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:

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 commented 2 years ago

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?

Bildschirmfoto 2022-05-25 um 09 09 04

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 commented 2 years ago

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 commented 2 years ago

How about handling it like Dashboards? https://github.com/elastic/kibana/issues/135887

stratoula commented 2 years ago

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.

image

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:

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 https://github.com/elastic/kibana/issues/136950