isbn9789526046266

15.4.2 UUhistle’s VPS exercises strike a balance between cognitive dimensions
Green and his colleagues have developed a set of cognitive dimensions of notations (see, e.g., Green and
Petre, 1996; Green and Blackwell, 1998; Green, 2000; Green et al., 2006). These dimensions serve as a
vocabulary for discussing cognitively relevant aspects of artifacts, and are intended as a convenient and
inexpensive “broad-brush evaluation technique” during the design of user interfaces and notations. An
influential paper by Green and Petre (1996) applied the dimensions to visual programming; the authors
and others have applied them to many other domains (see Green et al., 2006).
Table 15.1 names and outlines 14 of Green’s cognitive dimensions, and gives my interpretation of what
the dimensions mean in a VPS context. Slightly different versions of the cognitive dimensions framework
have been published in different articles; Table 15.1 is based on Green and Petre (1996), Green and
Blackwell (1998), and Green (2000).
I will now discuss how UUhistle’s visual program simulation exercises are located in these cognitive
dimensions. Out of necessity, my commentary (like UUhistle’s design) is partially based on conjecture as
an empirically grounded psychology of visual program simulation does not yet exist.
When reading what follows, the reader will observe that – as Green and his colleagues have underlined
– the dimensions are interdependent and involve many complex trade-offs. For instance, allowing the user
to define abstractions can have the desirable effect of reducing viscosity but may also introduce hidden
dependencies. The relative importance of each dimension depends on the task.
Closeness of mapping
Even someone who knows very well how Python programs work will need to learn a few tricks in order to
simulate programs in UUhistle. Figuring out how the evaluation areas work and finding where to click to
create new elements of different kinds are perhaps the trickiest of the tricks.
However, most aspects of a VPS exercise map directly to deeper meanings. There is very little in
UUhistle’s display that does not closely correspond to a concept in the notional machine that UUhistle
teaches about. The simulation steps that the user performs have been chosen to correspond directly to
what the notional machine does as it executes a program.
Not all of the ‘games’ the user has to learn to play are notation-induced, and neither are they necessarily
bad. For instance, that a function call requires the creation of a frame and some local variables is part of
what users need to learn and what they may struggle with. However, such a struggle is not an undesirable
side effect of UUhistle’s notation – unless it is the case that the notation makes it hard to realize the need
for frames and local variables – but part of an intended learning activity. 6
Novice programmers do not yet have a clear idea of the domain that UUhistle’s representation maps
to (the notional machine). When they use UUhistle, they learn about representation and domain at the
same time. Consequently, they may not realize whether they struggle with a superficial GUI issue or are
failing to understand a deeper concept. I will return to this important consideration in Part V.
One of the main reasons why not too many ‘simulation games’ need to be learned in UUhistle is
consistency.
Consistency
Internal consistency has been the driver behind many of the design decisions made during UUhistle’s
development. As I explained in Section 13.4, there are few different kinds of GUI operations that the
user needs to learn, and each kind of operation is consistently used to accomplish a particular kind of
simulation step. For instance, once the user has learned that arithmetical operators are first dragged
to the evaluation area and then clicked on to execute, it is not difficult to transition to calling library
functions by first forming the function call in the evaluation area and then clicking on it.
There are limitations to UUhistle’s consistency, some due to the notional machine, others due to
choices we made regarding representation and convenience of use. One limitation is that most visual
6 One of the additional cognitive dimensions proposed in the literature to extend Green’s original set is “useful
awkwardness”, which forces the user to reflect on their task, seeking to produce an overall gain in efficiency (Blackwell,
2000). One way to look at visual program simulation is that it promotes useful awkwardness for the purpose of learning.
237