Design and implementation of courseware for teaching programming ...

Design and Implementation of Courseware for Teaching Programming Languages T. Mtildner, R. Blondon Jockey School of Computer Science Acadia University Wolfville, Nova Scotia, Canada BOP 1X0 (902) 542-2201 Ext. 331 email: solid@ aucs.acadiau.ca

Abstract The first part of this paper describes requirements of courseware for teaching a computer programming language.

Besides typical requirements for a CBT material such as

interactivity and availability of hypertext facilities, additional needs must be satisfied. For example, courseware in question must be able to interact with tools such as compilers and specialized editors. The second part of our paper deals with the implementation issues of a hypothetical courseware on an IBM PC compatible machine. We examine the feasibility of using existing authoring systems and then describe the implementation of the core program using Asymetrix ToolBook and of the other components using the development tools for the Microsoft Windows 3.0 programming environment. We show that the selected environment can be used to create a powerful learning system which provides a variety of hypertext facilities such as user modifiable links, margin notes, and highlighting.

In

addition, this system includes a specialized programming editor and a database of examples that are essential for learning a programming language.

1 Introduction The concept of hypertext has been introduced many years ago [Bus45] but its popularity has grown tremendously during the last few years. At the same time, Computer Based Teaching (CBT) has gained widespread recognition. The interest seems to have been generated by industry and business enterprises. For many years, banks and insurance companies have been using CBT materials to train employees to use new equipment, procedures, forms, etc.

467

(that's why CBT sometimes stands for "Computer Based Training"). In the past, CBT presentations were based on the "book metaphor", that is they were showing one page (screen) at a time. Lack of interaction with the user and the fact that reading the text from the screen is much slower than from the printed page resulted in a rather limited success of this technology. Lately however, this technology has changed dramatically. More and more CBT materials are becoming highly interactive. Many are also taking advantage of non-standard inpu.t/output in a form of multimedia (such as voice I/O, still and live images, etc.). Even more importantly, CBT and hypertext technologies have merged, giving the user the power of well recognized hypertext features such as non-linear, associative organizations and dynamic modifications of selected parts of the material (such as a user-modifiable index). There are many interesting CBT materials (courseware) which have been developed for teaching university level courses, particularly science courses.

Surprisingly, when

compared to the amount of courseware developed for courses such as chemistry, physics, and mathematics, there has been very little developed for learning computer science [Mak87]. In this paper, we deal with the problem of designing and implementing courseware to teach computer programming, for example programming in Pascal. Our requirements for such courseware are not trivial. First of all, we wish to provide most of the facilities of hypertext, including links, global margin notes, bookmarks, highlighted text, table of contents, and the index. We demand that all these facilities can be modified by the user, in particular the user could create new links between two pans of the courseware 1. As for specific needs of our courseware related to its intended role of teaching a programming language, the most basic requirement is to provide the learner with the ability to edit and compile programs without exiting courseware. For this sake, our courseware has to be able to interact with the editor and the compiler.

In addition, our approach is example-based (see [Nea89]), that is

courseware is to be integrated with the repository of examples. This idea comes from the analysis of a learning process, during which students use examples to understand new concepts. Examples are particularly useful for programmers who have a limited knowledge of a programming language because the example can be used to recall the syntax or semantics of the language.

Also, programmers often modify existing code to suit their

needs. Thus, a modifiable repository, which is easy to query, would be an enormous help. To support queries, examples may have semantic annotations (see [Nea89]). The above requirements are not typical CBT requirements and we discuss them in Section 2. We have reviewed several existing authoring systems (programming systems 1This feature is seldom available in commercial hypertext systems.

468

specifically designed for creating courseware). While looking for the authoring system that can satisfy our requirements, we have limited our consideration to IBM PC compatible machines. We have found no "ideal" authoring system which would allow us to create the required learning environment. We have chosen the ToolBook authoring system, produced by Asymetrix [Too], because it allows easy interfacing with programming tools that can be developed to run under Miscrosoft Windows 3.0 [Win], and because it allows all requirements described in Section 2 to be satisfied relatively easily. Specifically, ToolBook can be used to develop a driver program, which implements the core of courseware. The remaining components (the editor, the repository of examples, and the compiler) are Windows 3.0 applications which communicate with the driver program through Dynamic Data Exchange (DDE). We present our findings in Section 3 and discuss implementation issues in Section 4. In Section 5 we summarize our experience with the existing authoring systems. In this paper, we assume that the reader is familiar with the basic concepts of hypertext (see [Tom91]).

2 Courseware for Teaching Programming Languages We claim that courseware for teaching a programming language has to have special features in addition to those available in interactive hyper-documents. Our approach is based on our own experience with the process of learning programming languages and on a series of papers by Neal, see [Nea89]. Below, we describe two sets of requirements which we have developed. The first set includes requirements of an "electronic book" (hyper-document) and is based on our observations of a behaviour of the learner using a classical book. Specifically, learners take advantage of built-in facilities, such as the table of contents, index, and references (both forward and backward). They extend these facilities by making margin notes, "global" notes (on separate sheets of papers attached to the book), inserting bookmarks, and highlighting selected sections. We wish to provide all of these navigational tools in our courseware with the provision that they can be modified by the learner (this provision does not exist in most hypertext systems).

For example, the learner should be able to add new entries to the

existing index, create or remove highlighting [Ber86]. References throughout the text are implemented in hyper-dacuments by links. We use two kinds of links. The first kind of a link connects a selected area of the screen (such as a word or an icon) with a pop-up window. This window is opened when the link is activated (for example by clicking the mouse button on the source of the link). In this paper, we call such a link a local link because its destination window appears on the same screen as the source. Local links help

469 to avoid cluttering the screen with an excessive amount of information.

Only basic

information is shown and the learner can get more information by activating the links. A particular application of local links is to produce help windows (for example, a window containing information about icons). Destination windows may be of different kinds - popup windows which disappear when the learner releases the mouse button, sticky windows which stay on the screen until the next time the learner clicks the mouse button, or more permanent windows which have to be explicitly closed (for example, by clicking a special "close" icon within the window). For the second kind of a link, called a

global link,

the

destination window appears on a different screen than the source. This type of link may be used when text contains a reference to text in a different section of the material. We require that both kinds of links are available both for the author and the learner.

Besides the

requirements described above, there are other requirements to help alleviate the well known problems of hypertext, namely cognitive overload and a disorientation in hyperspace (see [Tom91]).

To deal with these problems, we require that the controls used to navigate

through the courseware be organized as pull-down menus and mouse activated icons. Following the IBM standard, menus usually appear at the top of the screen and icons at the bottom. Since it is easier to access icons than to select items from pull-down menus, the controls that are used most often are invoked by icons, and those that are used less often are invoked by menu items. For example, the control to modify the background color of the screen would be implemented as an item in a pull-down menu while the control to access the index would be implemented as an icon. The author of courseware should be able to create various visual cues, such as icons, "sliders" (for indicating progress throughout the courseware), etc. Various fonts, foreground colors, and background colors should also be used. 2 Below we list all facilities which must be available to the author or learner when creating or using courseware: Requirements 2.1 The following facilities should be available to the author and the learner: 9

margin and global notes

9

local and global links

9

highlighting

9

index

2 Note that in this paper we do not discuss other useful features available in most authoring systems for example graphics, animation, answer analysis, etc.

470 table of contents foreground and background colors3 pull-down menus and icons (author only) fonts and formats of the text (author only). easy translations into other languages, for example French4 (author only). Now, we describe specific requirements related to our goal-creation of courseware for teaching a programming language. As we mentioned before, our approach is example-based. As soon as the user learns a new concept, she or he can experiment with the related example. For this sake, our courseware has to include several components. First of all, an editor should be available for editing source code.

This editor should probably be a

specialized programming editor with features such as folding functions into their headers (such as in the occam environment). The compiler should be fully integrated with the editor, so that the learner can easily compile the code (for example, by clicking the icon in the editor's window). For programming languages that support separate compilation, even more sophisticated facilities should be available to allow for easy creation of projects consisting of several source files (compare the make facility [Ker84]). The repository of examples would be useful only if the learner can easily locate the required example and then use them in the programming editor. The first issue we have to deal with is that of querying--the learners can find the existing examples if they know what they are looking for. In [Nea89] it has been suggested to add semantic annotations to the programming examples, for instance the annotation "string concatenation". It seems to be appropriate to impose a structure on the set of examples, rather than having a single flat universe. For example, there may be two classes of annotations--a name for the class of examples, such as string, and name of a specific operation within this class, such as concatenate. Indeed, this classification is used in a theory of abstract data types or classes in object-oriented programming (see [Str86]). To facilitate querying, we require that the repository includes a browser which provides a hierarchical view of the existing examples (the idea of a browser is borrowed from the Smalltalk environment [LaLg0]). The second issue related to the design of the repository is its interface with the editor. One possibility would be to show the example, and then allow the user to copy it to the editor. We have decided that a better solution would be to

3 Changing colours by the learner is a part of user customization. includes other parts of the user interface such as menus and icons.

This customization

4 The so-called internationalization of courseware can be greatly simplified by conslructs built into authoring systems, such as aliases available in ToolBook V1.5.

471

integrate the editing environment and the repository. This means that once a programming example is located, it is shown in the editor's window. Thus, there may be several editor windows opened at once, and the learner can move from one window to another (for example by moving the mouse pointer). Below, we summarize our requirements related to teaching a programming language:

Requirements 2.2 The following facilities should be available to the learner: 9

multi-window editing environment with specialized functions such as folding and (possibly separate) compilation

9

repository of examples.

Examples can be located using the browser and

placed in the editing window. The repository can be modified by the learner by removing existing examples and adding new examples (supplied with proper semantic annotations). This completes our presentation of requirements for courseware for teaching a programming language. To implement courseware, one can use any programming language, such as C [Ker78] or C++ [Str86], or use a specialized software, called an authoring system. Once we have designed our courseware, we have started looking for an authoring system which would be powerful enough for our purposes. It turned out that this was not an easy task.

3 Authoring Systems Lack of space prevents us from providing a complete discussion of various authoring systems. Here, we briefly describe why most authoring systems did not suit our needs. The first problem we have encountered was a lack (or limited power) of hypertext facilities. But the real stumbling block was the feasibility of the implementation of Requirement 2.2. Although some authoring systems provide built-in programming languages, these languages are not powerful enough to write specialized tools such as editors. It became clear that we had a choice of either giving up authoring systems and implementing everything in a standard language such as C or C++, or implementing the teaching core of courseware, here called the driver, in an authoring system and interfacing it with other components (such as the editor). The former alternative has been rejected because using the authoring system saves a lot of time and programming effort when implementing frame-based presentations, text, formats, graphics, etc. We have decided to try to interface the existing tools with the driver (for example to request the editor to read a new file and merge it with the file

472

currently being edited). From the beginning of our project, we have decided to consider only authoring systems running on IBM PC compatible machines with 386/486 CPUs, and focused our attention on two authoring systems running under Microsoft Windows 3.0 because most Windows applications can communicate through Dynamic Data Exchange (DDE) 5. The two systems were IconAuthor [Ico] and Asymetrix ToolBook.

We have

selected ToolBook for further investigations because (unlike IconAuthor) it comes with its own, object-based programming language (OpenScript) which was powerful enough to implement Requirements 2.1. This choice turned out to be correct, although we could not use the existing tools (for example we could not find editors running as Windows applications). Thus, we have decided to implement our own tools, such as an integrated editor and repository of examples, in Borland C++ [BC++], as Windows applications. This solution would allow us to establish the required communication protocols between the driver and our tools. The next section describes the implementation of Requirements 2.1 using ToolBook.

4 ToolBook Implementation In this section we provide a brief description of implementation of Requirements 2.1 in ToolBook version 1.5. This authoring system comes with a number of built-in functions, such as creation of pull-down menus, and its own object-based programming language called OpenScript. It is the power and flexibility of this language, combined with enhancements introduced in version 1.5 that allow us to implement the required hypertext facilities. The

ToolBook documentation describes

OpenScript

as

an

object-oriented

programming language. When building a book (ToolBook applications are referred to as books) you normally begin by placing objects (rectangles, text fields, push-buttons, etc.) on the screen. Each of these objects have certain built-in properties which describe the object (eg. an object's "position" property describes that object's screen position). The user can add other properties to each object. These objects may also contain scripts which in turn contain

handlers which are made up of OpenScript statements. These handlers allow objects to There are many different kinds of messages, each of which are generated by specific events. As an example, a 'buttonDown' message is generated whenever the left mouse button is pressed down. This message will be sent to the object

respond to messages.

5 It should be noted that links described in Section 2 are sometimes called cold links, while links used to transfer data are called warm links (see [Tom91]). Thus, DDE channel can be considered to be warm links.

473

under the mouse cursor (referred to as the

target). If the target object contains a

'buttonDown' handler, the handler will be executed, otherwise the message will be sent to the next highest object in the ToolBook object hierarchy (e.g. if a push-button is the target for a message but it doesn't have a handler for the message, the message will be sent to the page, or if the page doesn't have a handler for the message, the message will be sent to the book, and so on). Handlers may send other messages (either built-in or user-defined) to other objects (or to their own object) via the "send" command. They may also use the "forward" command to send the message that they where invoked by to the next highest object in the ToolBook object hierarchy. Messages may carry parameters. One of the first things that we looked for when selecting an authoring system was its ability to allow the creation of moveable, resizeable windows. ToolBook made this quite easy. Although ToolBook version 1.5 includes a dialog box utility and a Dynamic Link Library (DLL) which allows Windows-style dialog boxes to be easily built and integrated into ToolBook applications, dialog boxes are not resizeable and cannot carry out complex operations. We decided to make our own "windows" by building them out of ToolBook objects. Although these "windows" were not standard Windows-style windows, they served their purpose. The objects which made up the windows were given scripts so that they could send and respond to messages and to manipulate properties of themselves or of other objects. This allowed them to easily interact with other objects, both in the window and in the rest of the book. These objects were

grouped to make them easier to work with as a whole (e.g.

changing the position of the group would move all of the objects together). To simulate the opening and closing of windows, we made the objects either visible or invisible by changing the "visible" property of their group. Many of these windows that we built had to be able to appear on many different pages.

To accomplish this, the objects were put in the

background (in ToolBook, pages can share a common background) and their "drawDirect" properties were set to true. This allowed them to be visible over foreground and other background objects which had their "drawDirect" properties set to false. Margin and global notes were displayed and edited in windows. By the way of the design of windows as described above, only one window was needed to display all of the notes. Each page had a hidden text field which contained the text of that page's margin notes. There also was a unique page in the book (the first page) which had a hidden field which contained the text of the global notes. These hidden fields contained properties which held the size and position of the window while the window was closed. When the window was opened (shown) the handler which opened it set the size, position, and contents of the window according to the text and properties of the hidden field. When the window was closed (hidden), the handler closing it changed the text and properties of the hidden field to

474

reflect the updated size, position, and contents of the window. Local links were implemented much like margin notes--only one window was used and a hidden field contained the text and size and position of the window. However, there could be many links and hidden fields to a page. To create a link, its source had to be defined first. This involved selecting text. We had to write our own text selection handlers in order to keep track of what text was selected and to prevent the learner from modifying the selected text. If we had used ToolBook's built-in facilities for selecting text it would have left the text open to modification by the learner and it would have been too easy to loose track of what text was selected. After the source text of the link was established the "create link" mechanism was invoked. It asked whether the link should be local or global. If a global link was desired the learner would be asked which page was the destination of the link. If a local link was desired, a window (like a margin note window) would open to allow the leaner to edit text. Each page had a user-defined property organized as a list which allowed the book to keep track of the sources, destinations, and types of links on that page. When the reader was finished creating a link a line was drawn under the source text. It would seem natural that we would have used the "hotword" object of ToolBook to implement links, but we chose not to. When ToolBook shows where a hotword is it puts a box around it. This box does not indicate whether the hotword opens a window or goes to another page. We decided to draw colored lines under the source text of the links (to indicate their types) and to manage the links ourselves. Different types of links can have different colors of the underlining lines, e.g. forward references use a red color and background references use a green color. After a link was set up it could then be invoked by clicking it. There is also a mechanism to allow the learner to remove links by clicking them. To prepare text for highlighting, text was selected in the same fashion as selecting the source for a link. To highlight the text, transparent rectangles were created and put over top of the selected text. A user-defined property of the page was used to keep track of the highlighting rectangles.

The learner could remove highlighting by clicking on the

highlighting rectangles after invoking a "remove highlight" mechanism. To determine the positions and dimensions of the underlines (for links) and highlighting rectangles, we wrote handlers and functions which utilized the ToolBook function "textFromPoint0" and performed multiple binary searches on the pixels within the selected text's field. Given the fact that OpenScript is not very fast, this operation was quite slow. Our method of underlining and highlighting has, at present, one limitation--text which may be underlined or highlighted is not allowed to move (it may not be in a scrollable field for example). This was done because we have found no simple way to determine how much

475

the underlines and highlighting rectangles should be moved when the text moves. We could remove this particular limitation if we introduced another limitation-that text fields in which links may be created and highlighting may be performed contain only one type and size of font and the font is mono-spaced. The index and the table of contents windows required a fair amount of message passing between the objects which made up the windows. The index allowed the learner to find, add, and delete references and to add and delete page numbers of references. The table of contents was not modifiable but it allowed the learner to "fold" and "unfold" chapters in order to hide or show sections within a chapter. Most, if not all, of the complexity of the index and table of contents windows was in getting the objects to communicate with each other. In order to simplify the design of these windows they could be implemented as separate books. For example, the index could be in a book all of its own and the main book would then be able to run the index book (in another instance of ToolBook) and communicate with it through DDE. When the window is designed this way there is no need to implement your own move and resize mechanisms for the window. Over 16 million colors are available in ToolBook, although most display devices cannot display this many. In this case Windows will approximate or dither some of the colors. Colors of objects on the foreground or background may be chosen from these colors. Each background has its own background color. In order for different pages sharing the same background to have different background colors, some mechanism has to be implemented which changes the background color of the background as pages are entered. One limitation on text colors is that all text in a single field must be of the same color. ToolBook allows easy creation of pull-down menus and icons. The "add menu" and "add menultem" commands of OpenScript allow menus to be added to the main menu bar. The "remove menu" and "remove menultem" allow you to remove any menu or menu item from the main menu bar. When a menu item is selected, a message (whose name is the label of the menu item selected) is sent to the current page. A handler for that message can then take action. For creating icons, ToolBook allows objects (and groups of objects) to contain handlers which perform actions when the object is clicked. ToolBook allows text to be in any font which is available to Windows. It also allows four text styles: bold, italic, underline, and strikeout. These fonts and styles can be mixed within the same text field if desired. Sometimes courseware must be written in several different languages. ToolBook allows books to be written so that they can easily be modified to support different languages. The alias feature allows menus to be designed so that when a menu item is selected, the message sent is not the name of the selected menu item but the alias. This way, when menu

476

items are translated into other languages, the names of their corresponding message handlers do not have to be changed. Part of the documentation of ToolBook version 1.5 is a book entitled "ToolBook Ideas" which, among other things, contains hints on how to design books for international use. ToolBook also supports many different date, time, currency, and number formats.

5 Conclusion As a result of our research, we have formulated the requirements for a highly interactive hyper-document for teaching a programming language.

We have designed the

implementation using a combination of an authoring system and standard programming languages.

The existing authoring systems have claimed to be easy to use for non-

experienced programmers and powerful enough to create interactive CBT materials. Our conclusion is that this is not always the case as we had to resort to Borland C++ to implement some auxiliary components. Nevertheless, some of the facilities available in authoring systems, such as the ease of creation of frame-based presentations and answer analysis, are very helpful indeed. Because many authoring systems for IBM PC compatible machines run under MS-DOS, and because MS-DOS was not designed with inter-program communication in mind, there is sometimes a problem of interfacing the main program with other components. The Windows layer solves the problem of communication but the price is that all tools have to be developed as Windows applications which means that most existing tools cannot be used. Our future research goes in three directions. First, we intend to build a new authoring system which provides hooks to interface any specialized tools without having to use DDE. Second, we are considering UNIX implementations. Finally, we are investigating an enhancement of our courseware with multimedia features such as sound and video.

Acknowledgements This research was partially supported by NSERC General Grant from Acadia University, 1991. The second author was supported by the SEED'91 program.

Bibliography [BC++] Borland C++. Borland International, 1991. [Ber86] Mark Bemstein. The Bookmark and the Compass: Orientation Tools for Hypertext

477

Users. pp. 34-45, 1986.

[Bus45] V. Bush. As we may think. Atlantic Monthly. July 1945, pp. 101-108. [Ico] IconAuthor version 3.0. AimTech Corporation. 77 Northeastern Boulevard, Nashua, New Hampshire 03062, USA. [Ker78] Brian W. Kernighan and Dennis M. Ritchie. Prentice-Hall, Inc. 1978. [Ker84] Brian W. Kernighan and Rob Pike.

The C Programming Language.

The UNIX Programming Environment.

Prentice-Hall, Inc. 1984. [LaL90] Wilf R. LaLonde and John R. Pugh. Inside Smalltalk Volume 1. Prentice-Hall, Inc. 1990. [Mak87] F. Makedon, H. Maurer and Th. Ottmann. Presentation type CAI in computer science education at university level. Journal of Microcomputer Applications 10 (1987), pp.

283-295. [Nea89] Lisa Rubin Neal. A System for Example-BasedProgramming. CHI'89 Proceedings. May 1989, pp. 63-68. [Str86] Bjame Stroustrup. The C++ Programming Language. Addison-Wesley Publishing Company. 1986 [Tom91] Ivan Tomek, Saleem Khan, Tomasz Miildner, Mostafa Nassar, George Novak, and Piotr Proszynski. Hypermedia -- Introduction and Survey. Journal of Microcomputer Applications. 14, 1991, pp. 63-103. [Too] ToolBook version 1.5. Asymetrix Corporation, 110th Ave., N.E. Suite 717. Bellevue, Washington 98004, USA. [Win] Microsoft Windows version 3.0. Microsoft Inc, 1991.