Easy way to customize Kibana logo and theme

[elasticmachine]

Original comment by @tbragin:

The request to customize Kibana logo and some aspects of the chrome color scheme w/o the need to patch the code continues to come up in the field.

We've discussed this type of functionality potentially being a good candidate for X-Pack, so filing here (instead of the Kibana repo), for tracking purposes.

[elasticmachine]

Original comment by @Stacey-Gammon:

Copying over my thoughts from LINK REDACTED

Give users the ability to create and customize Kibana and/or Dashboard themes.

My original idea was for Dashboard themes, but as @uboness pointed out, that idea overlaps with Kibana level themes. My only thought about mixing the two is that your color choices might be different for a dashboard then say, for console in dev tools. Imagine if your company colors are black and orange - that might work okay for viewing a visualization but would make your eyes bleed for editing a bunch of text in console.

If we had two separate notions of the themes, we could do something like the below, where the 'Theme base' is a kibana level theme. Then the dashboard specific theme is almost like an override of that theme. I could see taking this idea even further and having panel level settings/themes, which would override both kibana and dashboard level themes.

[elasticmachine]

Original comment by @Stacey-Gammon:

Copying over @cjcenizal's comment on LINK REDACTED:

As @Stacey-Gammon pointed out, there are some overlapping ideas here. I think they generally fall into two buckets:

Kibana customizability

This is the ability to change aspects of Kibana's appearance (e.g. color palette, font, logo, icons) to suit the customer's tastes/needs. During a meeting with Blizzard (LINK REDACTED) earlier this year, they requested this kind of functionality:

They would like to be able to make Kibana look more Blizzardy, e.g. change logo and set a background image. Change colors. Makes it feel like the dashboard is theirs. They care a lot about that kind of stuff when it comes to their internal tools.

LINK REDACTED

We should look into how other companies provide this functionality, e.g. Atlassian's Confluence, competitors like Grafana. I have a feeling that the simplest option would be to clearly identify the CSS which can be overridden by customers and provide a clear guide on how to tweak the CSS.

Document-specific theme controls

If I understand correctly, the general idea is to surface controls in the context of a specific document (e.g. dashboard, vis, saved search) which allows a theme to be chosen which is specific to that particular document.

Here's my line of thought on this:

1. Documents can be viewed within the context of Kibana, or within their own context (i.e. when embedded or within a report).
2. Changing a document's theme inside of the context of Kibana has the potential to look jarring if the two themes are different.
3. If a user customizes Kibana to have a certain theme, I think that means they want that theme to apply to everything viewed within the context of Kibana, including documents.
4. If a user views an embedded document, they may want to change the theme to one that fits better within the embedded context.

So, it seems like we should think of "theme" as a user preference. When a user is using Kibana, the user controls the theme for the entire app. And if a user is viewing an embedded document, we should surface a control that lets them change the theme locally.

When you're working on a document in Kibana, maybe you can specify the default theme. It would be nice if it was easier to view the embedded version of document, e.g. by right-clicking the embed link and opening it in a new tab.

[elasticmachine]

Original comment by @Stacey-Gammon:

How would the UX flow work if we only allowed changing a dashboard theme in embedded mode? Would there be a button/icon/link in the embedded mode view, so that anyone viewing it could click it and up pop a modal dialog? Or would it be part of the options when creating an embedded link? If so, I can see it being tough to visualize how it would look if your choices weren't immediately reflected in the dashboard below. That flow feels a little weird to me, having a theme only for embedded mode, but maybe.

How would a full-screen view fit into with the model where we only allow theme customization on embedded view? I can see someone wanting to specify a dashboard theme for full screen mode. For example, a dashboard that is on at all times on a TV in an office. There is a lot of similarity between a full screen and embedded mode, maybe they will be one and the same.

A document theme may clash with a kibana wide theme, but a user would have to go out of their way to change it, and if they do, maybe it's intentional? Having a dashboard specific theme would let users create dashboards with different themes, which wouldn't be possible with a kibana-wide theme only. Look for instance at the colors on our different product logos. Kibana is teal and pink, Elasticsearch is yellow, blue and teal, Cloud is green and blue, etc. If we allowed dashboard specific themes, we could color a dashboard slightly differently for each product. Other companies may like this flexibility. Or you could color a dashboard that tracked errors more glaring, with red and yellows, and a dashboard that was informational differently.

++ on an easier way to open the embed link.

[elasticmachine]

