Session 11b5 Introducing High School Students to Event ... - CiteSeerX

Session 11b5 Introducing High School Students to Event Driven Programming1 R. Raymond Lang and Marguerite Saacks-Giguette Computer Science Department Xavier University of LA New Orleans, LA 70125 Abstract – The SOAR 3 Program at Xavier University of Louisiana is a summer bridge program for rising high school seniors and recent high school graduates planning to major in a computing discipline. The 4-week program offers instruction in quantitative and verbal reasoning, problem solving, and college vocabulary. The program features daily laboratories that expose program participants to subject material found in a typical college computer science curriculum. The labs are organized into 4 sequences or tracks: CS Software, CS Hardware, Math, and Physics. Each track consists of four 3-hour modules. In the CS Software track, we expose students to some of the basic concepts and terminology pertaining to graphic user interfaces and event-driven programming. Over the course of the four CS Software modules, the students use Asymetrix Toolbook II Instructor to explore and gain familiarity with the use of buttons, dialog boxes, and other GUI components. Their experience is set in the context of developing a simple GUI application that accumulates the total distance of a trip as the user clicks cities on a map. The application shows the trip as lines connecting the cities the user has clicked on; it also contains undo and reset buttons. In addition to their exposure to GUI components, the participants also receive exposure to important computer science concepts such as objects and their properties, events and event handlers, selection and repetition structures, stacks and their associated operations, and the use of a development environment to create, test, and deploy an application. In the paper, we will discuss the structure and content of the modules in more detail. We will also discuss what motivated us to develop this series of modules.

Introduction To address the problem of small numbers of computer science majors, the authors collaborated in the development of a program to increase the number of computer science majors. This program took the form of a summer bridge program for rising high school seniors and graduates. The program, SOAR 3, introduces the target group to computer science and motivates them to choose computer science as a

major. It is funded by a grant awarded by the National Science Foundation’s Minority Institutions Infrastructure Program. In this paper, we give an overview of the program and provide details about one aspect of the program in which participants gain hands-on exposure to central computer science software concepts.

History and Overview of the SOAR Programs SOAR is an acronym for Stress on Analytical Reasoning. The SOAR 3 program is an intense four-week program featuring inductive reasoning laboratory exercises emphasizing computer science concepts. We modeled SOAR 3 very closely after SOAR 2, a bridge program for students interested in engineering, physics, and mathematics. SOAR 2, in turn, was modeled after the original SOAR program, targeted to students planning to major in biomedical and health sciences. All the SOAR programs have had a major impact on Xavier’s participating departments. The original SOAR Program has contributed to Xavier’s becoming number one in the placement of African Americans into medical school. Since the inception of the SOAR 2 program in 1987, enrollment in the Xavier Engineering program has more than doubled. We have built on the past success of the previous SOAR programs by developing a program specifically tailored to students interested in majoring in a computing discipline (computer science, computer engineering, or computer information systems). Rather than teach content explicitly, the SOAR programs strive to improve problem solving ability. Participating students attend 3-hour discovery labs designed to exercise a student’s inductive reasoning and general problem solving skills. Students also receive instruction designed to strengthen the verbal and quantitative skills as well as critical reading abilities required for understanding textbooks, answering exam questions, and improving their performance on standardized tests. Other components are general vocabulary building and group competitions. All the SOAR programs follow a similar pattern of group structure and group leaders. Groups of between 15 and 20 SOAR 3

1 This material is based upon work supported by the National Science Foundation under Grant No. 9522079. 0-7803-5643-8/99/$10.00 © 1999 IEEE November 10 - 13, 1999 San Juan, Puerto Rico 29th ASEE/IEEE Frontiers in Education Conference 11b5-9

Session 11b5 participants are led by a successful Xavier computer science major. The group leader remains with his/her group most of the day. He/she helps administer the quizzes, helps conduct some laboratories, eats lunch and dinner with the group, conducts verbal and quantitative reasoning classes, conducts vocabulary sessions, and helps supervise other activities. [1] The SOAR group structure serves several important purposes. First, small groups enable each participant to receive personal attention so that he or she can reach his or her maximum potential. Second, the group structure guarantees that each SOAR student will become acquainted with a successful minority student from the discipline. The group leader functions as a role model old enough to win the participant’s respect, but young enough to identify with. Third, since groups, not individuals, are recognized in group competitions, the group competitions encourage the participants to work together. Thus, they learn to develop a peer support system based on academics, a skill that will increase their chance of academic success in the future. [3]

•

The SOAR 3 Program

•

