search

elastic / kibana

Your window into the Elastic Stack
https://www.elastic.co/products/kibana
Other
19.51k stars 8.06k forks source link

Customizable Header and Footer Banners #17298

Open alexfrancoeur opened 6 years ago

alexfrancoeur commented 6 years ago

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:

Also somewhat related (albeit closed) is https://github.com/elastic/kibana/issues/4452

Some notes:

Stages

mbarretta commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

👍 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 commented 5 years ago

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

StingyJack commented 5 years ago

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 commented 5 years ago

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): image

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 commented 5 years ago

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: image

Ugly, yes, but required by some folks.

legrego commented 5 years ago

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 commented 5 years ago

Pinging @elastic/kibana-design

alexfrancoeur commented 5 years ago

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 commented 5 years ago

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

alexfrancoeur commented 5 years ago

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 commented 5 years ago

@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 commented 4 years ago

Pinging @elastic/kibana-stack-services

elasticmachine commented 4 years ago

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

elasticmachine commented 4 years ago

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

kofi-grid commented 4 years ago

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

MichaelMarcialis commented 4 years ago

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

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

alexfrancoeur commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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.

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 banners

Example: No Banner

None

Example: Danger Banner Configured

Danger

Example: Banner Options Disabled

Disabled

Proposed General Settings Breakdown

General Settings Breakdown
mbarretta commented 3 years ago

@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 commented 3 years ago

@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

image

pgayvallet commented 3 years ago

@MichaelMarcialis

Just took a look at your mockups. If the user experience feels great, there are unfortunately a lot of things our current advanced settings page (and the underlying uiSettings) does not support:

When you change the banner placement, it instantly updates/refresh the position on the screen. The advanced settings page does not support that. You need to save (and eventually reload the page) to see the changes.

When you select placement: top & bottom, the mirror message option appears. When you uncheck mirror message, the second text field for the bottom banner does too (same goes with theme->colors). The advanced settings page does not support that kind of logic/dependency between fields.

The 'banner placement' field uses a custom renderer for the possible layouts / positions of the banner. Defining per-field renderers is not supported by the advanced settings page (and, more importantly, by the uiSettings implementation)

uiSettings are per-space settings. There are no fallback mechanism implemented. The 'if this setting is not defined on current space then use a 'global' setting instead is not something uiSettings are supporting.

We don't currently have a 'color' type for uiSettings. This one could be added though.

uiSettings do not support adding icons in select type dropdowns. (Minor, but still worth mentioning)

We don't have a wyziwyg field. The closer we got would be markdown. Also note that I don't think we want to allow to use a real RTE here. plain EuiCodeEditor mode=markdown would really be preferable, for consistency and to avoid security risks related to html injection.

Possible solutions:

  1. Use uiSettings and the Advanced settings page, with all the current limitations

Basically that means:

  1. Create a specific page (and plugin) for this feature

If we want a better user experience, we can decide to create a whole new page for the banner configuration. Note that this also means that we would NOT be using uiSettings under the hood, and will be creating our own space-aware saved object type to store the banner configuration.

Pros:

Cons:

  1. Improve uiSettings and the advanced settings page to support all we need

Supporting all these changes would be massive (and something like live update is probably not even doable given that we would need to support that for al the other settings), so I don't think this is a realistic option.

@alexfrancoeur @joshdover please tell me what you think, both functionally and technically. Imho it really depends on the effort we want to spend on this. Option 1 is probably faster than option 2, but is a worse user experience. Going with 1 by assuming that we could in the future improve the advancedSettings/uiSettings capabilities could be an option too, even if I realistically don't see that being done short or mid term.

ryankeairns commented 3 years ago

@pgayvallet Thanks for the thorough explanation.

Things that come to mind while reading the options:

alexfrancoeur commented 3 years ago

First, let me preface with the fact that I think the MVP priority would be a global setting defined through kibana.yml. We'll need this regardless so administrators can enforce this, particularly for the federal team requirements. Space specific banners is a nice to have, for use cases where teams want to identify spaces by environments (qa, prod, etc.) but if I had to choose priorities, global first and space specific second. Given that there is no fall back option, my expectation is that this setting is disabled if the kibana.yml setting is configured.

Generally, for time to market, I'm in favor of option 1 that functionally meets the requirements but may not be the preferred UI/UX. To Ryans point, given the limitations with the advanced settings page and ui_settings, I think we aim for functionality over ideal UX. The limitations outlined do not effect the end results for an administrator, it just may not be as smooth of a path to get there. Given that this will likely only be configured once or twice, I think that's fine. It sounds like the only new functionality we'd need to introduce here is a color picker. From reading the comments, that sounds do-able. Worse case scenario, we have a drop down with standard colors and an option to paste in hex codes.