Original comment by @cjcenizal:

Good point about full-screen view. I think it's similar enough to embedded view that perhaps we can think of them as both the same kind of "document-mode" view. In this case, we would have a chrome that's specific to this kind of view, which would surface specific controls, e.g. the theme selection control. Maybe it's a dropdown? Maybe it opens a modal? It really depends on what kind of content we need to surface (e.g. name of theme, preview of theme)... I'm not sure.

From your example about presenting dashboards with themes that reinforce their role, I think I understand the value proposition of being able to have different dashboards displayed inside of Kibana with different themes.

But, I think I may be biased against this because I have a feeling it could easily grow out of control, both in terms of maintenance and in terms of usability. From a maintenance perspective I can see it being really difficult to design a CSS system in such a way to allow this granular level of customization. From a usability perspective, I can see one user preferring one theme but another user preferring another theme, and the users becoming frustrated because they have no way to customize the appearance on a local level. So I think my position is driven by a desire to avoid these issues by simplifying the system, even if it means sacrificing some benefits.

[elasticmachine]

Original comment by @Stacey-Gammon:

Yea, I understand your fear of feature creep and maintenance overhead.

What about offering just a few style options for dashboard only and not allowing them to be saved as separate theme objects? I actually initially implemented a small POC this way - added a panel border color option under the 'Options' tab, using ng-style to put the style inline. Then the idea grew, but maybe it should be kept simple.

The idea was sparked by the comments in this ticket. It seems like borders were removed very intentionally, but clearly some people want them back. I don't know the backstory on why borders were removed, but if we had an option for it, maybe that would make everyone happy? Or maybe we just need to improve the UI and bring borders, or some sort of separation between visualizations, back.

[peterskim12]

Another use case for theming at the Kibana-instance level instead of just the dashboard level is to clearly indicate the environment the Kibana instance is tied to. e.g. a green-themed Kibana for production, a blue-themed Kibana for staging.

[elasticmachine]

Pinging @elastic/kibana-design

[elasticmachine]

Pinging @elastic/kibana-platform

[Randy-312]

I simply want to modify the Kibana logo to one of my internal Business Unit logos. As I'm using ECE, and have multiple clusters, it will be helpful to me to know which Cluster I'm in, and very useful for my Business Units who can now brand their UI with their logo.

Yes, the color pallete modifications for the left nav would be helpul to have also.

[yus4u]

Change the Kibana Theme/Colours/Logo is an easy way to distinguish in which Environment or Company you are working on. Especially if you manage different companies with different environments.

[timroes]

Another often asked use-case for this would be changing the default font and font-size (#2207), that would make sense being configurable via theming.

[justintime4tea]

What would be nice is an interim solution whereby it's somehow documented (officially or a forum) how to currently patch replace the logo and themes. I've been analyzing the code base for both Kibana and eui to come up with a way to do this. I'm starting small and trying to change just the discovery chart color but it's proven incredibly elusive (7.5).

[thekofimensah]

Yes I agree with above, I've gone through so many comments on the forums and nothing clear has come out. Plzz help with this!! Or just keep it in the same place :p

[ManuelFFF]

Any idea when this will become available for regular users?

If it wont' be available from Kibana interface config menu or config file for now, at least an easy-to-follow guide with steps to edit the Logos and Theme colors in Kibana 6.x and 7.x would be greatly appreciated.

Thank you

[francisco-hoo]

The easiest way that I found to do that @ManuelFFF is run an instance of Kibana and via Browser Dev Tools get the class/element identifier and then w/ grep --color -nr "content" src/ find the source files to change. Change the UI (Theme Colors, Icons) from 6.x to 7.x it's a difficult cause it's two different major releases. A lot of things change from 6 to 7.

[ManuelFFF]

@francisco-hoo , thank you for your advise. Unfortunately it's been difficult for me to apply that to Kibana 7.8.1.

I had found a Frankenstein combination of workarounds to finally get Kibana 6.8.9 customized (logos, colors and texts). Now I am testing recently installed Kibana7.8.1, but I am not making any progress on finding the right files to edit, or I am not doing it the right way.

ELK Team: If there is no feature yet available to make it easy for users to customize Kibana from the web UI, could we have at least a list of the files we need to edit this time? It shouldn't be so hard for the developers team to provide such details, since they maintain and update the code.

Thanks

[snide]

This issue is not easy, mostly because Kibana is a long running project with quite a few css layers and several dependencies. In general, the vast majority of these styles are consolidated through our outside design library: EUI which is included as a dependency in Kibana. It is well documented and you'll find ample info on theming there. You'll find that Kibana imports coming form EUI through Sass variables (that support theming), which are imported in Kibana's own core sass files. It gets more complicated though when you realize those sass vars are only part of the story. EUI also generates a JSON dist which includes the sass vars in something Javascript can read. What does this mean? That means it's probably easiest to fork EUI, make your theme changes there, then replace the dependency in Kibana. Avoiding that and making variable changes in Kibana's sass directly though will at least show you how the system works, if being imperfect.

The logos are easily greppable by searching in the Kibana repo for the logo. Currently I see 42 references you'd need to change. It's used almost always with EuiIcon which supports custom svgs. Again, you'd need to rebuild Kibana, since you're touching the source. I can not vouch for any licensing or trademark issues doing something like that may incur, I'm not familiar enough with the license, and do not endorse it. I'm only a designer speaking to the code itself.

Likely this will remain a difficult feature for many reasons, and I would not be surprised if the links I mention in this comment change over time. Kibana's frontend layer is always changing and it will remain difficult for people unfamiliar with the code to unwind the styling layer. It continues to improve, but is challenging given Kibana's roots (angular and bootsrap) and meteoric growth in code base size (which is now mostly react, sass and css-in-js) and contributors. It is not something we plan on documenting fully, and is not something we support in any way (though as mentioned in the original issue is something we might one day add). In general though, it should always remain the case that the best way to theme Kibana is by changing EUI directly.

I want to doubly remind folks that go down this path. Making these kinds of code changes often make it very difficult to upgrade later. Again, that is due to the velocity of the codebase and the constant improvement of Kibana's internals, which itself is often tied to outside libraries. Put another way, EUI's codebase is very stable, but Kibana's usage of it is often in flux minor to minor.

All that said, this is a feature I'd like to see eventually and feel we're constantly working towards. We'd love to see it as easy as picking colors in the browser. Changing the logo is likely easier and could happen sooner.

[ManuelFFF]

Hi @snide ,

I really appreciate your deep and detailed explanation regarding white labeling in Kibana. Although this does not solve the need I have, I am grateful for the time you have dedicated to sharing your knowledge and opinion.

I imagine that needy users like me will continue struggling with the code as far as knowledge allows us, to try to adapt the outer layer, according to our needs, of this wonderful product that is Kibana.

Like you, I look forward to seeing the day when after installing Kibana, I can simply go to the Advanced Configuration section and there is a Theming section, where with just a few clicks, you can upload your own logo, the name of your company , or select the matching color scheme.

Thank you

[rkbennett]

@snide, is this the only way of achieving this now that hacks have been deprecated as an option for writing a plugin to override colors and logos? Is there a plan to have something achieve the same function that hack plugins used to be able to in pre 7.7? This seems like, generally, a far less efficient way of doing this than hacks were.

[snide]

@rkbennett It's not that hacks are deprecated, it's that hacks are hacks, and likely will always need to change. We currently don't build Kibana towards this specification. Likely any css hacks you set up can still work, if you adjust them against the new code, but as mentioned before, anytime you overwrite the source in this manner, you'll need to shift with the internals as they shift.

[pgraca-38]

Hi. Is there any available plugin to achieve the customization? Thx

[ZimM-LostPolygon]

The way I was able to do it is to put Kibana behind an Nginx proxy that injects custom JS and CSS. It certainly is a hack as well, but arguably a hack that's easier to maintain.

[nerophon]

Perhaps we might break this issue down into manageable chunks? For example putting a configurable logo next to ours here and there in the app as a first step? To me it seems like a win-win from all angles. If we can make simple progress like this, we'll satisfy the majority of requests without causing us excessive code-strain :)

[Flixi555]

Make the elastic logo on the top left exchangeable for a custom one and I think most customers will be happy.

[lizozom]

I've made an example third party plugin (outside of my ES work) that does just that. Feel free to contribute \ clone and modify!

https://github.com/lizozom/custom-kibana-logo

@pgraca-38 @Flixi555 @ZimM-LostPolygon @Randy-312

[githubshirkevikas]

@lizozom : I tried using above plugin code but image and text is not getting appeared on Login page. Any help?

[lizozom]

@githubshirkevikas should be working now

https://medium.com/@lizka.k/an-easy-way-to-customize-kibana-ui-2cca0cdb9253