[UX] Redesigned Global Header

[kgcreative]

UX Changes:

• Consolidates the global header in order to minimize wasted space.
• Moves help and user contexts to the side bar
• Minimizes the OpenSearch Dashboards branding and removes the redundant 2nd header bar
• User context menu should be collapsed by default

Header, Nav Closed - Before

Header, Nav Closed - After

Header, Nav Open, Before & After

Related Issues:

• Wreck doesn't respect the root_ca option when using openid security-dashboards-plugin#569
• [BUG] 401 unauthorized error for openID security-dashboards-plugin#810
• OpenSearch Dashboards logo feels wrong

[joshuarrrr]

I'm going to re-summarize these changes as a series of actions/transformations (actions marked [Proposed] are ambiguous in the mocks, but my suggested solutions):

1. The logo (which links to home) on the top bar will be replaced with a mark that appears between the nav toggle button and the breadcrumb.
2. [Proposed] The loading spinner (which currently appears to the right of the logo) is combined with the placement of 1. (By default, or if a custom loading mark is configured, the mark itself will indicate the loading state. If there's a custom static mark, but no custom loading mark, the loading indicator will take the place of the mark during loading).
3. [Proposed] The existing navigational control sections we make available in the top bar (navControlsCenter, observables.navControlsRight will move to the lower bar, on either side of the currentActionMenu).
4. The help menu contents will be moved to the collapsible nav menu (it will no longer be a popover).
5. Update functional tests that are looking for header elements in the wrong places.

Note that the "user context" menu referenced in the requirements comes from the security plugin. But any other community or custom plugins can add navigation menu items in the same way. Changing the behavior of those UI elements from a popover menu directly accessible in a menu bar to an expandable list of menu items in the collapsible nav menu is a rather significant change, and one we should probably provide a bit more time for. (It would either require plugin owners to rewrite their popover menus, or we'd have to write some sort of brittle conversion utility). So I suggest that we only move the help menu for now and allow the other nav items to remain on the consolidated bar (3). That will also reduce the likelihood of breaking plugin functional tests.

[kgcreative]

Thank you for the summary, @joshuarrrr. I'm ok with the proposed solutions.

Regarding item 3

[Proposed] The existing navigational control sections we make available in the top bar (navControlsCenter, observables.navControlsRight will move to the lower bar, on either side of the currentActionMenu).

I would propose we move those to the right of the brand icon, and left of the breadcrumbs. This would allow the currentActionMenu to stay flush right. I am open to input on this suggestion, however.

[ahopp]

Couple of questions;

• Do we have a heuristic for which of the category drawers are open by default and which are closed?
• How are managing the menu ordering? If I install a new plugin, where does it land in the "OpenSearch Plugins" section. Note: Maybe we should consider opening an issue on a favorite concept in the menu.
• I'm mostly aligned with @joshuarrrr proposals, but having a hard time visualizing the alternative you're proposing @kgcreative (in addition to the security plugin implications). Can we update the designs to reflect?

Couple of nits/ideas;

• Do we think "Discover" is the right term/language for the last section that includes documentation? It seems that the term "Discover" has a ton of baggage in the OpenSearch Dashboards world. Maybe nest it in help for now?
• Can we provide a visual que the difference between the "tops of the drawers" (for lack of better terms) and the "inside the drawer content"? For example, if all drawers were closed you might only see white section headers and each open drawer would have nested content in grey.

[kavilla]

Is this to target 2.0? I believe it is correct. Perhaps we can over a "beta" version that is toggled in settings that enables to use the new header to prevent any "breaking" changes related to testing or automation.

[joshuarrrr]

@kgcreative Here's the labeled parts of the existing dual headers.

[kgcreative]

Given the new datapoints above, here is the redesigned header.

Redesigned Header, Revised

In summary:
I'm going to call the current sections: Top Header A, Top Header B, Top Header C; Bottom Section A, Bottom Section B, Bottom Section C.

New zone ordering in the combined header:
Bottom Section A | Top Header A | Bottom Section B | Top Header B -> Bottom Section C | Top Header C

This rearranges all the current sections into a single combined row. @joshuarrrr - let's look at how this stacks in the mobile views as well.

This means the current menu does not have any additional changes.

Menu, Revised

[kgcreative]

@ahopp -- the "Discover" section is intended to provide additional help for each section (in context) -- so if you are in "Observability" -- then that section should be labeled "observability" -- etc. We can take a pass at those in a later update. One of the things I want to propose in the future is a right-hand drawer that will provide contextual help anywhere you are. This might change how the "help" menu behaves in a pretty fundamental level.

[kgcreative]

@ahopp Re: Differentiation between drawer headers vs drawers content, that's on our todo list as we redesign our visual language.

[evamillan]

Thanks for considering how this affects the custom plugins that use the header sections. But not all of them just add a small icon button with a popover and may need more space. For example, the way to access the different dashboards is to open the side bar, click on “Dashboard” and browse through the list. This requires many clicks and is confusing to users who are not used to the platform, so in our company we developed a plugin that adds a menu on the top bar to organise them and help users navigate through them:

With this proposal we would have significantly less space on the header and our menu would be confused with the action menu or the breadcrumbs. What would be the way to handle this case?

[kgcreative]

@evamillan - thank you so much for this additional data point! Looks like you've made great use of what we've been considering "Wasted space" in that top header bar to add a lot of value for your users.

Without going down too far in to the "solutioning" rabbit hole, I can think of a couple approaches:

1. You could collapse the custom menu into some sort of "drawer" that can be accessed via a custom menu either before or after the action menu, perhaps with some sort of clear text label. The drawback here is that it would likely hurt discoverability, since it would hide a lot of those menu items behind yet another nav.
2. We might consider a "compressed" vs "extended" header. This would mean some sort of configuration that would allow you to set a flag to use the double header.

@evamillan - do you have a preference in the approach?
@joshuarrrr - given the 2.0 release timeline, what's the feasibility of approach 2?

[kavilla]

Just an update from my understanding we will be targeting a non-breaking change for 2.1 for this.

Correct @joshuarrrr, @kgcreative?

[kgcreative]

@kavilla - Yes. I'd like to dive deeper into @evamillan's use case, as well as allow for additional time for community feedback for this change. I'm going to iterate the design a bit and look for a path to provide additional options

[evamillan]

@kgcreative I prefer the second approach over the first one. As you said, a collapsed menu would make navigation harder for users.

[kgcreative]

@kgcreative I prefer the second approach over the first one. As you said, a collapsed menu would make navigation harder for users.

Thanks @evamillan! We're moving this out so we can properly account for your needs in a non-breaking way. We may still do some visual cleanup in how the stacked header works and rearrange things a bit. I'll iterate in the open so you can provide feedback.

[joshuarrrr]

While @kgcreative is working on accounting for these other use cases, I've put the PR into draft mode. But I wanted to at least share a demo of the current state we've gotten to so far:

It's also worth noting that there's already an option to load applications in a "chromeless" mode, where the global UI chrome (such as the global header) are hidden. If we opt for an optional second or otherwise extended menu, I'm kind of thinking it's an extension of this idea, that it's possible to have 0, 1, or 2 menu bars (I think it doesn't make much sense to go > 2).

[joshuarrrr]

@evamillan Are you currently collapsing your menu bar to some sort of expandable popover on mobile layouts?

[evamillan]

@joshuarrrr No, the menu bar is not optimized for mobile layouts yet.

[kgcreative]

Ok, team, i've taken another pass at this. @evamillan, please confirm that this approach would work for your use case. @joshuarrrr, please check me on making sure this makes sense from a grouping perspective.

I'm thinking about having a "Compressed" and "Expanded" header variants. Compressed is essentially the same design we have seen already.

The "Expanded" variant has a couple of subtle distinctions from the design today:

1. We've moved the User + Help icons to the "bottom" bar, to be consistent with the "compressed" design.
2. I'm making an explicit callout to move "help" to the far right. This is because eventually, i'd like for help to trigger a push flyout that will allow us to add contextual help, rather than a popover.
3. I've added a "home" icon in place of the opensearch symbol next to the menu. @joshuarrrr, then intent there is this would allow the "loading" spinner to replace that icon to be consistent with the compressed design.
4. The top bar now only has the brand & additional menu (or icon) hooks. This will make adding branding changes a bit more explicit for those users that want customize the brand in the top bar and add additional functionality.
5. Finally, I'm making a recomendation that when we trigger the menu, we move the "home" link below "recently viewed" (or remove it all togehter). The new header will link to "home" via the "mark" icon in compressed mode, or via the "home" icon in extended mode, so no need for additional extra repetition.

[joshuarrrr]

@kgcreative I like this solution a lot. I'll add a couple more implementation details and plans I have for executing this.

I agree that it makes sense to remove the home link from the dropdown, particularly because of the feedback we've heard about the clutter in menu. There may be some short-term user impact as folks who are used to using it adjust, but we can make the new logo home button as discoverable as possible, by at least adding a tooltip.

[evamillan]

@kgcreative Yes, it looks like this approach would work for us, thanks!!

[kavilla]

[Groom]: We are okay with utilizing the config/opensearch_dashboards.yml to toggle this on and off. Stay away from advanced settings.

One risk: How plugins utilize these bars.

[joshuarrrr]

Opened opensearch-project/oui#30 to address popover consistency.

[joshuarrrr]

As part of the code review and release planning, we've made a couple more changes to what was last proposed. To summarize:

1. We've introduced a new branding configuration option opensearchDashboards.branding.useExpandedMenu to provide control over the header layout. For now, it will default to true, to maintain the current two headers. Any users who want to start using the new condensed, single header layout will be able to set it to false. (For 3.0.0, we'll change the default to false as a breaking change).
2. Because we've moved all existing navControls insertion points to the bottom bar (see 1. below), any existing nav controls that need to remain on the top bar should use one of the two newly created locations: navControlsExpandedRight or navControlsExpandedCenter.