I'm guessing this would be more work than option 1, and I'm not sure if it's worth the effort. But is there another option (this may be a different flavor of 2) in which we could define the preferred designed by @MichaelMarcialis UX through a flyout from the advanced settings page?

mbarretta commented 3 years ago

I think the MVP priority would be a global setting defined through kibana.yml.

++ Our users have been making due with dirty CSS hacks and plugins of various quality for nigh on five years. An MVP just needs to show a persistent global header and footer banner with customizable text and basic color selects (e.g. reg, green, yellow, blue).

Used this earlier in the thread, but here again: image

Getting to the vision of the mock-ups would be awesome, of course, but let's get something to our users sooner rather than later.

pgayvallet commented 3 years ago

From a licensing standpoint, is there any advantage for the proposed options? Does the separate plugin, for example, make licensing implications any simpler?

Both options would have the actual banner display / wiring into core done from a separate plugin, so it doesn't change much I think.

But is there another option (this may be a different flavor of 2) in which we could define the preferred designed by @MichaelMarcialis UX through a flyout from the advanced settings page?

Unfortunately no. The advanced settings page just fetches all the registered settings, sort/order them by category and then display them (and handle all the update logic). We can't plug additional behaviors such as a button opening a modal without changes to the way the whole advancedSettings app works, which would not be less costly (probably more) than just creating a new management section for the banner.

pgayvallet commented 3 years ago

Getting to the vision of the mock-ups would be awesome, of course, but let's get something to our users sooner rather than later.

In that case, I guess using the advanced settings page would be fine.

We could start with bannerPlacement: off / header / footer / both bannerText: markdown editor, will apply for BOTH banners when in bannerPlacement=both bannerTextColor: colorpicker for the text color (default to black) bannerBackgroundColor: colorpicker for the border background (default to white)

@alexfrancoeur

mbarretta commented 3 years ago

It would be configurable via the kibana.yml config file using the uiSettings.overrides config properties

@pgayvallet override settings would be default for all newly created spaces, correct? For existing spaces where no values for banner* were specified, would the uiSettings.overrides value take precedence over "hard coded" defaults (e.g black text, white background)?

MichaelMarcialis commented 3 years ago

Thanks for that detailed breakdown, @pgayvallet! If it's been decided that option #1 (i.e. work within the limitations of the current advanced settings page) is the direction we wish to go, I'd be happy to provide updated mockups that reflect this. If so, just let me know and what timeframe we're working within, and I can prioritize it accordingly.

As a side question, based on our initial conversations regarding this task, the mockups also proposed reorganizing the advanced settings page. Am I correct in assuming that this reorganization is something we'd prefer to hold off on (either as a later phase or spun off as a separate issue)?

pgayvallet commented 3 years ago

@mbarretta

override settings would be default for all newly created spaces, correct? For existing spaces where no values for banner* were specified, would the uiSettings.overrides value take precedence over "hard coded" defaults (e.g black text, white background)?

Unfortunately, settings overridden in kibana.yml cannot be then edited per space.

I'm honestly unsure of the logic/reasons behind that, but this is how settings are working right now. If we need to change that, that would be way more work that what was initially estimated (cc @joshdover @alexfrancoeur)

@MichaelMarcialis

is the direction we wish to go, I'd be happy to provide updated mockups that reflect this

Let's wait until we agree on the technical implementation for that (see previous point). Also if we are to use the advanced settings page for this feature, I'm unsure mockups will provide much value, as we would not have any flexibility on how the settings are displayed (apart from labels/ section description).

Am I correct in assuming that this reorganization is something we'd prefer to hold off on (either as a later phase or spun off as a separate issue)?

That would be a separate issue yes (and handled by the kibana-app team, which is the official owner of the advanced settings page)

ryankeairns commented 3 years ago

@MichaelMarcialis we might be able to fold those advanced settings page changes in with the user personalization/settings project. It sounds like that project has the potential to generate changes in this area anyway (e.g. to communicate that user settings may override global settings, etc.)

mbarretta commented 3 years ago

we might be able to fold those advanced settings page changes in with the user personalization/settings project.

I don't know if this would be an outcome, but non-admin users should not be able to change the header/footer banner if it's to comply with NIST 800-53 controls.

mbarretta commented 3 years ago

@pgayvallet For my folks, a single value for these banners will be set at install time and remain the same for the life of the cluster (though there is a tiny chance they would need to update the text due to some change in regulation). So, setting once via kibana.xml and eschewing the UI is okay.

Polled other folks on the Fed team and haven't had anyone disagree with ^^ so far.

