[Discuss] Lens, Dashboard-first, and Navigational Search

[ryankeairns]

Related to #83380

Also important to note that the Lens result should also be displayed on the default result display, which is not possible atm as we are only displaying 'root' level app results (but this makes me wonder if Lens should then really be considered as a 'feature' of visualize). Maybe we just want to be able to display a app-level result for Lens even if the app is hidden, in which case this would be a totally different feature than what this PR is addressing

Related, I've put a question out to the Lens team to see whether or not there are plans for Lens to appear as a distinct app in the left navigation menu.

There are no current plans to display Lens in the left nav, however this question did stir up some existential questions around how far we lean into the dashboard-first approach and the resulting impacts to the discoverability of Lens. I'll spin this off into another issue for further discussion.

Originally posted by @ryankeairns in #83380 (comment)

---

The above thread got us thinking about the inter-relatedness of these topics and spawned a few new questions regarding the path forward. In short, how far do we lean into the dashboard-first approach and are we comfortable with the resulting impact on Lens discoverability? Tactically, it raises the following considerations:

Leaning into dashboard-first

• Should Lens appear in the left navigation? (it does not currently)
• If not, then should it also not appear in the default list of applications returned when you open nav search? (it does currently)
• If it's in neither, then is it sufficient to only have Lens appear after a person enters some search text?

Increasing discoverability of Lens

• Does including Lens in the left nav detract too much from the dashboard-first objective?
• Will the addition of the 'Add to dashboard' prompt to the save modal make this less of a detraction?
• Does Lens become less discoverable once Visualize is renamed to "Visualize assets/library"?
• With the marketing emphasis on Lens, is it sufficiently discoverable if it is only found within Visualize and search?

In regards to the linked issue, the display of Lens in the default result set creates an anomaly in the search UX. In all other cases, 'hidden' apps are excluded from the app list, however Lens breaks that pattern but could instead be considered a 'sub link' of Visualize. In the latter case, it would display something like Visualize assets / Lens or Visualize assets / Lens create.

It seems we can make several approaches work, but there are product-level implications which need further input. The question becomes, do we a) neither include Lens in the default app list for search nor the left nav and risk the discoverability factor b) include it in both the initial search result set and the left nav and risk the over-reliance upon the library (mitigated to some degree by the save modal changes) or c) some other combination :)

cc:/ @AlonaNadler @alexfrancoeur @pgayvallet @joshdover @timroes

[elasticmachine]

Pinging @elastic/kibana-app (Team:KibanaApp)

[timroes]

cc @timductive

[joshdover]

It seems we can make several approaches work, but there are product-level implications which need further input. The question becomes, do we a) neither include Lens in the default app list for search nor the left nav and risk the discoverability factor b) include it in both the initial search result set and the left nav and risk the over-reliance upon the library (mitigated to some degree by the save modal changes) or c) some other combination :)

To be clear, we don't have to add Lens to the left nav in order for it to be in search results. We have other potential technical solutions:

• Expose it as a 'deep link' of Visualize within search. It would appear as 'Visualize / Create Lens'.
• Add a feature on top of Add application deep links to global search #83380 that allows deep links to have custom titles & icons. This would still allow Visualize to determine which vis types should have their own deep links, but allow Lens to be displayed in the search results as if it were a regular app.

[alexfrancoeur]

I think it raises a good question. For ad-hoc analysis and investigative workflows, a full dashboard may not always be required. Promoting Lens leans into Lens by default, but less into dashboard first. Though with a lens first flow, I'm sure there are ways we could quickly save and add to a new or existing dashboard if needed. I'll share some thoughts below, but we'll likely want @VijayDoshi and @timductive to weigh in while @AlonaNadler is out.

Expose it as a 'deep link' of Visualize within search. It would appear as 'Visualize / Create Lens'.

This approach treats all visualization types equally. If we want to lead with lens first and by default, my guess is we'll want to promote Lens over other visualization types.

Add a feature on top of #83380 that allows deep links to have custom titles & icons. This would still allow Visualize to determine which vis types should have their own deep links, but allow Lens to be displayed in the search results as if it were a regular app.

In addition to these options and related to my last comment, I wonder if we should also be allowing parent visualizations to determine which sublinks are visible in search? This would allow us to highlight Lens and TSVB in search over the aggregation type visualizations.

do we a) neither include Lens in the default app list for search nor the left nav and risk the discoverability factor b) include it in both the initial search result set and the left nav and risk the over-reliance upon the library (mitigated to some degree by the save modal changes) or c) some other combination :)

We want our users to be able to quickly start analyzing and visualization data. If they type in "visual..", I agree that we should think through what we want the ideal flow for kicking off a new ad-hoc analysis. Should users be landing in a brand new dashboard? Or do we want them in a visualization builder? I think either approach could work. As stated above, Lens is already in the search results, and I'd prefer not to add and remove results with each release. So to me, this feels like a c, but I'd defer to Tim and Vijay on their thoughts here.

[ryankeairns]

I neglected to link to it earlier, but there is an in-flight PR that enhances the save modal to include an 'Add to dashboard' feature. It is targeted for 7.11 - #83140

It will look like this and appear in situations where the user did not come from a dashbaord. In essence, this lifts users onto the dashboard-first flow.

[joshdover]

This approach treats all visualization types equally. If we want to lead with lens first and by default, my guess is we'll want to promote Lens over other visualization types.

It doesn't have to necessarily. Visualize can choose to only add search results for whichever visualizations we'd like to promote. Just want to emphasize that the feature added in #83380 is quite flexible in this regard.

That said, looking at the new modal that Ryan shared, one question I have is how important is it to have the "Lens" name in the search results at all? Could we simply have a Visualize / Create link that defaults to Lens or drops you into a view with the visualization type picker / modal with Lens promoted at the top?

We could still register a "lens" keyword for this deep link once #76778 is implemented so that we don't break the current experience of being able to type "lens" and get to it fast.

I also wonder if we should hold off until we've had more time to think through how we want commands to be represented & the UX to be. We could leave the current experience we have now until then.

[ryankeairns]

I suspect there will be a desire to keep Lens in the results as-is, at least for now, and I agree we should continue thinking through the future vision.

With regards to #83380 , specifically, I'm sensing from @joshdover that we could likely keep what we have for Lens and still add the Stack Management sub links. The latter would be great to have for 7.11 as it is rather useful content, imo.

[VijayDoshi]

Sorry it's taken me a bit to weigh in - my opinion:

With the change to the create visualization dialog we've made it pretty easy to find Lens, there are multiple entry points to the dialog from visualize & dashboard. So, for now we don't need to put it in the left nav.

In the empty state, search results should show Lens above the fold (we're promoting it so people might be looking for it) and, we should weight search results in the empty state in a way other than alphabetical by app. if we can (ideally ordering would be based on user behavior)

Discover
Dashboard
Lens (create visualization) -> drops you into Lens
Then by app usage telemetry (or MRU if possible)

In the default (empty) state when you hit search you get this list, IMO not as useful as having the most commonly used apps at the top.

[timductive]

Looks like @VijayDoshi and I were reading this at the same time 😄

I agree with @VijayDoshi, specifically to the question about dropping someone into Dashboard when they search for Lens. This would be very confusing since users are likely to search with a specific app/action in mind. Given that we are introducing the new modal to bring people into the Dashboard flow from Lens I'd say both concerns are well mitigated by finding Lens in search but not the left nav.

[stratoula]

I think we have addressed everything here so I am closing this!