[Onboarding] Kibana landing page

[ryankeairns]

There is always something new in Kibana and customers are very often unclear what these new offerings can do for them. Further, customers coming from Cloud express an intent for their cluster type (e.g. Observability, Ent Search, etc.) and would benefit from landing on an appropriately themed page.

In order to provide a better onboarding experience, we would like to provide landing pages for each solution.

The new Kibana design will also group products by solution, of which, one will likely contain all the analytical or 'traditional' Kibana apps such as Discover, Visualize, and Dashboard.

This issue covers the landing page for the Kibana 'solution', which covers the following products:

• Discover, Visualize (incl. Lens), Dashboard, Canvas, Maps, ML, and Graph.

Design

Technically, there are two pages that make up the landing 'page' experience:

1. A quick 'get started' version when no data is present
2. A more full, guided overview page

Get started (no data)

Overview page (has data)

Mockups and prototype

• Figma mockups
• Figma clickable prototype

[elasticmachine]

Pinging @elastic/kibana-core-ui (Team:Core UI)

[MichaelMarcialis]

After additional internal/external research and gathering feedback from product management, we've crafted an updated v1/MVP design for the home and Kibana landing pages.

Design

• Figma mockups
• Figma clickable prototype

[MichaelMarcialis]

Hey, gang. @alexfrancoeur and I have been discussing the different RBAC and OSS scenarios that can occur on the upcoming home and Kibana landing page designs. The result of those discussions is that I’ve put together some mockups to show what would be possible/desired in those different scenarios. I’ve also recorded a quick Loom video that quickly runs through each of these scenarios. Links to both can be found below.

Please feel free to ping me with any questions or feedback. CCing @cqliu1 and @AlonaNadler.

• Loom Video
• Figma Mockups & Notes

[alexfrancoeur]

Looking at the other overview page, I don't think we need manage, dev tools or app directory. Those feel like they only belong on the homepage. Can we remove those and keep add data? What do you think @ryankeairns @MichaelMarcialis and @cqliu1 ?

Separately, @AlonaNadler will be putting together an issue for telemetry. With the current priorities, I think we can add a separate feed for Kibana related content as well. I'll open an issue in the newsfeed repo to start a discussion.

[alexfrancoeur]

Now that I'm looking at the screenshots, should we also match the logo / title in white with content pushed down in gray? We seem to have inverted colors in comparison to other overview pages

vs.

[ryankeairns]

Posting a shot of Ingest Manager for additional consideration... they also put the nav links in a top white bar:

cc:/ @MichaelMarcialis

[MichaelMarcialis]

@ryankeairns, @alexfrancoeur: I'm fine removing app directory, dev tools, and manage from the Kibana landing page header, if you feel there is no value there. My only rationale for including them was the consideration that some users may wish to make landing pages such as this one their new home page route, in which case I could potentially see it being useful. But I'll defer to you on that 😄

Regarding the stylistic differences between the Kibana, Observability and Security landing page designs, I think the final decision depends on a number of factors.

• There are some new patterns emerging for Kibana page headers, which I believe is being headed up by @hbharding. These new headers will provide some much needed consistency with how headers are treated across the board. From what I've seen of the early work, it looks as though most (if not all) will be utilizing the header text within a gray background look, similar to what Ryan posted above for Ingest Manager. The Kibana landing page designs also have the header text within a gray background.

• From what I've been hearing lately, there may be another pattern emerging that will eventually do away with the in-application top navigation (as seen in Observability, Security). I believe @johnbarrierwilson and the Enterprise Search team folks are pioneering a new in-application side navigation. This would essentially do away with the white in-application navigation bars that we're seeing currently.

• The above two factors aside, we can definitely talk about being consistent in other areas, including 1) whether these landing pages should have a header (Security doesn't appear to have one currently), 2) logo size, 3) inclusion of a subtitle, etc.

Thoughts?

[ryankeairns]

@MichaelMarcialis I'm +1 for only keeping 'Add data' up top.

As for the design consistency, I agree that the headers feel too ambiguous to align to anything specific at the moment. Let's see how the in-app headers and side nav designs play our before we adapt. Otherwise, we're likely just chasing a moving target.

As you suggest, a little tweaking to the logo size and subtitle does seems worthwhile.

[AlonaNadler]

Are we open to consider showing OSS users the full landing page with items disabled?
It's a good way to communicate the value they are not getting

[ryankeairns]

Are we open to consider showing OSS users the full landing page with items disabled?
It's a good way to communicate the value they are not getting

@AlonaNadler Sounds like a product decision to me; certainly open to trying it out.

For those implementing, we discussed using EuiCard which happens to have an isDisabled prop making this an easy thing to try.

[alexfrancoeur]

I think this is a broader discussion. We aren't showing value of other Basic features in highly visible areas (navigation, homepage, management, etc.). This Kibana landing page will be a prominent application in OSS builds, so if we do show Basic+ features in the landing page, I think there is an argument generally as to where we (or if) should draw the line. I spoke with @AlonaNadler and @VijayDoshi about this this afternoon and plan to open up a separate issue to discuss this topic in more detail. For now, let's continue as is.