Empty state suggestions for ingest

[snide]

History of decisions from comments in this issue

• @snide proposed consolidating all of our ingest views under a single visual language. This included linked to both Beats and Agent regardless of their GA state.
• @VijayDoshi consolidated PM guidance around linking to only Beats OR Agent so that the flows only lead in the recommended direction. This means that views in Obs link to beats tutorials, and views in Security link to Agent.
• We've asked that any changes in decisions need to be made by the end of the week (Aug 13) to make it in time for feature freeze.
• As part of [META] 7.16 Onboarding improvements around Empty States and Ingest #111374 we're going to want to point these empty states to the integration manager.

Status

• [KibanaPageTemplate] Adding a noDataConfig for templated add data screens #108293
• Update Analytics overview page to new empty state template #108532
• [Enterprise Search] Updated product_selector to match new No Data screens #108592
• [Security Solution] New Add Data Page #112142
  • UX copy review
  • Engineer review
• [Observability] New "No Data" screens #107709
  • UX copy review
  • CTA review
  • Engineer review(s)
  • [APM] Consistent "no data" screen with other Observability solutions #111630
  • [RAC] Apply "no data config" to the Observability Page Template for alerts and cases #113137

Additional considerations

• Analytics recently changed their patterns, and should likely consolidate as well
  • [Index Pattern Management] Show empty prompts in the page contents and don't auto-open flyout #109523

Summary

We need to standardize our messaging around data ingest in our applications during this period where Fleet is GA and Agent is GA, but the integrations themselves are not. The proposal is to consolidate our empty states throughout Kibana for ingest under a common visual language.

This empty state will always use this basic formula. The only difference would be what is the recommended pattern. We will be applying these empty states throughout the product.

Page decisions

This table gives a summary of what choices the user has on each view and the links we need to send them to.

Page	Recommended	Option	Route
Security home	yes	Integrations	app/fleet#/integrations?category=security
Observability APM	yes	Beats	app/home#/tutorial/apm
Observability home	yes	Beats	/app/home#/tutorial_directory
Observability logs	yes	Beats	app/home#/tutorial_directory/logging
Observability Uptime	yes	Beats	app/home#/tutorial/uptimeMonitors
Observability User Experience	yes	Beats	app/home#/tutorial/apm
Observability Metrics	yes	Beats	app/home#/tutorial_directory/metrics
Ent Search	yes	App Search	app/enterprise_search/app_search/setup_guide
	yes	Workplace Search	app/enterprise_search/workplace_search/setup_guide
Analytics	yes	Beats	/app/home#/tutorial_directory

All pages but enterprise search should include this link to the docs for more info.

Observability homepage

The observability homepage is a mix of panels that may or may not be configured yet. We'll need to show a dropdown button for the empty state for these panels. Design is incoming.

Troublesome views

We have several views in Observability (like Metrics and User experience) that show empty dashboards or the like rather than full empty states because there may be a different between the data being shown because of a filter, or because the data does not exist at all. @katrin-freihofner is making sure we have correct boolean hooks we can check to make sure some of these pages have something we can use to decide when to show the empty state.

cc @alexfrancoeur @mostlyjason

[mostlyjason]

@snide I think observability home Beats should point to /app/home#/tutorial_directory. @drewpost to confirm for the observability user experience app.

@nchaulet should we be linking to the integrations UI with package versions included? I thought there was a project to provide links without the package version? That would work more reliably because the user may have a different version installed.

[VijayDoshi]

IMO we'll want empty state messaging for Analytics apps too as well as the Kibana Home page. I've seen pretty much every person in trials clicking on the Kibana area and then immediately either going back or clicking on dashboards where you are presented with a list of empty dashboards to open - they aren't useful because there is no data.

I also believe we should have a link to sample data here - even if it's not our preferred path, it allows a user to explore.

[nchaulet]

@nchaulet should we be linking to the integrations UI with package versions included? I thought there was a project to provide links without the package version? That would work more reliably because the user may have a different version installed.

It's possible to link to the integration details page without version app/integrations/detail/apm/overview for example this will redirect to the latest version available if the package is not installed or the installed version otherwise

[alexfrancoeur]

I echo @VijayDoshi's comment here for the analytics experiences. One thing to note, the tutorials / current add data view has tabs for both File Upload and Sample Data. It's possible the same visual language would work, we just need to prioritize what view we want them to land on. If we can make this paradigm work, @AlonaNadler should be able to provide the prioritized CTA's for an analytics use case and validate the areas we need to provide this or a similar empty state.

Running through 7.14 with no data, there are two primary paths that seem appropriate at first glance, but some work will need to be done on the analytics side to introduce a consistent no-data experience.

/app/kibana_overview
/app/management/kibana/indexPatterns

Here's a breakdown of the current experience.

