Read on Twitter
I used to preach how the grammar of graphics was the single most important pivoting point for coding languages and dataviz.
I used to laud vega viz as the future. But now, after working so hard in the space of accessibility... I am far more interested in something else 1/7 https://twitter.com/palewire/status/1247247710282846208
I used to laud vega viz as the future. But now, after working so hard in the space of accessibility... I am far more interested in something else 1/7 https://twitter.com/palewire/status/1247247710282846208
What is wrong with a grammar focused on turning data into geometry as easily and expressively as possible?
That our true aim should be higher: to develop a grammar that improves how easily we turn data into *insights.*
Dataviz is just a proxy for insight.
2/7
That our true aim should be higher: to develop a grammar that improves how easily we turn data into *insights.*
Dataviz is just a proxy for insight.
2/7
A computational methodology to transform the symbolic into the geometric still fails to bridge the gap between the geometric and what it *means* in its context.
Building tools and solutions for accessible dataviz will show you how far we still have to go. 3/7
Building tools and solutions for accessible dataviz will show you how far we still have to go. 3/7
By focusing on a grammar that is so insular, we further encourage our authors and creators to become more efficient software developers.
But just the easy creation of geometry isn't enough.
We need software developers who strive to be authors, reporters, and creators. 4/7
But just the easy creation of geometry isn't enough.
We need software developers who strive to be authors, reporters, and creators. 4/7
This is a long winded way to say that if we really want to push for excellence:
Our languages (even down to the language of our code/libraries/packages) need to empower us to think of the reader, the learner, and the people whose lives our work is reaching.
This is not easy 5/7
Our languages (even down to the language of our code/libraries/packages) need to empower us to think of the reader, the learner, and the people whose lives our work is reaching.
This is not easy 5/7
Trying to describe the insights of a chart to a non-sighted person using programmatic methods lays bare the inadequacies of a grammar of graphics.
What is a "bar" or "line" really? And more importantly, why are they speaking? What is the language BEYOND the graphics?
6/7
What is a "bar" or "line" really? And more importantly, why are they speaking? What is the language BEYOND the graphics?
6/7
I want our code not just to produce marks and axes on a cartesian plane... but help us create content that EXPLAINS what these even mean, what they accomplish.
Technologies shape epistemologies.
Graphics alone are meaningless.
I'm ready for the grammar above graphics.
7/7
Technologies shape epistemologies.
Graphics alone are meaningless.
I'm ready for the grammar above graphics.
7/7
