[Analytics] Enhance the No Data experience with the new NoDataPage

[cchaos]

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.

Originally posted by @alexfrancoeur in #107682 (comment)

[elasticmachine]

Pinging @elastic/kibana-app-services (Team:AppServices)

[joshdover]

@elastic/kibana-app-services I started looking at fixing this by updating the logic in https://github.com/elastic/kibana/blob/master/src/plugins/data/common/index_patterns/index_patterns/ensure_default_index_pattern.ts to match the changes I'm using in #108193, however there are many layers here that I could use some help with fixing.

First, the ensureDefaultIndexPattern function likely needs to reuse the logic from new_instance_status in #108193. If we could split this API into two functions, hasIndexPatternWithData and ensureHasIndexPatternWithData we may actually be able to move this into the data plugin itself and have the home plugin call it from there (home already has a dependency on data). For more details on the logic, see either the associated test in that PR or you can read the 'plain english' here: #107020 (comment)

Next, if an index pattern does exist, but there isn't any data, then the redirect to /app/management/kibana/indexPatterns won't display the new flyover right now. It seems we need to adjust the logic in src/plugins/index_pattern_editor/public/components/empty_prompts/empty_prompts.tsx and src/plugins/index_pattern_editor/public/components/index_pattern_editor_flyout_content.tsx to handle the case where the metrics-* and logs-* index patterns exist, but there is no underlying data to show the EmptyIndexListPrompt UI. This part I don't feel very comfortable touching as there are a lot of layers here and I'm very familiar with this code.

[mattkime]

It should be noted that the new index pattern create flyout was recently merged. It includes no data and no existing index pattern flows. The intention is that any app that was redirecting to index pattern management could use the new flyout instead.

[joshdover]

It should be noted that the new index pattern create flyout was recently merged.

Interesting, that may make the fix for 7.14.1 a bit different than 7.15.0 then.

The intention is that any app that was redirecting to index pattern management could use the new flyout instead.

Sounds like a nice way to avoid redirecting to a completely different UI, however I worry about including that change in this fix as it seems quite large?

[mattkime]

about including that change in this fix as it seems quite large?

Agreed. I'm coming into this conversation in the middle, just wanted to make sure people knew about that even if it doesn't effect anything.

Interesting, that may make the fix for 7.14.1 a bit different than 7.15.0 then.

Yes, there will be two different fixes. Don't even try to backport.

[Dosant]

@elastic/kibana-app-services I started looking at fixing this by updating the logic in https://github.com/elastic/kibana/blob/master/src/plugins/data/common/index_patterns/index_patterns/ensure_default_index_pattern.ts to match the changes I'm using in #108193, however there are many layers here that I could use some help with fixing.

First, the ensureDefaultIndexPattern function likely needs to reuse the logic from new_instance_status in #108193. If we could split this API into two functions, hasIndexPatternWithData and ensureHasIndexPatternWithData we may actually be able to move this into the data plugin itself and have the home plugin call it from there (home already has a dependency on data). For more details on the logic, see either the associated test in that PR or you can read the 'plain english' here: #107020 (comment)

Next, if an index pattern does exist, but there isn't any data, then the redirect to /app/management/kibana/indexPatterns won't display the new flyover right now. It seems we need to adjust the logic in src/plugins/index_pattern_editor/public/components/empty_prompts/empty_prompts.tsx and src/plugins/index_pattern_editor/public/components/index_pattern_editor_flyout_content.tsx to handle the case where the metrics-* and logs-* index patterns exist, but there is no underlying data to show the EmptyIndexListPrompt UI. This part I don't feel very comfortable touching as there are a lot of layers here and I'm very familiar with this code.

We discussed with @joshdover, that the bug he was actually addressing got conflated with the more general problem of aligning the UX of empty states across solutions which this issue covers.
Created a separate issue to tackle index pattern redirect bug: #108726

[mattkime]

Closing this in light of #108887 and #109523