The Subtext UI sucks. One of the biggest problems is linking: the welter of compasses and vectors is bewildering. We need something that is much easier to read. I have been thinking about an approach that borrows from Alice.
Here is a screenshot of an Alice method:
Alice is a conventional OO language with a visual syntax based on nested “tiles”, which are just small forms with labels and fields. Squeak Etoys is similar but less slick. Alice uses a visual syntax that directly maps to standard language syntax. Nested tiles map to nested expressions. Sequences of tiles (as in the “Do in order” tile above) map to statements in begin-end blocks. In both of these cases, what are explicit links in Subtext are implicitly specified by physical adjacency. In other words, syntax.
Let’s face it: syntax is a simple and intuitive way to represent structure. But a fundamental principle of Subtext is to avoid syntactically encoding programs so that their semantics are explicit and immediate. It should be possible to use syntactic techniques as a visualization in the UI instead of as a representation of the source.
Here is factorial in Alice:
Here is factorial in Subtext:
Here is a new view of factorial:
Every box (tile) corresponds to a non-leaf tree node. Labels are black, and links are blue. Values have a gray background. Every function has a primary input argument with a blank label, and a primary output argument with the label “=”. There are three techniques used to represent links. The first is to represent a link to an input argument by preceding its name with a “$”. A link to the unnamed primary input argument thus becomes just “$”. This is a familiar convention from scripting languages.
The second technique for representing links is to vertically stack functions which are chained from output to input. The chain from Subtract->Factorial->Multiply is an example of this. Thus what would normally be written as “H(G(F))” becomes the stack F;G;H. One could argue that this is more readable than the parenthesized notation. Note that these vertical stacks will work nicely for histories of actions too.
The If function is an example of the third technique. It has a secondary input argument (else) that is linked to another function. The If box is layed out vertically, with the linked functions stacked to its right, and enough vertical white space added to avoid overlap. Note that this layout is automatic. It is based on determining a spanning tree within the graph of all intra-function links.
This layout provides a natural reading order. Normally we read from left to right on a horizontal line, then continue from the left side of the next line. Reading the Factorial function in this way gives you a sort of linear narrative of executing the function. Instead of using parentheses to stack up computations, the text is moved to the right of a vertical tile. Function tiles may be layed out horizontally or vertically, but maintain the internal reading order of their contents.
Here is a variant, in which the variable references are replaced with explicit arrows. Perhaps the vertical stacking reduces the clutter enough to make these arrows acceptable.
In fact, maybe the vertical stacking is all we need, and horizontal layout to replace parenthesized nesting is not needed:
Here the pink regions indicate consecutively linked components. This layout is simpler than the previous ones, at the cost of making the data flow harder to comprehend.
What do you think?