Participants in SOAR 3 study Computer Science Software, Computer Science Hardware, Mathematics, and Physics. Each subject track consists of four sessions. Each session is led by two instructors with the group assisting. The Mathematics and Physics sessions were developed for the original SOAR Program [1]. Because SOAR 3 is geared for students who express interest in a computing discipline, the program introduced two new subject tracks of four modules each: CS Software and CS Hardware. The CS Software modules emphasize theoretical computer science concepts and abstractions, while the CS Hardware modules illustrate the physical implementation and organization of computers. In keeping with the SOAR paradigm, all the modules include activities requiring problem-solving, analytical thinking, and/or synthesis of ideas.

Motivation for the CS Software Track Our original design for the software track was four independent laboratories focusing on software control structures, basic algorithms (sorting and searching), graph theory, and languages. After the first summer of the program (1996), the algorithm module was eliminated and the languages module was expanded to a two-part module that we used for the summer 1997 edition of SOAR 3. In preparing for the summer 1998 SOAR 3, we reflected on the following informal observations: •

Although most incoming freshmen computer science majors had used GUI programs, they were unfamiliar with the concepts of graphic controls and events.

More generally, many incoming majors had only a vague idea at best of what computer science is about. When asked why they chose to major in computer science, many students would give a reply reflecting that they enjoy using computers, but are not necessarily interested in the inner workings of a computer, let alone their theoretical underpinnings. Our observation is that such students are at high risk to change majors once they discover what computer science entails. To remedy this situation, we wanted the SOAR 3 program to provide participants with exposure to the subject matter of computer science so that they can make a more informed decision when choosing to major in computer science. Toward this end, for the summer 1998 SOAR 3, we dedicated the entire software track to a single programming project that would introduce participants to the following concepts: •

• • •

graphic controls, events, and event-driven programming, operation and use of an object-oriented development environment, selection and repetition structures, stacks, and user-interface design and application deployment.

Obviously, we do not expect that, over the course of four 3hour laboratories, participants will become proficient GUI application programmers or that they will retain much of the material they see. Our primary objective is that participants learn what the field of computer science entails. They do this by performing some of the tasks they will learn and exercising some of the skills they will acquire once they become computer science majors. Our goal is to give students a preview of what computer science entails in order for them to be able to decide whether they truly wish to choose it as a major course of study. Our expectation is that students who major in a computing discipline after having been through SOAR 3 will be more likely to stay in the major since they will already have some idea of what they’re getting into.

Overview of the Software Track Over the course of the four (4) laboratory sessions, SOAR 3 participants use Asymetrix Toolbook II Instructor to construct a simple GUI application that accumulates the total distance of a trip as the user clicks cities on a map. The application shows the trip as lines connecting the cities the user has clicked on; it also contains undo and reset buttons. The total distance of the trip is shown in a box, and the distance is updated as the user adds and deletes cities. The objectives of the track are to give participants:

0-7803-5643-8/99/$10.00 © 1999 IEEE November 10 - 13, 1999 San Juan, Puerto Rico 29th ASEE/IEEE Frontiers in Education Conference 11b5-10

Session 11b5 1.

an introduction to software as a collection of objects having properties and behaviors that send messages to other objects and respond to messages received from other objects (object-based computing), 2. experience using an integrated development environment to construct successively more refined versions of an application (incremental development), and 3. a completed, standalone application that each participant can take home with him or her. Upon arriving for the program, each participant receives all the materials they will require over the course of the next four weeks. Among these materials is a laboratory manual containing instructions for all four subject tracks.

The First Session The first 3-hour session has two objectives: (1) students should have an overall idea of what the finished application is and how it is supposed to work, and (2) students should be familiar with the fundamental operation of the Toolbook system. After using a finished sample of the project they will be creating over the next four sessions, the participants work through a custom-written tutorial covering those Toolbook features the students will use to develop the application. These include file operations, creating and modifying graphic objects and controls, creating and using scripts to define responses to events, and using controls for end-user I/O. Step 3: Using the Tool Palette to create a push button The long, narrow window on the screen is called the Tool Palette. It is used to simplify creation of graphic user interface components such as buttons, fields, and menus. • If you left the program in reader mode, switch it to author modeMove the mouse pointer over any of the items in the Tool Palette and pause. Observe that a small box will appear. The box tells you what component that button will create in your application. • Locate the item for Push Button and click. The mouse pointer will change to cross hairs • Move the pointer anywhere in the main TBII window. Click and, while still holding down the button, move the pointer down and to the right. A push button will be added to your application. The size of the button will depend on where you release the mouse button. Figure 1. Steps Needed to Create a Push Button from Participants’ Manual.

