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

[Lens] update default legend size to medium #130336

Conversation

drewdaemon
Copy link
Contributor

@drewdaemon drewdaemon commented Apr 14, 2022

Summary

Resolve #129474

Defaults legend size to medium instead of "auto" and gently removes the user's ability to select the "auto" option.

Also migrates visualizations to use string-based instead of numerical values for legend sizes (e.g. 'small' instead of 80). This will make the saved objects more readable and make the code more maintainable as well as increasing our flexibility to change the definitions of the legend sizes in the future in a uniform way.

Testing

"Medium" legend size for new visualizations

Create some of the following types of visualizations and assert that the legend size is medium for each of them.

Lens: pie/mosaic/(any other partiion type), heatmap, XY
Visualize: pie, area, histogram, horizontal_bar, line, heatmap

"Auto" preserved for existing visualizations

Import these dashboards and for each visualization:

  1. assert that it retains "Auto" as its legend size
  2. change legend size to something else
  3. make sure "Auto" is still an option in the list
  4. save visualization
  5. navigate away from editor
  6. navigate back to editor
  7. make sure "Auto" has disappeared from the list

Checklist

Delete any items that are not applicable to this PR.

@drewdaemon drewdaemon force-pushed the 129474/default-legend-size-to-fixed-migrations-strategy branch from 10cc455 to bacdef6 Compare April 15, 2022 16:32
@drewdaemon drewdaemon changed the title [Lens] update default legend size to medium - yes-migration strategy [Lens] update default legend size to medium Apr 19, 2022
…' of github.com:andrewctate/kibana into 129474/default-legend-size-to-fixed-migrations-strategy
"fieldFormats",
"discover",
"esUiShared",
"visualizations"
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Adding visualizations as a required bundle is the salient change here

Comment on lines 30 to 38
export const LegendSizes = {
AUTO: 0,
SMALL: 80,
MEDIUM: 130,
LARGE: 180,
EXTRA_LARGE: 230,
} as const;

export const DEFAULT_LEGEND_SIZE = LegendSizes.MEDIUM;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This seemed like the right place to put these for usage in all the vis_types. Still open to input.

Copy link
Contributor

Choose a reason for hiding this comment

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

@drewdaemon
Copy link
Contributor Author

@elasticmachine merge upstream

kibanamachine and others added 3 commits April 19, 2022 13:15
@drewdaemon
Copy link
Contributor Author

@MichaelMarcialis as mentioned here in the original issue, we want to remove the ability to select "Auto" as a legend size. However, we are keeping existing visualizations that are using "Auto" the same until the owner has updated the legend size.

I currently have this set up so that when the user of a pre-existing visualization selects a legend size other than "Auto," the "Auto" option disappears from the dropdown. @timductive pointed out that this could be annoying or confusing.

Do you have any input on how we can safely go about turning off the "Auto" option once the user has selected a different size?

Screen.Recording.2022-04-19.at.4.18.47.PM.mov

@drewdaemon
Copy link
Contributor Author

@elasticmachine merge upstream

@MichaelMarcialis
Copy link
Contributor

@MichaelMarcialis as mentioned here in the original issue, we want to remove the ability to select "Auto" as a legend size. However, we are keeping existing visualizations that are using "Auto" the same until the owner has updated the legend size.

I currently have this set up so that when the user of a pre-existing visualization selects a legend size other than "Auto," the "Auto" option disappears from the dropdown. @timductive pointed out that this could be annoying or confusing.

Do you have any input on how we can safely go about turning off the "Auto" option once the user has selected a different size?

@andrewctate: Perhaps we could delay the removal of the "Auto" option in these situations until after the user has 1) changed to a size other than "Auto" and 2) has saved their visualization. Once saved (likely at an ideal state for the user), then we can feel more comfortable in removing that auto option. Thoughts?

On a side note, would it be possible to add flanking prepend/append icon buttons to the selector to decrease/increase the currently chosen size respectively? I didn't recommend it initially, due to the inclusion of the "Auto" option, but once that option is removed, I think we can safely add in such shortcut controls. We take a similar approach in the metric visualization text size options, and though it would be a good pattern here as well. Just let me know if you'd prefer that spun off into a separate issue instead.

image

@drewdaemon
Copy link
Contributor Author

@MichaelMarcialis that plan sounds good to me.

Let's take the updated UI controls as a separate issue in the name of smaller, more focused changesets.

…' of github.com:andrewctate/kibana into 129474/default-legend-size-to-fixed-migrations-strategy
@flash1293
Copy link
Contributor

flash1293 commented May 4, 2022

It seems like the migration doesn't work correctly for xy charts (both lens and agg based). I created a dashboard with by value and by reference panels in 8.3 and the legend size looks like this:
Screenshot 2022-05-04 at 15 35 19

