home | copyright ©2016, tim@menzies.us
overview |
syllabus |
src |
submit |
chat
This talk: an attempt at offering guidelines for visual communication for software science.
"Just add a graphic" is never just. When writing papers, even the smallest graphic is hours of work and rework to tune the graphic and the text into the overall story of the paper.
And we've seen how... variable... graphics can be:
- Galileo's lack-of-seperation of text and graphics (at right: observations of Jupiter 15th-century)
- First six minutes of Hans Rosling's the best stats you've ever seen
- Anything by Edward Tufte: - an American statistician and professor emeritus of political science, statistics, and computer science at Yale University. - noted for his writings on information design and as a pioneer in the field of data visualization. - One of this principles is "to clarify, add details". Eg. Manhatten map, below. - For other Tufte principles, see slides 1..53 of this lecture on Edward Tufte
Papers containing "N" visualizations contain at least three types:
- Explanation: illustrations or elaborations of some point;
- Exploration: pictures that lead to some conclusion;
- Silly: pointless, waste of ink
Explanations and Explorations are an inference procedure that must be tuned to:
- the goals of the inference
- the background knowledge of the inference.
When we do visualizations, what are the tricks to add in "the story" to the picture? There is no easy, or short, answer this question. So we will other questions:
- Given a visualization, what change could be made to make the exploration/exploration worse/better?
- For explorations, what additional questions are raised by the visualization that might inform future analysis?
In the following, we apply this test to "N" visualizations to reverse engineering a list of useful operators for improving visualizations.
Ready? Go!.
What are
- The principles of software science?
- How might they lend themselves to visual components?