Using programming walkthroughs to design a visual language
Generate an AI Snapshot to get a quick, structured summary of this paper.
A concise AI-generated summary of the paper will appear here once you click Generate AI Snapshot.
Abstract
This thesis describes a search for an expressive yet facile visual programming language for creating and executing graphical simulations. The search for such a language is guided by a set of twenty problems, which include simulating mice in a maze, grasshopper life-cycles, computer network communication protocols, and a Turing machine. The programming language, called is a rule-based language in which both the condition and action of each rule are described as pictures. A ChemTrains rule will execute when the topology rather than the geometry of a pattern matches a portion of the simulation picture, enabling rules to be drawn at a fairly high level of abstraction. Unique and interesting design alternatives arise because of both the rule-based paradigm and the visual programming aspect. This thesis also describes a methodology for designing programming languages that are easy to write. The methodology, called problem-centered design with walkthrough feedback, involves continually re-evaluating the writability of different iterations of the language's design by examining the steps required in creating sample programs and weighing the knowledge required to choose among alternative steps. The walkthrough evaluation is used to compare competing language designs and to uncover a design's shortcomings. In applying the methodology to the design of ChemTrains, the process of doing walkthrough evaluations on the twenty problems uncovered over a hundred design alternatives, and the comparisons between walkthroughs of different designs led the search through the design space. User testing on a prototype of the final design showed that people with no computer science background and with minimal training could effectively write ChemTrains programs. These results confirm that the walkthrough evaluation analysis was on the mark. However, a few unexpected results in user testing showed that some difficulties in writing programs are hard to predict.