Otherwise I implemented @kgcreative's requirements (with implementation details in bold):

1. We've moved the User + Help icons to the "bottom" bar, to be consistent with the "compressed" design. (We've actually moved all existing navControls to the bottom bar: navControlsLeft, navControlsCenter, navControlsRight)
2. I'm making an explicit callout to move "help" to the far right. This is because eventually, I'd like for help to trigger a push flyout that will allow us to add contextual help, rather than a popover. Done
3. I've added a "home" icon in place of the opensearch symbol next to the menu. @joshuarrrr, then intent there is this would allow the "loading" spinner to replace that icon to be consistent with the compressed design. (Note: while we use the home logo by default, if a custom mark is provided, we'll use that.)
4. The top bar now only has the brand & additional menu (or icon) hooks. This will make adding branding changes a bit more explicit for those users that want customize the brand in the top bar and add additional functionality. (See 2. above - we created two new navControl locations)
5. Finally, I'm making a recommendation that when we trigger the menu, we move the "home" link below "recently viewed" (or remove it all together). The new header will link to "home" via the "mark" icon in compressed mode, or via the "home" icon in extended mode, so no need for additional extra repetition. (Removed. In the expanded mode, the full logo also links to home.)

[joshuarrrr]

@evamillan There will be some minor changes you'll want to do as part of your update to 2.1.0:

1. To keep custom nnav controls in the top bar, replace:
   coreStart.chrome.navControls.registerRight(...) with coreStart.chrome.navControls.registerExpandedRight(...)
   and
   coreStart.chrome.navControls.registerCenter(...) with coreStart.chrome.navControls.registerExpandedCenter(...)
2. Update your configuration to make sure opensearchDashboards.branding.useExpandedMenu is explicitly set to true. While not strictly required until we switch the defaults, it will ensure that you won't need to make further changes for 3.0.0.

[joshuarrrr]

After discussing with @kgcreative , we decided that the configuration option should be opensearchDashboards.branding.useExpandedHeader instead of opensearchDashboards.branding.useExpandedMenu

[seanneumann]

Video of Feature sign off. Note, we got feedback to make a change.

Meeting+Recording+-+Feature+Sign+Off+Global+Headers.mp4

[kgcreative]

After discussing with @kgcreative , we decided that the configuration option should be opensearchDashboards.branding.useExpandedHeader instead of opensearchDashboards.branding.useExpandedMenu

Demo/Sign-off outcome: Approved, contingent on configuration naming changes above