Kibana: [Discuss] Remove 'Dock navigation' feature

[ryankeairns]

Current situation

The current (and previous) version of the left hand navigation provides a feature which allows users to dock, or keep visible, the navigation menu.

_On the positive side_, this saves users a click each time they want to change applications. In prior versions, this also allowed users to avoid an icon-only navigation.

_On the negative side_, it takes up a substantial slice of horizontal screen real estate. Further, there is an emerging challenge for solution teams as they implement app-level, side navigation elements. Essentially, you end up with something like:

Side nav screenshot

Telemetry

As far as I am aware, there is no available telemetry for us to measure actual usage.

Historical & anecdotal information

Historically speaking, there are a few things to note:

• In version 5, the nav was docked by default
• In version 6, the nav was collapsed to the icon-only view. As the number of apps (icons) grew, this became problematic and I suspect usage of the docking feature grew as well. However, there is also anecdotal feedback suggesting many users overlooked the feature, likely due to its placement in the bottom 'footer' of the nav.
• In version 7, the nav has been redesigned to use an offscreen approach which still offers a docking feature. Feedback has been predominantly positive and there is no longer an icon-only option.

Proposed solutions

Given the redesigned nav, the forthcoming navigational search feature, and the imminent use of app-level side navigation, the question arises: _What should we do with the docked navigation feature/design?_

1. Do nothing - users dock/undock the navigation based upon personal preference and tolerance of broken/busy layouts
2. Remove the feature altogether - point to search as a mitigating factor
3. Keep the feature but increase the breakpoint at which docking is allowed - currently, docking is not allowed on tablet (portrait) size and down; increasing the breakpoint reserves the feature for larger screen sizes

Recommendation

Initial discussions within the design team (i.e. those working towards a side nav solution) are leaning toward option 2, with option 3 as a secondary preference.

As a next step, we wanted to collect additional feedback by way of this issue.

cc:/ @alexfrancoeur @daveyholler @MichaelMarcialis @kaleighflynn @hbharding

[iankoetter]

Don't remove features. Look at all the waste in the left dock that could be cleaned up with some width adjustment.
Leave more to personal preference. Sometimes I'm moving between elements that make it easier to lock the left dock, sometimes I'm digging in data and can hide it if I choose.

In general, there needs to be more user-specific tweaking permitted. I should be able to set my personal environment up to my liking and not be tied to a shared space(for things like color themes!)

In larger production environments we have to all agree to use the same space settings to share a lot of the work/context. I don't understand why UI presentation customization is tied to that space and not the specific user.

[timroes]

Slightly related https://github.com/elastic/kibana/issues/69646

[alexfrancoeur]

I'm hesitant to remove the docking feature from our navigation. I've been a PM for Kibana since 5.0 and with each attempt to change the navigation, the most vocal feedback has been around docking and keeping it as part of the experience. A lot of our community who use Kibana also have a fairly large monitors, so screen real estate isn't typically an issue.

Generally, I think the new navigation is a significant improvement to what we had in previous versions, but the majority of our community is still not using it. It takes time to upgrade. So I imagine we've only begun to receive feedback here. I do believe that the introduction of navigational search (https://github.com/elastic/kibana/pull/72331) will fundamentally change how our users navigate Kibana. But again, it's too early to tell.

As docking the navigation is optional, and the preference is stored locally, I don't see this hindering the majority of our user base. I don't see a good, definitive rush to removing this functionality if it's optional and most likely - used less frequently then we think. I'd like to propose a fourth option:

1. Postpone the decision until we learn more
2. My hypothesis is, search will become the primary and preferred way to navigate Kibana. But we'll need to prove it.
3. If we can begin to understand how search is being used (https://github.com/elastic/kibana/issues/74430) and analyze docking in a similar fashion, we can make more informed decisions around removing this type of functionality. Anecdotally, our community wants this capability, but we don't have any insight into actual usage at the moment.

Similar to @gimmic's comment, functionality like this should be user specific. As user settings is on the near term roadmap, and will likely rise in priority, these types of customizations will become user centric. I plan to work with @joshdover and the platform team on fine tuning those requirements in the coming weeks.

[ryankeairns]

Related telemetry issue: https://github.com/elastic/kibana/issues/77183

[iankoetter]

(My) Related issue #71954 in regards to screen real estate utilization for the side bar.

This should be re-sizable and stored user-specific as a preference.

[elasticmachine]

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