[Lens] Add styling options for x and y axes on the settings popover #71829

stratoula · 2020-07-15T09:17:29Z

Summary

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

This PR adds more settings to the settings popover.

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.

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.

Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
Unit or functional tests were updated or added to match the most common scenarios
This was checked for keyboard-only and screenreader accessibility
This renders correctly on smaller devices using a responsive layout. (You can test this in your browser
This was checked for cross-browser compatibility - Safari, FF and Chrome

What to test

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

stratoula · 2020-07-15T09:25:34Z

@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:

and here is a screenshot of the settings:

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

stratoula · 2020-07-15T14:23:05Z

@elasticmachine merge upstream

cchaos · 2020-07-15T14:33:14Z

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

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.
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
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 · 2020-07-15T14:43:18Z

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 · 2020-07-15T15:12:42Z

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.

stratoula · 2020-07-15T15:14:09Z

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

AlonaNadler · 2020-07-15T17:47:55Z

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 · 2020-07-15T18:37:34Z

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:

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.

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.
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 · 2020-07-15T18:40:27Z

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

flash1293 · 2020-07-15T19:05:12Z

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

stratoula · 2020-07-17T06:20:34Z

@elasticmachine merge upstream

stratoula · 2020-07-17T16:37:27Z

@elasticmachine merge upstream

stratoula · 2020-07-20T06:33:21Z

@elasticmachine merge upstream

stratoula · 2020-07-30T06:17:08Z

@elasticmachine merge upstream

stratoula · 2020-08-03T06:22:38Z

@elasticmachine merge upstream

cchaos · 2020-08-04T16:46:08Z

@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:

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.
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 · 2020-08-05T06:33:07Z

@elasticmachine merge upstream

flash1293 · 2020-08-05T08:40:00Z

@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:

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 · 2020-08-05T17:31:40Z

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 · 2020-08-05T18:14:43Z

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 · 2020-08-06T17:09:30Z

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?

flash1293

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

x-pack/plugins/lens/public/xy_visualization/xy_expression.tsx

x-pack/plugins/lens/public/xy_visualization/xy_config_panel.tsx

flash1293 · 2020-08-10T14:45:09Z

x-pack/plugins/lens/public/xy_visualization/xy_config_panel.tsx

+    setYaxistitle(yTitle);
+  }, [xyTitles]);
+
+  const [tickLabelsVisibilitySettings, setTickLabelsVisibilitySettings] = useState({


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.

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

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):

kibana/x-pack/plugins/lens/public/indexpattern_datasource/dimension_panel/popover_editor.tsx

Line 59 in b165538

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.

I have removed the localstate from gridlines and ticklabels

…pen changes

kibanamachine · 2020-08-10T18:05:17Z

💚 Build Succeeded

continuous-integration/kibana-ci/pull-request
Commit: 7b3bc4a

Build metrics

page load bundle size

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

History

💚 Build #67176 succeeded 593f226
💔 Build #67153 failed a03dd0d
💚 Build #66552 succeeded 482af76
💚 Build #66003 succeeded 1ce9a70
💚 Build #65461 succeeded 01874bd

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

flash1293

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

flash1293 · 2020-08-11T09:33:10Z

@cchaos Could you have another look?

cchaos · 2020-08-11T13:51:51Z

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

flash1293 · 2020-08-11T14:39:06Z

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.

cchaos

👍 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.

…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 · 2020-08-11T17:12:41Z

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

* 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) ...

…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]>

…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

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

0d001d5

ts related changes

2c1ec95

Merge branch 'master' into lens-xy-axia-styling

5b5f3a7

flash1293 mentioned this pull request Jul 16, 2020

Inplace editing for axis titles elastic/elastic-charts#753

Closed

3 tasks

stratoula added the WIP Work in progress label Jul 16, 2020

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

4235afb

elasticmachine and others added 6 commits July 17, 2020 00:20

Merge branch 'master' into lens-xy-axia-styling

959a87a

fix types and add unit tests

a5c7aae

Add extra translations

036ef3a

Fix functional test and change the logic of the yTitle

96d60b7

fixes

ff14e6d

fix showTitle settings bug

3ddb22f

Merge branch 'master' into lens-xy-axia-styling

9db022f

elasticmachine and others added 2 commits July 20, 2020 00:33

Merge branch 'master' into lens-xy-axia-styling

c2e494b

Fix ticklabels bug on y axes

56e0df1

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

fix some tests

8cb771b

Merge branch 'master' into lens-xy-axia-styling

01874bd

Merge branch 'master' into lens-xy-axia-styling

1ce9a70

Merge branch 'master' into lens-xy-axia-styling

482af76

Merge branch 'master' into lens-xy-axia-styling

