Kibana: Nav drawer UX

[cjcenizal]

This is a huge improvement over the expand-on-hover behavior! There are still a couple issues that this new component introduces which didn't exist in the 6.x side nav, though.

Overlapping with content

Sidenote: In the above gif, it looks like the nav collapses automatically once I navigate to Dashboard, which I believe is a bug, orthogonal to the UX issues I noticed.

The issue here is that the user has a choice between either:

• Pinning the nav shut and being able to use the main UI, or...
• Pinning the nav open and not being able to use the main UI.

I think an ideal UX would be one in which pinning the nav open doesn't degrade the UX of Kibana as a whole. In other words, it would be great if the user wasn't penalized for preferring the nav to be pinned open. This problem doesn't exist in 6.x so if we were to maintain the 6.x behavior then this would be one way of solving the problem. Example:

Nav drawer auto-collapses when viewing sub-drawers

The issue here is that the user's preference of pinning the nav drawer open is reverted if they open a sub-drawer, e.g. "Recently viewed". So the UI is essentially fighting the user. 😄 I think an ideal UX would be one in which the drawer is _only_ collapsed if the user explicitly chooses to collapse it, by clicking the "Collapse" button -- this way the user is in control of the UI.

CC @elastic/kibana-design @alexfrancoeur

[snide]

I think an ideal UX would be one in which pinning the nav open doesn't degrade the UX of Kibana as a whole. In other words, it would be great if the user wasn't penalized for preferring the nav to be pinned open. This problem doesn't exist in 6.x so if we were to maintain the 6.x behavior then this would be one way of solving the problem. Example:

We don't plan on supporting this behavior and have no intentions to change it at the moment. Kibana has changed a lot since the days when the original nav was conceived. In general, the apps require much more width than they used to. We really need the space.

We will of course address bugs, but there will be no more changes of the functional interaction before 7 lands.

[cchaos]

I think there's also a misconception of what the toggle button does. This is not the "pin/unpin" functionality of Kibana 6 days. The toggle button just temporarily allows the side nav to expand to view the full text of the options. But there is no option to keep it open forever. It will automatically close when navigating and when opening the sub-nav drawers.

[cjcenizal]

there will be no more changes of the functional interaction before 7 lands.

💯 I completely agree... to be clear, I'm not trying to push for any changes for 7.0. I'd just like to point out some friction in the UX with an eye towards ways we can improve it in the future. With that in mind, is this a topic you're open to discussing?

[snide]

At this time we just want to pause to receive feedback. I think you've made your opinions clear, so thanks. We'll let it gestate like the last round and respond appropriately if we see a need.

[cjcenizal]

Thanks, sounds good! Would it be useful if I gathered feedback from other people and asked them to chime in here?

[snide]

The click while expanded issue is addressed in https://github.com/elastic/kibana/pull/34011. It now closes on click if the menu is expanded.

Still no plans to use a pushover vs. overlay for the menu itself when expanded.

[jaijhala]

I think users should have the option whether they prefer "Expanded" side tabs or "collapsed" ones.
Right now if you expand those tabs, it eats up the main UI like below -

This was not the case in 6.x as mentioned earlier. It's easy to get rid of that when you click anywhere on the main UI and those side tabs collapse again.

But the problem is I have to click on Expand everytime when I have to go to a separate tab as it's pretty hard to remember what those tabs are just from the icons.

[m-adams]

+1 for an option to pin expanded in a future release. I'm finding myself squinting at small logos or expanding every time. I'm no UX expert but I would think it might also reduce accessibility.

[snide]

Design is trying to prioritize development of https://github.com/elastic/kibana/issues/29222 so that we can't cut down the cognitive barrier of all these apps.

Our _theory_ at the moment is that it's less about needing to see text, and that it's more about not being able to read 15 icons at once. Grouping the apps into lets say 6 total icons, that clicked into a menu with a text list would likely help.

We're really sensitive to horizontal space concerns in Kibana which is why we're avoiding using that width in a pushover fashion.

We'll do some user testing on whatever we come up with, but we're trying to prioritize this stuff.

[epixa]

I'll start by saying that I'm fine with doing some testing here to make sure we get this right. My experience might be an outlier.

Personally, I can't use icons for navigation. It's just not a practical option for me. It has nothing to do with Kibana specifically, either - I've found it very challenging to navigate with icons in every app and site I've used that uses that design.

When I see icons, even just 2 or 3 of them, my brain doesn't distinguish between them automatically. They're just kind of slightly different blobs on the screen up until I intently focus in on them, and then I need to go icon by icon to determine which icon is representing the thing I need. This problem gets dramatically harder, and borderline completely unusable for me when I'm not sure exactly what I'm looking for.

I'm very familiar with the capabilities and features of Kibana as well as where they are positioned in the sidebar, and in both 5.x and 6.x I always defaulted to navigation expanded. All the way back to when we only had 4 apps.

Significantly different colors of icons is really the only thing that allows me to distinguish them at a glance. For example, while I rarely interact with my mac dock directly, firefox is orange, terminal is black, slack is white, and vscode is dark blue. Those icons weren't intentionally designed with the same color palette and aesthetics, which is actually a feature in this case.

Edit: So far, 100% of the time I've navigated in K7 involved manually expanding the menu so I can find the right app to click.

[bmcconaghy]

Totally agree with Court's viewpoint here. As someone with limited vision, I can't distinguish amongst a bunch of tiny icons and thus they offer no help to me when I'm trying to navigate. I know the management one is at the bottom so I can find that easily enough, but all the other ones, no idea.

[pb-expa]

Love the overall look, but I have to agree that this drawer design is a HUGE headache.

[cjcenizal]

Here's a suggestion that I think addresses all of the concerns I've seen so far. Let's add an Advanced Setting that lets people opt into using the pinning behavior from 6.x. This way if the horizontal space concern (below) is a problem for the user they can choose to use the default existing behavior. But if the user is comfortable sacrificing 200 or so pixels of horizontal space in order to gain the ability to read the names of the apps in the side nav, they're allowed to make that decision.

In general, the apps require much more width than they used to. We really need the space.
We're really sensitive to horizontal space concerns in Kibana which is why we're avoiding using that width in a pushover fashion.

[viglia]

For the purpose of this conversation I'd like to report a feedback from a customer which is also having a problematic experience with the collapsible sidebar.

While he finds it handy when displaying dashboards, he says it becomes annoying when there is a need to navigate quickly between different menus.

Main concerns:

1. sidebar collapsed by default
2. status no longer persisted on the client side -> if the menu is open and Kibana is refreshed the status is forgotten and the menu will be shown as collapsed

Requests:

1. being able to change the default behaviour

[snide]

We have this scheduled as a task item for 7.4. Will update when we have some concepts.