Designing for Open Source Charting Library

Lessons learned from designing Britecharts

Sun Dai
Sun Dai
Jul 28, 2017 · 5 min read

There are lots of beautiful data visualizations on the web. As open source libraries however, they lack the flexibility required for people to use right out of the box. Most are highly customized and designed with a particular use case or scenario in mind, making them less reusable for larger audiences. Earlier this year, the team at Eventbrite released a charting library aiming to solve that problem.

Britecharts is a client-side reusable charting library based on D3.js and allows easy, intuitive use of charts and components. We open sourced Britecharts because we want to empower designers and developers who have less experience with D3.js to build great interactive charts with minimal effort.

Open Source Design vs Tailored Design

Most of us go down the “tailored design” path at work: we craft a vision and a goal with product managers or clients with a target audience in mind, decide metrics to measure success and do research and competitive analysis. All ultimately to determine which type of design best demonstrate the goal. When it comes to designing the solution, we make rules and guidelines, draft best practices, dos and don’ts… the list goes on.

Designing for open source, requires a different way of thinking. Rather than focusing on who and what the solution is for, you need to think about the pieces of the puzzle and how users can combine them to form solutions that work for their needs. The challenge is finding the balance between the amount of liberty your users can have while maintaining the usability and accessibility of the charts.

A grouped bar chart visualizing sales across multiple events, where each hue represents an event (left). The same chart could also illustrate the ticket price level within each event (right). Using tints and shades, the user can quickly associate the colors to their respective events.

As there are so many unknowns, it’s almost impossible to make universal rules that apply to every use case scenario when designing a library for others. With that said, the key to open source design is to keep an open mind: remind yourself that you are designing a tool, which is meant to be used by anyone, however they want. Leave the best practices and user experiences to the designer implementing the tool. In the case of Britecharts, we’ve divided up the components as small as possible so the charts are flexible enough to adapt for different use cases.

Open source chart components are designed to be stitched together for case by case scenarios.

Make customization usable (and pretty too)

Developers and designers typically want to hit the ground running once they get an open-source library. They don’t want to worry about usability issues like overlapping text, cut-off graphs and inaccessible colors — that’s where designers come in to prevent any of that from happening.

Take colors for example, Britechart’s default colors are tested against each other to ensure sufficient contrast for users who are color blind — one of my favorite tools for this is Color Oracle. While a delightful and accessible color palette should be included out of the box, users should also be given the options to choose other colors that they prefer.

Providing a robust set of customization options is another approach to ensure usability and the quality of your open source design.

Take a legend for example. At Eventbrite a legend could live in a few places: floated to the side of a chart, stacked below a chart, inside of a tooltip, or even tucked behind buttons. There could also be a large amount of legend items (unfortunately) or legends with long names.

Location and shape of the legend container, container width, text, alignment, value display rules, etc are all things to consider. The more scenarios you can think of, the more design power you own.

A variety of options enabled us to customize the legend so they don’t look out of proportion against charts. In order to keep open source projects usable out of the box, designers need to think of as many scenarios as possible and incorporate those options in anticipation of user needs.

Depending on the legend size, shape/text size and spacing may differ.

Point is, in order to keep our open sourced project usable out of the box, us designers will need to think of as many scenarios as possible and incorporate those as options, so the users can use the charts without worrying too much about such issues.

Collaborating on Github

On Github we use labels to identify categorized tickets. Anything done or needs to be done by a designer should have a `design` label. If a bug or a general question uses `design` label, the designer should be responding to them. When combining labels together the designer can quickly identify design tasks and actionable items.

Each design ticket should include a screenshot or mock up of the design work.

Some of our most used “design” label combinations include:

Design proposal. Provide a short write up of why this ticket is created, what this design is for, what are some of the use cases for this design, references, etc.

Design enhancement. Pixel pushing, visual cleanups and design updates fall into this category.

Design proposal
Design enhancement label

If you are excited about Britecharts, want to add more awesome designs, or have any suggestions, please reach out to us on Github.

Sun Dai

Written by

Sun Dai

Product Designer @Facebook. Previously @Eventbrite. I love cats!

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade