Adding a Touch of glitr: Developing a Package of Themes on Top of ggplot - posit::conf(2023)
Presented by Aaron Chafetz and Karishma Srikanth Please note, a power issue cut off the first five minutes of the talk. Explore how our team at the US Agency for International Development (USAID) created our own data viz branding R package on top of ggplot2 and how you can too. How do you create brand cohesion across your large team when it comes to data viz? Inspired by the BBC's bbplot, our team at the US Agency for International Development (USAID) developed a package on top of ggplot2 to create a common look and feel for our team's products. This effort improved not just the cohesiveness of our work, but also trustworthiness. By creating this package, we reduced the reliance on using defaults and the time spent on each project customizing numerous graphic elements. More importantly, this package provided an easier on-ramp for new teammates to adopt R. We share our journey within a federal agency developing a style guide and aim to guide and inspire other organizations who could benefit from developing their own branding package and guidance. Materials: - https://speakerdeck.com/achafetz/adding-a-touch-of-glitr - https://usaid-oha-si.github.io/glitr/ - https://issuu.com/achafetz/docs/oha_styleguide Presented at Posit Conference, between Sept 19-20 2023, Learn more at posit.co/conference. -------------------------- Talk Track: Compelling design for apps and reports. Session Code: TALK-1103
image: thumbnail.jpg
Transcript#
This transcript was generated automatically and may contain errors.
And in doing so, we identified a couple key elements. Firstly, we were repeating the same ggplot2 theme elements within a file and across multiple different files. Meaning we were copying code chunks every single time we were creating a new script and new plot. Importantly, this wasn't standard across the board.
So if I were creating a new plot, I would open up my script, copy in this code chunk, and then make a small modification. Let's say I wanted to increase the line weight of my axis or something like that. That's not to say then that the next person who goes and copies my code is going to keep the same things and make the same customizations. So we were having these repetitions, but also lacked uniformity across the board.
Secondly, we were repeating hex colors throughout our scripts and had, as Aaron mentioned, multiple different colors that were being used that we were explicitly calling out with their hex code each time.
And finally, our team had custom export parameters for the size and DPI of our plots that we were using for presentations. And while we had this ggsave function that was ready to go at the end of each of our scripts, we still had to copy that every time we were creating a new script.
And so doing this inventory allowed us to then parse through our code base and make decisions about what we wanted to keep that we would then pull into our standard plot elements going forward.
Designing the custom theme
So here you have a mock-up of our notes and sketches throughout this process and the decisions that we made about formatting. And we took it a step further and specifically ascribed for each plot element what we wanted those decisions to be.
And the goal of this slide is not for you to be able to see every single element on this plot, but to understand our thought process behind what we were doing. We went through and specifically said for the title, this is going to be in all capital letters, 14-point font, in this very specific shade of dark gray. And we did this for every element of the plot, from the caption to the annotation to grid lines and even to the source note at the bottom of the plot.
This effort to better document and understand our previous work allowed us to then move into ggplot2 seamlessly with this mock-up and start building our custom refinements on top of what already existed in ggplot2.
We focused on three main buckets to make these refinements to our custom plot branding. Starting with the plot elements themselves, we were really motivated to adhere to data visualization principles, namely to declutter our plots and show the data.
To do so, we really liked the minimal from ggplot2 as a great starting point for this and leveraged the replace function from ggplot2 to then make small refinements on top of the minimal based on our notes from all of our previous code. And so this was making adjustments to things from title and subtitle all the way down to things like ticks and margins.
For typeface, this was one of the ways that we could really distinctively make this style our own. Our agency has a branding guide, and while this branding guide doesn't necessarily discuss too much about data visualization principles, it does denote a specific web font to use, which was Source Sans Pro.
And we really wanted to use this font instead of the three default fonts in ggplot2. And to do so, we used the extra font package in gr-devices, which allowed us to build in our custom font, Source Sans Pro, into our existing R package.
And so by packaging all of these elements into their own central theme and building in a custom font for our package, we were able to pull all of these elements together into one simple function called si-style. And the idea behind si-style is that any user could pick this up and pipe this into their existing ggplot2 code and then immediately be able to standardize their plot elements to our style. So visual hierarchy, axes, whitespace, the likes, while still remaining flexible and customizable to the user.
Building the color palette
So the last leg of the stool is color, right? We needed to create something that really made it our own. So as Krishna mentioned, we have this branding guide that doesn't talk about visualization for our agency, but we wanted to use some of the colors, right? There's some nice colors going on here. There's just not a big enough palette to make it useful for data visualization, nor is there enough contrast to really make this accessible. So those were our two priorities.
So we used this as a starting place to work from, and we picked two of the USAID-branded colors. And from there, we used free software, Adobe Color, Palatable, and VizPalette to play with the hue and saturation of those two colors to then adjust them, do additional adjustments, and then make sure that there was enough contrast going on. And as a result, we came up with our own colors that were similar, yet distinct from the original and had enough contrast in them.
And then from there, we built out a larger set of colors and a gray, and then each of those then had lights that we could use. And then we defined additional colors for each of our plot elements that we could use to standardize them.
If you're feeling a little overwhelmed by having to make all these decisions about color, we really, really, really love Lisa Charlotte-Mooth. She has some unbelievable resources that we relied on in talking about color for data visualization and how to put together color for a style guide. And she's working on a book right now that I think is coming out later this year.
Packaging and sharing the work
So with those three pillars in place, we were able to create a package, right? We started small. We had our SI style that Karishma mentioned earlier, and we're able to have a good starting place for something everybody could use. And to make it so that everybody could use this, boom, we pushed it up to GitHub, and it became accessible not just to our team, but to our colleagues in the missions and our other agencies that we're working with.
So we started, like I said, with SI style, got the job done, and then we expanded from there. That SI style has about nine different alterations that you can use just to be flexible. And then as we realized there were more things that we were repeating, we built out additional functionality to interpolate colors and to make sure that our exports were the same every single time, regardless of whether Karishma was doing it or I was.
So I think everybody, right, is familiar with based ggplot2 and those colors, right? You would not be, you know, if you've ever used it, looks pretty standard. And so it gets the job done. But to those points that Laura was talking about earlier, we added our own style here to help at a baseline provide some differences to help with focus and other things.
So we have scale fill SI that we've just added on top of ggplot2, which is providing the colors by default from our color palette, which then the user could adjust the different colors on our palette. And then lastly, this SI style grid, which is providing a wide grid instead of just the standard SI style. And then you're seeing changes in our title, our caption. The strip text at the top looks different. The placement of the legend. So all of these are conscious decisions that we're doing to make declutter our graphs and make them more legible.
So the great thing about this is it just works, right? We don't have to think about these things every single time. You just add a line or two to your ggplot2 code, and it just works.
Creating a tool-agnostic style guide
The last piece of the puzzle for us was to take all of this work that we had built in the R environment and package it into a tool agnostic style guide. So we had a tool that works really, really well and powerfully in R to standardize our plot elements and apply visual coherence to our visuals. But the next step was to think about how we could socialize this more broadly within our team and make this something that was useful to folks, regardless of their data visualization platform of choice.
We also recognized that the glitter package alone was not enough. Let's take this visual, for instance. This is a pet bar plot that's built in Excel, and it's trying to convey the point of funding being transitioned to local partners in the blue. And while we can leverage the glitter package to apply our standard plot elements, to add some visual coherence with our font, colors, and white space, there's still something missing from this visual to really effectively tell the story.
And that missing piece is the intentional use of data visualization principles throughout your plot. Things like sorting your data to more effectively show your point, or encoding the key takeaway message into the title to make it meaningful, or strategically leveraging labels to add context to your plot. All things that can't be built into an R package.
All things that can't be built into an R package.
And this really solidified for us the need to have one resource that anyone can come to that explains why we made the choices we made for our custom plot elements, but also outlines the data visualization principles that you need to be thinking about when making plots on your own.
We wanted this to be like a paint by numbers, if you will, where no matter where you are in your data visualization journey, you have tools and resources that you can easily build upon and have guideposts for what you're doing and why.
And so our data visualization style guide was born. And this style guide takes you through all of the elements that you should be thinking about when creating a data visualization of your own. It also details out the choices that our team made when creating our custom themes and colors, and acts as one central resource for our entire office of 300 people to come to as their data visualization hub.
Impact and benefits
So what? Where do we go from here? Well, before Glitter and the style guide, our teams were working in silos and often were creating products that lacked visual coherence and ended up creating a lot of cognitive load anytime you were looking at your presentations. And while this before and after is zoomed out, you can still see a little bit more visual coherence in the slide deck on the bottom.
In addition to this just looking nice and professional, our team has seen numerous benefits since the introduction of these tools. Firstly, our team has seen significant efficiency gains since the introduction of the style guide and the R package. Instead now of all of our colleagues having to reinvent the wheel every single time, they have a foundation that they can build off of and can spend more time focusing on the analytic questions at hand.
This style guide has also enabled us to create unified branding within our team and recognition of products that are coming out of our office. And as mentioned in the previous talk, having visualizations that look nice matters. And it also improves your data storytelling and the quality of your analytic products.
From a visibility standpoint, our team has been able to share what we've learned throughout this process with other teams in the federal space who are looking to implement similar processes within their organizations. And finally, having these central data visualization resources makes for easier onboarding of new staff.
We can speak firsthand that these resources do not stand alone within our team. It's created a community of collaboration within our office and also lowers the barriers to entry for folks who are looking to get engaged in data visualization or even in the R space.
So all in all, these processes take time and they take effort. But in doing so, you're not only enabling yourself to succeed, but others in your team to succeed well into the future. Our framework was to first do an inventory of our universe of outputs and workflows and find pieces that we could build upon and then move those into ggplot2 to make refinements to our plot elements, typeface, and any decisions to be made about color. And then finally, take all of that work and package it into a tool agnostic style guide that you can share more broadly within your teams and create and generate more buy-in and promote accessibility.
We've shared this framework with you today in the hopes that this will be useful and beneficial to you and your teams so that next time, you don't need to start from a blank canvas. Rather, instead of starting from scratch, you have a palette that you can work off of, you have tools that can help you get there, and guideposts for what you're doing and why.
Thank you all for coming today, and we hope that this talk has inspired you to add a touch of glitter to your data visualization workforce. Thank you.
Q&A
Thank you both for a great talk. And we have time for a couple of questions. One question is, have you thought about glitter for Plotly? So I guess people are interested in, you know, interactive. Sure. I mean, we haven't, but I mean, it's kind of a next extension that we have all this built out. That wouldn't be hard.
Okay, a second question. How can none, I guess you partially answered this already, but how can none of our users use your resources? Yeah, I think the style guide is really that bridge to allow folks to engage in the R space with this, but also pull this into their other visualization tools. So our team also works at CrossTableau and Excel, and we've been able to pull these guiding principles into our work in those software as well.
How do you convince others at your organization to use your package? We don't. So we, within our office, have been able to basically showcase what this can do, but we are in a federal space where there are these branding and guidelines. And so most of our work is internal. And so we're able to kind of skirt around that for now by just doing this internally.
Lastly, what was the trickiest part about the process to set up your design in terms of selling it to the office as well as making decisions? It's tough. I mean, I think just the time, like communication that it has to take. You have to be able to show your product and the difference that it's going to make, and then also get some buy-in from the people you're working with to make those changes from doing what they're doing to the product. To make those changes from doing what they're doing to kind of buy into the rest of this.
