Customizable Header and Footer Banners

[alexfrancoeur]

Some work environments require a constant reminder of the environment that you are in. Ideally, this would be surfaced as a persistent banner with customizable text that cannot be dismissed. The banner(s) should be completely optional and shown in all aspects of Kibana, including the login screen. In order to fulfill this use case, Kibana would need the following:

• A configurable option to create a header and / or footer banner. Users should have the option to configure either one or both.
• Configurable descriptive text for either banner
• A configurable background color for either banner
• The banner would need to be full screen width, fairly thin and persisted at the bottom and/or top of the page - not necessarily always visible.
• This should be included on all screens within Kibana

Also somewhat related (albeit closed) is #4452

Some notes:

• Should make sure this potentially sensitive data is not reported to Telemetry (Customizable Header and Footer Banners #17298)

Stages

• Phase 1: Introduce a customizable header that is configurable from kibana.yml and the global header will be visible on the login / logout screen - Implement custom global header banner #87438

• Phase 2: Add an alternative configuration option for space specific headers. This will visually differentiate spaces for environment, teams, or however spaces are defined

• Phase 3: Pending Kibana page layout shared components #86528, add support for footers for the global kibana.yml configuration

• Phase 4: Pending Kibana page layout shared components #86528, add support for footers for the space specific configuration

[mbarretta]

@alexfrancoeur Looks like a lot of these linked issues should instead be linked to https://github.com/elastic/x-pack-kibana/issues/4953 - thoughts?

[alexfrancoeur]

@mbarretta some of them are, happy to add all of them though. I tried to split them where I thought made sense but feel free to adjust where necessary.

[aaaronic]

👍 for the feature

I was just looking for this option today, as we have many clusters and want to prevent modifying the incorrect one on accident. Putting a banner with color-coding would help me easily remember which environment I am interacting with.

[mbarretta]

In the context of spaces, I think we can re-describe the request as:

• provide an option to display header and footer banners for each space
• the header and footer banner should be the same color as the color configured for space
• provide an option to display the space name and/or description in the header and footer banner
• [optional] allow markdown in the space description field to provide customized formatting (bold, italics, etc) in the header and footer

[StingyJack]

This would really help with preventing "whoops" mistakes.

EDIT: I would like to reinforce that the existing means for defining the colors and text for "spaces" isn't enough. That designator is all the way toward the bottom of the left nav and may not be visible depending on zoom level or resolution.

[legrego]

Regarding the comments around Spaces:
@mbarretta :

provide an option to display header and footer banners for each space
the header and footer banner should be the same color as the color configured for space
provide an option to display the space name and/or description in the header and footer banner

@StingyJack :

I would like to reinforce that the existing means for defining the colors and text for "spaces" isn't enough. That designator is all the way toward the bottom of the left nav and may not be visible depending on zoom level or resolution.

The new K7 design places the Space indicator on the top left of the new navigation, where it is much easier to see (or harder to miss):

I see two different enhancements here:

1. A persistent site-wide banner (configured via Advanced Settings)
2. A space-specific banner. This could replace the site-wide banner when configured.

[mbarretta]

Given there is no Kibana view that is outside of a space, I think option 1 is really just option 2 for the default space. In other words, there is just one enhancement: optional header and/or footer for each space.

To be clear, I'm looking for something like this:

Ugly, yes, but required by some folks.

[legrego]

Given there is no Kibana view that is outside of a space, I think option 1 is really just option 2 for the default space. In other words, there is just one enhancement: optional header and/or footer for each space.

I could buy that argument, as long as we don't need this functionality without Spaces. If the spaces plugin is explicitly disabled (xpack.spaces.enabled: false), or not available (OSS distribution), would you still want the ability to set a global header/footer?

[elasticmachine]

Pinging @elastic/kibana-design

[alexfrancoeur]

I think having the feature be space specific is fine, though it would be nice to have an automated way to update all to be the same if there are 100's of spaces (advanced settings API?). This has been a long-standing ask from the federal community in particular. I was at ElasticGov last week with ~500 members of this community and this feature came up numerous times. There are workarounds, but they are pretty hacky and it'd be nice to support natively.

@mbarretta do you think this would be fine being space specific? This means, the banners would only be shown after login. I believe it's a separate requirement for an acknowledgement page.

[ryankeairns]

@alexfrancoeur @mbarretta is this at a point that somebody from the design team should do a mockup(s) of the banner?

[alexfrancoeur]

I think so, @cchaos added the design label though. I would think things like background / text color would need to be configurable for either banner, but would have to defer to @mbarretta for that one.

[mbarretta]

@alexfrancoeur For the Fed stuff, under NIST 800-53, yes, it's ok to display the header/footer post-login, as login controls are a different requirement (and still in need of an implementation in Kibana!)

800-53 doesn't go into much detail for implementing markings on information systems (AC-16(5) is as far as it goes), but various implementation guidelines seem to specify or at least permit the display of markings at the top and bottom of the page.

I think per-Space makes sense since it opens up this functionality beyond fed compliance use cases (like one @aaaronic referenced above)

Last, yes, color and text would need to be configurable (and multi-line text also handled without clipping, see https://github.com/elastic/enhancements/issues/3308)

[elasticmachine]

Pinging @elastic/kibana-stack-services

[ryankeairns]

Any insight on plans for phase 3, the global footer?

#86528 is still a hard requirement to add support for a global/fixed footer. @elastic/kibana-design, any progress or visibility on that one?

There are no existing plans in place that I'm aware of regarding the next phase. That particular issue is more about a11y improvements to be gained, in parallel. In some ways we've made progress - there are new EUI page layout components, those are wrapped by a Kibana page wrapper (that we're starting to use on empty state pages), but actually wrapping the entire app in such a way to support an always visible banner/footer has not been discussed since the current banners were put in place.

I can bring it up on the design side for more clarity on possible implementation approaches but, as with all things, prioritization on the Eng/Product side is the ultimate factor in getting it moving.

[pgayvallet]

as with all things, prioritization on the Eng/Product side is the ultimate factor in getting it moving.

cc @alexfrancoeur then (not sure if you're still directly owning this, feel free to forward the ping)

[mbarretta]

Thanks for the updates, all. The header helped, but the footer is still an ongoing requirement for a large number of federal users. Are we in the post-8.0 timeframe already?

[pgayvallet]

Are we in the post-8.0 timeframe already

Given @ryankeairns's answer, most definitely yes.

cc @thesmallestduck

[1Copenut]

Adding a bit to this issue. A customer is asking for full HTML in these customer footers so they can add ARIA markup for accessibility. I'm working to bracket the exact use case, but it sounds like this custom footer is being shown/hidden dynamically and needs markup to announce to screen readers / assistive tech that the footer has been added to the page.

[cchaos]

@1Copenut Just a note, but the header/footers have been restricted to certain content because they're also restricted/truncated to a specific height. Is the ARIA markup they were going to implement something that should just be inherent in the banner itself?

[1Copenut]

@cchaos I've asked for more clarification, but my hunch is yes, this might be something inherent to the banner. If that's the case, I'll update my comment and open a ticket in EUI as needed.

[1Copenut]

@cchaos and @ryankeairns Follow on to my previous comments from a week ago. We had a quick demo call with the customer and I was able to get verbal confirmation the customer is wanting full HTML editing capability within the custom banners. Their use case involves creating content (links, text, ARIA) that is custom to their install. EuiMarkdownFormat appears to support GitHub style Markdown only.

[ryankeairns]

@1Copenut Thanks for the input.

As an aside, we do have some existing designs for creating banners via a UI that would potentially handle links and some text formatting. I'm not certain if this sort of content could be accomplished via the existing, config file based approach. In either case, I don't believe any enhancements are currently in the scheduled at the moment, so this will await prioritization.

[alexfrancoeur]

It seems that #86528 is still a blocker to introduce footers. @clintandrewhall @rayafratkina @cchaos this is still a high priority ask for a number of customers. It'd be great to better understand the effort required to get a customizable footer banner out that matches the same functionality as the header today. I realize we have planning next week, and there are numerous priorities to discuss, but flagging this one because we've received another request for an update and I believe this work would fall under the charter of the shared UX team.

[cchaos]

If we can prioritize updates the the KibanaPageTemplate, ensuring all views use this template, then we can absolutely wrap this effort into that.

[EricPSU]

This issue seems to have lost all of its momentum. Our Federal customers still (and will always) have this requirement. It is likely preventing some Federal customers from using the product completely. We are well into version 8, is there any expectation this issue will be completed within v8? CC: @mbarretta since you understand this impact

[mbarretta]

Thanks @EricPSU from re-raising this. It is indeed an ever present requirement that is not going away. Our users need custom plugins (an increasingly complex thing to do) or waivers. It's also important to remember that this isn't a federal-only ask: there are a number linked ERs in the above history, and probably more users where the ask wasn't captured and linked.

[rayafratkina]

We have started working on white labeling in #141427. Once this is done, we will consider taking on banners.

[1Copenut]

Thank you for linking the new issue @rayafratkina.

[elasticmachine]

Pinging @elastic/appex-sharedux (Team:SharedUX)

[chais0n]

This issue seems to have lost all of its momentum. Our Federal customers still (and will always) have this requirement. It is likely preventing some Federal customers from using the product completely. We are well into version 8, is there any expectation this issue will be completed within v8? CC: @mbarretta since you understand this impact

We recently put in a support case requesting this feature for that exact reason. In addition, the feature should be configurable per space and globally. Setting a classification or company banner per space is cumbersome and more error prone. I understand that some customers will want a different banner per space. That is excellent. However, there are also many that will want one global banner per system.

We can currently set a global banner via kibana.yml, however, it requires a restart of the process to update it. That is not acceptable as it requires a service interruption to the user community just to modify a banner. The Global banner should be an option in the Kibana Global settings menu where the branding is located.

[chais0n]

In similar fashion, the Custom Notification option is nice, but I'd like to see it offered as a Global option as well. Setting a custom banner for every space to inform them of pending maintenance, outages, etc. is a bit unwieldy, even via an API. A setting for this in the Global Settings area would be greatly appreciated.

[mbarretta]

We have started working on white labeling in #141427. Once this is done, we will consider taking on banners.

@rayafratkina with #141427 completed and merged, what's the status of this ask? I'd be happy to talk through common user requirements that are driving this.

[mbarretta]

FYI @jstibbards-elastic

[TinaHeiligers]

The Global banner should be an option in the Kibana Global settings menu where the branding is located.

@elastic/appex-sharedux

[predogma]

@mbarretta The issue is still the same for multiple customers. The accessibility to updating the default global banner without having to do a restart. The ability to provide a temporary global banner across all spaces. See desc in enh here