Semiotic Lessons & Goals

Semiotic is a React-based data visualization framework I began developing for internal applications at Netflix. It’s designed to emphasize information modeling, an approach I found to be optimized for internal analytical applications (think data visualization dashboards). What that means in practical terms is that Semiotic gives you the flexibility to move between related chart methods, like line chart to stacked area chart to difference chart, while providing you with the ability to adjust the individual components to create diagrams and charts that one usually associates with bespoke data visualization.

When I open-sourced Semiotic back in September I wasn’t sure how it would be received. It’s not a traditional low-level data visualization library, like D3 or P5, which treat data visualization as a series of moments of mapping data attributes to visual channels. Nor is it a traditional charting library like HighCharts or react-vis which expose semantically meaningful chart components for composition. Instead, Semiotic provides you with three abstract frames, and allows you to generate allied data visualization approaches by adjusting the settings in those frames, or injecting your own custom code to handle pieces like tooltips or marks that require anything more sophisticated. It also ships with a few features that any traditional charting library would likely consider frivolous, like support for sketchy rendering or canvas processing to let you create glowing effects.

Measuring Adoption

The feedback I received from people in the data visualization community was tremendously positive. That’s not surprising — I explained in detail the emphasis on information modeling and folks doing data visualization know that we need to do a better job of it. But I frankly doubt most of them are actually using it. After all, Semiotic is wedded to React, so it’s not enough to make data visualization, you have to be doing it with React and that’s already going to limit adoption. On top of that, for folks who are developing with React, there are already several mature data visualization frameworks along with well-described approaches for using pure D3 with React (including my own both here on Medium and as a chapter in my book D3.js in Action).

While it’s hard to tell exactly how many people use a library, stats on NPM are a pretty good indication, and by those numbers, Semiotic (around 1000 downloads in the last month) isn’t nearly as popular as react-highcharts (77,000), victory (66,000) or react-vis (22,000). That’s not surprising, given how those libraries expose simple interfaces like <Line> or <Bar> or <Scatter> that map pretty closely to how we traditionally think of data visualization.

In comparison, a pie chart in Semiotic isn’t made via a <Pie> component, but rather circuitously via an OrdinalFrame with a "radial" projection, fixed range accessor and dynamic column width based on the values. That’s a mouthful, and harder to explain than “Pass the <Pie> component an array of data you want to display on your pie chart.” But I was inspired by the philosophy that Mike Bostock used in D3, which has a similarly tortured approach to making pie charts that I always used to help people understand the library. There is no pieChart function in D3, rather there is a pie layout and anarc shape generator that in combination and with the right settings, might be used to make a pie chart but might also be used to make a wind rose. It takes more time and investment but rewards you with more flexibility. Similarly with Semiotic, it takes some effort to get a pie chart but because of that the pie chart you make has the same information model as other ordinal charts.

For those of you keeping score at home, it’s d3 (931,000).

Design Considerations

Now, I didn’t design Semiotic explicitly to make it take more time to make charts, but I didn’t design it to be “quick and easy” to let you make a treemap in 20 minutes. That’s an important distinction, and one which I think doesn’t get enough attention in modern data visualization work. We’re so awash with tools and libraries that offer fast and convenient charts. But in my experience, the challenge of putting a chart in an application was never “how long will this take” and always “is this the right chart for this situation.” As such, I think flexibility and prominent design functionality are much higher on the list of priorities for good data visualization than speed and convenience. I’m not claiming Semiotic is the pinnacle of API design, and in fact I think it’s suffered in some ways because its feature set has developed incrementally where it could have used some solid planning that I’d likely invest in for a putative Semiotic 2.0.

But that prioritization of thoughtful information design over speed and convenience carried over to the features that I’ve ended up implementing since releasing Semiotic. This has included better support for icons in bar charts, despite the puritanical hatred for icons in modern data visualization, along with support for custom elements more generally. It has also meant an emphasis on more and better options for annotating a chart, which I think is clearly an underserved and important aspect to good data visualization.

New Features

Beyond that, Semiotic also saw the addition of support for traditional hierarchical charts, like treemaps and circle packing, as well as the hierarchical JSON data typically used for those charts. These were implemented in the NetworkFrame because from an information modeling perspective, hierarchical charts are just a kind of network diagram, like a sankey diagram or a force-directed network or a chord diagram. I had originally planned to avoid implementing these charts, because my goal was not to just implement D3 but in React with my own mental model. But it turned out that the hierarchical code added little size to the existing build given that I was already using D3's hierarchical functionality in various other aspects of Semiotic (for instance in annotations). As a result, hierarchical data can be represented with hierarchical charts but also with network charts and network data.

Semiotic also shrank in some ways since release. One of my favorite features was support for Noah Veltman’s flubber library, which gave you the ability to morph one shape into another. I thought this was the perfect solution for animating chart transitions from one form to another. What I found, though, was that while Flubber was perfect for its designed use case, the abstract shapes in data visualization would often transition in a way that was less useful than just foregoing animation entirely. The library shrank in other ways, for instance with dependencies cut when it stopped automatically rendering alpha shapes as one of the area types. It’s still too big, and reflects its origins as a library for internal applications as well as my own lack of familiarity with the ins and outs of optimizing builds. If that’s something you know and feel like helping me get Semiotic further optimized for deployment in other use cases, by all means contact me — I’d love to work with you.

What’s Next

Going forward I’m thinking of a few different areas where I could focus on improving the library:

• Maybe develop a GeoFrame for doing vector maps? I have no desire to compete with the fully-fledged 3D and tile map libraries out in the world but if there’s a solid use case for developing better cartographic techniques that emphasize the approach in Semiotic (which to me means annotations, exotic but interrelated expressions of the same information model) I could see it working. Just before I started at Netflix I was developing d3.carto and I think some of the principles in that could prove useful to folks making charts. GeoFrame discussion on Github.
• A sophisticated approach to Small Multiples with Semiotic, that lets you define a few parameters by which to deploy the same frame across different dimensions or metrics. This could also allow for a shared Annotation Layer so cross-highlighting and annotating would be trivial. Small Multiples discussion on Github.
• Better handling for annotations and labeling. While Semiotic does a great job of letting you deploy annotations, the functionality for dynamically creating them and ensuring that their placement and appearance is optimized is rudimentary at best. The same can be said for labeling techniques which could be much better, especially for charts where peculiar labeling conventions (like labels for treemaps) might prove useful for other less exotic charts. Annotation & Labeling discussion on Github.
• I wonder if it might help increase adoption of Semiotic if I created a set of Common Chart Abstraction Components (like <PieChart> that just maps to a few settings in <OrdinalFrame>). Chart Components discussion on Github.
• Other features? Feel free to file an issue, even if it’s just a challenge for how to make a bespoke chart using Semiotic, I love those.

Looking Forward

There’s always something to do with a library like this, even if it’s not the fun stuff like implementing a Chuck Close filter. For one thing, there’s always more documentation. I’m happy with the interactive and wiki documentation but it needs to be better and there are a few features that are currently only documented in the release notes. I’ve also started doing live streaming tutorials of Semiotic and I love it, but more importantly they should help people understand how to use the library.

More generally, I’m happy with how the library is evolving and stabilizing. It is and has always been a place for me to innovate on the areas of data visualization that interest me, and the results have proven remarkably useful in professional application. I’d love to see Semiotic become a dominant data visualization framework — not just for my own megalomania but also because I think we need more data visualization technologies that are focused on how to do things deliberately rather than how to do things fast.