When I began to investigate whether my SDL-related thesis (since abandoned in favor of T.124) should focus on the grammar or on the visual programming aspects of the specification language, my friends started to look at me funny. Visual programming seems to be something like splitting products of large primes or proving P = NP - a problem that tends to hypnotize young computer scientists, but that is widely regarded as impossible to solve.
Half a year later, starting on the T.124 work, I found the (beginnings of the) text below in my "thesis" directory at home.
Graph-grammars and graph-rewriting system, often expected to be miraculously powerful, are theoretically well-founded and have been studied thoroughly in the last few years. There are several graph-rewriting rule paradigms to chose from, and a number of graph-oriented environments have been written, sometimes with considerable effort. (The Aachen PROGRAPH environment contains 400,000 lines of C code.) They exist; they're free - why don't people use them?
But, far from being immediately understandable to even novice users, the straightforward application of the graph paradigm is a confusing mess. Why? Unsuprisingly, little pieces of text in boxes with arrows between them are just as hard to interpret as little pieces of text without boxes and arrows, except that they take up more space, and have visual clutter around them that distracts from the meaning of the text.
Even when one kind of arrows-and-boxes are replaced by normal, "bold" and dashed arrows, boxes, boxes with round edges, oval boxes, oval boxes with three kinds of lines behind them, boxes dented inwards, boxes dented outwards, and boxes with the upper left corner folded in - even then, the visual "alphabet" that this constructs is far less efficient than the alphabet of words that we have grown up with.
Most visual programming environments suffer from that exact same disease, only more so. They use their visual power to emphasize the syntax of the programming language, instead of helping the user to express their ideas.
User-defined types can become syntax, and user-defined functions can become keywords, once one has gotten used to them. They vanish as problems; they become means to achieve a higher goal, and very little cognitive effort is expended to parse them. For visual programming, this means that the user must be able to easily specify visual primitives, not just combine existing ones.
Sure, I can call up a paint program with an unlimited number of line thicknesses, fonts, and geometrical figures, can draw brush strokes with any bevil shape I like, on any background pattern I like, with any color I like, and run the result through any number of image processing primitives.
But the results aren't sexy, they don't have that swing that any old handwritten doodle has. They're not personal. It is fun to draw; it isn't fun to draw with a mouse.
This meaninglessness makes drawings ideal for the development of meaning; they don't crowd on those who see it. Starting with squiggles, annotating, animating them, slowly fleshing out the missing parts - that would be a great system to have. Make images first, then make rules.