a03dd0d

elastic deleted a comment from elasticmachine Aug 10, 2020

disable linter warning

593f226

flash1293 reviewed Aug 10, 2020

View reviewed changes

stratoula added 2 commits August 10, 2020 18:58

PR Comments

33de3d1

Add a comment to callback to explain the decision to listen only to o…

7b3bc4a

…pen changes

flash1293 approved these changes Aug 11, 2020

View reviewed changes

cchaos approved these changes Aug 11, 2020

View reviewed changes

stratoula merged commit 0cfc7b4 into elastic:master Aug 11, 2020

stratoula mentioned this pull request Aug 11, 2020

[7.x] [Lens] Add styling options for x and y axes on the settings popover (#71829) #74782

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Lens] Add styling options for x and y axes on the settings popover #71829

[Lens] Add styling options for x and y axes on the settings popover #71829

stratoula commented Jul 15, 2020 •

edited

Loading

stratoula commented Jul 15, 2020

stratoula commented Jul 15, 2020

cchaos commented Jul 15, 2020

stratoula commented Jul 15, 2020

cchaos commented Jul 15, 2020

stratoula commented Jul 15, 2020

AlonaNadler commented Jul 15, 2020

cchaos commented Jul 15, 2020 •

edited

Loading

cchaos commented Jul 15, 2020

flash1293 commented Jul 15, 2020

stratoula commented Jul 17, 2020

stratoula commented Jul 17, 2020

stratoula commented Jul 20, 2020

stratoula commented Jul 30, 2020

stratoula commented Aug 3, 2020

cchaos commented Aug 4, 2020

stratoula commented Aug 5, 2020

flash1293 commented Aug 5, 2020 •

edited

Loading

AlonaNadler commented Aug 5, 2020 •

edited

Loading

flash1293 commented Aug 5, 2020 •

edited

Loading

flash1293 commented Aug 6, 2020

flash1293 left a comment

flash1293 Aug 10, 2020

stratoula Aug 10, 2020

flash1293 Aug 10, 2020

stratoula Aug 10, 2020 •

edited

Loading

kibanamachine commented Aug 10, 2020

flash1293 left a comment

flash1293 commented Aug 11, 2020

cchaos commented Aug 11, 2020

flash1293 commented Aug 11, 2020

cchaos left a comment

flash1293 commented Aug 11, 2020

[Lens] Add styling options for x and y axes on the settings popover #71829

[Lens] Add styling options for x and y axes on the settings popover #71829

Conversation

stratoula commented Jul 15, 2020 • edited Loading

Summary

Checklist

What to test

stratoula commented Jul 15, 2020

stratoula commented Jul 15, 2020

cchaos commented Jul 15, 2020

stratoula commented Jul 15, 2020

cchaos commented Jul 15, 2020

stratoula commented Jul 15, 2020

AlonaNadler commented Jul 15, 2020

cchaos commented Jul 15, 2020 • edited Loading

cchaos commented Jul 15, 2020

flash1293 commented Jul 15, 2020

stratoula commented Jul 17, 2020

stratoula commented Jul 17, 2020

stratoula commented Jul 20, 2020

stratoula commented Jul 30, 2020

stratoula commented Aug 3, 2020

cchaos commented Aug 4, 2020

stratoula commented Aug 5, 2020

flash1293 commented Aug 5, 2020 • edited Loading

Alternatives

AlonaNadler commented Aug 5, 2020 • edited Loading

flash1293 commented Aug 5, 2020 • edited Loading

flash1293 commented Aug 6, 2020

flash1293 left a comment

Choose a reason for hiding this comment

flash1293 Aug 10, 2020

Choose a reason for hiding this comment

stratoula Aug 10, 2020

Choose a reason for hiding this comment

flash1293 Aug 10, 2020

Choose a reason for hiding this comment

stratoula Aug 10, 2020 • edited Loading

Choose a reason for hiding this comment

kibanamachine commented Aug 10, 2020

💚 Build Succeeded

Build metrics

page load bundle size

History

flash1293 left a comment

Choose a reason for hiding this comment

flash1293 commented Aug 11, 2020

cchaos commented Aug 11, 2020

flash1293 commented Aug 11, 2020

cchaos left a comment

Choose a reason for hiding this comment

flash1293 commented Aug 11, 2020

stratoula commented Jul 15, 2020 •

edited

Loading

cchaos commented Jul 15, 2020 •

edited

Loading

flash1293 commented Aug 5, 2020 •

edited

Loading

AlonaNadler commented Aug 5, 2020 •

edited

Loading

flash1293 commented Aug 5, 2020 •

edited

Loading

stratoula Aug 10, 2020 •

edited

Loading