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] Add styling options for x and y axes on the settings popover #71829

Merged
merged 25 commits into from
Aug 11, 2020

Conversation

stratoula
Copy link
Contributor

@stratoula stratoula commented Jul 15, 2020

Summary

Closes #68314 and #68313. Adds styling options for both x and y axes.

This PR adds more settings to the settings popover.
Screenshot 2020-07-21 at 1 12 01 PM

By default, the tick labels for x and y axes are enabled while the gridlines ones are disabled.
Update : We decided to go with the gridlines enabled by default

User can also hide the titles of x and y axes by switching off the corresponding switch. If the switch is on, then the user can also overwrite the title of each axis.
Screenshot 2020-07-21 at 1 13 57 PM

Note: I assume that if the user has both left and right y axes, then the y-axis title setting overwrites both. For this reason, only one y-axis title appears on the screenshot above. If we want to give the possibility to the user to change both titles then it needs an extra setting and makes things a little bit more complicated.

Checklist

Delete any items that are not applicable to this PR.

What to test

  1. Check that your previous Lens Charts render correctly
  2. Create a new Chart, check that the defaults are correct, change the settings and check that everything works properly
  3. Add extra layers
  4. Check the suggestions
  5. Add lens charts to a dashboard and check that everything works fine
    ....

@stratoula
Copy link
Contributor Author

@AlonaNadler @cchaos I would like your feedback on the styling settings of X-axis for Lens. It has to do with this issue. Here is a demo:

Lens_-_Elastic

and here is a screenshot of the settings:
Screenshot 2020-07-15 at 12 24 40 PM

What do you think? Do you have any suggestions regarding the UI?

@stratoula
Copy link
Contributor Author

@elasticmachine merge upstream

@cchaos
Copy link
Contributor

cchaos commented Jul 15, 2020

Thank you for adding these options! A couple first impressions.

  1. When creating toggles/checkboxes always make sure the label is in the positive tense. Meaning, always use "Show" not "Hide". Using "hide" makes users have to think in a double-negative and so it's harder for them to parse.
  2. It would be great not to have to two completely separate sections for x vs y axis configurations which will most likely be the same. So instead, let's use button groups to allow them to select x vs y vs both and if none are selected, it hides for both. I'll create a mock
  3. The placement for these with the missing values is fine for now, but soon we'll want to start thinking about how we might want to break these all down into categories for individaul toolbar buttons.

@stratoula
Copy link
Contributor Author

Thank you @cchaos for your feedback! Totally agree with the third, was thinking the same. Waiting for your mock, I understood your idea but the mock will help a lot! And thanx for the tip about the positive tense :)

@cchaos
Copy link
Contributor

cchaos commented Jul 15, 2020

Here's a mock for you. I can help figure out the configuration for the toggle within the label since it's not an easy or established pattern yet.

Screen Shot 2020-07-15 at 11 11 21 AM

@stratoula
Copy link
Contributor Author

That was quick :D Will start working on this and let you know if I encounter any problem

@AlonaNadler
Copy link

Thanks @stratoula, I checked the PR

  • Why do you add another place to have a label for the x-axis? I find it unnecessary and since we already have it feels wrong to add it in another place

@cchaos
Copy link
Contributor

cchaos commented Jul 15, 2020

I had the same discussion in my head @AlonaNadler , but what ends up happening is that it gets complicated with multiple x and y axis configs. Take the example from @stratoula's gif:

Screen Shot 2020-07-15 at 14 33 30 PM

There's 2 x-axis and 2 y-axis configs each with their own "Label" input. How does the chart decide and how does the user know which label will be shown on the chart?

So I see two options for handling this.

  1. The "Label" inputs in the config popovers simply allow the user the change the label of the config in the sidebar. The first of which will be the default axis title unless the user changes this title in the Settings popover from the toolbar.
  2. Remove all "Label" inputs in the config popovers and only having the axis title inputs in the Settings popover from the toolbar.

Edit Though I'm now realizing that the config labels also label them in the legend, so I don't think we can go with route 2.

@cchaos
Copy link
Contributor

cchaos commented Jul 15, 2020

Eventually we really need to be able to edit everything directly on the chart, like double-click the axis title to change it.

@flash1293
Copy link
Contributor

