-
Notifications
You must be signed in to change notification settings - Fork 8.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Customizable Header and Footer Banners #17298
Comments
@alexfrancoeur Looks like a lot of these linked issues should instead be linked to https://github.com/elastic/x-pack-kibana/issues/4953 - thoughts? |
@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. |
👍 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. |
In the context of spaces, I think we can re-describe the request as:
|
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. |
Regarding the comments around Spaces:
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:
|
I could buy that argument, as long as we don't need this functionality without Spaces. If the spaces plugin is explicitly disabled ( |
Pinging @elastic/kibana-design |
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. |
@alexfrancoeur @mbarretta is this at a point that somebody from the design team should do a mockup(s) of the banner? |
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. |
@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) |
Pinging @elastic/kibana-stack-services |
#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. |
cc @alexfrancoeur then (not sure if you're still directly owning this, feel free to forward the ping) |
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? |
Given @ryankeairns's answer, most definitely yes. |
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. |
@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? |
@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. |
@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. |
@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. |
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. |
If we can prioritize updates the the KibanaPageTemplate, ensuring all views use this template, then we can absolutely wrap this effort into that. |
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 |
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. |
We have started working on white labeling in #141427. Once this is done, we will consider taking on banners. |
Thank you for linking the new issue @rayafratkina. |
Pinging @elastic/appex-sharedux (Team:SharedUX) |
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. |
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. |
@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. |
@elastic/appex-sharedux |
@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 |
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:
not necessarily always visible.Also somewhat related (albeit closed) is #4452
Some notes:
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 #87438Phase 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
configurationPhase 4: Pending Kibana page layout shared components #86528, add support for footers for the space specific configuration
The text was updated successfully, but these errors were encountered: