Initial Stages
A web developer with an education research group at a major public university contacted us asking for help with a Shiny application.
The app was designed to help their clients visualize progress and status indicators of students and teachers, often broken down further by demographic groups, so much of the application was devoted to Plotly output.
There are some rough edges in the R implementation of Plotly, especially when the plots are broken across a lot of categories and need to fit within a given space. The problem only compounds when there are long labels.
Before: Factor label overflow, and legend overlap.
After: Everything has its own place, including the legend, and the bars are vertical with a number label at the top.
Getting Busy
We started by looking into the worst-case scenarios, and asking what we’d prefer to happen instead. Rather than a smashed-together graph, how about fixing the plot width per category level and letting the plot overflow with a scrollbar on the x-axis, and let the plot become as tall as necessary on the y-axis?
Surely scrolling left to right is better than not being able to read any of the labels, right?
Now, that’s easy to say – but it does come with trade-offs. What about printing? What about pagination instead?
We decided we couldn’t do much for the print case anyways – if the graph overflows a browser window, it’s not going to fit simply in a print media scenario either.
We did consider pagination, but there’s a big drawback – requiring active clicking through multiple graphs just doesn’t feel fluid like a quick horizontal drag of the mouse. It requires more waiting during processing between graphs too.
So we’re happy with our settled solution (scrolling through overflow), but certainly open to considering more options as feedback arrives.
However…
We thought the problem was solved, but we were wrong! You can make a plot as big as you want, but if the user resizes the browser window, the plot will get resized to fit rather than overflow. Back to the drawing board.
It actually wasn’t too bad. All we need to do was trigger a redraw of the plot with window.onresize. It adds an unfortunate half second of grayed-out pause in the plot area, but again, slower and readable is better than unreadable.
We also did some work on dependent enabling and disabling of inputs to avoid awkward or nonsensical input combinations.
For example, given a selected grade and subject, we only wanted to allow selection of relevant test score metrics, not tests that are only given to other grades.
Deployment
The application changes were simple to update. Most of the systems work was handled by the research group’s developers, so we were really able to focus on the appearance most of all.
Lessons Learned
We thought we knew more than we actually did about using Plotly in R, particularly the ggplotly and plot_ly functions. We had to do some reading in the Plotly docs to get a good handle on some of the lesser-known options. Hopefully that will serve us well on future projects.
Also, color matters. We spent some time choosing eye-friendly, accessible color schemes for plots. This is an under-appreciated practice. Make sure your site is viewable and informative for everyone (color is just one of many accessibility issues, of course).
Modern Research Consulting 