Application	No data experience
Overview	Single CTA to add data => Index pattern page
Discover	Redirect to index pattern page
Dashboard	Single CTA to create dashboard => Index pattern page
Canvas	Single CTA to create Canvas => Blank Canvas
Maps	Blank Map
Machine Learning	Data Visualizer with multiple CTA's for file upload or select an index pattern
Visualize Library	Redirect to index pattern page

If we are leading with a common overview / ingestion visual language for 7.15. Do we want to fix the interstitial page regression in Cloud #107020? The flow today directs users to the add data tutorials should they choose add data.

[VijayDoshi]

I suspect #107020 is behind lower ingest rates since 7.13. Can't prove it; however, I believe it should be fixed for 7.15.

[snide]

Yep. To be clear. The Analytics views likely need logic changes that we may not be able to fix. For example: we currently look for index pattern existance rather than documents in those index patterns. Design can't solve these issues, and they will continue to be broken in 7.15 unless someone in engineering wants to step up or the Fleet assets issue is fixed.

[joshdover]

The Analytics views likely need logic changes that we may not be able to fix. For example: we currently look for index pattern existance rather than documents in those index patterns. Design can't solve these issues, and they will continue to be broken in 7.15 unless someone in engineering wants to step up or the Fleet assets issue is fixed.

