Variable Density Graphical Language
In 2008, I worked with the CTO of Progress Software to create a new graphical programming language. This paper summarizes that work.
In designing the visual programming language, we considered the following guiding principles:
- variable density,
- familiarity and
- computer aided editing.
Variable density is the ability
- To represent a program as text or graphics • To choose arbitrarily at what level the program is represented as text or graphics • To represent all levels of the program as graphics or text, from business process down to the method
Most graphical languages have a cliff. At some point, the user is dumped from the graphical representation into a sea of text. There is no gradual transition.
Graphics are useful only to a certain point. Usually we rely on graphics when we are learning.
The second principle is that the visual language should be useful for multiple purposes and in multiple domains. The shapes and symbols should not be so specific and restricted that they are only applicable to certain domains. For instance, the visual language should be useful for data structures, business processes, services, objects and user interfaces.
The third principle is that shapes and symbols should mean the same thing at all times and in every domain. The user should be able to learn a new domain quickly because the shapes mean the same thing. For instance, the transition from user interface design to business process design should be easier.
The fourth principle is that the visual language should be familiar, even intuitive. We should use shapes and symbols that programmers are familiar with and use them in expected ways. There are many common visual programming tools, such as UML and BPML.
Not hand drawn
Previous graphical languages such as data flow diagrams, IDEF and UML assumed that a human would have to draw the graphs by hand. We make no such assumption. Humans will use graphical editing tools to create the graphs. We have greater flexibility in our selection of shapes and symbols.
The visual programming language has four base elements: rectangles, ellipses, solid line arrows and dashed line arrows. These four elements are shown in figure 1.
Fig 1. Four base elements.
Rectangles, squares and other similar shapes with hard corners represent things, or nouns.
Circles, ellipses, rounded rectangles and other similar shapes with rounded corners represent actions or verbs.
Arrows with dashed lines connect things to represent data flow, value assignment or physical state transition.
Arrows with solid lines connect actions to represent process flow, sequence flow or temporal transition.
With these four base elements, we build visual language for multiple domains.
Visual programming language is a language for communicating to both humans and machines. Languages have nouns and verbs. In English, we use sentences with subjects, predicates and nouns.
Fig. 2. Simple sentence
Figure 2 shows a simple sentence. The basis of the sentence is a predicate. The small square on the left is a place holder for the assignment of a subject while the square on the right is a place holder for the object.
Fig. 3. Simple sentence with assignment
Figure 3 shows how the simple sentence can have assignment. A thing named “Actor” is assigned to the subject and a thing named “job” is assigned to the object. In programming language, we can consider the thing named “Actor” an object with a method named “does” which receives a parameter named “job”.
Fig. 4. Collapsing the graph to text
Figure 4 demonstrates the variable density of the diagram. It shows how the sentence could be collapsed to text in two different representations, which may be two different programming languages. Conceptual one should be able to draw the boxes and arrows and convert to the text, or type the text and convert to the boxes and arrows.
Note that the labels on the different shapes are not necessary. One could easily replace the labels with various icons.