Skip to content
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

[TSVB] Use default Kibana palette for split series #62241

Merged
merged 10 commits into from Apr 20, 2020

Conversation

wylieconlon
Copy link
Contributor

@wylieconlon wylieconlon commented Apr 1, 2020

Release note

TSVB colors now match other visualizations in dashboards by default.

Before:
Screenshot 2020-04-01 14 56 42

After:
Screenshot 2020-04-01 16 46 23

Closes #62219
Closes #62209

Migration note

A migration has been added targeting 7.8.0. The behavior of the migration is to look for TSVB visualizations where the split_color_mode was default, and to explicitly set the value to gradient, which was the previous default. This migration will continue to work in the future because the split_color_mode can no longer be missing.

Checklist

@wylieconlon wylieconlon added release_note:enhancement Feature:TSVB TSVB (Time Series Visual Builder) Team:Visualizations Visualization editors, elastic-charts and infrastructure v8.0.0 v7.8.0 labels Apr 1, 2020
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-app (Team:KibanaApp)

Copy link
Contributor

@majagrubic majagrubic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great change, Wylie 🙇‍♀
I tested this in Chrome on Mac on "ecommerce" index pattern - works as expected. Tested in light and dark mode. Haven't tested in other browsers. Regarding the code itself, I'm not too familiar with color calculations code, but overall looks good to me.

@@ -163,6 +169,8 @@ export const TimeSeries = ({
const stackAccessors = getStackAccessors(stack);
const isPercentage = stack === STACKED_OPTIONS.PERCENT;
const key = `${id}-${label}`;
// Only use color mapping if there is no color from the server
const finalColor = color ?? colors.mappedColors.mapping[label];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: can we use ternary operator here, it's a bit more readable.

@timroes timroes requested a review from markov00 April 2, 2020 14:35
Copy link
Contributor

@flash1293 flash1293 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested in chrome and looks much better to me 👍

It's a little strange that the rainbow color theme is now applied on the client while the gradient is applied on the server - could you create a technical debt issue to clean that up in a later iteration? Now it's implicitly using the rainbow theme on the client when the server doesn't provide a color, I can see this causing confusing behavior in a few years from now.

Just a side note: As long as the theme isn't changed in the UI, the TSVB request doesn't contain a value for it - this means we are now implicitly switching a lot of existing TSVB visualizations from gradient to rainbow (if I'm not mistaken). Not sure whether that's intended or not - I have a slight preference for keeping existing visualizations in their current state, but I'm fine with both ways. If that was intended take my approval :)

@wylieconlon
Copy link
Contributor Author

wylieconlon commented Apr 2, 2020

@flash1293 Thanks for the note, that is exactly the kind of case I'm interested in getting feedback on. It sounds like I could fix this by always sending the color, even if it is the default.

@flash1293
Copy link
Contributor

@wylieconlon sounds good to me, I'm not sure how awkward it is to place this in the current code structure.

Copy link
Member

@markov00 markov00 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't want to fully block this PR, but I'd like to highlight the fact that if you have saved a visualization with the default color scheme in TSVB in a previous version, you will be suddenly render a visualization with a completely different set of colors and this, from my point of view is a breaking change.
Let's me show the example: this is a TSVB chart with rainbow colors saved before this PR.
Screenshot 2020-04-03 at 14 59 32

After applying this PR the TSVB chart will render as:
Screenshot 2020-04-03 at 15 30 55

I think this can be considered a visual breaking change.

My suggestion is to add a saved object migration that migrate a default rainbow configuration into a set of custom user configured colors for that visualization to keep the preexisting colors to every preexisting saved visualization. For every new chart is fine to apply the new color scheme

@flash1293
Copy link
Contributor

Good idea with the migration, @markov00 - we can also fix the breaking change switching from gradient to rainbow implicitly I mentioned above the same way - seems like the cleanest option.

I'm not sure whether it's necessary to keep the colors exactly the same for existing visualizations - as there is no explicit mapping from label to color like in standard visualizations, it's anyway not guaranteed to get the same colors for a visualization - e.g. when a filter is active, a color could get mapped to different series any time.

@wylieconlon
Copy link
Contributor Author

@markov00 Echoing something that @flash1293 wrote, I originally did not think a migration would be useful because users have never been able to customize the rainbow palette. I made the choice to put up a PR which replaces the behavior of "rainbow" with different behavior because I think of this as fixing a bug, not as a breaking change.

What you're proposing seems to be that instead of replacing the current behavior, I should add a new behavior. For example:

  • Kibana palette (new default)
  • Rainbow
  • Gradient

This change is possible, but it means that we can't get rid of the existing rainbow palette. Would appreciate some more feedback about whether to continue with the approach in this PR, or to add instead of replacing.

@markov00
Copy link
Member

markov00 commented Apr 3, 2020

The idea of adding the Kibana Palette as default is a better solution. What if we keep the rainbow one on the dropdown, but make it not selectable from TSVB dropdown.
It's selected by default if you visualization used it before, but if you change it to Kibana or Gradient and save the visualization you can't select it anymore. Only a manual change in the saved object will let the user go back to the original rainbow, or they can reenable it from a kibana.yml configuration.
This basically help us to get rid of all old rainbow palette making it unavailable for new vis, but doesn't create a breaking change for the existing one

@markov00
Copy link
Member

markov00 commented Apr 3, 2020

Also remember that we should move toward the EUI visualization color palette in 8.0 that is slightly different from the one currently used in kibana

@wylieconlon wylieconlon requested a review from a team as a code owner April 3, 2020 21:39
@wylieconlon wylieconlon changed the title [TSVB] Standardize rainbow color palette [TSVB] Use default Kibana palette for split series Apr 3, 2020
@wylieconlon
Copy link
Contributor Author

@markov00 It's a bit more complicated to hide parts of the UI conditionally, like you have suggested. Can you take another look at this change which adds the new behavior and a migration?

@wylieconlon
Copy link
Contributor Author

@elasticmachine merge upstream

@wylieconlon
Copy link
Contributor Author

@elasticmachine merge upstream

@wylieconlon
Copy link
Contributor Author

@elasticmachine merge upstream

@wylieconlon wylieconlon requested a review from a team April 16, 2020 20:14
},
};
}
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@elastic/kibana-app-arch This migration needs codeowners approval

