Remove support for dashboard dark themes in favor of Kibana wide dark theme

[stacey-gammon]

New with 7.0 we’ll be introducing Kibana Wide theming support which has been something users have been looking forward to for a while (#6786) - everything in dark theme! Yay! On the flip side, this throws a little bit of a wrench in with how we currently handle dark theming which is per dashboard.

We have decided to remove support for per dashboard themes in 7.0.

Note that we do still wish to eventually add support for the ability to customize dashboard appearance (#9243), but it will not be something for 7.0, and is not on any roadmap plan yet.

Possible phases:

• [7.0] Support Kibana wide dark theme as an advanced setting, per space
• [?] Support Kibana wide dark theme as a per user setting (when we have support for RBAC)
• [?] Support the ability to customize dashboard appearance.

cc @rayafratkina @alexfrancoeur @snide @epixa @elastic/kibana-sharing

[JacobBrandt]

Dark theme is more than a per space preference. Why add something that removes the current behavior and then add it back it in and call it an enhancement later?

[?] Support the ability to customize dashboard appearance.

This shouldn't be a phase. It is the current functionality today. It shouldn't have been too hard to add the global setting for a space and keep the current behavior.

[stacey-gammon]

Thanks for the feedback @JacobBrandt. We didn't reach this conclusion lightly, there was a lot of back and forth, but now I see that it would have been more useful to add some of those discussion points to this issue, so I'll drop in some of the notes from those discussions to show our reasoning behind taking this step:

What to to with Dashboard Themes when we have Kibana Wide Themes

Background

New with 7.0 we’ll be introducing Kibana Wide theming support which has been something users have been looking forward to for a while - everything in dark theme! Yay! On the flip side, this throws a little bit of a wrench in with how we currently handle dark theming which is per dashboard. We have to decide whether to remove support for per dashboard themes, or somehow implement them side by side.

Limitations with Kibana Themes in 7.0

Since we don’t have per user settings yet, Kibana theming in 7.0 will be an advanced setting that is per space. Anyone with write capabilities will be able to change the theme for all users. We discussed possibly using local storage to simulate per user settings but it’s just yet another approach that needs to be fully thought out with an already full timeline, so it’s unlikely to happen.

Option 1: Keep Dashboard Themes

Dave, Court and I discussed about a path that would let us keep both. Implementation wise, this is doable, though creates a bit awkward of a UX. The way we’d make it work is to switch the entire page over to the dashboard’s chosen theme. If the Kibana Theme is dark, and the user opens a dashboard with light theme, they see light theme. If they then navigate to Discover, they will be back in dark theme.

We would change the UI to offer the user three options now, instead of the historical on/off flag: default, light, or dark. A choice of default would mean the dashboard would be in whatever theme the Kibana theme is in, and dynamically change along with it.

Implementation wise, this would require a migration step. We decided the most unintrusive way to migrate would be to convert existing dashboards in dark theme to the dark theme option, and dashboards with dark theme off to the default option.

Option 2: Remove support for Dashboard Themes, but leave the door open.

The other option is to simply remove support for dashboard themes and mark it as a breaking change. We remove the option under the options menu.

Under the hood, we would not do a migration step to get rid of the dark theme flag. This leaves us the option of continuing with Option 1 depending on what we hear from the community. We also have the option of taking our time and implementing a more thoroughly thought out way to support per dashboard customization, not simply dark or light theme, but page background color, etc (more along the line of how canvas works).

Reasons to keep Dashboard Themes around

Per dashboard theming may alleviate issues where users in the same space disagree on what the theme should be. User 1 creates their own dashboards in dark theme, while User 2 creates their dashboards in light theme.
Still, a poor replacement for per user theming which is on the horizon. What if both User 1 and User 2 need to work on the same dashboard?
Users may be choosing dashboard themes based on the environment they will eventually be embedded in. A dark theme dashboard embedded in a dark themed web page, and vice versa. Without per dashboard theme support, all dashboards will either be dark or light.
We can offer a workaround via spaces, though it’s not ideal.

Reasons to remove support for Dashboard Themes in 7.0

Less implementation steps. Support for dashboards can be done but there is very little time for anyone to work on it, and it really could only be started on after platform completes Kibana Themes. This does not leave much, if any, time to implement a way to keep Dashboard Themes around.
We don’t know yet how many clients truly want per dashboard theming. Removing it in 7.0 will give us time to hear from the community and make a more informed decision for 7.x. This worked well for Dashboard Only Mode filtering. Given the extra breathing room from not implementing in the same release, we were able to make a more informed decision to put resources towards a better, more flexible solution, spaces. If we had rushed ahead, it could have created more work for the Spaces implementation.

If the community does express an interest in dashboard customization we can take our time to decide the next best move. We can continue with Option 1 proposal if it’s time sensitive, or we can come up with a better solution that doesn’t have the UX awkwardness.

We briefly discussed some options here: an embed mode that created an embed object with it’s own unique set of parameters (could include theming) which points to a dashboard template.
A theme option that is configurable but would not be stored with the object.
[Note none of the above were fully thought out, just tossing around some quick ideas]

Conclusion

We decided that Option 2 was the best path forward. It doesn’t paint us into any corner and is more realistic given our resources.

Risks

The risks are that some users won’t upgrade to 7.0 because they can’t control individual dashboard themes. We hope this risk is limited only to 7.0, as if it becomes a major issue, we can announce our plans to bring back dashboard themes in 7.1.

Hope this helps shed some light on why we chose this step, and thank you for speaking up since that is a very important part in what we decide our next move is!

[JacobBrandt]

@stacey-gammon Wow, thanks for sharing that. I thought about both options you presented but I'm still surprised and confused that this happened. The dark theme for the whole app is nice but not at the expense of a current feature users have for customization. I know I won't change your minds and I'm ok with that but here was my thought on this.

We've been waiting for more dashboard customization features already for a long time. Here are a few discussions.

#3668
#9575
#16898

There is obviously a lot more than that but these felt appropriate to the discussion.

Then there's the fact that some embedded dashboard capabilities were lost because of upgrading to 5.6 when the dashboard edit mode feature came into play.

#16766

I would argue that for most users Kibana's dashboard view of visualizations is why people use it. Grouping visualizations together for analytical purposes. To see more features get removed from the dashboard is heart breaking.

[snide]

@JacobBrandt I'd be interested to hear about your use case. Specifically, what are you trying to get out of theming support? Are you looking for per user settings, per dashboard settings, or per installation settings. Forgetting the implementation, what are you looking for a user to do and why.

As an example. If you wanted per dashboard settings, why do the dashboards need to look different from dashboard to dashboard from a color perspective for your usage?

People use Kibana in totally different ways, so it's useful for us to know the stories of why you need the features rather than just the implementation details.

Thanks!

[JacobBrandt]

@snide Sure thing. I would say ultimately it would be great to have a per user setting. But what I'm looking for in the mean time is to not lose the current per dashboard setting that exists today that has an easy ability to change the theme by the user. Let me explain why.

We have lots of users. A small handful of them are dashboard creators. The majority are consumers who use the dashboards provided to them or ones they search for. Some of these consumers don't mind an embedded view and some of them don't mind seeing all of Kibana. You mentioned that users have varying ideas of which theme looks best and that is true for us. However, there are some things that remain out of their control, like room brightness, which can negatively impact the way the dashboard looks so it's not always a one theme fits all for a dashboard because not all consumers of the dashboard have the same environment. Also there is no way to tell which of the 1400+ dashboards a consumer will throw up on their display for the day.

Currently, if my dashboard creator shares a dashboard with someone that consumer can change the theme to light or dark. It is even possible for them to change the theme on an embedded dashboard today because it only takes a simple url change to switch to light or dark. So a provider (some website) of the embedded dashboard could still give users the ability to change the theme by adding a toggle that changes this value in the url. The user of the dashboard gets control of what the theme looks like for their workstation/room requirements/etc. This makes sense as they are the ones using it.

A dashboard of ours can be used by over 200+ people and right now each person can have a theme they want. With this change the owner of the space, instead of the consumer of the data, gets to control the way it looks. Before 5.6 our users even had the ability to rearrange those dashboards but that got limited to only non embedded views because you have to be in edit mode to do that now. I only wanted to mention this last bit because it shows how we keep losing dashboard customization and how it affects our users.

Hope that helps.

[snide]

Thanks for the detailed response. The basics from what I can read is that per user settings are important, not per dashboard settings. Meaning. If we can give a user a toggle to switch the display at will (regardless of whether it is saved for others), that would satisfy your needs. Two users might see the same dashboard and want to view it in opposite themes.

This aligns with my own assumptions, that ultimately we're talking about subjective, personal preferences, and we should attempt to provide this stuff to the user, not the application (even though the application/space might provide the initial default).

Sorry for the roadabout questioning. I'm just making sure that having specific dashboards be specific themes and that they should change as you go from dashboard to dashboard is likely not a real thing. It's more that users themselves want to view dashboards however they want and not be tied to some global setting for that dashboard (or all dashboards).

This is basically me a way for me to say that in a perfect world were development was instant this should be stored on the user, not the dashboard (as it was previously) or on the space (as it is now).

[JacobBrandt]

Yep. We're on the same page. This decision itself is subjective and had personal preference. That happens, I was only sharing thoughts not to persuade but to inform and be informed. It definitely helped so thank you @stacey-gammon @snide.

[timroes]

I will close this, since the dark themes from dashboard has now be removed in favor of the global theme. But please feel free to continue discussion on this ticket if you want, just want to indicate that the issue itself is done.