Confusing terminology: Saved search and saved query

[gchaps]

Kibana uses the terms saved search and saved query, which are close in wording and easily confused:

• Saved search. The current state of Discover including the search bar, filters, selected fields, column sorting, and so on.
• Saved query. The current state of the search bar + filters only.

Let's renew the discussions on renaming these two objects. For example:

• Saved search -> Discover view
• Saved query -> Saved search

We'll need to revisit the copy in these two screens:

[elasticmachine]

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

[lukasolson]

@stratoula Correct me if I'm wrong, but I think the term "filter set" got thrown around as a replacement for "saved query" (although I'm not aware of current plans to actually rename it).

[stratoula]

Yes we haven't concluded on the naming yet, filter set was one suggestion, saved search was another.

[elasticmachine]

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

[kertal]

While I think renaming
Saved query -> Saved search
is technically correct, I'm afraid I would cause even more confusion #babylon

[stratoula]

I agree but still both terminologies are wrong (saved search for discover view, saved query for unified search).
Possibly we should not use saved-search anywhere and go with another name for unified search

[jughosta]

Adding some other options:

• Search query or saved search query
• Search bookmark
• Search favorites
• Search preset

[markov00]

I'm wondering if we could instead consider merging these two objects into a single concept.
From Gail's description:

Saved search. The current state of Discover includes the search bar, filters, selected fields, column sorting, and so on.
Saved query. The current state of the search bar + filters only.

the main difference is in the additional Discover configuration applied to the table, but the search bar and filters are the same.
Now, these are two different things, and the users need to wrap their heads around these two concepts before mastering both worlds.

If we instead have a single concept of "search configuration" (don't think about the naming here) that is reusable from Discover and from the unified search? the "discover view" could be just an extension to that, that is saved together with the "search configuration" and can be used elsewhere, like today in Dashboard.
In this way we can have:

• a single shared concept of "search configuration", that a user can load from Discover or from Unified Search or from anywhere else.
• the possibility to visualize this "search configuration" as "Discover view" when you are looking to add it to a dashboard: when clicking "add from library" in Dashboard these searches could appear as "Load Search Configurations as Discover views" or something along these lines. You are no more limited to "Saved Searches" objects to add a discover table, but you can also use a "Saved query" there.
• other "search configurations" can be searched/loaded from the Unified Search, like a "search configuration" saved within a Visualization etc.
• we can limit the number of specialized Saved Objects that contain the same information and we can make them interoperable across tools/solutions

[stratoula]

@markov00 I really like this idea and is possibly a smaller breaking change ( we can keep the saved-search for Discover and migrate the saved-queries)

[ninoslavmiskovic]

I like your idea / concept also @markov00 👍 the only comment I have is the same you also have namely the naming "Search configuration". The plus of using "Saved..." is that it indicates to the user that is something they store/save. I don't know the right answer, but perhaps the copy team @gchaps could come up with suggestions. @jughosta also proposed some good ones.

[nreese]

How about
Saved query -> search context
Saved query -> search

[gchaps]

We should also look at the terminology in these screens. "Save saved query" is also confusing.

[markov00]

We should also look at the terminology in these screens. "Save saved query" is also confusing.

I can't speak from a design perspective, but we can probably remove the Saved query title in the first screenshot on the left. The Load saved query and Save saved query could be probably simplified to Load query, Save query
On the second screenshot, the title could be just Save current query and the button could be Save query, or nothing, we the same information is already on the action button below.

IMHO we shouldn't use the term saved, this indicates the state of the object and can be confusing: is it a "saved query" if I just open that dropdown menu but I haven't saved the query before? does it become "saved" only when I click save? if so why I'm saving a saved query (as the action button implies)? Keeping a simpler name is the best option in my opinion.

[mdefazio]

I'm +1 for a single concept here as well. I'm not sure if there are reasons users currently would prefer to keep the selected fields/columns or not in discover (knowingly or not), but perhaps it's included as an option when saving?
Not suggesting copy edits with the mockup here, just showing the extra option...

[andreadelrio]

I'm +1 for a single concept here as well. I'm not sure if there are reasons users currently would prefer to keep the selected fields/columns or not in discover (knowingly or not), but perhaps it's included as an option when saving? Not suggesting copy edits with the mockup here, just showing the extra option...

I really like this idea. With this approach what we could do is that in the dialog for "save query" in Discover, we show the additional options that are available in that app. These would be Include selected fields, Include column sorting, etc shown as selectable options (as seen in the mockup above). That way users could create what we today know as "saved search" from the new "save query" dialog and we merge the two concepts.

Also, I like the name that Julia suggested above "search bookmark". It has the added benefit that if we ever wanted to make creating a "saved query" a one-click deal (like when you bookmark a URL in a browser) we could.

[markov00]

I'm not sure if there are reasons users currently would prefer to keep the selected fields/columns or not in discover (knowingly or not)

@mdefazio this is because you can open a "saved search" in Dashboard and it shows up as a table with the selected fields/column

[gchaps]

Until we have a single concept, I'd propose that we go with @markov00's suggestion and update the copy.

One question though. Can we remove the Saved query title in the menu? Would that make the menu inconsistent with other menus that use a title. Also, when you save a query, the name of that query then becomes the title of the menu. as insave-query in the following image on the left.

I found the 'save saved` copy in 2 additional places:

Following @markov00's suggestion, the copy then becomes:

In the screenshot on the left:

• Change Load other saved query to Load a different query

In the screenshot on the right

• Change the title to Load query
• Use Find a query in the search box
• Use Replace query for the action button.

Are there any other places that "saved" appears in this workflow?

[stratoula]

@gchaps I can remove the title so this will look like

and if I load a query it will look like:

I think it is fine

[stratoula]

Implementation of the aforementioned changes here #154517

[mdefazio]

In the screenshot on the left:
Change Load other saved query to Load a different query

@gchaps Do we need to provide different text when a query is loaded? Was this previously unclear for users what would happen when choosing this option?

Some thoughts on the above screen...
Perhaps this then becomes 'Save' or 'Save changes' as a single button (maybe in the popover footer)? And we rely on the Save as new further down the menu?

I understand if this is going outside the scope of the original issue. So I apologize. This just also struck me as a bit repetitive.

[andreadelrio]

@stratoula @gchaps what if we further simplify the menu like this?

[mdefazio]

@gchaps and I worked through a collection of copy edits shown in this prototype:

QueryMenu.mp4

I like @andreadelrio 's idea above as it solves the odd interaction of clicking on the popover footer button, but showing a 2nd context menu. I think one possible edit could be that we don't need both Save as and Save query if it's not currently a saved query (first screen).

https://www.figma.com/proto/KkT7eh5VzmVbJl7Bt81xk7/Search-Bar-Ideas?page-id=13%3A58402&node-id=13-97874&viewport=-417%2C-1175%2C0.58&scaling=min-zoom&starting-point-node-id=13%3A97874

Update: List of copy edits below:

[mdefazio]

The one extra copy bit I couldn't show in the prototype was the tooltip:

[mdefazio]

@andreadelrio @gchaps Mind taking another look at the summary of copy / minor UI edits to make sure we're all in agreement? Thank you!

[andreadelrio]

@andreadelrio @gchaps Mind taking another look at the summary of copy / minor UI edits to make sure we're all in agreement? Thank you!

In my proposal, I'm also pushing all the saved queries related elements/text to the bottom of the popover. That way the popover is a Query menu with 3 different sections: (1) filter actions, bulk actions (2) query language selector, and (3) saved queries. To make this distinction clear, I suggest removing the saved query title from the popover header and instead using the query's name in the menu item. For example, if there is a saved query called agent php, the menu item would read: Save agent php query.

Also, if we remove the add filter button (which already has an exposed dedicated button) then (1) would just be bulk filter actions.

[gchaps]

I like @andreadelrio's proposal to push all saved query related elements to the bottom and removing the using the query name in the menu item.

For the bulk filter actions, I think we still need to include the word "filter" somewhere in the copy.

@mdefazio would this work with the designs that you proposed?

[drewdaemon]

If we're changing this terminology, does it make sense to update the blog post?

[mdefazio]

To make this distinction clear, I suggest removing the saved query title from the popover header and instead using the query's name in the menu item. For example, if there is a saved query called agent php, the menu item would read: Save agent php query.

My hesitation with removing the popover title is if there are no edits to the saved query, then the save option would be disabled and this would be the only way to see which query I have selected.

I'm fine keeping Save my-saved-query and Save as new where you showed, but I think showing the query name in the popover title still provides a nice context. Granted, perhaps there's a better method to show this. But maybe its worthwhile to do a deeper dive into this specifically.

Do we want to move some of these UI specific changes to another PR or Issue? The main issue here is the terminology. So whether we show Save as a menu item or Save as a footer button is a bonus to the overall terminology clean-up.

@stratoula I know you've already done some work on these edits. Apologies for the updates after-the-fact, but do you have a preference on if it makes sense to split up this work?

[stratoula]

@mdefazio yes I would prefer to use this issue for terminology changes and move everything else in another ER. Can you create one and send it to me? Also if we have more terminology changes can someone mention them here in a comment in order to do them before the FF? Thanx a ton!

[mdefazio]

@stratoula No problem.

I've cut out the broader changes that we've discussed (reordering menu items and including saved searches) and only showing the copy/terminology changes. Ok...so there's a few minor UI edits, but I think these are important to be done alongside these copy edits. I'm not mentioning the icon changes here—I think those can be done in the followup ER (which I'm working on now).

• Remove title
• Load saved query --> Load query
• Saved saved query --> Save query

---

• Load saved query --> Load query
• Replace with selected query --> Load query
• Manage --> Manage saved objects
• Also shows a minor tweak to the alignment of the footer buttons, going from row to column (and filled button first)

---

• Load other saved query --> Load query
• Save as new --> Save query

---

• Load other saved query --> Load query
• Save changes --> Update query
• Save as new --> Remove button from title section (duplicate from menu item further down the list

I've kept this button in place for now so this only is removing a button and updating copy. But this will be updated again for the next release. Please advise if you or anyone wants to break this up differently

---

• Adds title and back button to context menu to match with copy change from previous screen
• Save saved query --> Update query

---

• Save current saved query --> Save as new
• Save saved query --> Update query

Let me know if you have any questions! Thank you.

[markov00]

@mdefazio I love this redesign, thanks for that. I have a minor thing to propose, discuss.
In the screenshot below, the title of the query remains a bit lonely/isolated IMHO, there is no label that indicates that this is the query's given name, and looks a bit out of context. It also looks misaligned with the rest of the text/buttons below.
I don't have much to propose, but probably having something similar to your last screenshot with the Name label and the not-editable input could give a bit more context. There are probably multiple other ways, but I don't have other ideas (except for changing the text to Query: query title or something along those lines)

[stratoula]

@mdefazio thanx, this is very helpful. I am not sure if this will make it for 8.8. Just a comment on the changes
This is not possible (or at least I havent found a way to do it). I can add a title but not the back button. This is a custom item, I am using the EuiContextMenuPanel but it is not part of the EuiContextMenu. So I can't do the navigation

[mdefazio]

@stratoula Thank you for the heads up—makes sense and I suspect the terminology updates outside of this will help regardless.

@markov00 I agree with your thinking. I will wrap up my enhancement request today that summarizes our other proposed changes. This is something absolutely worth including there. I'll be sure to tag you on it when I have it up.

[stratoula]

Closing in favor of #155528 This changes described here #153809 (comment) have already been merged

[lukasolson]

Related: #174144

[mdefazio]

Perhaps relevant for this group as well, a proposal on how context menus can be customized: elastic/eui#7507