a Scientific Basis for Visual Notations

This paper [pdf] defines a set of principles for designing cognitively effective visual notations.

(i'd quote more but i can't copy and paste and i'm already tired of typing.)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

This seems like a good paper

This seems like a good paper but will take quite a bit longer to get through. But I want to point out how much more challenging doing science on design seems than just doing science on science. They pull out a lot of cognitive psych theories, which is definitely appreciated, but you get the sinking feeling that there is no actionable advice to be gained in the end.

nice attempt to introduce a shared vocabulary perhaps

i like that it (see Figure 1) gives one a vocabulary to talk about the pieces that must go together to make a visual notation. sorta get people understanding where to look and how the aspects fit together.


The Physics of Notations does not consider encoding-side issues as it focuses only on the effectiveness of the resulting representation. Further research could expand the theory to include such considerations.

Bummer. One of my major motivations for using visual languages is that it should make diagrams easier to draw and maintain. Most notations don't enforce spatial constraints, for example, or provide guidelines for how to layout information. These are crucial for a successful notation.

For example, Microsoft Visio and Visual Studio have never supported automatically maintaining connector relationships for anything but the simplest arrow. This automatically dissuades people from experimenting and thinking about their relationships. Further, there is a little known "crow's foot rule" (Barker technique) when laying out entity relationship diagrams that greatly enhances user understanding. Even weirder, although the Barker technique was created by a guy at Oracle, the Oracle Designer software does not include affordances for using the technique. Compare Figure 3.24 and Figure 3.25 in the article I link about crow's foot rule.

Given the lack of automated support for the Barker technique, it is little wonder why I never bother to draw entity relationship diagrams. Its too much of a pain in the tuckus. I have actually never seen visual software that actually helps doing the Barker technique, and one day hope to set up some leisure time to think about the computational limitations of doing so, and code up a demo.

By the way, I have created a visual programming language in the past for querying data and helping to understand data better. My major motivation was how annoying it is to transform something like a LINQ query or (back then) SQL statement to use a GROUP BY or ORDER BY clause, or how annoying it was to have to manipulate characters on a screen to do what a simple checkbox could do: "group this field". My major limitation was I never figured out a satisfactory way to:

a) do left outer joins visually, distinguished from inner join. [I assume there is no need for right outer joins, as they are simply a noisy option if you have left outer joins).

b) help the "average Joe" figure out how to express sub-queries. I was able to do this for existential quantification rather effectively, but I could never figure out a way where users could say "where the price in our Charge Master was equal to what we got paid on these invoices I am querying".


Microsoft Visio and Visual Studio have never supported automatically maintaining connector relationships for anything but the simplest arrow.

To my chagrin as well. Really, most software that has ostensibly to do with layout is actually not very good at it. Take alignment and margins, two fundamental features of design. Even if software has good drag-and-drop snapping that does what you want, there’s often no way to express what you mean: that some pair of objects are linked and should always be aligned together or separated by some margin. “Groups” do this effectively for inflexible layouts, but they impose unnecessary hierarchy because they can’t generally be overlapped.

Do left outer joins visually, distinguished from inner join.

Can’t say I know enough about it—or like the guy all that much—but Jeff Atwood had some thoughts on visualisation of SQL joins a while back. Presumably inner join would be the default, with a checkbox for “include all rows from this table” or some such. Depends on what the UI is like overall.

…how to express sub-queries.

Why not decompose subqueries into separate queries altogether, on a dataset that just happens to be the result of a previous query?