| TITLE PAGE | TABLE OF CONTENTS | BIBLIOGRAPHY | AUTHOR'S HOME PAGE |
The need to produce some sort of observable feedback for the user poses a challenge to the instructional designer who tries to illustrate computer processes. Early in this project I decided to use interactive graphics as a means of representing computer functions. The use of computer graphics to introduce computer programming has been used in classic teaching materials such as Karel the Robot (Pattis 1981) and the LOGO programming language (Papert 1980). Karel is a visually displayed "robot" that students can operate by instructing him in a PASCAL-like programming language. LOGO is a programming language designed specifically for children; programs written in LOGO direct a "turtle" (a cursor shaped like a turtle) to draw graphics on the screen. As with these two programs, my project seeks to divest computing of its numerical emphasis in order to create a more comfortable atmosphere for learning. It is clear that there is a strong precedent for the use of graphics in the literature. From turtle graphics (LOGO) and Karel the Robot to the graphical user interface, graphics provide a concrete way of displaying the inner processes of an opaque machine. Since the computer's processes are not available for direct inspection, the use of graphic representation is a likely method of demonstrating computer functions. Many sources refer to this use of graphics as creating a "visual metaphor." Research has suggested that learners prefer visual diagramming and graphical displays of information over verbal description; there is evidence that graphic representation can benefit from a `gestalt' response - an informative impression of the whole that provides insight into the structure (Petre 1995). This overall picture of a complex system may lead to the formation of a clearer mental model.
This project was not meant to be an exhaustive demonstration of computer science, it was meant to be a quick look - a presentation that would intrigue people who might ordinarily assume that computer science is too difficult for them to understand. To attract and hold the interest of this audience I assumed a minimum of prior knowledge. In this case the need for prior knowledge of math could have scared off members of my target audience who might be subject to "math anxiety." By de-emphasizing the mathematical basis of computing I also hoped to minimize the effects of the "gender gap" in mathematics learning which, I suspect, has created a corresponding gender gap in computer science. In general, I tried to attract people to the project who might be otherwise be considered atypical candidates for learning about computer technology. For all of these reasons I chose to examine a very simple graphics program rather than an applied mathematics program. The operations of this simple drawing program were traced through several levels of the processing hierarchy. Multimedia software was used as the delivery medium for presenting this simple model of computer processing.
The simple design of the program permitted a wide variety in the ages and experience of the audience. I expected that the youngest users of this program would be middle school students - students who would be capable, according to Piaget's stages of development, of abstract thinking.
The Morse code analogy worked well for explaining digital encoding but it could not be extended to explain the other areas of computer processing. One of my goals was to demonstrate how it was possible for an inanimate object - the computer - to "make decisions." Because I chose to address a fuller model of computing than simply binary encoding, the prototype was quite different in its approach than the Morse code game. In the prototype I began with the notion that the de-bugging process is like a game: one must understand and fix a problem before advancing to the next level of problem solving. Initially the approach seemed intriguing because it paralleled the process that real computer scientists and engineers would use to perfect a program or computer component. The game would engage the user in trying to fix a broken program. At first one of the squares in an eight-by-eight grid would not work properly; this square would do nothing when the user clicked on it. Being unable to fix the problem at the end user level, the player would be forced to look deeper, into the programming level, to resolve the problem. At each successive processing level the player would be asked to test the defective pixel. The player would be lead through high-level programming to low-level programming, basic CPU functioning, binary encoding and finally to the hardware level where the user would finally find the last "bug" and fix it. For the prototype I divided processing into the six sections described below. (Screen shots of the prototype can be found in Appendix A):
End User Level. The prototype started the user at a simulated "End User Level" of a defective graphics program. The user needed to fix the program at different levels to advance in the game. The graphics program was a simple eight-by-eight grid of pixels each of which could be toggled from black to white and white to black by clicking on it with the cursor.
Programming: High-Level Language. The screen describing the part played by high-level languages was almost identical to the "Programming" activity in the final project. The lines of the program shown would check the pixel for its condition (black or white) and then flip it at the mouse click. In the final version the specific relationship between information and memory location was reinforced. When the user put the lines of the program in the correct order the software prodded him to the next level. The user would receive a message that the program is right but that the program isn't working because the computer still doesn't know how to find the pixel. Then the next step would be to come up with a system that both the user and the computer could agree on to describe this location.
How the Program Works. The concept for this screen was to show how an operating system works and what a computer's instruction set is. This subject was in the first outline but it proved too complicated for me to include. When I reviewed which parts were essential this was one of the subjects that seemed expendable and too complex for a quick view.
Inside the CPU: Low-Level. "Inside the CPU" was modelled on the VIC software that I saw demonstrated at an NYU Colloquium in February 1994 (Schocken 1994). It too was omitted in my final project. I decided that the educational payoffs wouldn't be great enough to merit the effort of producing a working model of CPU processing at this level.
Binary. The "Binary" screen was adapted and improved in my final version. It originally showed the numerical address directly labeled on each square of the grid. In the final design the memory addresses were depicted as a linear run - a model which is closer to the way memory is actually organized.
Logic Gates. Finally I show a circuit configuration into which the user must insert the proper logic gates so that an XOR gate is created. A more fully fleshed out version of this became the last activity screen in the final project. In the final version, however, the individual types of logic gates were explained more fully and were linked to electronic circuitry.
Four buttons, "To the game", "What to do", "Why" and "Hints" appeared on each screen the prototype. "To the game" returned you to the activity screens after you'd selected any of the other three buttons. "What to do" directed the user through the activity. "Why" was an explanation of why a specific processing level was important. "Hints" were meant to explain a process by suggesting familiar metaphors. The distinctions between some of these was lost in the final version because I folded several of these functions into the "Help" button which was used to deliver directions and instructions.
One of the problems I noted in other attempts to present this material was the level of complexity invoked when introducing the link between electronics, logic and computer science. Sources often assumed a working knowledge of electronics (voltage, current and resistance) and even the ability to read circuit diagrams. This kind of information is not generally presented to students until they reach high school physics. Since the youngest and potentially the most interesting part of my target audience had not been exposed to these concepts, I searched for a way of graphically presenting only the information about electronics that could be understood without prior knowledge. I found a diagram in one book (Gordon et al. 1990) which revealed how an AND gate works and I used slightly modified and animated versions of that diagram as my model.
As I stated above, I decided early in the development process to use computer graphics as a window on computer processing. I chose to use only black and white pixels for my demonstration because a direct correlation can be seen between black and white and a system with only two possible alternatives (ie. on/off, zero/one, true/false). There was also a practical consideration because Hypercard, in its present form, only permits drawing and icon manipulation in black and white. My screens were designed to optimize the use of color only in cosmetic ways where it wouldn't be a significant drain on processing speed. Use of color in Hypercard is not well implemented and is limited to only a few functions. In fact, the way one has to control the color screen re-draw in Hypercard was an inspiration for the example program I used in several of the activities. The fact that a monitor must re-draw many times per second is a property of computing (and television) that is usually made invisible to the user. Screen redraw is generally part of what I think of as the computer's autonomic nervous system - re-drawing the screen is a process that occurs below the user interface level, without any user input. Using Hypertalk, the programming language of Hypercard, the programmer can force a re-draw of the screen at any point in a script. On the other hand, the programmer can request that the computer not update the screen from the buffer until a specific list of screen elements have been read out of the screen memory buffer or VRAM.
As I built the project I realized that there was a need to edit my original content plan so that all of the material presented was fully enabled. The selected material needed to be cohesive; I didn't want the omitted material to leave a noticeably gaping hole. In the end, I chose to present the aspects of computing that, one could argue, would not become outdated. Since I was very keen to illustrate a connection between the physical, electronic world and the abstract, symbolic world I expanded the hardware section significantly to present the relationship between logical operations and electronic components. This hardware section demonstrates how logical decision making can be simulated using just a few electrical components. To do this, the switches often mentioned as part of computer processing had to be graphically represented and their behavior had to be identified with computer processes that anyone could understand. With this as my primary focus, I reduced the scope of the project. I determined that it would be possible to introduce the following four concepts:
Ten buttons are accessible at all times from all screens; together these ten buttons form a frame around the center area of the screen which is used for activities and information. The ten buttons are: Graphics, Encoding, Programming, Hardware (the four subject areas), Info, Help, Quit, Restart, Sound and Map. Clicking on any of the four subject buttons takes the user directly to the first screen of that section. "Quit" quits the program. "Restart" resets all of the activities and sends the user back to the first screen of the program. "Sound" turns the sound on or off. The functions of the other three buttons, "Info," "Help" and "Map" are described below.
Info screens provide textual information about all of the processes presented; these screens are optional reads and are not necessarily required for the user to understand the significance of each activity. Each section contains at least one activity. The Info text was displayed in sixteen point (Geneva font) type to facilitate on-screen reading but I was careful to make the text only one screen long for each activity because I expected that users would rather not read large volumes of text on the screen. On the first screen of each section the Info field pops up automatically but for all other screens the Info field is a hidden element that can be accessed if the user is interested in learning more. The Info field doesn't contribute information that would help the user with functional issues in the program but it does provide context. The text contained in the Info screens can be found in Appendix C.
Help is accessed when the cursor is positioned over the mouse button; when help is selected text windows appear over the parts of the screens requiring further explanation or labelling. I chose to present the directions this way to make it possible for the user to read the directions and see what they referred to simultaneously. Unfortunately, my solution to this problem meant that the help text windows often obscured parts of the activity screen and the user could not perform the activity when the help widows were visible.
The Map button sends the user to a special screen from which he can jump directly to any activity screen or Info screen in the program. I still feel that the program works better if the user progresses through it linearly and so the map is not my preferred method of program navigation - the Map is useful because it allows users to return to screens or info that they want to see again. The Map screen represents the four subject areas of the program and the introductory section with pick lists of the titles of each individual screen. The color coding described earlier extends to the Map screen so that each subject is framed in the corresponding color.
The first screen at the beginning of the program is just a black and white title screen; from this screen the user can turn off the audio before the program begins. If there is no user preference the program default is to leave the audio on. I decided that it was important to be able to do this after I used several programs that do not allow you to turn off the audio; I also guessed that in some environments (e.g., classrooms and libraries) there might be a need to control audio playback. Clicking anywhere on the black and white opening screen launches the program into an "attract loop." This loop simply flashes the first screen of each section for about two seconds while an audio loop plays. The loop gives an illusion of animation and motion as the title of each subject area flashes in turn. The words "click the mouse to begin" appear on the bottom of the screen during the loop. If the program is restarted the attract loop is not played, instead a screen is shown with Arthur C. Clark's quote, "Any sufficiently advanced technology is indistinguishable from magic." This quotation is displayed for several seconds before the user is sent to a screen describing the various interface elements.
With the exception of the first screen in each section, the graphics are very simple and have a functional role. The screen is blocked out in a strict grid system with the location of the ten framing interface elements consistent across all sections of the program. Within each section the interface varies depending on the activity selected. Each section has at least one activity for the user to complete, each activity is meant to build understanding of the subject area. The next section introduces each activity and describes the pedagogical strategy of each.
Graphics: There are three activities in the graphics section; later screens build on information introduced in the earlier activities. The activities introduce the concept of digitized images.
Activity 1: Draw Your Own Picture. This activity invites the user to draw a picture out of small squares. Clicking the mouse toggles these boxes from white to black and black to white. The squares are simply magnified pixels but the magnification calls attention to pixels. After drawing a picture the user clicks on a large button which leads to the next screen.
Activity 2: Your Drawing. On this next screen the drawing created by the user is shown at "normal" size; that is, seventy-two pixels per inch. This makes the user's drawing about the same size as a computer icon. The small icon-like image can be magnified by clicking on a "zoom in" button - one can zoom in on the picture progressively until the pixels are about half an inch wide, then the button becomes a "zoom out" button.
Activity 3: In the final drawing activity the user is presented with a scanned bitmapped image of several pencils. The image gives the illusion that there are gray tones where there is a mix of black and white pixels. The user can zoom in and out on this image using the same interface as the previous activity.
Encoding: The encoding section demonstrates how graphical information, like the drawings presented in the graphics section, can be stored as bits of information and encoded as ones and zeros.
Activity 1: Binary Encoding. The first activity presents two eight-by-eight grids side-by-side. In the grid on the left the squares toggle between black and white when clicked. On the right, squares in the grid contain the number zero or one corresponding spatially to the black and white squares on the left; these get toggled back and forth to reflect changes made to the left grid. For example, if a white square is clicked it turns black and the corresponding square on the right grid flips from zero to one. Clicking on the numbers has the same effect in reverse as clicking on the black and white squares. Below these two grids is a small matrix of "memory cells" that also reflect the condition of the grids by placing a one or a zero in "memory locations" which are numbered from zero to sixty-three. The object of this activity is to link the concept of encoding to the representation of pixel color.
Activity 2: Painting by Numbers. The activity suggests that the user create a graphic in another eight-by-eight grid but this time the expected graphical user interface tools are unavailable; in this activity clicking on the grid has no effect. In order to flip the squares from white to black the user must proceed through the steps that are ordinarily hidden by an interface. Not all of the hidden steps are included; I chose the ones that were easiest to understand in a graphical context. In order to "draw" on this grid one must make the correlation between grid positions and numbered memory locations. The activity forces you to:
Programming: Only one activity was included to illustrate the concept of programming.
Activity: Assemble the Program. The programming activity screen begins with eight slots on the left side of the screen and eight rectangles on the right side of the screen. Each rectangle has one line of a computer program written in it. The lines are listed in an arbitrary order and the user is instructed to put the lines of this program in the correct order. The program itself is a natural language description of a program that would allow the user to draw on the screen pixel by pixel. The program makes the connection between the cursor's location on the screen and a mapping of the screen locations in memory. Several if/then statements let the computer know what to do when the mouse is clicked. Unlike the previous activities which were exploratory in design, this one has a correct solution. To help direct the user toward the correct solution the program provides a reward for each correct step along the way and a reward at the end when the program is all in the right order - the rewards are simply positive audio feedback when a line is placed in the right slot. If a line is dragged to a slot where it doesn't belong it simply springs back to its original location. When all lines are in order the screen flashes and an audio "jingle" is played. The exercise is meant to introduce the concept of programming in a way that any ordinary computer user can understand - and in a way that will not permit failure. The process described in this activity requires that the computer's next step is always dependent on the state of its memory. This theme is emphasized in other more complicated programs; VIC, for example, focuses on the condition of registers in the CPU. For simplicity's sake I've not included steps in which the contents of each memory cell are temporarily stored in a register for comparison or mathematical operations.
Hardware: The hardware section is one that I'm particularly proud of because I think it clearly bridges the gap between physical, electrical processing and the abstract programming and digital processing concepts introduced in previous activities. There are several activities in this section.
Activity 1: Logic gates. This screen introduces logic gates and their iconographic representations. The three gates introduced are the basic three: AND, OR and NOT. Each type of gate can be tested to see how it would handle various combinations of inputs. The AND and OR gates have two inputs that can be toggled between one and zero. To determine the output of any gate and a selected combination of one and zero inputs, the user must click on a large button displaying the graphic symbol of that logical operator.
Activity 2: Electronics of AND. This screen demonstrates how an AND gate can be constructed of actual electronic components. Once again the user can select and change inputs and test the circuit's output; in this example, however, the path of the current is shown and users can see how transistors act as switches. The effect of voltages applied to the transistors (represented by zero and one) can be observed as the switches open and close.
Activity 3: Electronics of OR. This activity is similar to the activity described for the AND gate above. In comparing the circuit configuration of the AND to the OR, one can see that the AND circuit is configured with two switches connected to each other serially, while the OR circuit is composed of two switches connected in parallel. These relationships demonstrate how abstract ideas in the two state system of boolean logic can be modelled in the physical world of electronic computing.
Activity 4: Electronics of NOT. This diagram is similar to the previous two except that it corresponds to a NOT gate and, thus, will accept only one input which it flips as output. In actuality it is possible to build these three gates using a variety of electronic configurations but for the purposes of these activities I chose configurations which required the smallest number of transistors. Much has been written, in computer science and engineering about the NAND gate, a gate which is essentially an AND gate with the output flipped. It is of particular interest because all of the other gates can be constructed using NANDs; I chose to omit the NAND gate because it requires a much more elaborate configuration of transistors - it would have been much more difficult for a beginner to trace the path of current flowing through a combination of NAND gates than the simple circuits I've used.
Activity 5: XOR. In this exercise the user must drag the symbol for the correct gate into the correct slot so that the final result is a functioning XOR gate. The user can determine whether the configuration is correct by trying various inputs. The XOR is a logical operator which can be created by configuring the other three gates I've introduced. It is a very simple example of how one can arrange the basic operators to perform a specific function. The function of an XOR is to compare two inputs. If both inputs are the same then the output of the gate will be one (or true/yes). If the two inputs are different then the gate will output a zero. By feeding two inputs through such a gate one can determine whether they are the same or different. This is a simple function which demonstrably occurs entirely in hardware.
For example, the Map function was a late addition to the interface; it was my response to early user testing at the Exploratorium. Several users felt that the program was too rigidly linear and they asked for a tool which would allow them to access all screens directly. Originally I had planned that the Map button location would be occupied by a "Glossary" button. The glossary would have defined a list of computer terms, but as of the beta release the glossary wasn't yet built so I chose to replace that function with the Map. The Quit, Restart, and Sound buttons were originally invisible and could be made visible by depressing the tab key which worked as a toggle. My original design was intended to keep the screen less cluttered but I saw immediately that users were not finding these buttons without additional coaching. Because of this, I opted to keep the buttons visible on the screen at all times. Another feature change made in the first week involved the way each new section was presented. In the beta version each of the four sections opened with the opening graphic for that subject area and the theme music for that section playing behind it; the first information field for the section - the one introducing the new subject - remained hidden unless the user clicked on the Info button. In the second version each section opened with the graphic and music, but after a one second delay the introductory information screen for the section was revealed using a box wipe (video effect). This had the additional advantage of creating an illusion of animation.
All features were frozen after the second release of the software on February 5 although some interactivity problems remained. Changes made after that date were either minor bug fixes or changes made to the data gathering module only. The data gathering module, an on-line questionnaire, is discussed fully in the next chapter.
Copyright © 1996 by Lisa H. Weinberg