ryankeairns commented 3 years ago

we might be able to fold those advanced settings page changes in with the user personalization/settings project.

I don't know if this would be an outcome, but non-admin users should not be able to change the header/footer banner if it's to comply with NIST 800-53 controls.

Nope, just suggesting that we'd be working in that section of Kibana on another project.

joshdover commented 3 years ago

I'm honestly unsure of the logic/reasons behind that, but this is how settings are working right now. If we need to change that, that would be way more work that what was initially estimated

Also not sure of the historical reason for this behavior. If we absolutely needed the ability to support default values that are overrideable per-Space, we could explore adding a uiSettings.defaults.* configuration option that behaves in this way. Implmentation-wise this probably isn't a huge change, but we would need to audit all Advanced Settings to make sure this behavior is acceptable and consider the long-term maintenance/support of this feature. How we tie-in authz into this is another concern.

I'm +1 on waiting until we tackle the user settings project to determine the longer-term requirements of settings in Kibana before making such a change. I suspect we have different classes/tiers of settings that need different behaviors and I'd rather flesh out all of those requirements before adding a new feature that we have to support for the long-term.

pgayvallet commented 3 years ago

@mbarretta

For my folks, a single value for these banners will be set at install time and remain the same for the life of the cluster (though there is a tiny chance they would need to update the text due to some change in regulation). So, setting once via kibana.xml and eschewing the UI is okay.

Even if that means that all spaces will share the same banner/text ? Or do we still need to be able to specify per-space values/configuration?

mbarretta commented 3 years ago

@pgayvallet

Even if that means that all spaces will share the same banner/text ? Or do we still need to be able to specify per-space values/configuration?

Yes. For my folks the same banner would apply to all Spaces.

Per-Space settings are probably the more desired feature in general, but US Fed users need this mainly to show on what network Kibana/ES is running, which is the same regardless of Space.

alexfrancoeur commented 3 years ago

@pgayvallet let me know if it'd be helpful to sync up on requirements at all. I think generally, we need both. Options for global banners (priority 1) defined through kibana.yml or per-space banners (priority 2). I realize we cannot override global settings (or at least it's not trivial) and am fine with having one or the other for the foreseeable future.

pgayvallet commented 3 years ago

After a sync discussion with @alexfrancoeur, we came to the conclusion that the current capabilities of the uiSettings and the advancedSettings page were good enough for the initial implementation of the feature, as it answers these two use cases:

Settings

