Kibana: 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 https://github.com/elastic/kibana/issues/4452

[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

[elasticmachine]

Pinging @elastic/kibana-platform (Team:Platform)

[elasticmachine]

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

[kofi-grid]

This would be super helpful also if users want to paste Google Analytics code so they can track how their users use Kibana

[MichaelMarcialis]

@alexfrancoeur: While doing some early thinking about this feature, I had a handful of questions that came to mind.

• Banner positioning: Should the header/footer banners be sticky-positioned (i.e. always visible and stuck to the top and bottom of the user's viewport) or static-positioned (i.e. when I scroll down from the top, the header banner scrolls out of view)?

• Content: Is the requirement that we simply have a single text string input that users can customize for these banners? Or two inputs; one for a banner title and one for an optional description? I'm not sure how long we are expecting the banner text to be, and the comments above make it sound like it could go either way.

• Markdown: There is the mention above about optionally supporting Markdown syntax. Is this a requirement? If so, am I correct in assuming that a Markdown-supported field would be limited in terms of what would be allowed (no images, etc.)?

• Mirror or independent: Assuming the user selects to show both the header and footer banners for a given space, should the same content be mirrored across both banners (i.e. the header banner text and color selection is the same as the footer banner text and color selection)? Or should these two banners be independent of one another and allow for differing text and color selections?

• Settings location: I assume the settings for this feature should be located in the Kibana advanced settings page. Is this correct?

Let me know if you'd prefer to have a quick Zoom session to chat about this. Thanks!

[alexfrancoeur]

Thanks for the follow up questions @MichaelMarcialis! Answers to the best of my ability are inline. @mbarretta since you work with our end users who are requesting this functionality, mind weighing in as well?

Banner positioning: Should the header/footer banners be sticky-positioned (i.e. always visible and stuck to the top and bottom of the user's viewport) or static-positioned (i.e. when I scroll down from the top, the header banner scrolls out of view)?

I think ideally, these are stick and always visible on screen.

Content: Is the requirement that we simply have a single text string input that users can customize for these banners? Or two inputs; one for a banner title and one for an optional description? I'm not sure how long we are expecting the banner text to be, and the comments above make it sound like it could go either way.

I think a single text string would be enough for the purposes of this use case

Markdown: There is the mention above about optionally supporting Markdown syntax. Is this a requirement? If so, am I correct in assuming that a Markdown-supported field would be limited in terms of what would be allowed (no images, etc.)?

I think markdown would be helpful for minor formatting, but agree that things might get out of hand. I could see adding an emoji with a warning sign useful. I think for an initial implementation, we could probably skip formatting / markdown support given where the configurations should probably live. More details in the settings location answer below.

Mirror or independent: Assuming the user selects to show both the header and footer banners for a given space, should the same content be mirrored across both banners (i.e. the header banner text and color selection is the same as the footer banner text and color selection)? Or should these two banners be independent of one another and allow for differing text and color selections?

I think we can keep them independent. If the administrator would like them mirrored, they can copy and paste the text. Or we can have a checkbox or something that allows for mirroring on the other banner and disables config.

Settings location: I assume the settings for this feature should be located in the Kibana advanced settings page. Is this correct?

I think there will need to be two configurations. The first, would be through the kibana.yml file. This would introduce a global header and footer option that cannot be changed by anyone. I also think it'd be great to support space specific banners. I could see this especially being useful to identify teams or different environments while in Kibana. What I do think we'll need, is a configuration option in the kibana.yml file that disables configuring space-specific banners in favor of a global one that cannot be removed or adjusted.

Hope this helps, let me know if it's easier to connect live or if you have any questions.

[legrego]

I think there will need to be two configurations. The first, would be through the kibana.yml file. This would introduce a global header and footer option that cannot be changed by anyone. I also think it'd be great to support space specific banners. I could see this especially being useful to identify teams or different environments while in Kibana. What I do think we'll need, is a configuration option in the kibana.yml file that disables configuring space-specific banners in favor of a global one that cannot be removed or adjusted.

We can accomplish this today using the uiSettings.overrides kibana.yml setting. For example, if we had globalHeader and globalFooter advanced settings, then administrators who wished to disable the per-space customizations could set:

uiSettings.overrides:
   globalHeader: Some global header text goes here, and cannot be changed
   globalFooter: Some global footer text goes here, and cannot be changed

I think it would just be a matter of documenting this as an option for administrators who wished to disable the per-space setting.

[mbarretta]

Banner positioning: Should the header/footer banners be sticky-positioned (i.e. always visible and stuck to the top and bottom of the user's viewport) or static-positioned (i.e. when I scroll down from the top, the header banner scrolls out of view)?

I think ideally, these are stick and always visible on screen.

Yes, sticky and always visible

Content: Is the requirement that we simply have a single text string input that users can customize for these banners? Or two inputs; one for a banner title and one for an optional description? I'm not sure how long we are expecting the banner text to be, and the comments above make it sound like it could go either way.

I think a single text string would be enough for the purposes of this use case

Yes, single text string, no title. The "title" could be done via a \n

DEV ENV
Nothing here really matters, anyone can see

Markdown: There is the mention above about optionally supporting Markdown syntax. Is this a requirement? If so, am I correct in assuming that a Markdown-supported field would be limited in terms of what would be allowed (no images, etc.)?

I think markdown would be helpful for minor formatting, but agree that things might get out of hand. I could see adding an emoji with a warning sign useful. I think for an initial implementation, we could probably skip formatting / markdown support given where the configurations should probably live. More details in the settings location answer below.

Think I threw out MD as a means of giving basic formatting like bold, underline, and italics. It isn't a requirement for my users, AFAIK, but I have seen styling used.

Mirror or independent: Assuming the user selects to show both the header and footer banners for a given space, should the same content be mirrored across both banners (i.e. the header banner text and color selection is the same as the footer banner text and color selection)? Or should these two banners be independent of one another and allow for differing text and color selections?

I think we can keep them independent. If the administrator would like them mirrored, they can copy and paste the text. Or we can have a checkbox or something that allows for mirroring on the other banner and disables config.

Yes, independent

Settings location: I assume the settings for this feature should be located in the Kibana advanced settings page. Is this correct?

I think there will need to be two configurations. The first, would be through the kibana.yml file. This would introduce a global header and footer option that cannot be changed by anyone. I also think it'd be great to support space specific banners. I could see this especially being useful to identify teams or different environments while in Kibana. What I do think we'll need, is a configuration option in the kibana.yml file that disables configuring space-specific banners in favor of a global one that cannot be removed or adjusted.

yml config makes it easier to programmatically bootstrap environments, I think, which is a good thing. My customers would be using the same banner for all spaces, so having it and/or needing it done per-space would be annoying.

That said, space-specific settings would make it more broadly usable, I think. So, @alexfrancoeur 's approach would help everyone.

[MichaelMarcialis]

Hey, gang. @alexfrancoeur and I have been working on design concepts for this task, and I'd like to share our current progress. Below, I've linked to a Loom video that runs through the design and the thinking behind it. Links to the Figma mockups and clickable prototypes can be found below as well.

• Video review
• Mockups
• Clickable prototype

If you have any questions or feedback, don't hesitate to let me know. If you all feel that we should get together for a quick meeting to review and discuss further, I'd be happy to throw something on the calendar. Thanks!

Example: Placement Options

Example: No Banner

Example: Danger Banner Configured

Example: Banner Options Disabled

Proposed General Settings Breakdown

[mbarretta]

@MichaelMarcialis quick question on this since I didn't notice it in the mock ups: is it possible to configure the banner color along with the banner text?

[MichaelMarcialis]

@MichaelMarcialis quick question on this since I didn't notice it in the mock ups: is it possible to configure the banner color along with the banner text?

Hey, @mbarretta! Yes, in the latest version of the designs and prototype, when the user has selected the "Custom theme" option for the "Banner theme" field, additional fields for both "Text color" and "Background color" will reveal themselves for further customization.

An example can be found here, in the Figma mockups: https://www.figma.com/file/zOTqotG64gobMCxddIrrnx/Awaiting-Dev-Banners-MVP?node-id=75%3A6722