Copy link
Member

@markov00 markov00 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, tested locally and works correctly.
The migration keeps the "old" used default to avoid any color breaking change.

Copy link
Contributor

@streamich streamich left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just looked at AppArch code changes, approving to unblock. The changes look fine to me, but if you want a thorough review, then maybe @ppisljar could take a look on Monday.

@wylieconlon
Copy link
Contributor Author

Thanks @streamich for the review to unblock! I think this PR has had enough review, but doesn't need to be merged today. So I will wait until Monday evening to merge, giving @ppisljar a chance to review- but I consider it optional.

Copy link
Member

@ppisljar ppisljar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

migration looks good.

@wylieconlon
Copy link
Contributor Author

@elasticmachine merge upstream

@kibanamachine
Copy link
Contributor

💚 Build Succeeded

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

@wylieconlon wylieconlon merged commit 7e3de56 into elastic:master Apr 20, 2020
@wylieconlon wylieconlon deleted the tsvb-colors branch April 20, 2020 16:43
wylieconlon pushed a commit to wylieconlon/kibana that referenced this pull request Apr 20, 2020
* [TSVB] Rainbow palette shares colors with dashboard

* Add migration

* Add charts as NP dependency

Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
wylieconlon pushed a commit that referenced this pull request Apr 20, 2020
* [TSVB] Rainbow palette shares colors with dashboard

* Add migration

* Add charts as NP dependency

Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>

Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
gmmorris added a commit to gmmorris/kibana that referenced this pull request Apr 21, 2020
* master: (30 commits)
  Migrate vis_type_table to kibana/new platform  (elastic#63105)
  Enable include/exclude in Terms agg for numeric fields (elastic#59425)
  follow conventions for saved object definitions (elastic#63571)
  [Docs]Adds saved object key setting to load balancing kib instances (elastic#63935)
  kbn/config-schema: Consider maybe properties as optional keys in ObjectType (elastic#63838)
  Fix page layouts, clean up unused code (elastic#63992)
  [SIEM] Adds recursive exact key checks for validation and formatter
  [Maps] Migrate remaining maps client files to NP (except routi… (elastic#63859)
  [Maps] Do not fetch geo_shape from docvalues (elastic#63997)
  Vega doc changes (elastic#63889)
  [Metrics UI] Reorganize file layout for Metrics UI (elastic#60049)
  Add sub-menus to Resolver node (for 75% zoom) (elastic#63476)
  [FTR] Add test suite metrics tracking/output (elastic#62515)
  [ML] Fixing single metric viewer page padding (elastic#63839)
  [Discover] Allow user to generate a report after saving a modified saved search (elastic#63623)
  [Reporting] Config flag to escape formula CSV values (elastic#63645)
  [Metrics UI] Remove remaining field filtering (elastic#63398)
  [Maps] fix date labels (elastic#63909)
  [TSVB] Use default Kibana palette for split series (elastic#62241)
  Ingest overview page (elastic#63214)
  ...
jloleysens added a commit that referenced this pull request Apr 21, 2020
…t-node-pipelines

* 'master' of github.com:elastic/kibana: (32 commits)
  Move authz lib out of snapshot restore (#63947)
  Migrate vis_type_table to kibana/new platform  (#63105)
  Enable include/exclude in Terms agg for numeric fields (#59425)
  follow conventions for saved object definitions (#63571)
  [Docs]Adds saved object key setting to load balancing kib instances (#63935)
  kbn/config-schema: Consider maybe properties as optional keys in ObjectType (#63838)
  Fix page layouts, clean up unused code (#63992)
  [SIEM] Adds recursive exact key checks for validation and formatter
  [Maps] Migrate remaining maps client files to NP (except routi… (#63859)
  [Maps] Do not fetch geo_shape from docvalues (#63997)
  Vega doc changes (#63889)
  [Metrics UI] Reorganize file layout for Metrics UI (#60049)
  Add sub-menus to Resolver node (for 75% zoom) (#63476)
  [FTR] Add test suite metrics tracking/output (#62515)
  [ML] Fixing single metric viewer page padding (#63839)
  [Discover] Allow user to generate a report after saving a modified saved search (#63623)
  [Reporting] Config flag to escape formula CSV values (#63645)
  [Metrics UI] Remove remaining field filtering (#63398)
  [Maps] fix date labels (#63909)
  [TSVB] Use default Kibana palette for split series (#62241)
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:TSVB TSVB (Time Series Visual Builder) release_note:enhancement Team:Visualizations Visualization editors, elastic-charts and infrastructure v7.8.0 v8.0.0
Projects
None yet
8 participants