Kibana: Global navigation updates

[katrin-freihofner]

The ultimate masterplan 😉

1. Current state / Done

• [x] https://github.com/elastic/kibana/issues/50628
  Identify challenges with the current navigation. And identify good things about the current navigation

-> + Test? We could send out a form (internally) with a few questions. We might get some things we have not thought about. Additionally, I think this could help us to get people on board.

2. Research

Research common navigation patterns and alternative ideas

3. New ideas

List our own ideas.

Check all for

• [ ] Accessibility
• [ ] Responsive
• [ ] Context-aware (solution, use case, permission...)
• [ ] Needs to help with identifying the structure of kibana (Where am I? Where else can I go?)
• [ ] Scale with the number of solutions
  (this list is likely to be extended)
  Identify with which we should move further.

4. Wireframe

Create wireframes, prototypes. +Iterate

5. Test

Run usability and user tests on the prototypes to see which one sticks

[mdefazio]

I think these fall into the checkmarks you have but perhaps a bit more explicit:

• the ability to scale with a growing list of solutions
• And I guess context-aware also means permissions-aware?

[katrin-freihofner]

@mdefazio thank you, these are very good points! I will update this to be more specific. 👍

[ryankeairns]

We will also need to consider the Cloud-related navigation alternatives that have been discussed recently. I’m headed to ElasticON, so I’ll add links later, but those proposals could significantly influence what we do here.

Also, I believe we should consider the page header/tabs as a distinct yet related part of this work. Changes to those areas may face less scrutiny while still having a positive impact on the UX.

[ryankeairns]

For some additional history, we changed the left nav for K7 and received a good amount of feedback which resulted in a few iterations to arrive where we are today. I share not to discourage this new effort, but to make sure we don’t repeat some of the same mistakes 😬

[katrin-freihofner]

@ryankeairns I would love to hear that part of the history. Can you please share this with me?

[formgeist]

@katrin-freihofner I think this is a great process and starting point. As you suggested, I can see us creating a company-wide survey to get feedback on the existing solution and perhaps get an idea of the daily user patterns (how many different apps are in use on average) and do we find common patterns in how the apps are used in conjunction with each other etc.

[elasticmachine]

Pinging @elastic/apm-ui (Team:apm)

[ryankeairns]

@katrin-freihofner , et al, here are a few notes and links from when we redesigned the navigation earlier this year:

• The nav initially expanded on hover and did not have a distinct open/close button. This presented not only accessibility issues, but also errant hovers would block the UI and force users to wait for the flyout menus to close. We quickly added a distinct toggle button to the bottom of the nav to address these issues.
• For K7, we made the nav drawer collapsed by default and users initially had no means to lock it open (while previous versions of Kibana did allow for this). You could now toggle to expand (previous bullet point), but this setting was not persisted. After much feedback, we just recently (7.4?) added this capability back. Long story short, there are many app icons and even experienced Kibana users struggle with identifying them solely by their icon.
• When redesigning the nav drawer component, we also added designs for grouping applications, pinning applications to the top of the list, and favoriting (apps or objects). None of these concepts have been implemented yet, however grouping gained new life at EAH and Dave is currently moving this effort along. While not functional, you can see the icon buttons, grouping, and favorites section in the docs: https://elastic.github.io/eui/#/layout/nav-drawer
• Recently viewed items used to exist only on the Kibana home page. They were relocated to the top of the nav drawer in order to make them globally accessible, this has been positively received.
• The nav drawer has been designed to work on mobile and should continue to work on smaller devices. We've not received much feedback on this aspect, but it does work and we should retain that capability.
• Lastly, we explored and prototyped several alternatives prior to landing on the current design. Some were more drastic than others (e.g. hiding the nav altogether) and you can review them here for your consideration: https://40zyv7llm9.csb.app/

We received a lot of feedback along the way, both internally and externally from customers, much of which was captured in this issue.

It was a learning experience :) Please let me know if you have further questions, happy to help.

[cchaos]

I will add to @ryankeairns' second bullet about persisting the open state of the nav drawer.

Most engineers develop with their browser fully taking over their 27"+ monitor. A lot of our users did too. That's why we got a lot of push back that the nav drawer wouldn't stay open because "they had the room". We initially didn't allow it because at standard browser sizes the nav drawer squished the content too small.

Our current design is a compromise between these two ideas where the nav drawer can be locked open, but only if the browser is wide enough. So as the browser gets narrower, we undock it.

Just to give some more background as to where it is today and to keep in mind going further that you will get push back from engineering and some users if they have to rely solely on icons to navigate.

[katrin-freihofner]

Thank you @ryankeairns and @cchaos - this is extremely helpful if anything else comes to your mind, let me know.

[alexfrancoeur]

Great summary @katrin-freihofner! We're addressing a few of those topics already. Too many icons and the icon mapping will likely be addressed by grouping soon (https://github.com/elastic/dev/issues/1329) and the long loading of apps will be resolved with the new platform.