[Home] Redesign Kibana Homepage to reduce clutter

[alexfrancoeur]

We'd like to redesign the homepage for Kibana for 6.x / 7.0. There is a lot of clutter on the homepage at the moment and it acts like a duplicate navigation to some extent.

Mockups updated on June 18, 2020

• Figma mockups
• Figma clickable prototype

Some notable features include

• Showing sample data when appropriate. This logic is built in, but we'd be emphasizing the sample data even more upon entry. This would remove the need for the splash screen so it can be utilized for other things.
• Set your own homepage. This would be fantastic so users can choose a view in Kibana they'd prefer to land on when entering Kibana. This ideally would be done at a space and user level. Unfortunately, this will likely require a bit more work and outside the scope of the design team. We'd need some help here. [Home] Provide the ability to set your own home page #25735

Open questions

• With this design, we no longer have index pattern and file upload emphasized on the homepage. How can we enhance the add data UI to include these as well as emphasize the categories of tutorials we had?
• How can we emphasize solutions more on the home page? If for some reason we don't have new product guides in the first phase, is there a good way to approach this?

cc: @AlonaNadler

[elasticmachine]

Pinging @elastic/kibana-design

[elasticmachine]

Pinging @elastic/kibana-app

[ryankeairns]

@alexfrancoeur the boxes could be used to promote solutions as well, and we don't have to limit ourselves to three... although we don't want to end up with too many and end up back where we are today ;)

[elasticmachine]

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

[ryankeairns]

Copying over @MichaelMarcialis comment from #34397

---

We've gathered some additional internal research and started crafting early design concepts for these home page improvements. Adding the links here for visibility.

Design

• Figma mockups
• Figma clickable prototype

[ryankeairns]

Here is a related issue for adding search to the 'Add data' pages. It's an offshoot of this effort, but linking here since it has been proposed in some of the early onboarding design concepts.
#14701

[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

[alexfrancoeur]

As I think more about this page, I have a few design questions for @MichaelMarcialis and @ryankeairns.

• How do we plan to handle feature controls and RBAC on this page? If you don't have access to solutions, what happens to the boxes? If you don't have the ability to ingest or manage data, what happens to those sections?
• The more I think about it, I'm not sure if we want to make sample data equal to other add data options. It's only relevant for onboarding, and in order for them truly to engage, we'd prefer they add their own data anyway. Thoughts on making it a link or some how minimizing the sample data option?
• If this is landing in ~7.10, do we want to promote add data tutorials equally to ingest manager? Which one should be more prominent? @mostlyjason might be able to help here as well as with some of the text.

[alexfrancoeur]

I know as part of this discussion, we also have explored adding or not adding an interstitial page. I wanted to note here, that we will need to provide notice of telemetry that is captured in the first run of Kibana. Happy to provide more details when we start building the Elastic home page out. Example below:

[mostlyjason]

@alexfrancoeur in 7.10 we should promote the add data pages more since the ingest manager is still in beta. I like having it included though, especially with text describing it as beta.

[MichaelMarcialis]

Great questions, @alexfrancoeur. Apologies for the delayed response.

• How do we plan to handle feature controls and RBAC on this page? If you don't have access to solutions, what happens to the boxes? If you don't have the ability to ingest or manage data, what happens to those sections?

This is a tricky one. In thinking about it briefly, I believe we have three possible directions to take:

1. Hide solution boxes. While the most obvious choice, it does have the potential to create problems with the current design. For example, if a user only had permission to the Kibana applications, would they just see a huge Kibana box? I think this direction would require rethinking/redesigning the top solution space to accommodate such scenarios.
2. Disable solution boxes. By having the solutions that a user doesn't have access to present but in a disabled state, we achieve the same effect as hiding them, but without disrupting the design layout. However, it also means showing a solution on the home page that the user cannot interact with (which may be more undesirable).
3. Show permission denied message at the solution landing page level. This also avoids disruption of the homepage layout by instead notifying the user that they do not have access to a particular solution when they attempt to visit that solution's landing page. That said, I think this stinks from a user experience perspective, since we're actively promoting and linking to something the user unknowingly cannot access.

Thoughts?

• The more I think about it, I'm not sure if we want to make sample data equal to other add data options. It's only relevant for onboarding, and in order for them truly to engage, we'd prefer they add their own data anyway. Thoughts on making it a link or some how minimizing the sample data option?

I think that makes sense. Do you wish to take this approach on both the home page and index management pages as shown in the design? Or just the home page?

[alexfrancoeur]

Hey @MichaelMarcialis thanks for the response!

The more I think about it, the more I feel option 1 is our only real option. I believe 2 would be confusing to a user if they see disabled solutions in the home page and not in the navigation (this was a choice we made a long time ago with feature controls). Option 3 is a pretty poor UX and one issues have been opened for when we've accidentally provided this experience.

We'll also need to think through what the OSS experience is. It's a very similar problem as with RBAC, but I wonder if it's worth putting together a few mockups for both OSS and if we've removed access to a few different apps (solution, ingest options, data management options, etc.). Do you think you could put maybe two examples together?

I think that makes sense. Do you wish to take this approach on both the home page and index management pages as shown in the design? Or just the home page?

For now, let's focus on just the homepage. I believe the index pattern management view will only look like that in an empty state. The homepage however, will always have these options. How does that sound?

[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

[ryankeairns]

@alexfrancoeur regarding the 'set as home page' link. @cqliu1 and I noticed that this only affects the page you land on when you log in. At first, I thought it was not working since I expected clicking on the Elastic logo to take me back to the page (route) that I had set.

What are your thoughts on that? Should the cluster logo take you to the home page for the Space?
With the new navigation, there is also a Home link so the original home page could always be accessible...

[alexfrancoeur]

Thanks for raising @ryankeairns and @cqliu1. I think to work with what we have today (space-centric and existing configurations) we could adjust the text to be more specific to the functionality itself. So, rather than say change your homepage, we could say "change the default page when for login" (with lots of help from Gail 😄 ).

I do think the home link and the Elastic cluster logo should behave the same way. So if I click either, they route to the same view. So whatever we decide here, from a UX perspective, it feels like they should have the same behavior. I'm open to discuss alternatives though. With the Home link, we could think of alternatives for what the cluster logo could do.

Looking ahead, I generally think in order to make this work well, we'd need to do a few different things.

• There should be a hierarchy. Any homepage modifications should be space-centric first, and then user-centric. This could be hacked with local storage (not ideal) or we can wait for the user-settings service (still to be defined).
• We should provide an experience outside of advanced settings. This would include some "smart" defaults like solution landing pages, an app, or specific saved objects. I have a feeling we could leverage the API's we now have for navigational search to provide a simple modal experience here.

My vote is that we adjust the text to describe exactly what they're modifying today, make the text / link itself conditional based on permissions (RBAC - if you don't have access to advanced settings you shouldn't see this) and create a discuss issue for the ideal experience. I imagine others will want to weigh in. How's that sound?

[ryankeairns]

+1 what @alexfrancoeur proposed. Do the simple thing right now and spin up a larger discussion (i.e. create an issue) on how this could be improved in the future. As it stands, setting the login page is sorta helpful, but I'd bet that it's not meeting the majority of user expectations.