Proceedings of the workshop "Intelligent Educational Systems on the World Wide Web",
8th World Conference of the AIED Society, Kobe, Japan, 18-22 August 1997

Has anyone seen this program?
Synchronous and asynchronous help for novice programmers

John Domingue and Paul Mulholland
Knowledge Media Institute
The Open University
Walton Hall
Milton Keynes, UK
+44 1908 65-5014{~john|~paulm}/
{J.B.Domingue | P.Mulholland}

Abstract: This paper describes recent developments in our approach to teaching computer programming in the context of a part-time Masters course taught at a distance. Within our course, students are sent a pack which contains integrated text, software and video course material, using a uniform graphical representation to tell a consistent story of how the programming language works. The students communicate with their tutors over the phone and email.

The main problem with relying on the telephone and email for communication is that it is very difficult to establish the context for a discussion. The student wishes to talk about their program and it's behaviour. The tutor cannot see their program work. Secondly, tutors will often find themselves giving the same explanation to a number of students on the same day. Current facilities do not allow for the effective reuse of explanations.

We hope to alleviate these problems through our Internet Software Visualization Laboratory (ISVL), which supports both synchronous and asynchronous communication. ISVL can be used as a synchronous communication medium whereby one of the users (generally the tutor) can provide an annotated demonstration of a program and its execution. Also, ISVL can be used to support asynchronous communication, helping students who work at unsociable hours by allowing the tutor to prepare short educational movies for them to view when convenient. The ISVL environment runs on a conventional web browser and is therefore platform independent, has modest hardware and bandwidth requirements, and is easy to distribute and maintain. Future work will consider how search agents and ontological classification can be used to support the student in accessing useful resources.

Keywords: Distance teaching, teaching computer programming, Software Visualization.

1. Introduction

Teaching computer science has never been a straightforward or simple process. As a result, a great deal effort has been aimed at improving the teaching process, from intelligent tutoring approaches such as the Lisp Tutor [1], to educational visualizations of programs such as Baecker and Sherman's [2] "Sorting out sorting" movie. The potential value of effective support tools for helping students grasp difficult programming concepts is even greater in a distance education setting, where students spend more time working alone, have limited contact with tutors, and often have no contact with fellow students. We wish to alleviate these problems in the context of a distance education masters level course in Prolog, using an internet-based Software Visualization environment.

Software Visualization (SV) is defined as the use of graphics, text and animation to describe the execution of computer programs. Software Visualization systems have been used in computer science teaching with varying degrees of success over a number of years (for example see [15]). Their primary use has been within a one-to-one setting. A student or professional programmer views a visualization on their own, on a single user workstation. To share an SV one has to bring the participants around the same machine. Unfortunately, there are many instances when this is not feasible.

At the Open University the majority of our undergraduate and Master's courses are taught at a distance. On our larger courses students benefit from face-to-face tuition from a local tutor. We have a number of programming courses however, where because of relatively small student numbers we can not provide a local tutor. On these courses communication between the tutors and students is restricted to telephone and email contact. The tutors often comment on how difficult it is to conduct technical discussions using these impoverished media. For example, tutors will often have to deal with a student's programming problem over the telephone. This often makes it difficult for the tutor to establish what the student needs, meaning either the tutor has to guess and plough through areas of the course (which could confuse the student further) or require the student to undertake the difficult task of explaining what it is that they do not know.

Our approach to solving this problem is to allow Software Visualizations of programs to be communicated over the Web. Using our software tool, the Internet Software Visualization Lab (ISVL), students and tutors can create live broadcasts or recorded movies of their interactions with SVs using any Java aware Web browser.

The rest of this paper is structured as follows. In the next section we describe the ISVL interface, and then give a scenario of how ISVL can be used. We then describe ISVL's architecture. This is followed by a description of related work, future work and a summary.

2. The Internet Software Visualization Laboratory

We now describe our first system which is currently being used and evaluated within a teaching context: we are currently running an internet version of our Master's level Intensive Prolog course [11] using a visualization based on the Transparent Prolog Machine (TPM) [9]. The difficulties students have in learning Prolog have been well documented [12]. It has been widely claimed that a crucial problem is students' inability to conceptualise the complex execution model [16]. This has lead to a great number of Software Visualizations being developed, aiming to present a clear story of program execution. Each Software Visualization developed tends to be based on particular claims as to what kind of representation a student needs in order to learn effectively. Examples include the Prolog Trace Package [7, 8] and the Textual Tree Tracer [20], which aimed to show Prolog execution in fine-detail, using a representation close to the underlying source code. Conversely, the Transparent Prolog Machine (TPM) [9] used a graphical notation, allowing students to appreciate high level patterns indicative of various kinds of execution events without having to plough through a long textual history.

TPM was incorporated into a Masters level course on Prolog programming [11], the notation being used across a range of media: textbooks, videos and software. The course is divided into three parts. The first part deals with the essentials of how Prolog works and how this is represented in TPM, and leads up to the point of understanding recursion. The second part of the course considers simple Artificial Intelligence programs, which involves the introduction of list processing and complex features of the language such as the "cut" and "not". The final part of the course explains the development of an expert system shell. Each part of the course is supported by exercises and video explanations using the TPM notation.

ISVL adds an extra dimension to the course material by allowing the visualization to be used collaboratively. Figure 1 below shows a labelled figure describing the parts of the ISVL Prolog client. A user can obtain the view below by typing a query into the Prolog Query window (1). The result of the query 'NO' (indicating that the query has failed) and a TPM style visualization are returned (2). The user can then step through the execution using the control panel until she reaches the point shown in figure 1. A fine-grained view of the arrowed node can be obtained by clicking on the node (3).

Figure 1. The ISVL interface.

3. Scenario

Bill is working on an exercise from his course workbook. The exercise asks students to write a sorting program, called qsort, which uses the quicksort algorithm. The quick sort algorithm works by splitting a list around an element into a list of lower numbers and a list of higher numbers which are then recursively sorted. The program should take an unsorted list and return a sorted list. For example, the query:

qsort([4, 3, 1], _y)

where _y represents an unbound variable, should return:

_y=[1, 3, 4]

signifying that the query has been proved and the value of _y is [1, 3, 4]. Bill loads his solution by copying it into the text area and clicking on the 'Load' button in the control panel. Bill types his query:

qsort([4, 2, 3, 1], _y)

and clicks on the 'Evaluate' button. A TPM visualization is returned. Even with the visualization Bill fails to track down the bug, so he makes a movie asking his tutor Ingrid for help (figure 2). Bill does this by clicking on the 'Record' button in the control panel. When the 'Record' button is selected all of Bill's interactions are recorded. Bill plays through the visualization adding annotations at appropriate points. The sketched lines are drawn using the mouse with the 'Trail' button selected. The labels (e.g. "This does the empty list") are added by clicking at the desired location with the mouse whilst holding the control key down. Bill ends the recording session by clicking on the 'Record' button again and typing in the name of the movie.

Instead of making a movie Bill could have linked to Ingrid synchronously. To achieve this Bill would have clicked on the 'Broadcast' button in his control panel and Ingrid would have clicked on her 'Receive' button. In this case, all of Bill's interface actions would have been replicated on Ingrid's screen.

Figure 2. Bill asks for help (full-size) (click image for ISVL movie).

Later that day, Ingrid views the movie Bill has made by downloading the movie from a stored movie database. Ingrid plays through Bill's movie using the video-recorder style buttons in the control panel. By viewing the tree and clicking on the nodes to get fine-grained views she is able to spot the bug. The split part of Bill's program is working incorrectly. Splitting the list [3, 1] around 2 should yield the list [1] (numbers less than 2) and the list [3] (numbers greater than 2). Ingrid makes an annotated movie to direct Bill's attention to the buggy part of the code (figure 3). After viewing Ingrid's movie Bill fixes his code and checks it by running it on the server.

Figure 3. Ingrid helps Bill (full-size) (click image for ISVL movie).

It should be noted that for explanation purposes the example programs presented within the scenario are small. Like the original TPM, Web-TPM, contains features for pruning and compressing areas of the execution. For example, all parts of the tree above a chosen node can be hidden from view. Conversely, a node and its subtree can be compressed into a single node. These features allow the visualization to scale up to much larger programs.

4. The ISVL Architecture

The ISVL server is composed of a customised Web server, a generic software visualizer and a specific programming language. The customised Web server is based on LispWeb [18] a specialised HTTP server written in Common Lisp. In addition to implementing the standard HTTP protocol, the LispWeb server offers a library of high-level Lisp functions to dynamically generate HTML pages, a facility for dynamically creating image maps, and a server-to-server

ISVL is based on our framework for creating SVs called Viz [6]. We have split Viz between the server and client as shown in figure 4. The program execution history and views are stored on the server. The history is made up of events which cause players to change state (see [6] for details). A view consists of a series of locations (e.g. the TPM SV uses a tree based view). A mapping maps a history structure to an icon/image class (e.g. a Prolog goal is mapped onto a coloured square). The views and maps form the basis of the ISVL HTTP protocol which is used to transmit the SV. The client interprets the view and map data to produce the on screen images which the user manipulates through a navigator. The navigator allows large execution spaces to be viewed by using techniques such as scale and compression.

Using a protocol specific to SV systems means that the amount of data transferred is minimal. Reproducing views and maps on the client means that an SV can be examined without the need for repeated accesses to the server.

Figure 4. The ISVL Architecture.

On the client side the mapping module converts the ISVL HTTP stream into textual and graphical representations. These representations are then transformed and presented on the screen by the navigator. The user interacts with the visualization using the navigator. The navigator controls panning, zooming, local compression and expansion, and moving forward and backward in time through the program execution space. User requests for non-local information, such as visualizing a new execution result in requests sent to the ISVL HTTP Processor.

Users can elect to broadcast or record their interface actions. In this event their actions are sent via the HTTP Processor to the broadcaster or storage modules. The broadcaster simply sends whatever it receives to the currently receiving clients. The client-server architecture of ISVL is similar to that of Baker [3] whereby the bulk of the work is done on the server, the interface being created by the Java client.

5. Related Work

Recent work within the Algorithm Animation community has lead to the creation of a number systems which allow pre-written animations to be viewed remotely. These systems primarily concentrate on delivering animations synchronously as part of a classroom style tutorial.

John Stasko has provided a facility where XTANGO [19] animations can be run remotely. Although useful for quickly getting an overview of XTANGO's look and feel, which is the purpose of the facility, the system is restricted to X-Window systems and has scaling problems as all the work is carried out on a central server.

The Collaborative Active Textbooks (CAT) of Brown and Najork [5], is a web-based environment, which allows the same animation to be run simultaneously on a number of machines. Intended for classroom style teaching the view and speed of the animation can be controlled remotely by the tutor. This form of synchronous demonstration of programs is possible within ISVL, though within ISVL the animations are not canned, being created on the fly from the program submitted.

6. Future Work

ISVL provides an environment for students to communicate synchronously and asynchronously with their tutor. Asynchronous communication in the form of ISVL movies provides a growing educational resource which can be carried over from year to year. This will lead to a new problem: how does the student find the movies they need?

Towards this end we are developing two methods by which each movie will be indexed. One method will focus on the kinds of execution patterns featured in the movie. The other method will use ontological classification. These will be considered in turn.

Often a student will wish to view movies containing the same kind of execution pattern as found in the program they are working on. This extension to ISVL will be based on the search agents incorporated within the Multiple Representation Environment (MRE) [4]. Within MRE, users are able to select an execution pattern directly from the display. The selected pattern could then be identified in other programs stored locally. Within ISVL, the student could select a tree shape, and then activate the search process to find any movies within the ISVL server archive containing that execution pattern. We envisage the search agent working in a proactive as well as a reactive way. Its proactive mode would bear similarities to the Remembrance Agent (RA) [17]. RA is an agent that sits in the background while someone is developing a document on a word processor. RA continually updates a list of archived documents that are similar to the one being written. The proactive agent within ISVL would work on arbitrary program fragments and execution patterns rather than on the natural language constructs parsed by RA.

The second proposed method by which movies may be indexed and search will use explicit ontological labels rather than execution patterns, allowing movies to be annotated with machine readable semantic knowledge. This draws on the work of Sean Luke and colleagues [13, 14] who have developed SHOE (Simple HTML Ontology Extensions). SHOE allows HTML pages to be indexed and searched according to ontological labels. This allows web pages to be indexed semantically rather than relying on a keyword search, that can often produce spurious results. Documents annotated with SHOE can be searched using Expose, their web-crawling agent. This will require an ontology for the programming course, which is currently under development. For example, the knowledge that a particular movie was made for a tutor, to be viewed by a student, and is an inference engine employing user defined operators could be represented in a way similar to that found in SHOE:

Find isvl web pages for all x, y, z such that
	x is a tutor
	y is a student
	z is a movie where
		madeFor(x, z, y) and
		programType(z, "inference engine") and
		programUses(z, "user defined operators")

We would work to provide a user friendly graphical environment with which students could generate ontological queries.

These two approaches to indexing ISVL resources will help ensure that not only does ISVL give a home for a growing body of educational resources but allows them to be found when needed.

We also wish to consider how the use of sound within ISVL can be enhanced. Sound can be used in the current version of ISVL. Any annotation can be recorded as a sound to be played at some particular point in the execution. Although these are useful, it would be desirable if a complete "soundtrack" could be recorded over and automatically synchronised with the screen activities making up the staged SV event. Currently, an audio delivery tool is being developed in Java within the KMi Stadium project [10]. This would allow users to develop more expressive presentations in a more naturalistic way, making the activity of staging an SV presentation on the web, similar to demonstrating a program to someone looking over your shoulder.

7. Summary

ISVL provides a rich medium within which to communicate programming knowledge. The design appreciates the importance of supporting both synchronous and asynchronous forms of communication. The architecture underpinning ISVL is generic, allowing the domain language or visualization to changed. The efficient client-server communication protocol allows its application even when bandwidth resources are limited. We hope to extend our work further by supporting students in finding the resources they need.


1. Anderson, J. R. and Reiser, B. J. The LISP Tutor. Byte, 10, 4, 159-175, 1985.

2. Baecker, R. M. and Sherman, D. Sorting Out Sorting. Narrated colour videotape, 30 minutes, presented at ACM SIGGRAPH '81. Published by Morgan Kaufmann, Los Altos, CA, 1981.

3. Baker, J. E., Cruz, I. F., Liotta, G. and Tamassia, R. Algorithm animation over the World Wide Web. In Proceedings of the International Workshop on Advanced Visual Interfaces, ACM Press, 1996.

4. Brayshaw, M. Information Management and Visualization for Debugging Logic Programs. Ph.D. Thesis, Human Cognition Research Laboratory, The Open University, Walton Hall, Milton Keynes, UK, 1994.

5. Brown, M. H. and Najork, M. A. Collaborative Active Textbooks: A web-based algorithm animation system for an electronic classroom. SRC Research Report 142, Digital, 1996.

6. Domingue, J., Price, B. and Eisenstadt, M. Viz: a framework for describing and implementing software visualization systems. In Gilmore D. and Winder R. (eds) User-Centred Requirements for Software Engineering Environments, Springer-Verlag, 1992. pp. 197-212.

7. Eisenstadt, M. A Powerful Prolog Trace Package. Proceedings of the Sixth European Conference on Artificial Intelligence, 1984.

8. Eisenstadt, M. Tracing and debugging Prolog programs by retrospective zooming. In R. Hawley (Ed.), Artificial Intelligence Programming Environments . Chichester, UK: Ellis Horwood, 1985.

9. Eisenstadt, M. and Brayshaw, M. The Transparent Prolog Machine (TPM): an execution model and graphical debugger for logic programming. Journal of Logic Programming, 5,4 1988, 277-342.

10. Eisenstadt, M., Buckingham Shum, S. and Freeman, A. KMi Stadium: Web-base Audio/Visual Interaction as Reusable Organisational Expertise. In Proceedings of Workshop on Knowledge Media for Improving Organisational Expertise, 1st International Conference on Practical Aspects of Knowledge Management, Basel, Switzerland, 30-31 October, 1996.

11. Eisenstadt, M., Dixon, M. and Kriwaczek, F. Intensive Prolog. Milton Keynes, UK: Academic Press, 1988.

12. Fung, P., Brayshaw, M., Du Boulay, B., and Elsom-Cook, M. Towards a taxonomy of novices' misconceptions of the Prolog interpreter. Instructional Science, 19(4/5), 311-336, 1990.

13. Luke, S., Spector, L. and Rager, D. Ontology-based discovery on the world wide web. Workshop on Internet-based Information Systems, AAAI-96. Portland, Oregon, 1996.

14. Luke, S., Spector, L., Rager, D. and Hendler, J. Ontology-based web agents. First International Conference on Autonomous Agents, AA-97, 1997.

15. Mulholland, P. and Eisenstadt, M. Using Software to Teach Computer Programming: Past, Present and Future. In Software Visualization: Programming as a Multi-Media Experience, Stasko, J., Domingue, J., Brown, M., and Price, B. (eds) MIT Press, in press.

16. Pain, H. and Bundy, A. What stories should we tell novice PROLOG programmers? In R. Hawley (Ed.), Artificial Intelligence Programming Environments. Chichester, UK: Ellis Horwood, 1987.

17. Rhodes, B. J. and Starner, T. Remembrance Agent: A continuously running automated information retrieval system. Proceedings of The First International Conference on The Practical Application of Intelligent Agents and Multi Agent Technology (PAAM '96), pp. 487-495, 1996.

18. Riva, A. and Ramoni, M. LispWeb: a Specialised HTTP Server for Distributed AI Applications. Computer Networks and ISDN Systems, 28,7-11 pp. 953-961, 1996.

19. Stasko, J. T. The Path-Transition Paradigm: A Practical Methodology for Adding Animations to Program Interfaces. Journal of Visual Languages and Computing, 1,3 pp. 213-236, September, 1990.

20. Taylor, C., du Boulay, B., and Patel, M. Outline proposal for a Prolog 'Textual Tree Tracer' (TTT) (CSRP No. 177). Sussex, Cogs, 1991.