Add group labels in SVG for easier manipulation in Figma

[danyx23]

When we prepare our charts for sharing them in Instagram or other social media platforms, we export SVG charts and then manually optimize them in Figma. When doing so, the structure of the SVG is often confusing. Adding labels to groups would be a simple measure that would make this much easier.

@lucasrodes are there any additional measures that would save you a lot of time? Some restructurings would probably be difficult to do in Grapher, but if you had a wishlist of bullet points of changes to our SVG structure - what would they be?

[lucasrodes]

hi @danyx23, thanks for following up on this.

currently there are some tasks that we do at first that would be nice if could be automated:

• better structure of the folders so that these are more human readable
• change dash-pattern of charts. The default has a dash and gap length that is quite short (I think it uses sth like 3-2). Currently on Instagram we use 7-7 pattern.
• We always move the OWID logo to the btotom right part of the chart.

On this, I ran a session two months ago on the current process end-to-end when remixing charts for Instagram. We recorded the session. The first part of the session is invested in this cosmethic changes that are always there. More details on this here

[sophiamersmann]

Hey @lucasrodes,

I added labels to Grapher's SVG output that hopefully make it easier to manually edit our charts. Here is a staging site: http://staging-site-improve-for-figma/. Could you check it out and let me know if the labels are helpful?

• better structure of the folders so that these are more human readable

I made an effort to group elements together that belong together. For example, such that a tick's line and a tick's label is rendered into the same group. Is this helpful?

• change dash-pattern of charts. The default has a dash and gap length that is quite short (I think it uses sth like 3-2). Currently on Instagram we use 7-7 pattern.

We compute the dash pattern from the current font size. I played around with it but didn't really find a way to land on a 7-7 pattern for mobile that also looks good on desktop.

• We always move the OWID logo to the btotom right part of the chart.

We could consider adding an option to the "Export" tab in the chart admin to move the OWID logo to the bottom, but it would be a bit of an effort :)

[lucasrodes]

hi @sophiamersmann, thanks for addressing this!
This is a great improvement, and will make us more agile when working on drafts for social media! I really like that namings of items (e.g. area__Other-renewables) make sense now. This is so helpful.

After trying it out with this chart, I have some additional comments, that I wanted to share. These are not urgent, but just wanted to surface them. It is probably the case that I am missing some edge cases and that there are good reasons to keep things mostly as-are. But just sharing in case it is helpful.

Again, these are by no means urgent, and the current implementation is already a nice improvement over previous versions.

Footer

In the footer there are typically three elements:

• source
• origin url
• logo

(and optionally, also notes)

I understand that moving the logo there is a bit tricky, so no rush in doing that. So that leaves us with just two element in most of the cases (source and origin url) and optionally, an additional one (notes). When looking at the structure I observe that we still have some nesting of folders, and that multi-line texts are broken down into multiple elements (e.g. with the source Ember (2024); Energy Institute - Statistical Review of World Energy (2023) → Ember (2024); Energy Institute - Statistical Review of World Energy and (2023)).

I think that it would be nicer if we did not have any folders, and just plain elements: the origin url, the note and the source name.

Header

Similar thing occurs with the header as with the footer, where multi-line texts are broken down into multiple elements and there are still folders with single-elements (I've omitted the logo):

I think we only need two text elements: 'title' and 'subtitle'.

chart-area

(1) chart-area

Within the chart-area group, there is a single element: stacked-area-chart group. I think we don't need this additional grouping.

(2) stacked-area-chart

Within the stacked-area-chart there are three elements: Clip path group, dual-axis and Vector. I think that we could:

• Rename Clip path group → Data for instance.
• Remove Vector group. Unsure its purpose.

(3) Clip path group

• Is boundsClip-4 needed?
• Can we get rid of Group and instead have stacked-areas and line-labels bumped up a level?

In stacked-areas, there is a Vector element. Is it needed?

In line-labels, it might be nicer if we had three groups (instead of a group per entity). That is:

• labels
• background
• connectors

This way, it'd be easier if we wanted to make the font of the labels larger; or if we wanted to change the width of the connectors. Right now, we need to open each entity folder individually and select the element we are interested.

(4) dual-axis.vertical-axis

In vertical-axis, do we need to group each tick? Is it bc maybe in some instances there can be more than one element?

(5) dual-axis.horizontal-axis

In horizontal-axis, I think that, while grouping tick labels with ticks is smart, it makes it difficult to change the shape of these elements as a group rapidly. Suppose I want to make the fonts of all tick labels larger; or that I want to make the ticks wider. For such case, I'd need to open each folder and select the tick label.

It might be nicer if we just have two groups: tick-labels and tick-vectors. This is a similar point mentioned in line-labels (see point 3)

[sophiamersmann]

Hey @lucasrodes, thanks a lot for your detailed feedback! It's appreciated 🙏🏻

In line-labels, it might be nicer if we had three groups (instead of a group per entity). That is:

• labels
• background
• connectors

This way, it'd be easier if we wanted to make the font of the labels larger; or if we wanted to change the width of the connectors. Right now, we need to open each entity folder individually and select the element we are interested.

I wrongly assumed that it would be better to group all different elements of a tick or label together (e.g. the line label and the connecting line in one group). I reverted the changes that I made to that effect in the PR, and I created an issue to look into it in the future.

When looking at the structure I observe that we still have some nesting of folders, and that multi-line texts are broken down into multiple elements. [...] I think that it would be nicer if we did not have any folders, and just plain elements: the origin url, the note and the source name.

SVG doesn't have a concept of "overflowing content" and thus can't break text into lines automatically. Every SVG element is always absolutely positioned. It's unfortunately impossible to render multi-line text into a single SVG element :(

Within the chart-area group, there is a single element: stacked-area-chart group. I think we don't need this additional grouping.

The groups or elements that you see in Figma that don't seem to have a purpose are often used for interactions (e.g. they have event listeners attached or they're present to catch mouse/touch events). Technically, we could omit these groups and elements when exporting a static version of the chart, but for easier maintainability, I would like the interactive version and the static version to be as similar as possible.

In vertical-axis, do we need to group each tick? Is it bc maybe in some instances there can be more than one element?

I removed the extra group :)

Thanks again!