Good call, Caroline - I will create an issue for this in elastic-charts as I think it's not possible at the moment.

@stratoula stratoula added the WIP Work in progress label Jul 16, 2020
@stratoula
Copy link
Contributor Author

@elasticmachine merge upstream

@stratoula
Copy link
Contributor Author

@elasticmachine merge upstream

@stratoula
Copy link
Contributor Author

@elasticmachine merge upstream

@stratoula stratoula changed the title [Lens] Add styling options for x axis on the settings popover [Lens] Add styling options for x and y axes on the settings popover Jul 21, 2020
@stratoula
Copy link
Contributor Author

@elasticmachine merge upstream

@stratoula
Copy link
Contributor Author

@elasticmachine merge upstream

@cchaos
Copy link
Contributor

cchaos commented Aug 4, 2020

@AlonaNadler And I talked about this today and we're both in the mindset that we need to stop separating styling concerns from their configuration. This means that any settings under the toolbar needs to be Chart-type specific and not affected by the configuration. The split causes too much dissonance and makes the settings harder to find.

Yes, this may cause some complexity on the engineering side as to how to handle some specific cases, but I've outlined how this would be handled in this mock:

https://www.figma.com/proto/VonTZ0hxwASCvWHrWdnXRQ/Layers-panel-and-Aggs?node-id=418%3A531&viewport=868%2C650%2C0.7183288931846619&scaling=min-zoom

(Use your arrow keys to scroll through the screens)

Essentially, there are 2 main ideas:

  1. Use the Display name from the configuration panel as the axis label. Yes, this is different from what we've talked about earlier in this PR, but it's just not logical to have a completely separate input for this label. We should keep the logic the current way we have it in Lens, where the top axis display name is what is actually displayed on the chart.
  2. Move all the axis-specific display options (shown as "extras" in the mocks) into the "Format & style" tab of the configuration popover. The same idea maintains here where the top configuration is basically the one that takes precedence. In order to get all grid lines turned off, they have to turn them off of each Y-axis config. This is most explicit and clear to users.

Those ideas make it also a lot easier to understand how to handle the styling if there is both a left and right axis. The current PR does not handle this situation.

@stratoula
Copy link
Contributor Author

@elasticmachine merge upstream

@flash1293
Copy link
Contributor

flash1293 commented Aug 5, 2020

@cchaos We went through the new UI setup and I have some concerns with this approach:

  • How does the user specify to hide the axis titles in this case? Deleting the display name for all of the dimensions? In that case it would show up like this in the side bar:

