-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
[Meta] Dashboard appearance #14125
Comments
Speaking strictly from an engineering point of view, I think this one might be the most future-proof because it introduces the least amount of complexity into the code. I think this will let us implement theming and dashboard-customization logic without worrying about breaking BWC, right @stacey-gammon? This does hinge on whether @snide and other designers think they can make the borders look good, though. 🎨
I wonder how much of that really was due to the borders specifically, and how much of it was due to the general look-and-feel of Kibana 4 dashboards. They had a lot of clunky chrome overall, and the contrast between the background color and the panel background color would have been sufficient to distinguish panels from one another without the borders. I think we may have just over-corrected in K5. |
After chatting with the design team, the best long term solution we've decided on (for now) is K7 is close and has dramatically improved our CSS structure. A dark theme was generated with ~12 LOC. It's very close to becoming the reality, and is the most extensive option. We will document the process so users who do not like our default styling can create their own plugin to modify it. It can even be dashboard specific. For the short term, this means we shouldn't introduce any UI controls to customize the appearance. The best thing we can do is pick "the best UI for the majority of our users". Now we just have to decide whether that's with borders, or without borders. |
++ agree @cjcenizal, I think that's our best option for the short term. |
To clarify, is the proposal to add borders back into Kibana in 6.x? Fundamentally changing the appearance of all dashboards in a minor version seems really risky to me. It's one thing for a user to not like the way dashboards look in the next major, but it's an entirely other thing for a user to not like the wash dashboards look in the next minor. It's important that we don't make it harder or less appealing for people to upgrade through minor versions wherever possible since we don't backport security fixes within a major beyond the last minor or two. I wouldn't say this would be a breaking change, as we've never treated visual changes as breaking changes before, but I don't think it should be taken lightly either. The change is technically low risk, but it's very high impact. |
Hmm, well we still have the option of putting this in 6.0, right? |
No, this would be a 6.0 feature freeze sort of change. The only stuff that can go into 6.0 is stuff that we would ship in a patch release if necessary. |
Personally, I think if we feel confident about a UI improvement then that confidence should justify shipping it in a minor release. I think if the improvement really does make the UI better then any users who dislike it because it's a change to the status quo will eventually come around and make the upgrade. |
@cjcenizal I agree with your sentiment, but I don't think we're anywhere close to knowing whether this change would make the UI better. We thought no-borders was better for dashboards, and that was backed up by our internal usage and in our conversations with users, but there are some users that refuse to upgrade from 4.6 to 5.x because of that change. I don't see how the current situation is different, only we're talking about the possibility of making that change in a minor version instead of a major. |
@epixa I agree... my point is that I think we need to see a new bordered dashboard design before making a decision. We should place our confidence in actual designs, instead of in abstract ideas like "borders" vs. "no borders", since it's the implementation that really matters. I'm pretty sure whatever Dave and the other designers come up with will knock the socks off what we had previously. |
@cjcenizal ++ |
I know I'm late to the party 🎉 🎈 🍰 and it looks the like group has already come to a consensus, but I wanted to share my thoughts. I think no matter what design decision we make, some users are going to prefer dashboards without borders / visualization segmentation and others clearly prefer it. No matter which decision we make, a group of users will be unhappy. I imagine this will likely be the case for K7 as well. If we want to give users the option to easily customize this aspect of their dashboards without creating a plugin, I think we can combine The way I see it we can offer a configurable option that enables this new "theme" and you can still enable/disable dark mode separately. I agree with @epixa's concerns. While this isn't a breaking change, it's a fairly significant change to the UI. Given that there are a number of users (#9701, discuss) who will not switch to K5/K6 because of the way we style dashboards, offering as a configurable option (turned off by default) will allow us to implement the style changes in a way that is least impactful to end users. Not to mention, we'll have a better idea of which view is preferred for K7. |
Chose a path and went with it in #14708, so closing this. The path was a combination of a simple new option (use margins), but one that also changes the background color, so we get K7 designs with the flip of a switch, without introducing two new themes (though implementation wise, that's kind of what it is), and no need to support a custom background color since we choose it for you, but give you more than just borders (margins and borders and shadows!) |
When Kibana 4 was released, we heard from users that didn't like the cluttered feel, with the panel borders and margins. When we released Kibana 5, we removed those, and found another group of users who vastly preferred the border and margin look.
Goals
Options
Panel border on/off toggle #13948
Pros: Simple to implement, solves the main complaint of not being able to tell where one visualization ends and another begins.
Cons: Doesn't give the user the best UI. Feels like a mirco solution (distinguish between panels) rather than a full solution (provide beautiful dashboards for all use cases).
Give users the ability to customize the dashboard style themselves via UI input controls (#9243)
Pros: Covers most possible use cases. Puts control in the users hands.
Cons: Users can create ugly dashboards. Slippery Slope for number of attributes to allows users to customize (where does it stop? Do we eventually let them use their own custom style sheets?).
Add a extra built-in themes (#14123)
Pros: We have control over how they look, so we know all themes will meet certain guidelines.
Cons: Will it be sufficient? How many themes will we have to add? What if users want to add their own themes? Pluggability?
Add borders back into the default style
Pros: Extremely simple solution.
Cons: Risk hearing negative feedback from original group of users who did not like the Kibana 4 look and feel.
Give users the ability to customize the dashboard style themselves via plugins that modify the CSS.
Pros: Covers all possible use cases. Most extensive solution. Puts control in the users hands.
Cons: Users can create ugly dashboards. Fragile - requires us to have a stable CSS interface. Security issues?
This one is probably a no-op due to our current CSS infrastructure.
Let users set background color and margins only (Limited version of #9243)
Pros: People who found Kibana 4 to be cluttered can keep 0 margins with a white background. People who want differentiation can set a different background color and add margins. Essentially the smallest amount of #9243 that would (hopefully?) resolve both contending view point.
Cons: Is this inline with our final vision? Or just an ad-hoc solution, similar to a border toggle? What is the ultimate solution?
cc @elastic/kibana-design @elastic/kibana-sharing @alexfrancoeur
The text was updated successfully, but these errors were encountered: