28.03.2014 Views

isbn9789526046266

isbn9789526046266

isbn9789526046266

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

another panel. A better solution in the future might bring explanatory texts closer to where the VPS<br />

action is.<br />

Another limitation of UUhistle that is highlighted by the split-attention and modality effects is its lack<br />

of support for the auditory channel. The human capacity to receive sensory information is very limited,<br />

and one of the few known ways to alleviate the problem is to use visuals and sound simultaneously. The<br />

current failure of UUhistle to do so must be viewed as something to improve upon.<br />

The overall effects of UUhistle’s user interface on cognitive load are unknown at present.<br />

Conclusions on usability<br />

UUhistle’s usability appears fairly good.<br />

The analysis of cognitive dimensions suggests that the design of UUhistle’s VPS exercises suits their<br />

intended purpose. The laborsome, viscous nature of some interactions is perhaps UUhistle’s greatest<br />

usability challenge from the cognitive dimensions point of view. The split-attention effect is another<br />

cause for concern. There are many small problems that we are aware of and UUhistle is, of course, still a<br />

work in progress.<br />

Ultimately, UUhistle’s usability depends on how learners use it. We have conducted no formal usability<br />

studies. However, thousands of students have succeeded in using the system and most have found it easy<br />

enough to use. I present some results from an opinion survey in Chapter 20.<br />

An external evaluation<br />

This chapter has presented our own analysis of UUhistle. In a recent independent review of visualization<br />

systems, Gondi (2011) evaluated a visualization example in UUhistle against nine best practices identified<br />

in the literature. A 2–3–4-tree visualization in UUhistle was found to support eight of these practices,<br />

namely, support for flexible execution control, providing a context for users to interpret the visualization<br />

(such as a textual description), providing multiple views or representations, allowing user-specified data<br />

sets, showing the source code of what is being visualized, suitability for use as a lecture aid, suitability<br />

for self-study, and suitability for debugging.<br />

The ninth best practice, having students answer questions or make predictions, was apparently not<br />

present in the particular example evaluated by Gondi. As the reader will know by now, UUhistle does, of<br />

course, very much support such modes of interaction as well.<br />

In Part IV, I have presented visual program simulation and a supporting piece of software as the outcomes<br />

of what I hope appears to be a rational and logical process.<br />

In a keynote address at the Koli Calling 2010 conference on computing education research, Michael<br />

Kölling 10 remarked that the design of pedagogical software by computing educators is often informed<br />

by gut feeling, but that this is not bad – gut feelings are important and useful. Nevertheless, Kölling<br />

reminded us, with reference to Parnas’s famous article A Rational Design Process: How and Why to Fake<br />

It, it is worthwhile to rationalize our design process and to relate it to theory.<br />

According to Parnas, no software project, past, present, or future, proceeds in the ‘rational’ way, but<br />

we can still make an effort to approach rationality and to document our software as if we had followed<br />

the ideal process: the documentation should help the reader to understand what we have created, not to<br />

relive the creation process. “It is very hard to be a rational designer; even faking that process is quite<br />

difficult. However, the result is a product that can be understood, maintained, and reused.” (Parnas and<br />

Clements, 1986, p. 256)<br />

Parnas wrote about designing and documenting software artifacts and their modules. My concern<br />

in this thesis is not one of software design in Parnas’s sense, but the design and documentation of a<br />

software-supported pedagogical approach. This work on visual program simulation has not followed a<br />

rational, well defined sequence of steps, although this thesis may sometimes portray it as such. The work<br />

has been informed throughout by a complex interweaving of gut feeling, literature, and emerging empirical<br />

10 Say this five times fast: collected colleagues of Kölling at Koli Calling.<br />

245

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!