Role of Artifacts in Programming and Physics Learning with Emile

Mark Guzdial
College of Computing, Georgia Institute of Technology
guzdial@cc.gatech.edu
Paper presented at the 1995 AERA Symposium
"Artifacts of Learning: A Perspective on Students' Learning Processes and Strategies through their Learning Products"

Emile is a scaffolded programming environment in which students created simulations and multimedia presentations in physics in pursuit of physics and programming learning (Guzdial, 1994; Guzdial, 1993). The principles that Emile was based upon were that the process of designing and creating an artifact(a simulation or presentation)would be a rich learning opportunity for students, and that with appropriate scaffolding (Collins, Brown, & Newman, 1989; Rogoff, 1990; Wood, Bruner, & Ross, 1975), students should be able to undertake this activity with little prior knowledge about programming, physics, or design. The goals that I(as the designer/developer of Emile and of the workshop in which it was used)had for the artifacts that students attempted in Emile were:

• To require a set of physics and programming concepts and skills to be used in completion of the artifact.
• To be motivating enough that students are interesting in undertaking the process and in learning and using the concepts and skills in order to complete the artifact.

This paper addresses how the specific artifacts that students created in Emile related to the kind of learning that took place. In particular, I argue that:

• Students using Emile were probably consciously addressing an unseen audience for their artifact, and that the perceived interests of this audience influenced (1)what features students included in their artifacts and(2)how motivating individual artifacts were for student learning.
• However, the artifacts themselves were not the critical determinants of the kind of learning(e.g., what skills)were gained. Rather, the process that students undertook in completing the artifact was more highly correlated with the depth of understanding and with the kinds of skills which were learned. The process that the students undertake is determined by a variety of factors, including prior knowledge, how motivating the artifact is for the students, how motivating the process is for the students, and the interaction between the students' interests and abilities with the environment in which the artifact is being built.
• The artifacts were the motivation for the students, and the characteristics of the artifacts defined the potential set of concepts and skills to be learned, but it was the process that the students undertook which determined the kind of learning which occurred.

In the following sections, I present Emile briefly(Section 1) present some of the students' artifacts and how they talked about them(Section 2) and present how student process on the artifacts differed(Section 3) and how student learning and process were related.

1. Emile

Emile is an environment where students build models and test them as simulations. They are prompted to write about what they are doing in a Design Notebook. The Design Notebook is also where students define the components of their model. The components are assembled in a Project Window which is where the simulation ran. In addition, a number of supporting facilities are provided, which can be modified from a Preferences page in the Design Notebook.

Figure 1 is the view that a student has after choosing to create a new, empty project from the File menu.

• The main window(largest, seen at front)is the Design Notebook which contains all of a student's programming representations(such as the node-and-link Project Chart view of their project) all of a student's articulations about the project(such as Journal entries and Plans) and descriptions of all the components of the project - each on a separate page of the Notebook. Components include Goals(statements of program purpose) Groups(collections of components) Buttons, Fields, and Actions.
• The window which can be seen behind the Design Notebook and to the right is the Project Window where the components of a student's project are assembled and tested. When a student completes her project, the Project Window(stored in a file separate from the Design Notebook)can be given away to others to execute without Emile - it is a standalone component[1]. Figure 2 shows a Project Window that is a simulation of two objects which fall as if under the influence of gravitational fields of different intensities.
• Not seen is the Library of components which is pre-filled with over 70 basic components before the students begin using Emile. These components include a Positive Gravity button which simulates free-fall.

Figure 2 is a screenshot of a Project Window depicting a sample of the kind of program that a student might create with Emile.

• The graphical objects Positive Gravity, Weaker Gravity, Compare Buttons, and Clear Graphics are all buttons which can be clicked on to generate program behavior. For example, clicking on Clear Graphics clears the screen of the small circles which are used to trace the trail of the buttons Positive Gravity and Weaker Gravity. Each button has a page to itself in the Design Notebook defining its appearance and behavior.
• Behavior is defined in terms of code chunks called actions. Actions are tailored by filling slots in an action. For example, an action which calculated position and velocity for an object in free fall was called Accelerated Motion and it contained a slot for acceleration.
• Positive Gravity and Weaker Gravity are the focus of the model-building in this program. Each of these graphical objects can be clicked down upon(using the mouse cursor) dragged to the top of the screen, and released - after which the object falls as if it was attracted by gravity.
• The fields in upper right corner hold text and numeric data: Labels for the fields, and the values for the objects' vertical position on the screen, velocity, and simulation time. Each field in the Project Window also has a page in the Design Notebook which describes its appearance and behavior.