Screenshot 2020-08-05 at 09 52 25

  • I'm not sure whether this logic is clear to users. Example scenario:

    • User configures chart with three different y axis dimensions, all mapped to the left axis
    • User decides to remove the tick labels for the left axis. (1. point of confusion: Why should they start looking at the dimension level for this setting? There are three dimensions all mapped to the same axis)
    • Let's say they know this setting is part of each dimension. They go to the first dimension and uncheck "tick labels". Nothing happens (2. point of confusion)
    • Let's say they figure out they have to go to the second and third dimension to finally disable it - this sounds frustrating to me. The same would happen if they want to hide the axis title given we find a way to do so (see first point)
  • This is a fundamental problem that also happens in other places, because a setting is stored in multiple places, making it redundant. Another scenario:

    • User has a chart with three y axis dimensions again, all mapped to the left axis
    • User wants to show gridlines
    • As the first setting takes precedence, this is easy to do - they just have to go to the first dimension and enable grid lines there
    • Later, user decides they don't need the first of the three y dimensions, and deletes it. Grid lines disappear as well, because they were tied to the first y dimension. User has to configure it again
  • In some cases the user has to go from the dimension they currently configure to another dimension to configure styling. Example:

    • User configures a chart with one y dimension
    • User decides to add a second y dimension
    • User changes the color of the second y dimension to something else
    • User sees the grid lines configuration and decides that would make sense for the current chart as well
    • User enables grid lines - nothing happens
    • To actually enable the grid lines, the user has to go to the first y dimension and enable grid lines there to actually get them, even though they already had the grid line settings right in front of them. This seems counter-intuitive to me - showing these controls as part of the current y dimension makes the users think they are about the current y dimension (but this isn't the case)
  • It feels like this approach is optimizing for the case of separate axes for each dimension. In this special case it makes indeed a lot of sense to have the axis configuration as part of the dimension editor. But this is a special case that should rarely be chosen because it's often not the right choice to begin. I don't think we should sacrifice a clear hierarchy of configuration objects just for optimizing for this special case.

Alternatives

I think there is an alternative to this to ease the tension which is going into the other direction - move settings which are applied on a chart level into the toolbar and specifically make them chart level settings. IMHO this is clearer because it doesn't have the problem of specifying the same setting in n places while just applying a single one with all others not taking effect.

  • Make "Axis settings" a toolbar button on its own to make it easier to find
  • Do not take the first metric name as label for the y axis if there are multiple dimensions - this is rarely the right choice. Instead hide the y axis label if there are more than two y dimensions and rely on the legend to label them. Then let the user override the chart-global y axis label in the toolbar. I've seen this behavior in other tools as well.
  • Let users specify the right and the left y axis label and provide separate controls for grid lines for left and right axis. These separate settings can be hidden as long as there is just a single y dimension. As soon as there are two, we can show both with a little info text about the second set of settings only being applied if there are dimensions mapped to both axes

My concerns are not about the technical complexity (it's easy to implement "first one takes precedence"), it's about worrying we put controls in a place they don't belong. I might have not considered something here, happy to discuss this further.

@AlonaNadler
Copy link

AlonaNadler commented Aug 5, 2020

How does the user specify to hide the axis titles in this case? Deleting the display name for all of the dimensions? In that case it would show up like this in the side bar:

The complexity by adding another place to set axis label doesn't worth the benefit to allow remove the axis labels (which is a niche)
How about if a user on the click explicitly on the space button as the display label it can show as empty. This way the y-axis label is always the first series on the y-axis

Later, user decides they don't need the first of the three y dimensions and deletes it. Gridlines disappear as well because they were tied to the first y dimension. User has to configure it again

minor in my opinion

chart setting is a good idea in my opinion and we can add the grid lines there but users shouldn't have to go to chart setting to name the x-axis y-axis labels - which is a common operation. There are many different chart configurations we can have add to chart configuration in the future.

@flash1293
Copy link
Contributor

flash1293 commented Aug 5, 2020

chart setting is a good idea in my opinion and we can add the grid lines there but users shouldn't have to go to chart setting to name the x-axis y-axis labels - which is a common operation. There are many different chart configurations we can have add to chart configuration in the future.

That’s exactly how it works on this PR (as far as I understood) - if the override on chart level isn’t used, the labels of the first x and y dimensions are used. I would be fine with this behavior (especially as it’s compatible with the current UI of Lens.

So they wouldn’t have to switch the menu to do this in most cases, but there is a top level setting they can use for full control (e.g. hiding it completely). We could put it in an advanced section as well to prevent it from being used often.

Another option I can think of is to not allow the user to overwrite the axis labels from the chart level settings, only hiding them (as an "advanced feature" used from time to time). Labels are always tied to a dimension, global settings are specified in the chart settings. What do you think @AlonaNadler ?

@flash1293
Copy link
Contributor

After syncing offline with @AlonaNadler we came to the conclusion doing the discussed changes is not worth the effort at the moment and we will stick with top level axis options for 7.10 given the existing experience with defining axis labels via the first dimension will be kept for now.

@cchaos given this are you fine with the current state of the PR?

@elastic elastic deleted a comment from elasticmachine Aug 10, 2020
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.

This looks mostly good to me, I have some technical nits

setYaxistitle(yTitle);
}, [xyTitles]);

const [tickLabelsVisibilitySettings, setTickLabelsVisibilitySettings] = useState({
Copy link
Contributor

Choose a reason for hiding this comment

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

Why are you storing all of these settings both in local state and in the frame state (via setState)? When you call setState, the frame will re-render the toolbar and value will be adjusted. We should try to avoid local state whenever possible.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If I remember correctly, without localState is extremely slow, have to check it again though

Copy link
Contributor

Choose a reason for hiding this comment

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

That's a good point, and an interesting solution.

For the buttons it should be irrelevant, for the label in the dimension popover we used this workaround (basically debouncing the state update):

const LabelInput = ({ value, onChange }: { value: string; onChange: (value: string) => void }) => {

It keeps the ugly performance optimization in a single place, so the top level form component doesn't have to deal with it.

Copy link
Contributor Author

@stratoula stratoula Aug 10, 2020

Choose a reason for hiding this comment

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

I have removed the localstate from gridlines and ticklabels

@kibanamachine
Copy link
Contributor

💚 Build Succeeded

Build metrics

page load bundle size

id value diff baseline
lens 857.3KB +14.0KB 843.2KB

History

To update your PR or re-run it, just comment with:
@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.

LGTM, works as expected. Thanks for working on this!

@flash1293
Copy link
Contributor

@cchaos Could you have another look?

@cchaos
Copy link
Contributor

cchaos commented Aug 11, 2020

There's still the question of how to handle right vs left Y-axis grid lines and tick marks.

@flash1293
Copy link
Contributor

Good point, @cchaos - I assumed we would implement that in a separate PR as the current status is a meaningful increment and benefits users, so there's no need to keep this PR open longer.

Copy link
Contributor

@cchaos cchaos left a comment

Choose a reason for hiding this comment

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

👍 Ok, so long as we do circle back before the 7.10 release. I'm good with this PR as-is to get this functionality started. Thanks for all your work @stratoula and sorry about all the extra discussion.

@stratoula stratoula merged commit 0cfc7b4 into elastic:master Aug 11, 2020
stratoula added a commit to stratoula/kibana that referenced this pull request Aug 11, 2020
…lastic#71829)

* [Lens] Add styling options for x axis on the settings popover

* ts related changes

* Changes to the popover's design and y-axis implementatin

* fix types and add unit tests

* Add extra translations

* Fix functional test and change the logic of the yTitle

* fixes

* fix showTitle settings bug

* Fix ticklabels bug on y axes

* fix some tests

* Change the user flow on x and y titles on settings popover and enable the gridlines by default

* disable linter warning

* PR Comments

* Add a comment to callback to explain the decision to listen only to open changes

Co-authored-by: Elastic Machine <[email protected]>
@flash1293
Copy link
Contributor

I will create a separate issue for left/right y axis settings.

gmmorris added a commit to gmmorris/kibana that referenced this pull request Aug 11, 2020
* master: (106 commits)
  [Functional Tests] Adds a wait time between setting the index pattern and the time field on TSVB (elastic#74736)
  [Lens] Add styling options for x and y axes on the settings popover (elastic#71829)
  [Maps] add initial location option that fits to data bounds (elastic#74583)
  theme function (elastic#73451)
  [data.ui.query] Write filters to query log from default editor. (elastic#74474)
  [data.search.SearchSource] Move some SearchSource dependencies to the server. (elastic#74607)
  [Canvas][tech-debt] Convert renderers (elastic#74134)
  [security solutions][lists] Adds end to end tests (elastic#74473)
  pluralized for occurrences vs occurrence (elastic#74564)
  Update links that pointed to CONTRIBUTING.md (elastic#74757)
  [Ingest pipelines] Implement tabs in processor flyout (elastic#74469)
  [Event log] Use Alerts client & Actions client when fetching these types of SOs (elastic#73257)
  Bump chalk to 4.1.0 (elastic#73397)
  Index pattern field list - transition away from extending array - introduce and use getAll() (elastic#74718)
  [SECURITY] Bugs css/inspect (elastic#74711)
  [telemetry] update README to downplay ui_metrics (elastic#74635)
  Fixed grammar (elastic#74725)
  [Telemetry][API Integration] size_in_bytes to be a number (elastic#74664)
  [ILM] Convert node details flyout to TS (elastic#73707)
  [Ingest Node Pipelines] Sentence-case processor names (elastic#74645)
  ...
stratoula added a commit that referenced this pull request Aug 12, 2020
…71829) (#74782)

* [Lens] Add styling options for x axis on the settings popover

* ts related changes

* Changes to the popover's design and y-axis implementatin

* fix types and add unit tests

* Add extra translations

* Fix functional test and change the logic of the yTitle

* fixes

* fix showTitle settings bug

* Fix ticklabels bug on y axes

* fix some tests

* Change the user flow on x and y titles on settings popover and enable the gridlines by default

* disable linter warning

* PR Comments

* Add a comment to callback to explain the decision to listen only to open changes

Co-authored-by: Elastic Machine <[email protected]>

Co-authored-by: Elastic Machine <[email protected]>
jloleysens added a commit to jloleysens/kibana that referenced this pull request Aug 12, 2020
…nes/processor-forms-a-d

* 'master' of github.com:elastic/kibana: (25 commits)
  [ML] Removing full lodash library imports (elastic#74742)
  [Search] Server strategy example (elastic#71679)
  [Reporting] Fix and test for Listing of Reports (elastic#74453)
  [maps] fix drawing shapes (elastic#74689)
  [Resolver] Improve simulator. Add more click-through tests and panel tests. (elastic#74601)
  Deprecate schema-less specs in Vega (elastic#73805)
  [Security Solution] Rename Administration > Hosts subtab to Endpoints (elastic#74287)
  Timelion deprecation doc (elastic#74508)
  [Functional Tests] Adds a wait time between setting the index pattern and the time field on TSVB (elastic#74736)
  [Lens] Add styling options for x and y axes on the settings popover (elastic#71829)
  [Maps] add initial location option that fits to data bounds (elastic#74583)
  theme function (elastic#73451)
  [data.ui.query] Write filters to query log from default editor. (elastic#74474)
  [data.search.SearchSource] Move some SearchSource dependencies to the server. (elastic#74607)
  [Canvas][tech-debt] Convert renderers (elastic#74134)
  [security solutions][lists] Adds end to end tests (elastic#74473)
  pluralized for occurrences vs occurrence (elastic#74564)
  Update links that pointed to CONTRIBUTING.md (elastic#74757)
  [Ingest pipelines] Implement tabs in processor flyout (elastic#74469)
  [Event log] Use Alerts client & Actions client when fetching these types of SOs (elastic#73257)
  ...

# Conflicts:
#	x-pack/plugins/ingest_pipelines/public/application/components/pipeline_processors_editor/components/manage_processor_form/field_components/text_editor.tsx
#	x-pack/plugins/ingest_pipelines/public/application/components/pipeline_processors_editor/components/manage_processor_form/manage_processor_form.tsx
#	x-pack/plugins/ingest_pipelines/public/application/components/pipeline_processors_editor/components/manage_processor_form/processors/append.tsx
#	x-pack/plugins/ingest_pipelines/public/application/components/pipeline_processors_editor/components/manage_processor_form/processors/bytes.tsx
#	x-pack/plugins/ingest_pipelines/public/application/components/pipeline_processors_editor/components/manage_processor_form/processors/circle.tsx
#	x-pack/plugins/ingest_pipelines/public/application/components/pipeline_processors_editor/components/manage_processor_form/processors/common_fields/field_name_field.tsx
#	x-pack/plugins/ingest_pipelines/public/application/components/pipeline_processors_editor/components/manage_processor_form/processors/common_fields/ignore_missing_field.tsx
#	x-pack/plugins/ingest_pipelines/public/application/components/pipeline_processors_editor/components/manage_processor_form/processors/convert.tsx
#	x-pack/plugins/ingest_pipelines/public/application/components/pipeline_processors_editor/components/manage_processor_form/processors/csv.tsx
#	x-pack/plugins/ingest_pipelines/public/application/components/pipeline_processors_editor/components/manage_processor_form/processors/date.tsx
#	x-pack/plugins/ingest_pipelines/public/application/components/pipeline_processors_editor/components/manage_processor_form/processors/date_index_name.tsx
#	x-pack/plugins/ingest_pipelines/public/application/components/pipeline_processors_editor/components/manage_processor_form/processors/dissect.tsx
#	x-pack/plugins/ingest_pipelines/public/application/components/pipeline_processors_editor/components/manage_processor_form/processors/dot_expander.tsx
#	x-pack/plugins/ingest_pipelines/public/application/components/pipeline_processors_editor/components/manage_processor_form/processors/drop.tsx
#	x-pack/plugins/ingest_pipelines/public/application/components/pipeline_processors_editor/components/manage_processor_form/processors/index.ts
#	x-pack/plugins/ingest_pipelines/public/application/components/pipeline_processors_editor/components/manage_processor_form/processors/shared.ts
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Lens release_note:enhancement Team:Visualizations Visualization editors, elastic-charts and infrastructure v7.10.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Lens] Y axis styling options
7 participants