Create a common no-data view and conditional check for Analytics applications

[ryankeairns]

Similar to how this has been handled for Solutions, we would like to show the same empty state page for all Analytics applications, as the default. Specifically, this new empty state design for the Kibana Overview page should be displayed for each Analytics application when no data is present.

Proposed technical approach

One way we could handle this would be to:

1. Create a shared Analytics no-data view that all applications whether they live under /src or /x-pack (PoC PR merely for demo purposes; need to be replaced)
2. Create a service that checks whether this is a new Kibana instance that has no data

What exists today?

• As seen in the Overview PR above, the empty state design can be implemented via the noDataConfig and template="empty" props on the existing KibanaPageTemplate. The proposal is to, essentially, pull out the Overview setup into a shared component that all Analytics apps can use, perhaps alongside the page template itself at src/plugins/kibana_react/public/page_template
• Currently, the Kibana Home and Overview pages use very similar logic to derive a isNewKibanaInstance state. Given that we want all Analytics to behave the same, we should probably pull this out into service, of sorts, for each app to use conditionally like:

return (
  !isNewKibanaInstance ?
  <DiscoverLayoutMemoized
    indexPattern={indexPattern}
    ...
  />
  :
  <AnalyticsNoData />
);

Where <AnalyticsNoData /> is the aforementioned shared, no-data view component (see this PoC PR)

[alexfrancoeur]

@clintandrewhall @thomasneirynck @ryankeairns @snide what is the possibility we could still backport this to 7.16? And if not, how about 8.0?

[afharo]

Create a service that checks whether this is a new Kibana instance that has no data

@ryankeairns are you referring to the IndexPatternService's API hasUserDataView? Or anything else?

[lukeelmers]

cc @elastic/shared-ux

[ryankeairns]

Create a service that checks whether this is a new Kibana instance that has no data

@ryankeairns are you referring to the IndexPatternService's API hasUserDataView? Or anything else?

It appears the check varies between the Home and Overview pages as linked in the 4th bullet point above. The Home page appears to use hasUserIndexPattern while the Overview page uses hasUserDataView. I'm not 100% certain which is more correct, it just struck me that we should do apply this uniformly thus the recommendation for a centralized/shared check.

[majagrubic]

Two questions:

1. Why do we need a separate view instead of just a redirect to kibanaOverview page, which already does exactly that?
2. What data (besides index patterns data views) do we want to check for? Is the idea here that there exists an ES index, ie. some sort of integration has been made, but no data views? Or do we want to check for specific saved objects, ie. in Discover if there are saved searches, in Dashboard if there are dashboards etc? Or any saved objects? Or something else entirely?

[alexfrancoeur]

Why do we need a separate view instead of just a redirect to kibanaOverview page, which already does exactly that?

I'd be interested in hearing @ryankeairns and teams thoughts here, but if the experience is the same with a single CTA it might be good enough. We want to match solution experiences here. If we can avoid a redirect, I think that'd be the best outcome, but if it speeds up implementation I think it's worth exploring.

What data (besides index patterns data views) do we want to check for?

There should be logic that exists already we can just leverage in both solution views and the analytics overview page. I believe it checks against integration data views that have been bootstrapped with Kibana. The "no data check" should be standardized, but if it isn't, happy to discuss in more detail. If there's no user generated data, then we want to show this empty state.

[afharo]

It appears the check varies between the Home and Overview pages as linked in the 4th bullet point above. The Home page appears to use hasUserIndexPattern while the Overview page uses hasUserDataView. I'm not 100% certain which is more correct, it just struck me that we should do apply this uniformly thus the recommendation for a centralized/shared check.

@ryankeairns Oh! I see that it could be confusing. When the renaming occurred, we switched to that same API hasUserDataView, but the Home component didn't change its props name:

kibana/src/plugins/home/public/application/components/home_app.js

Line 79 in 9d662b7

hasUserIndexPattern={() => indexPatternService.hasUserDataView()}

I'm happy to create a quick PR to rename the prop if you think it will help in the future 🙂

[ryankeairns]

I'm happy to create a quick PR to rename the prop if you think it will help in the future

Thanks for explaining @afharo . I do think that would be a good idea in order to clarify the logic.

@majagrubic @alexfrancoeur +1 for the redirect if that gets things addressed more quickly. When Clint and I last spoke, that was his inclination as well. I apparently just did not update this issue to reflect his proposal at the time.

[majagrubic]

Before I say I am in favor of a redirect, I'd still like to understand benefits of a non-redirect better. Is the idea that the user stays in the same app, to speed things up after the setup?

[ryankeairns]

It's probably trivial, but suppose you try to open Discover and then the breadcrumbs/url show you are on Kibana Overview. It may feel broken if it's not clear why you can't get to Discover. There may be other considerations, but that is what came to mind for me when reading the comments above.

[majagrubic]

It's a fair point. I still think that when users are presented with a completely empty Kibana, they'll have bigger worries than which app they are on. So my vote goes for redirect.

[LL6688]

@alexfrancoeur the release label should be 8.1...

[ryankeairns]

Closed by #123366