I already started a POC (https://github.com/elastic/kibana/pull/87438) where I add the settings to the management page:

Screenshot 2021-01-06 at 09 36 06

we will still need to perform the following changes, but it should be alright:

Further improvements on the way the banner configuration behaves or how the settings are displayed would need to be considered as enhancements of the advancedSettings application

Banner integration

@alexfrancoeur @mbarretta:

When I look at the issue's initial description:

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.

After a quick look at our HTML layout / structure, I can say that having the banner always visible (aka 'sticky' as the header) would cause some significant changes in our layout, and will probably require the help of the @elastic/kibana-design team, so I would just want to confirm that it would be alright to go with the not necessarily always visible solution? When I look at https://github.com/elastic/kibana/issues/17298#issuecomment-480319560, it seems that the banners needs to always be visible on the screen, which is why I ask.

It would behave the same way our Help us improve the Elastic Stack does (without the possibility to dismiss it, of course):

Screenshot 2021-01-06 at 09 57 16

Would that be alright?

Telemetry collection

Should make sure this potentially sensitive data is not reported to Telemetry

Currently, all settings changed via the advanced settings page are collected by telemetry. There is a discussion issue opened about adding an allow/block list to this collection (https://github.com/elastic/telemetry/issues/450), but it's not even prioritized yet. @alexfrancoeur I feel like this is going to be blocker for us here? cc @afharo @Bamieh

ryankeairns commented 3 years ago

After a quick look at our HTML layout / structure, I can say that having the banner always visible (aka 'sticky' as the header) would cause some significant changes in our layout, and will probably require the help of the @elastic/kibana-design team, so I would just want to confirm that it would be alright to go with the not necessarily always visible solution? When I look at #17298 (comment), it seems that the banners needs to always be visible on the screen, which is why I ask.

@pgayvallet there is a SASS mixin that we use to set the header height which includes compensation for flyouts. I'm not 100% certain this will work, but check out the Demo JS tab for this EUI docs example for how we might handle this. In essence, we use javascript to add a class to the body tag and then pass a new height value via the mixin, like so:

.euiBody--headerIsFixed--double {
  @include euiHeaderAffordForFixed($euiHeaderHeightCompensation * 2);

^ In our case, that me something like *3 when the banner is present. I've not fully tested this out, but I did try jamming a larger value into the existing mixin use for the Kibana header using:

@include euiHeaderAffordForFixed(200px !important);

Anyway, just some initial thoughts. Happy to help tinker on this further with @MichaelMarcialis

Oh, and I have no idea what to do about the footer just yet 😄

Mdnkhan commented 3 years ago

When will this feature will be available for the users?

ryankeairns commented 3 years ago

When will this feature will be available for the users?

We're aiming for version 7.12

mbarretta commented 3 years ago

@pgayvallet

Speaking only for my users, the persistent (always visible) display on both header and footer is a requirement.

choobinejad commented 3 years ago

+1 the banner should be always visible on header and footer in order to meet NIST and similar requirements.

pgayvallet commented 3 years ago

Speaking only for my users, the persistent (always visible) display on both header and footer is a requirement.

I guess that settles it.

@ryankeairns @MichaelMarcialis

there is a SASS mixin that we use to set the header height which includes compensation for flyouts.

Yea, I thought about just adding additional classes when the header and/or footer banners are present. However, the banner's text is user inputed, meaning that the height of the banners will (ideally) be variable, which make me think we may not be able to get away with just a new fixed-height style for the header, and would be forced to change the whole layout to be reactive to the actual height of the header (and also of the new footer, which is something we don't have atm)

However tbh, I don't think there is any pure-css technique to have variable-height header and footers with the scrollbar still on the full height of the body/container, so this would be all but trivial to implement. We could probably get away with a fixed-height banner with v-aligned content inside it, if we limit / restrict the content to fit into one or two lines. I don't really like it, but it seems like the most pragmatic solution by a large margin.

Oh, and I have no idea what to do about the footer just yet

If we go with fixed-height banners, we will just have to apply the same trick by adding classes on the body/container when the footer banner is present to add padding-bottom compensation to the body when when footer banner is present. We should be able to just mimic the euiHeaderAffordForFixed mixin, wdyt?

The current mixin is:

@mixin euiHeaderAffordForFixed($headerHeight: $euiHeaderHeightCompensation) {
  // The `&` allows for grouping inside another specific body class.
  // When not applied inside of another selector, it simply renders with the single class
  &.euiBody--headerIsFixed {
    padding-top: $headerHeight;

    // When the EuiHeader is fixed, we need to account for it in the position of the flyout
    .euiFlyout,
    .euiCollapsibleNav {
      top: $headerHeight;
      height: calc(100% - #{$headerHeight});
    }
  }
}

The only tricky part here is that when both footer + header are present, the rules on .euiFlyout, .euiCollapsibleNav are going to conflict because we would ideally need something like

 .euiFlyout,
    .euiCollapsibleNav {
      top: $headerHeight; // ok if two mixins (only in header mixin)
      bottom: $footerHeight; // ok if two mixins (only in footer mixin)
      // the following line one will cause problems if we use two distinct mixins
      height: calc(100% - #{$headerHeight} - #{$footerHeigh}); // would ideally need to substract both header and footer height...
    }

But maybe having the flyout / collapsive navs overlaps on the footer is acceptable? In which case, we could just have the footer mixin impact the padding-bottom of the body.

Else, we will need to create a whole new mixin that takes both header and footer height in parameters. But that doesn't seems like very difficult either, and could be the correct solution, wdyt?

@mixin euiHeaderFooterAffordForFixed($headerHeight: $euiHeaderHeightCompensation, $footerHeight: $ourFooterHeightCompensation) {
  // The `&` allows for grouping inside another specific body class.
  // When not applied inside of another selector, it simply renders with the single class
  &.euiBody--headerIsFixed {
    padding-top: $headerHeight;
    padding-bottom:  $footerHeight

    // When the EuiHeader is fixed, we need to account for it in the position of the flyout
    .euiFlyout,
    .euiCollapsibleNav {
      top: $headerHeight; 
      bottom: $footerHeight;
      height: calc(100% - #{$headerHeight} - #{$footerHeigh}); 
    }
  }
}

Not sure the mixin should be provided by EUI or just done in Kibana styles though, as it's rather specific to our needs?

@mbarretta @choobinejad

what is the approximate length of the text content that would be put inside the banners? I'm guessing it shouldn't be too long and that having banners with a fixed height would be acceptable?

choobinejad commented 3 years ago

@pgayvallet I'd suggest typical values in the 20-50 character range. I can't think of a reason to need more than 150 characters. Fixed height is perfectly fine too.!

mbarretta commented 3 years ago

I'll disagree with @choobinejad. I've seen text that's gone from one side of the screen to the other, so more than 150 characters I think. I do agree that a single line of text should be fine for starters.