In developing the exercises, we made no assumptions about prior experience or knowledge. For each topic presented, an explanation is given about the material, then the participants follow detailed step-by-step instructions to perform the activity. For example, Figure 1 provides an excerpt from the participants’ manual that explains the steps needed to create a push button. In composing the manual, we made an effort to let the reader know in detail how their screen should appear, what to look for, what will happen when they take the action, etc. The manual includes numerous screen shots so they can verify that they are performing the actions correctly. In keeping with the spirit of the SOAR programs, embedded throughout the manual are questions designed to lead the participant to think about what they are doing rather than merely following instructions. For example, when they reach the section on user input, they follow instructions to create any graphic object and attach the script provided in Figure 2. to handle doubleClick ask "Enter your name:" if It is not null then request "Welcome to the Tutorial," && It end if end doubleClick Figure 2. Script for Graphic Object The script uses the Toolbook variable “It” but does not provide an explanation of the variable; instead, after creating the object, attaching the script, and observing how it works, the student is asked to write in their manual answers to the following questions: 1.

2.

Why do you think the welcome message is displayed exactly as it appears in the script, but the word It is not displayed? What is displayed after the welcome message? What does that have to do with It? What do you think is the purpose of the && in the above script?

Other activities conclude with invitations for the participant to explore further features coupled with workbook questions they must answer by means of experimentation with various Toolbook mechanisms. For example, to introduce the operation of Toolbook’s property browser and property editor, they work through an activity in which they create a push button object and set the caption property (the text which appears on the button). Upon completing the activity, they are asked to experiment with properties not covered in the activity. Then, they must figure out for themselves which property controls the color


Session 11b5

Define at least five handlers for different mouse events. You may put them on separate objects or all on the same object. Below are some ideas for possible responses you may wish to define: • change the color of the button when the mouse passes over it, change it back when the mouse moves away from the button • create some other objects on the page such as rectangles, circles, or a compound object. Have selected objects change color or position in response to a mouse event sent to a push button. • have an object change position on a double click. • ask for the user’s name when the right mouse button is clicked over an object, display the name in a field on the page. • place a few different objects on your page, display the color (or some other property) of an object in a field whenever the mouse passes over it. Figure 3. Session 1 Concluding Exercises. of the button and which property controls the color of the caption. By the end of the initial three-hour laboratory, participants have created and explored the operation of a variety of graphic objects and GUI controls. In the workbook, the first session concludes with the free-form exercises provided in Figure 3. The manual contains all the reference information required to complete any of the above exercises, such as the names of the various mouse events described (e.g. mouseEnter, mouseLeave, buttonDoubleClick, etc.).

The Second Session Having become familiar with some key Toolbook features, the participants are prepared in the second week to begin work on an actual application which presents an end-user with a map containing a collection of clickable buttons at specific locations. The user specifies a “tour” of several locations by successively clicking on the locations the tour will visit. After clicking to indicate the starting point of the tour, each successive click causes (1) an arrow to appear from the last location to the newly clicked location, and (2) a field containing the total distance of the tour to be displayed in a box on the map. The application also has an “Undo” button to remove the most recently added location from the tour (and appropriately update the distance) and a “Reset” button to clear the entire tour and reset the distance field to zero. In the second three-hour laboratory, participants develop the application up to the point where (1) lines are

drawn as the user clicks on locations and (2) the undo and reset buttons are in place. In the process of developing the initial stages of the application, participants explore the following topics: • • • • • •

organizing an application with user-defined messages and message handlers (functional decomposition), shared scripts (control abstraction), creating and referring to user-defined properties (programmer-defined variables), selection control structures, an overview of stacks, and repetition control structures.

The exercises in the second week provide participants with their first taste of programming. In week one, the participants were introduced to the notions of a handler and a message; in week two, they see how they can define their own messages and handlers to create behaviors not already pre-defined in Toolbook. The manual explains that behaviors be created by composing a series of instructions. The entire series of instructions can be made to execute by organizing them as a handler for a user-defined message. Thus they get a glimpse of functional decomposition, although the manual does not use the term. Because all the clickable locations will behave in fundamentally the same manner, they will all share one script defining the desired behavior. Thus the students gain exposure to the concept of control abstraction, although again the manual does not use the term as such. They create the various behaviors in stages. At each stage, they are given a code segment to enter along with a line-by-line explanation of the code. For example, Figure 4 provides a code segment that causes a line segment to be added when the end-user clicks a location. The Toolbook script editor performs syntax checking on scripts when they are saved; so the students, especially those that are not careful typists, learn what syntax errors are. to handle addCity set checked of target to true set newPos to position of target draw line from lastPos of this page to newPos set lineEndStyle of selection to solidTail,openHead set lastPos of this page to newPos end addCity Figure 4. Code Segment. The script as given above is incomplete. Specifically it causes a run-time error since the user-defined property lastPos of this page is initially null. The manual


