Legend design v2

[gvnmagni]

A new legend design is proposed here.

Instead of the existing legend behavior, we will have two legend formats: table and inline. Each version has its own pros and cons and its use depends case by case.

Each legend format can be used with each 4 possible positions around the chart (top, left, bottom, right), each format will behave slightly differently on each position.

Both format can support series statistics (or multiple values) depending on the chart type as highlighted here

Table format

Series names are aligned to the left, and values are aligned to the right (such as their header) in order to simplify comparison between rows.

Table header:

• can be hidden by default when only the series/categories name are displayed and no statistic/value is visible
• the series header label should be passed from the API
• the other statistics header labels are in English by default, but we should provide a way to internationalize them (also on a subsequent PR)

Table content:

• using what was implemented here is possible to ask for one or many statistics to be shown in the table/inline version.
• the same statistics order should apply

Inline format

Values follow the data series name, for each data series columns header are repeated. We use a : char to separate them

Legend sizing, truncation, line wrapping

The legend can be sized automatically or statically with a fixed width/height.

Currently, when auto-sized legend and is rendered at the left/right side of the chart, the legend computes its maximum size automatically before rendering (via canvas measureText and not via DOM requests to avoid multiple rendering passes before rendering the chart). The current size is computed based on the label length and the legend value that is currently displayed without interactions.

With these new formats, we should improve this calculation and find a good way to measure the max legend size based on something similar clamp(max(table headers, formatted cell values), 1/2 of the chart parent size).

format	position	size	scroll	wrap/truncate
table	left/right	clamp(max(header/values), 1/2parent))	horizontal + vertical	values and their header are fixed to their max size, label/series name title instead will take at maximum the 3/4 of the available space, then it goes to 2 lines max and then truncates
table	top/bottom	full chart size \ 3 rows	vertical + horizontal	values and their header are fixed to their max size, label/series name title instead will take at maximum the 3/4 of the available space, then it goes to 2 lines max and then truncates
inline	left/right	clamp(series + values, 1/2parent)	scrollable vertically	wrap to multi lines, no truncation
inline	top/bottom	full chart size	vertical scroll, items float left	wrap to multiline, no truncation

[formgeist]

Looks very clean 😍

[teresaalvarezsoler]

This looks great, one question regarding the statistics available for the legend, is it only min. max. and avg? Or will there be more options?

[gvnmagni]

It will be agnostic so that we can include any metric we like, this purely represents the structure that the legend will have once it is updated

[nickofthyme]

@gvnmagni just thinking about this legend design. Have we thought about how we would apply this design for hierarchical legends? Where each group is indented, how would the parent rows be highlighted differently than the ones below. Here is an example story.

[gvnmagni]

I have a couple of considerations about this. First, I believe the indentation is a visual clue that is strong enough to be a good solution for our tabular version but I tried to emphasize this a little bit more, especially for legends where information is displayed inline instead of table. Let me show you:

If we have a table-legend, we could still use indentation and maybe add a stronger font-weight to make it pop out even more. Option A would still be the best to me but I am not against Option B, while Option C seems e little bit too much to me.

If we have an inline version though, it is a little bit more complicated because we lose the vertical alignment and therefore we don't have that kind of clue to rely on, I was experimenting with font-weight and font-decoration such as underlines since it looks harder to me to recognise elements in such a list of strings.

What do you all think?

[markov00]

Thank you Gio, I'm in favour of option A or C for tabular and version A in List version

[teresaalvarezsoler]

I agree on version A for both tabular and list :)

[nickofthyme]

Thanks @gvnmagni I think A is good for the table.

I honestly don't know if we should support list legends for hierarchal data or maybe we force a 1 depth legend that only shows the bottom layer. Happy to discuss offline.

[mbondyra]

Closing in favor of #2475