[Data views] revisit user facing terminology for ad-hoc data views in Lens

[drewdaemon]

Action to be taken

In the Lens editor only,

• "Use without saving" -> "Save to visualization"
• "Save to Kibana" -> "Save to library"
• "temporary" badge should either show up as "current" in Lens or not show at all in Lens

Background

I'm wondering if the current terminology we use to describe ad-hoc data views is prone to confuse users and scare people off. I know naming is hard, but thought it was worth starting a discussion.

"Temporary"

Currently, ad-hoc data views are called "temporary" in the UI and the docs.

This seems to imply that my data view is going to disappear at some unclear point in time. This is true for Discover, but not for Lens.

"Use without saving"

Another "scary" phrase is found on the button of the data view creation flyout.

When you’re creating a data view from Lens, the button reads “Use without saving,” implying that it’s going to disappear somehow if you don’t save it… save it where?

It seems to me like the buttons could read something like “Save to Kibana” and “Save to this visualization.” That makes the scoping clear without implying (again) that my data view is ephemeral.

cc @amyjtechwriter

[elasticmachine]

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

[ninoslavmiskovic]

@drewdaemon Have we got some information from users that there is confusion here?

I remember the discussion about the label and why it was important to indicate that the data view in Discover is temporary because as soon as you clean your cache it is gone.

I do understand from the visualization part it is a bit different use case.

Don't know if @KOTungseth can add to the discussion.

[mattkime]

I agree with @drewdaemon but I've lacked the confidence to submit a solution. I also think we ended up here because the technical possibility was ahead of the UX.

There's no reason to reinvent the wheel when it comes to persisting changes but we find ourselves in an awkward spot with this UX. It really depends upon where you are in kibana whether a given change is persisted or needs to be saved.

Ideally an ad-hoc data view would be the default and then you'd be prompted to save it - just as though you were working in Word.

[davismcphee]

Ideally an ad-hoc data view would be the default and then you'd be prompted to save it - just as though you were working in Word.

++++ I definitely think this makes the most sense conceptually.

I wonder if something like "Use this data view" and "Save to library" as options would improve how these actions come across to users without requiring a significant UX overhaul?

[drewdaemon]

It really depends upon where you are in kibana whether a given change is persisted or needs to be saved.

Okay, I think this is the key problem. I did not understand how these work in Discover. Now, I understand better where the original messaging came from.

Have we got some information from users that there is confusion here?

@ninoslavmiskovic no direct feedback. This caught my eye when I was I was trying to explain how these work to a community member. I wrote:

Also, I don't see any reason why you can't include a custom data view with an integration as long as its scoped to a particular visualization (the docs call these "temporary data views").

It struck me that "temporary data views" doesn't convey how these work in Lens at all. As I stated in that explanation, the key difference in Lens is not really the longevity of the data view, but instead the scope in which this data view is available.

[ninoslavmiskovic]

I also agree on the notion of upgrading a ad-hoc dataview (which is not possible today).

The idea of starting with something temporary and save it. It is like Word , but we also live in 2023, so perhaps we can have auto save 😊 that is however a bigger discussion.

[amyjtechwriter]

Hello hello @drewdaemon can I just clarify if I should still be looking at the UI text here? Or because it depends oh where you are in Kibana are we waiting for a larger discussion on potentially using auto-save? :)

[drewdaemon]

@amyjtechwriter I think @ninoslavmiskovic is ideating for the future when he mentions auto-save so you can set that aside for the moment (correct me if I'm wrong, Nino).

The immediate point I'm raising is that the term "Temporary" makes sense in Discover, but not in Lens (IMO). I have updated the title and body of this issue to clarify that it is the Lens case that is the problem. I tagged you in case you had any thoughts on this particular issue.

[ninoslavmiskovic]

@amyjtechwriter I think @ninoslavmiskovic is ideating for the future when he mentions auto-save so you can set that aside for the moment (correct me if I'm wrong, Nino).

The immediate point I'm raising is that the term "Temporary" makes sense in Discover, but not in Lens (IMO). I have updated the title and body of this issue to clarify that it is the Lens case that is the problem. I tagged you in case you had any thoughts on this particular issue.

It is for the future ++

[amyjtechwriter]

Thank you for the clarification @ninoslavmiskovic :).

What do you folks think about "Save to visualization | Save to library" for the buttons?

When thinking about the "temporary" badge - is it is a shared UI component? I'm wondering if changing it in Lens would mean it changes in Discover as well. If it's not then maybe we could change it to "current" for Lens, or have no badge at all.

[ninoslavmiskovic]

I like the copy for the buttons @amyjtechwriter - regarding the badge I think it is a global component - part of unified search. Correct me if I'm wrong here @drewdaemon

[drewdaemon]

Yes, @ninoslavmiskovic I see that you're right. Anyway, I'm glad to see the sensitivity to the component architecture but, at the end of the day, I think we can call this an implementation detail.

With @amyjtechwriter 's guidance in place, I feel that this issue is now actionable.

[drewdaemon]

Another twist: Discover does persist the "temporary" data views when you save a search. So, actually the behavior of the two apps is more similar than I thought.

• Creating the ad-hoc data view doesn't save it anywhere
• When the piece of content (vis or saved search) is saved the ad-hoc data view is persisted