Figure 1: Emile screenshot

Figure 2: A sample project created in Emile

2. Student Artifacts

Students created three simulations and one multimedia presentation in a three week(M-F, three hours a day)summer workshop. Five students participated in the workshop. Below is one of the project assignments given to the students, and two examples of student artifacts

• Project 3: Simulation of projectile motion in two dimensions. Create a simulation object(button)that has initial vertical velocity and horizontal velocity and that falls under the influence of gravity - moving in two dimensions. Your button should leave a trail.

• To use this simulation, the user clicks on and drags the Launching Thing to the starting position, then clicks on the Launch It button to make the button actually move with the given initial horizontal and vertical velocity. This is student B's first use of one button(Launch It)to control another button(Launching Thing)
• By separating off the function to clear the screen of trails into a Clear Screen button, the user can compare different settings of the horizontal and vertical initial velocities. Every launch of the Launching Thing leaves a trail. By dragging and launching the Launching Thing from the same position but with different velocities, the user can compare the trails that mark the different trajectories. When the user desires, the trails can be cleared with the Clear Screen button.
• Because the Launching Thing moves in two dimensions, it can fly off the screen in any direction. Student B decided to implement a floor for the Launching Thing and to provide a Reset button which positions the Launching Thing in the middle of the screen, no matter where it flies off to.

Figure 3: Student B's 2-D projectile motion simulation

Figure 4 is a screenshot from student C's two-dimensional projectile simulation.

• In his simulation, the user clicks on and drags the Positive Gravity button, and the button launches when the user releases the mouse button.
• The Positive Gravity button clears the screen before each launch.
• Student C didn't create an icon for his launching object.
• Student C provides a Reset button to bring the button back on the screen if it launches somewhere off screen.

Figure 4: Student C's 2-D projectile motion simulation

Generally, Student B's artifact is somewhat more sophisticated than Student C's, although not extensively. Both provide the same core functionality, and both programs work fine. Student B separated off the functionality of clearing the screen, and also spent a little more time on the appearance of his project.

Students seemed to be aiming their artifacts towards an(unseen)audience. I offer three pieces of evidence for this observation:

• Students frequently made notes in their articulations about future users of their artifacts.
• When I asked students why they used(or didn't use)certain features in their software, the most frequent response was based on what their perceived audience wanted, as in this quote from the final workshop whole-group discussion:

R: Why didn't you use multimedia in your final project?
B: My idea was a lot better than any multimedia thing.
S: There wasn't really that much you could do.  The videodisc and the CD, I mean, how many people have videodisc players and CD players?
L: If you wanted to show it to other people, it's hard.
S: And I don't consider recording sound anything special.

• At the end of the workshop, I offered students the opportunity to copy to disk any of their artifacts that they might want to. All the students took all their artifacts home with them.

3. Student Process

Emile kept recordings of events in the students' interactions with the user interface. Here's a description of how each of these two students started their artifacts:

Student B began with articulation and more creation of new objects than copying of Library objects:

• Student B began by entering a Project Description.

This project will be to create a button to launch from any particular place on the screen that the user defines.  The user can also select the velocity(both vertical and horizontal)  This will help people to understand the strange and crazy laws of physics.  So I hope you like it.

• He copied the button Droppable Object to his Notebook and tailored the appearance of his Project Chart.
• He returned to the library and coped several actions to his Notebook: Set Left of Button, Save Left of Button, Sound a Beep, and Clear the Graphics.
• He created a new button and named it Clear Screen.
• He composed the actions Clear the Graphics and Sound a Beep into the new button, then tested it five times.
• He created a new field and named it Time in Motion.
• He created two new goals and named them Initial Vertical Velocity and Initial Horizontal Velocity.
• He created two new fields and named them also Initial Vertical Velocity and Initial Horizontal Velocity.
• He composed the button Droppable Object and tested it, but received an error because some of the fields which Droppable Object required(e.g., the field Time)were not created.
• He made a Journal entry:

Today was an OK day in terms of productivity, but I didn't do that much.  This is a new project called Launching Things.  It is going to work but I don't know when.

Student C made extensive use of the library with frequent testing as he began his program three:

• First, he copied both the Droppable Object button and the Gravity Simulation group into his Design Notebook from the Library. His verbal explanation at the time was that he wasn't sure which he'd need, so he thought he would take both.
• He composed the entire Gravity Simulation group, tailored his Project Chart(i.e., organized the icons in a structure he preferred) and tested his project.
• He then emptied the slot for the initial velocity in the simulation object(Positive Gravity button)and selected the menu item to fill the slot, but canceled out of that action.
• He created a field, named it Starting Velocity, and linked it to the Gravity Simulation group.
• He then returned to the Positive Gravity button, again asked to fill the slot, and selected the field Starting Velocity to fill the initial velocity slot.
• He tested his project again with different values for the initial velocity entered into the Starting Velocity field.
• He returned to the Library and copied actions Save Left of Button, Set Left of Button, and Increment Value(which had been discussed as being useful in implementing horizontal motion)
• He composed all three actions into the button Positive Gravity.
• He ended the day with making a Journal page and typing an entry:

Today I started to create my button which will move up and have horizontal pull at the same time.

I note a difference in style between Student B's and Student C's processes:

• In general, I would characterize Student B's process as more reflective than Student C's. Student B creates a Project Description(a kind of articulation in Emile)which Student C does not. Student B creates Goals while Student C does not. Student C hasn't planned what he's going to need for this project, so he simply loads in from the Library everything that he might need.
• Student B is somewhat more playful or relaxed in his development than Student C. He attempts more than does Student C. He adds a beep sound to his clearing the screen button, though that wasn't necessary. Although we don't see it here, we know from the artifact screenshot that Student B creates an icon for his launching button, while C does not.

4. Student Learning

There were substantial learning differences between students using Emile. Learning was measured through pre- and post-workshop clinical interviews on near-transfer tasks. For example, while students created simulations of objects falling or launching, the clinical interview asked about rocks falling off buildings or people walking up the street to the local ice cream shop. Thus, the tasks were focussed on applying the knowledge to relatively common events.

On the pre-interview, neither student(B or C)was able to even attempt a problem involving calculating the time to impact and terminal velocity for a rock falling from a two story building. They both said that they had no idea how to compute that and asked to go on.

On the post-interview, Student C was again unable to solve the problem, but he had more of an understanding of what the problem was about and what variables were involved. He did not understand how the variables relate nor the causal and temporal relationships involved in the problem.

C: If you dropped it off the building, it would go out just a little bit...no, it wouldn't.  are you just dropping it?
R: You're just dropping it
C: Then it will probably fall straight down.
R: How fast do you think it's going when it hits?
C: Is this four floors?
R: Three stories
C: The only way to know exactly is if you know how tall the building is.
R: Okay, let's take a guess.  how tall do you think the building is?
C: I have no idea
R: It's three stories, let's say that it's 10 feet per story, so it's 30 feet.
C: 30 feet, so...you'd have to figure it out using that per-second-per-second.  You'd have to take the velocity that it's falling, and you have to take the...it's hard to say, I'd have to write it out.
R: Would you like pencil and paper?
C: Okay
R: <Gives him pen and paper>
C: <Draws a long vertical line>  Then you just have to guess at how fast it's going per-second-per-second.
R: Yeah, you could.  Go ahead and take a guess.
C: I guess...it's 30 meters, feet, 30 feet.  you have to get from there in 30 feet.(Motioning to his paper.) That's what...things fall a couple miles per second..  It depends on how big of a rock, how fast it's going to accelerate.

Student B, on the other hand, gave a rather sophisticated answer:

R: Can you tell me how long it took the rock to get to the ground?
B: It would be about one second
R: Okay, where did you get that from?
B: If the acceleration is 30 feet per second per second, then per second it will be going 30 feet per second, then it will just take a little longer for it to get to the ground.
R: Why?
B: Because you have to divide the, to get the average velocity, which is how fast it's going, and how you can measure how far it's gone, you have to...let's see...it will be going, it will be going 15 meters per second.  Maybe two seconds, I guess.
R: Why?
B: Because...1.5 seconds.  Because, by the time it's accelerated the second second, it will be going about 45 feet per second, so it'll have to be between the first and second second that it hits the ground.
R: In the second second, it's going 45 feet per second?
B: Yeah, I think so.
R: Where did you get that number from?
B: Umm, adding the 30 meters per second, you add that to the 45, and you have to divide it by 2.  Oh yeah, I forgot about that part.  So that'll be 22.5 feet per second.  22.5 meters, I mean, feet per second.  Then it'll probably be 2 and a half seconds.

5. Summary: Relating Artifact and Process to Learning

Students B and C built relatively similar artifacts during the Emile workshop. However, their learning was markedly different. Student B gained a greater depth of understanding of relationships between variables in kinematics and was able to explain how these variables and relationships spelled themselves out over time in a simulation. Student C did learn, but his learning was more limited: He became aware of concepts and he developed some new ideas of how to undertake some problem-solving processes.

I attribute the difference in learning between Students B and C to the difference in their process. Because Student B explored more options in his artifacts(including trying to build his artifacts at a lower-level than did Student C)and was more reflective, he had a greater opportunity(1)to understand his simulations and(2)to explore how to develop them further. There are a number of factors which might have influenced why these students' processes differed.

• Student B had more prior knowledge about the domain than Student C because he'd had a physical science class that Student C had not. (Though neither student had had any previous programming experience.) Student B expressed much more interested in video games and software than Student C. Thus, the artifact may have been more motivating for Student B, and he may have seen more potential directions and possibilities in his artifacts than did Student C.

The artifact certainly plays some role in the learning. In particular, the characteristics of the artifact define the space of potential learning for the student. The potential space is large and multi-disciplinary. For Emile, the space includes various parts of kinematics, computer science, and design. For Harel's ISDP, the space included mathematics(fractions) computer science, design, and visual design (Harel, 1991). However, the space for either project probably did not include, say, political science or quantum mechanics.

By defining the potential space of learning, the artifact is also limiting the potential motivational impact of the artifact, and thus, the process. Students who are not interested in kinematics, computer science, nor design would probably not be motivated to succeed at creating Emile artifacts.

If it's the process that determines whether learning occurs and the depth to which it occurs, the challenge for successful project-based learning is to facilitate the student's use of a good process. Such facilitations may include a constructionist learning curriculum (Harel, 1991; Kafai, 1993; Papert, 1991), a rich learning environment such as Boxer (diSessa, Abelson, & Ploger, 1991) or Emile, or a collaborative experience (Guzdial, Rappin, & Carlson, 1995; Ruopp, Gal, Drayton, & Pfister, 1993; Scardamalia, Bereiter, McLean, Swallow, & Woodruff, 1989). Process, more than product, seems to be where learning occurs in an artifact-centered learning experience.

References

diSessa, A. A., Abelson, H., & Ploger, D.(1991) An overview of Boxer. The Journal of Mathematical Behavior, 1(1) 3-15.

Guzdial, M.(1994) Software-realized scaffolding to facilitate programming for science learning. Interactive Learning Environments, In Press.

Guzdial, M., Rappin, N., & Carlson, D.(1995) Collaborative and multimedia interactive learning environment for engineering education. In ACM Symposium on Applied Computing 1995(pp. Accepted.)

Guzdial, M. J.(1993)Emile: Software-realized scaffolding for science learners programming in mixed media. Unpublished Ph.D. dissertation, University of Michigan.

Harel, I.(1991) Children Designers: Interdisciplinary Constructions for Learning and Knowing Mathematics in a Computer-Rich School. Norwood, NJ: Ablex.

Kafai, Y. B.(1993)Minds in Play: Computer Game Design as a Context for Children's Learning. Unpublished Ph.D. Dissertation, Graduate School of Education of Harvard University.

Papert, S.(1991) Situating constructionism. In I. Harel & S. Papert(Eds.) Constructionism(pp. 1-11) Norwood, NJ: Ablex Publishing Company.

Rogoff, B.(1990) Apprenticeship in thinking: Cognitive development in social context. New York: Oxford University Press.

Ruopp, R., Gal, S., Drayton, B., & Pfister, M.(Ed.)(1993) LabNet: Toward a Community of Practice. Hillsdale, NJ: Lawrence Erlbaum and Associates.

Scardamalia, M., Bereiter, C., McLean, R., Swallow, J., & Woodruff, E.(1989) Computer-supported intentional learning environments. Journal of Educational Computing Research, (1) 51-68.

Wood, D., Bruner, J. S., & Ross, G.(1975) The role of tutoring in problem-solving. Journal of Child Psychology and Psychiatry, 17, 89-100.