Not how it seems to work fine for pies (the last row are treemap visualizations)

@drewdaemon
Copy link
Contributor Author

@flash1293 that display issue should be resolved now

@@ -26,3 +26,13 @@ export const VisualizeConstants = {
EDIT_BY_VALUE_PATH: '/edit_by_value',
APP_ID: 'visualize',
};

export const LegendSizes = {
AUTO: 0,
Copy link
Contributor Author

Choose a reason for hiding this comment

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

In the spirit of future-proofing, can we think of any case where someone would actually want a legend size of zero? We could use a different number like -1 to denote "auto" if we think zero should be left available.

cc: @flash1293

@drewdaemon drewdaemon requested a review from flash1293 May 4, 2022 16:30
@flash1293
Copy link
Contributor

Tested and this works fine now. About

In the spirit of future-proofing, can we think of any case where someone would actually want a legend size of zero? We could use a different number like -1 to denote "auto" if we think zero should be left available.

@markov00 made a good point about this offline - what about storing an enum in the saved object instead (auto/small/medium/large) and only mapping that to a pixel number in the toExpression function? It would make problems like 0 vs auto I encountered above much harder to miss and give us additional flexibility later on (allowing pixel value OR enum string).

@drewdaemon
Copy link
Contributor Author

@markov00 made a good point about this offline - what about storing an enum in the saved object instead (auto/small/medium/large) and only mapping that to a pixel number in the toExpression function? It would make problems like 0 vs auto I encountered above much harder to miss and give us additional flexibility later on (allowing pixel value OR enum string).

This was a great idea. I was experimenting with auto as a special string case with the other sizes staying numbers, but it got messy. Making them all strings is much more consistent and has the other benefits ^^ as well!

@drewdaemon
Copy link
Contributor Author

@flash1293 @Kunzetsov I'm starting to wonder if we should push the legend-size-to-pixel translation one level deeper than each visualization's toExpression function. Do you think it makes sense to have the chart expression functions accept the legend size strings (auto, small, medium, etc) instead of a pixel number?

Seems like there's precedent for this with the legendDisplay and legendPosition arguments.

    legendDisplay: {
      types: ['string'],
      help: strings.getLegendDisplayArgHelp(),
      options: [LegendDisplay.SHOW, LegendDisplay.HIDE, LegendDisplay.DEFAULT],
      default: LegendDisplay.HIDE,
      strict: true,
    },
    legendPosition: {
      types: ['string'],
      default: Position.Right,
      help: strings.getLegendPositionArgHelp(),
      options: [Position.Top, Position.Right, Position.Bottom, Position.Left],
      strict: true,
    },

An added benefit is that we wouldn't have to split the current visualization config interfaces (example) into two, one for the saved objects and one for the expression arguments.

@flash1293
Copy link
Contributor

Sounds good to me - it makes sense to keep the abstraction layers aligned if possible.

@drewdaemon
Copy link
Contributor Author

@elasticmachine merge upstream

@flash1293
Copy link
Contributor

@elasticmachine merge upstream

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 and works as expected, LGTM

@kibana-ci
Copy link
Collaborator

💚 Build Succeeded

Metrics [docs]

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id before after diff
expressionHeatmap 100 103 +3
visualizations 344 350 +6
total +9

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id before after diff
expressionHeatmap 80.7KB 80.8KB +91.0B
expressionPartitionVis 44.1KB 44.2KB +83.0B
expressionXY 55.8KB 55.9KB +86.0B
lens 1.1MB 1.1MB +326.0B
visDefaultEditor 142.4KB 142.4KB +1.0B
visTypeHeatmap 7.4KB 7.5KB +80.0B
visTypePie 8.9KB 9.0KB +80.0B
visTypeXy 60.3KB 60.5KB +165.0B
total +912.0B

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id before after diff
expressionHeatmap 14.0KB 14.3KB +304.0B
expressionPartitionVis 21.9KB 22.7KB +756.0B
expressionXY 27.5KB 27.8KB +303.0B
lens 32.5KB 32.6KB +154.0B
visDefaultEditor 21.1KB 21.3KB +124.0B
visTypePie 8.1KB 8.0KB -102.0B
visTypeXy 43.2KB 43.3KB +141.0B
visualizations 45.9KB 46.5KB +559.0B
total +2.2KB
Unknown metric groups

API count

id before after diff
expressionHeatmap 104 107 +3
visualizations 365 371 +6
total +9

History

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

@drewdaemon drewdaemon merged commit 57597f7 into elastic:main May 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:skip This commit does not require backporting Feature:Lens release_note:deprecation Team:Visualizations Visualization editors, elastic-charts and infrastructure v8.3.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Lens] Default legend size to fixed