5 things a chart editor has to get right

Imagine someone creating an important chart in a presentation tool you're building.

They click a column to give it the same colour as a callout on the final slide. This is a quick decision for the user, but for the team building the editor, that click starts a chain of decisions and potential work.

What exactly did they select when they clicked? Which controls belong there at that moment? Where should the menu open without covering the thing they’re trying to edit?

As soon as people can edit a chart in your app, they expect it to look and behave like the rest of the product. They should be able to work in the language they’ve chosen. They'll want to be able to try an edit and change their mind if it doesn't work for them.

Over the time we've been building Graphy’s React SDK, which includes an editor for that work, we've encountered countless user stories and edge cases that frequently throw up tricky design and engineering challenges. Below you'll find five of the most challenging areas we've worked on whilst creating our chart editor, with examples of how we've solved them.

1. Match the editor and the chart to the app’s locale

People generally prefer to work in their own language. If they've chosen a language for the rest of your app, any chart editing interface should carry that choice into the words describing menu options and the values they’re looking at. Equally, if a menu changes language while the axis keeps its old date format, the two parts of the experience can disagree on how to present the same data.

There are three things that need connecting here. Menu labels need translations. Dates, numbers and currencies need a display locale. Some languages also need the controls to flow right to left. Chart.js, for instance, can format numeric ticks for a locale, while its time axis uses a date adapter. But when your app provides the editor, it also will need to apply the language choice to the controls, check that labels fit, and test what happens when a translation is missing. A lot of extra complexity.

Graphy's SDK supplies the chart controls and locale-aware formatting. Your app can pass its locale into the editor and supply the translations it needs, along with its own titles and surrounding copy. In the example below, switch between English, Japanese and Arabic using the menu in the top left to see the control labels and chart values together. In Arabic, you'll see the direction of the menu change as well.

2. Put the right controls where people click

When someone clicks a chart, they’vre often already telling you what they want to change. Clicking a column is probably a request to change a colour. Clicking an axis can be a request to adjust a scale, and so on. Put every option in one panel and even changing the colour of a single column can mean searching through settings for the whole chart.

Point-and-edit turns that click into a useful selection. The hard part is deciding what the user hit and which controls make sense for that target. A click on a legend item might mean edit the legend or hide a series, depending on the mode. Chart.js for example gives you legend positions and click callbacks. Its default legend click on a bar chart toggles the dataset. To offer a placement menu there, you’d also need to distinguish editing from viewing, place the menu inside the available space and give keyboard users a way to open and dismiss it.

Graphy supplies selection and contextual menus for supported chart elements. Click different parts of the chart below. The menu moves with the selection and offers controls for the element you chose.

Try it below.

3. Let people change the chart type as they work

A column chart helps you compare revenue across regions. When the question becomes how much each region contributes to the total, a donut shows those shares directly. The author is still working with the same revenue figures.

The hard part is changing how the data is mapped, scaled and laid out in one edit. Graphy’s grammar of graphics lets the editor work with those parts separately. Both views use the same bar mark. To turn a column chart into a donut, Graphy stacks the values, scales them to shares of the total and wraps the stack around a circle in polar coordinates.

That gives the app one type picker for both views. The author can ask a different question of the data while staying in the chart they’re already editing.

4. Make Undo follow the order of the edits

Chart authors often try things while they work. From changing the graph's colours to tweaking line thickness to changing the chart type altogether, it's important they can test things out to get things looking just how they want. An Undo control is extremely important here that at a minimum should reverse the most recent chart edit, even if it came from a different control than the one they’re using now.

That takes more than redrawing with the previous options. A chart editor needs one record of the order in which changes happened. It needs to know what each edit changed and how to reverse it. It also needs to decide what counts as one step. Dragging a slider can change the chart many times before the author lets go, and they’ll usually expect one Undo to take them back to where they started.

Graphy’s editor routes supported edits through a shared command history. The chart menu and controls your app adds can use that same history. Try the Cookbook demo below. Make a couple of edits and step back through them. Your app decides how chart undo fits alongside the history of the surrounding document.

5. Make the editor feel like part of your app

The editing interface becomes part of your product the moment it opens. In a presentation tool it might need to feel quiet and out of the way. In a dense dashboard, the same controls might need stronger contrast and a layout that works in a smaller space. Matching the chart palette gets you only part of the way. The menus, buttons and selection outline are what people use to make the changes, and these should all feel like you made them.

If you build the controls yourself, every menu has to carry the product’s visual rules into its hover, focus and selected states. Those details matter because they tell authors what’s clickable and which thing they’re editing. A different look still needs to work with a long label, a keyboard and a small chart.

Graphy lets you style the whole editor as well as the chart. You can bring the supplied controls closer to your design system and replace controls where your app calls for something more specific. Switch between the running app, financial paper and developer platform examples below, and open an edit menu in each to see how the controls fit the surrounding app.

Ultimately the best chart editors are the ones users barely notice. People edit charts in the middle of doing something else; they’re finishing a slide, answering a question about revenue or making a report clearer. A good chart editor lets them make the change and carry on.

That’s what we’ve built into Graphy’s SDK. It handles the details of editing the chart, from working out what someone clicked to undoing a change. You decide which edits to offer them, and how the controls fit into your app.

Learn more about Graphy’s embeddable chart editor