Session 11b5 walks the participant through the steps of entering, saving, and testing the script, whereupon the error occurs. Before advancing to the next section, they must think about what happened and answer the following question in their manual: Click Edit to open the script editor. The point where the error occurred will be highlighted. This error occurs because the user-defined property lastPos, does not yet have a value. It won’t have a value until the second time the user clicks on a city. Why? Thus the manual motivates the need for selection control structures, which is the next activity. After modifying the script with the appropriate selection statements, the students’ application will draw lines from location to location, but they have to use author-level controls to delete lines. In order to create a button which will allow an end-user to remove the last line added to the tour, they are introduced to the concept of a stack (which Toolbook supports as a built-in type). They use the stack to store the locations the end-user clicks on. They then create an “Undo” button which removes the most-recently added location from the tour and deletes the line ending at that location. From there, it is only a short step to creating a “Reset” button which uses a loop to undo all the locations, thus introducing the concept of repetition.

The Third Session Having created the basic behavior of the application, the participants are prepared in the third week to enhance their application with features intended to make the application easier for an end-user to use. This is motivated in the following introduction to the third week’s laboratory: In the early days of computing, most of the people using them were specialists who had a great deal of knowledge about how the machine worked. Frequently, computer users wrote their own programs, which meant the programmer had a pretty good idea of how the user would use the program (since the programmer and the user were the same person!). Likewise, the user had a very detailed understanding of how the program worked, since the user wrote it! Now, of course, it is much more likely that the person using a program did not write it. Similarly, programmers must construct computer programs that non-computer-specialists will be able to use without a lot of trouble. Very often, the user of a computer program has little or no knowledge of the internal workings of the machine or of the program. This means that the

on-screen instructions and controls (i.e. the userinterface) must be clear, direct, and consistent. These qualities are summed up as “userfriendliness.” A successful program must be easy to use by members of its intended audience; it must make it easy for the user to provide necessary input; and it must compute its results accurately and make them readily available to the user. Keep these principles in mind this week as you add further features to the Tour Planner. [2]

In the third week, participants add the following to their application: • A box which displays a message telling the end-user what to do. The contents of the box change depending on the state of the application. If no locations have been clicked, the field displays the message “Click on the first city of the tour.” If at least one location has been clicked, the field displays, “Click on the next city of the tour.” • A box which displays the total distance of the tour from the first location to the last location. The distance is updated whenever the end-user adds a location, deletes a location, or resets the entire tour. • A mechanism whereby the end-user is able to set the scale of the map. The scale is used in the calculation of the total distance. The “look” of the application is left up to the student; but the manual encourages the student to consider user-interface issues. For example, they are encouraged to experiment with various colors for the prompt field and the text which appears in it; but in choosing a color combination, they are asked to evaluate the combination for readability (e.g. yellow text on an orange background is hard to read). Likewise, they may experiment with different typefaces, sizes and styles for the message texts.

The Fourth Session In the final session of the software track, participants complete their application by going out onto the World Wide Web to find a map to use as the background of their application. Once they find a map, they import it into their Toolbook file and position the buttons as they see fit. Then they use Toolbook’s Setup Wizard to create a series of distribution diskettes which will install their application on any Microsoft Windows-based PC. Since most SOAR 3 participants are between their junior and senior year of high school, this enables them to return to their high school in the fall with a reasonably sophisticated application they developed at the program. This helps to serve our purpose of promoting the program in the high schools.


Session 11b5 Conclusion and Future Plans Our initial experience with this series of modules was very positive. Although we did not conduct a formal survey which examined reaction to the software track, our observation was that the participants very much enjoyed creating a GUI based application and most maintained a high level of enthusiasm for the project throughout the four weeks of the program. This is very significant since the SOAR 3 Program as a whole is very demanding and it is very common for energy levels to wane about halfway through the third week as participants become tired and the daily routine loses its novelty. Our plans for the 1999 edition of SOAR 3 will include: • •

•

Tweaking the manual to improve the discussion at certain points where we observed that many students got confused about what they were supposed to do; Adding more thought questions and allowing more space in the manual for students to write their answers. Our observation was that students tended to skip questions and plow straight through to the next thing they had to do or code segment to type in; and Develop a pre-test and post-test specifically covering concepts presented in this track and in the hardware track. We are especially interested in determining whether the two computer science tracks meet our overall objective of giving participants a better understanding of what the field of computer science is and the study of computer science entails.

Critical to the success of this subject track is the fact that there is a very low instructor-student ratio. In all the SOAR 3 discovery labs, there are two instructors. In addition, the group leader is expected to assist the instructors. This is especially important with this subject track since most of the participants have no prior programming experience.

References 1) Carmichael, Jr., JW, et al. Project SOAR: Stress on Analytical Reasoning, Second Edition, Stipes Publishing Company, Champaign, IL., 1989. 2) Lang, R., Beaubouef, T., and Giguette, M., Project SOAR Computer Science Hardware and Computer Science Software Modules, Xavier University of LA, 1998. 3) The SOAR2 Handbook, Xavier University of Louisiana, 1994.