I need to investigate further to confirm, but I believe the analytics apps may be able to update their logic to something similar to what I plan to use for the global "Add data" interstitial (#107020 (comment)). Essentially instead of only checking if an index-pattern exists, we should also check to see if there are any concrete indices behind these index patterns, ignoring the one that is created by default for elastic-agent.

[snide]

@joshdover Awesome. If you can ping @cchaos when you figure out that solution, we'll be happy to piggyback in the appropriate places.

[ryankeairns]

@alexfrancoeur and @VijayDoshi it's not listed but @MichaelMarcialis and I were discussing the Kibana/Analytics "No data" page alongside the other home page tweaks we discussed for 7.15. In other words, my thought was to update the "No data" page to match the others. As Alex notes, we'll need Product direction on the content adjustments for Analytics, specifically.

[ryankeairns]

@alexfrancoeur For Discover and Visualize Library (possibly others) I think we will now be showing the index pattern creation flyout that @mattkime is working on #101853 as opposed to navigating away to Stack Mangement > Index patterns.

[alexfrancoeur]

@ryankeairns Like that we're keeping everything contextual! Will we have the same or similar empty state?

[ryankeairns]

@ryankeairns Like that we're keeping everything contextual! Will we have the same or similar empty state?

Yes. We'll just need Kibana Product input on the content.

[ryankeairns]

@alexfrancoeur , et al, should we apply this design to the interstitial/welcome page? Right now, it's pushing 'Add data' and not Integrations or Beats, directly. At a minimum, we might want to change the copy and CTAs.

[gchaps]

Docs can help with terminology and consistency of the UI copy.

[VijayDoshi]

• I believe a user in a no-data state will likely not have the knowledge to know whether to select the Beats path or the Agent path. Therefore we should only show a single option and have the second option on the corresponding page as an escape hatch - Enterprise Search does have two paths though.
• What does the link "Check our docs for more information." go to? It should be a page that differentiates the different ways to get data in, but I'm not certain that exists. @gchaps can you look into that?
• We should have a link at the bottom (and on the Integrations page in a no-data state) to Sample Data - I've seen many users exit without ever seeing Kibana/Elastic with ANY data - sample data will be better than no data.

@gchaps @alexfrancoeur @ryankeairns @mostlyjason

[gchaps]

@VijayDoshi How about this page for the link: Beats and Elastic Agent capabilities

[mostlyjason]

@VijayDoshi I agree choosing between Beats and Agent is complex. As this page shows its not an easy decision. Giving people a single primary option would simplify the onboarding flow. Minimizing the friction of making a hard choice may make more users successful.

@snide I wonder what the escape hatch would look like? Do you have any mockups of that?

[mostlyjason]

@bradenlpreston @mukeshelastic what do you think about defaulting to Elastic Agent integrations for new clusters in the security solution? Do you feel like we are ready for that in 7.15? I think we'd recommend Beats for O11y because we only have a single GA agent integration.

[alexfrancoeur]

While I know it's not the primary focus or scope of this issue, I think @VijayDoshi's suggestion also makes more sense for the general purpose analytics use case / empty state. There is no preferred option, just multiple options until we have the unified view.

The o11y flow today is a single CTA to add data tutorials with an "escape hatch" to the integrations view. To an extent, we can likely validate the success rate of a single CTA vs. multiple options in Security if it helps the argument.

[VijayDoshi]

<style> </style>

Page	Recommended	Option	Route
Security home	yes	Integrations	app/fleet#/integrations?category=security
Observability APM	yes	Beats	app/home#/tutorial/apm
Observability home	yes	Beats	/app/home#/tutorial_directory
Observability logs	yes	Beats	app/home#/tutorial_directory/logging
Observability Uptime	yes	Beats	app/home#/tutorial/uptimeMonitors
Observability User Experience	yes	Beats	app/home#/tutorial/apm
Observability Metrics	yes	Beats	app/home#/tutorial_directory/metrics
Ent Search	yes	App Search	app/enterprise_search/app_search/setup_guide
	yes	Workplace Search	app/enterprise_search/workplace_search/setup_guide
Analytics	yes	Beats	/app/home#/tutorial_directory

Here's an updated table of proposed single-path ingestion flows. This assumes that we can get CTAs that reference Beats from Integrations and Integrations from Beats.

@hmnichols @alvarolobato @tbragin @mostlyjason - Please confirm these from the Obs & Security POV.

[mostlyjason]

Thanks @VijayDoshi the observability entries look good but adding @mukeshelastic in case he has any input on it.

This assumes that we can get CTAs that reference Beats from Integrations and Integrations from Beats.

We have the latter but not the former. Once we recommend Integrations we don't have any way to recommend Beats in the UI. We might want to consider maintaining the double flow for the security use case if its important to represent both. Adding @bradenlpreston @caitlinbetz for input.

[ryankeairns]

@ryankeairns do we need a unique "learn more" link for Security, Obs and Ent. Search?

Correct. As it stands, this subtitle (with link) will show by default. As I interpret it, the intent is to take the user to a product/solution page on our site (e.g. https://www.elastic.co/kibana/).

[mostlyjason]

@VijayDoshi Yeah I think we could add a link to the Beats tutorials if there are no search results. You also see the footer in that screenshot and we could add a link there. @jen-huang for visibility as a potential 7.15 requirement.

[mukeshelastic]

@snide I did a click through on empty states for all obs UI pages in a brand new 7.14 cluster. That experience was inconsistent and incoherent. So changing these empty states to a consistent visual theme with these two ingest options will be a huge improvement in the onboarding flows for sure! Thanks for leading the charge here.

When users click on obs tile from kibana home page, they are taken to Obs landing page which describes different types of obs data we support. On that page, we have getting started CTA, I expect that to have similar consistent visual experience. So I will update the table in the issue description to list the landing page as well.

For APM pages, I don't think we should point people to APM integration and only to apm agents page. Because that is how, people get started with ingesting apm data. APM integration is an apm-server integration which is an middleware component and not something users need to fiddle with in onboarding workflow. @alex-fedotyev please correct if I am on wrong path here.

For uptime, the two options make sense but I will let @drewpost decide on the recommended option. I may be wrong here but synthetics integration provides most of the heartbeat functionality so we may want to recommend the integration route even if the integration is not GA yet.

As part of this effort, are we also changing the kibana home page layout for visual consistency of data ingestion options for the onboarding workflow? e.g. the ingest data section, try our sample data, Add data link at the top right corner etc.

[snide]

@cchaos and I have been passing back and forth #107709. It now contains the "single choice" flows as suggested from @VijayDoshi. I've also updated the table at the top of this issue to reflect those decisions.

If you want to make changes to where you app goes, please provide that by the end of the week.

[jen-huang]

@VijayDoshi Yeah I think we could add a link to the Beats tutorials if there are no search results. You also see the footer in that screenshot and we could add a link there. @jen-huang for visibility as a potential 7.15 requirement.

I opened #108224 for this.

[formgeist]

For APM pages, I don't think we should point people to APM integration and only to apm agents page. Because that is how, people get started with ingesting apm data. APM integration is an apm-server integration which is an middleware component and not something users need to fiddle with in onboarding workflow. @alex-fedotyev please correct if I am on wrong path here.

@mukeshelastic That's right - at this time we would want to link to the apm agents add data tutorial because that's the most sufficient way of onboarding APM users within Kibana.

For the copy, we'd need to deviate from the others a bit as we're directing the users to APM agents. Just a proposal, here's some changes for the title and button copy in the empty state.

[drewpost]

Exciting to see work being done on this. I’m happy to go with the option that the team decides is best for this iteration. I would prefer to link directly to the integration right now though if possible. We want to move away from Heartbeat as much as possible. Whatever we decide though, I think that it shouldn’t close the door on allowing different options across the UI IF that can deliver a better experience. For example, it is our vision for Synthetics that once the hosted testing nodes are built and generally available, customers won’t ever have to worry about agents or integrations. It would allow us to deliver a getting started experience, built on top of Fleet and Agent APIs, that looks something like this (but you know… better designed) Drew

…

On 11 Aug 2021, at 06:31, mukeshelastic ***@***.***> wrote: @snide <https://github.com/snide> I did a click through on empty states for all obs UI pages in a brand new 7.14 cluster. That experience was inconsistent and incoherent. So changing these empty states to a consistent visual theme with these two ingest options will be a huge improvement in the onboarding flows for sure! Thanks for leading the charge here. When users click on obs tile from kibana home page, they are taken to Obs landing page which describes different types of obs data we support. On that page, we have getting started CTA, I expect that to have similar consistent visual experience. So I will update the table in the issue description to list the landing page as well. For APM pages, I don't think we should point people to APM integration and only to apm agents page. Because that is how, people get started with ingesting apm data. APM integration is an apm-server integration which is an middleware component and not something users need to fiddle with in onboarding workflow. @alex-fedotyev <https://github.com/alex-fedotyev> please correct if I am on wrong path here. For uptime, the two options make sense but I will let @drewpost <https://github.com/drewpost> decide on the recommended option. I may be wrong here but synthetics integration provides most of the heartbeat functionality so we may want to recommend the integration route even if the integration is not GA yet. As part of this effort, are we also changing the kibana home page layout for visual consistency of data ingestion options for the onboarding workflow? e.g. the ingest data section, try our sample data, Add data link at the top right corner etc. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#107682 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABZJOCGZUNG7JCD77VD24CTT4IDJLANCNFSM5BRXO4XQ>.

[gchaps]

@mostlyjason will provide the copy for the description, but here are a few comments:

• "Set up" is two words for the button label (same as in the title): Set up APM agents
• This line needs a comma before the word "or":
  Add your data to get started, or learn more about Observability.

[mostlyjason]

@drewpost are you ready to make the synthetics integration GA? It might be frustrating to tell users to onboard with the synthetics integration but not support it in production environments. Also, would User experience link to the RUM (JS) agent add data tutorial?

I wrote up draft copy for the cards here https://docs.google.com/document/d/1EoYp8Ae5nDk4P61_YCzbMKLi16t8KFW3amO4XUzDZks/edit?usp=sharing (public link) and tagged several folks to review it.

[drewpost]

@mostlyjason - We are ready to make it GA however I want to confirm the timelines as this is not something we could do until 7.16 given FF is Tuesday for 7.15

cc @paulb-elastic

[gchaps]

Currently, I see "Set up", "Add", "Welcome", and "Install". I like "Welcome" for the title. For the body text,
use Jason's google doc as the go-to doc, and copy and paste the text from there. For example:

Welcome to xxxx!
Add your data to get started, or learn more about xxxx.

Add data
Use Beats and APM Agents to send observability data to Elasticsearch. We make it easy with support for many popular systems, apps, and languages.

Add data

See the google doc for copy specific to Logs, APM, Uptime, and more.

[elasticmachine]

Pinging @elastic/kibana-design (Team:Kibana-Design)

[mgiota]

@snide I was wondering about Observability Alerts and Cases pages. At the moment here's how they look like when there are no data. Actually they look pretty good! I was just wondering if we would we like to consider making these pages consistent with rest Observability No Data pages as well? cc @paulb-elastic

The message we display in the Alerts page says Try searching over a longer period of time or modifying your search even if there are no data. Maybe we could differentiate the message in case there are no data.

[cchaos]

That's a great question @mgiota. I don't think these pages were accounted for during the breakdown of this issue. My guess is that since those exact pages live within Observability, we should still be doing the general Observability data specific check on these pages as well to show that "Add data" interstitial (similar to how the Overview page handles it).

@jasonrhodes has created this issue to track: #113137

There would still be these individual views before a user has actually created any Alerts or Cases. I'd suggest syncing with @katrin-freihofner about creating an issue specifically for aligning general / per page empty states across Observability.

[jasonrhodes]

The message we display in the Alerts page says Try searching over a longer period of time or modifying your search even if there are no data. Maybe we could differentiate the message in case there are no data.

Thanks for calling this out, @mgiota -- just for clarity I want to separate a few kinds of no data states relevant here:

1. No Alerts Data for the given criteria / No Cases Data for the given criteria
2. No observability source data at all, likely determined by the lack of indices/data streams existing (we already expose this logic for determining when to show these screens for other pages in this observability plugin)
3. No alerts data at all for any observability alerts, determined by lack of indices

For the "no data" screens in observability, we want to show them in scenario number [2] here.

In your screenshots above, I believe that's for scenario [1], which we don't want to change. (Consider how it would feel if you change the date range and suddenly have a screen instructing you to install integrations, etc.).

For scenario [3], I don't think we've thought through how to properly do that and I think we can/should probably ignore that for now. In the future we should likely consider how to detect "no observability rules currently running" which would be something worth mentioning here, probably.

Please let me know if any of you were picturing something different here!

[snide]

@cchaos we're close on this. Should we make a new issue?

[cchaos]

Yep! The only places left are the Analytics pages and there's a specific META issue to track that: #111184