First Semester Reflections

Table of Contents

Introduction

One of the project proposals for the class was a proposal for building a visual programming environment that children can use to program the LEGO Programmable Brick. According to the proposal, the project team members would have to meet several requirements:

• Be willing to interact with users (high school and elementary students)

• Feel comfortable to sit in a pile of LEGO and play

• Have basic experience with Lisp

Figure 1: The LEGOgang and its Sponsor: Back Row (left to right): Alex Repenning (sponsor of LEGOsheets), Olav Lokkebo, Jim Gindling. Front Row: Jennifer Loh, Andri Ioannidou.

Soon after we came up with our initial plans for approaching the project's task, we had to do something to meet the first requirement of the project: interact with users.

It was through our Senior Project professor that we came in contact with Centennial Middle School (CMS). Our intention was to get a group of students to do our user testing with. We visited the school's Computer Club and we were amazed by what the kids could do. Anything from using drawing software to make cards and using the network to send e-mail to programming little adventure games in Basic and even C! We explained to the teacher who is in charge, Mr. Scott Dixon, that we were looking for some students that would be interested in our project and would be willing to stay with this task for the whole year. We did not require any knowledge of programming. We actually preferred to have kids with no programming background. Our only 'real' requirement was that we needed kids who would not be afraid to tell us what they really thought about the things we would have them try out and not hide their opinions by saying that they liked everything about our system. We suggested that since the teacher knew the students better, he should help us out with the selection process. He agreed on that and he said that he would talk to some kids that he thought would be interested and would meet our requirement. The next time we were over at CMS, again during Computer Club, he pointed out some (6-7) kids and we just walked around and observed what they were doing and how. We told Scott to choose among those kids and that was how the CMS group (Figure 2) was formed.

Figure 2: The CMS group (left to right): Christine, Lindsay, Kendal, Greg and Ester.

Christine is in 8th grade. She is involved in the Student Council. Lindsay is in also in 8th grade. She is interested in sports and she is in her class' basketball team. Kendal is in 6th grade. Her favorite subject in school is math. Greg is also in 6th grade. He is into fast downhill skiing! Ester is in 7th grade. All of them said that they enjoy playing with LEGOs a lot. We arranged to meet with the CMS group once a week. Since our project was at early stages of prototyping and our design was changing rapidly due to the research nature of the project, we did not want to expose the kids to an incomplete system. Therefore, we started experimenting with the existing systems: the LEGO Dacta Control System and Microworlds Logo for the Brick. Our plan was to use the two systems side-by-side. We had already played a little with the Brick and we had read papers about the Dacta Kit. However, we were interested in extensively using these systems ourselves and especially seeing how the kids would use them. We wanted to explore the differences between the two systems and to find out what kids think about programming in Logo. At first, we completely shielded them from our system and we played with them using the existing ones (Figure 3). We helped them create and program several LEGO models. Later on, we briefly introduced them to rules and then to the rule structure of LEGOsheets (on paper).

Figure 3: At Centennial Middle School: the group on the left is using Microworlds Logo while the group on the right is using the LEGO Dacta kit

All these were fun and educating for both the kids and ourselves. The kids have learned how to use certain Logo primitives to program the Brick and the LEGO components of the Dacta Kit. But what we think to be a more valuable lesson for them, is that they learn to work together in groups, cooperate with each other in order to achieve something. While we are playing, we (the LEGOgang) do not take the strict role of the educators and the kids the role of the learners. We actually learn a lot from the kids and we have gained valuable experiences that proved to be helpful in the design of our project. In this paper, we will present some of the projects that we have built with the kids, what we have learnt from these experiences and how this knowledge has affected the design of LEGOsheets.

Design Goals

Our experience with the programmable brick indicates that Logo is a very effective programming mechanism. Nonetheless, we believe that the programmability for some types of problems could be improved by using a rule-based approach to simplify the expression of parallel behavior and by elevating the role of the Macintosh through the addition of a simulation component to the programming environment:

Rule-Based Programming: Our experience indicates that the sequential model championed by Logo is an excellent match to solve sequential problems. For instance, to program a traffic light in Logo was quite trivial for the kids. However, when faced with a problem that required parallelism the kids would experience difficulties. Our hypothesis is that a rule-based approach would help the kids to overcome these problems. This may come at the cost of simplicity to express sequential problems. For instance, a rule-based approach to define the behavior of a traffic light becomes unnecessarily challenging. We will, initially, stress a "pure" rule-based approach to explore the virtues and limitations but later we may have to extend our framework with additional control mechanisms to simplify the solution of sequential problems.

Simulating a Virtual Brick: The Microworld environment is of restricted use for kids if the brick is not connected to it. LEGOsheets should be able to completely emulate the programmable brick to the point where programs can be created and tested even if the brick is not attached to the programming environment. This has economical as well as logistical advantages. Users can program the brick and experience its behavior (in limited ways not including interaction with physical reality) without the need to have the brick attached to the Macintosh. Given the typical budget of schools, the number of kids interested in programming the brick would usually be much larger than the number of bricks available. Sharing a small number of bricks becomes more feasible if the programming environment allows kids to experience the behavior of programs even without the brick. A simulation can also be a shortcut to test the behavior of a program in complex situation that would require an elaborate setup of the real brick in the real world possibly leading to extended, frustrating turn around of programming, testing and debugging cycles.

Macintosh Ports: In addition to the input and output ports of the brick, LEGOsheets offers additional Macintosh Ports that can be used, typically for debugging purposes. For instance, an input port picking up the signal from the microphone built into most Macintoshes can be used to create interesting signals based on sound. An application of a Mac Microphone input port could be to create a simple clap on/clap off device. A Macintosh output port such as a value/time plotter can be used to represent temporal characteristics of a signal. Macintosh ports may go as far as being network connections to other running LEGOsheets applications enabling distributed multi-user simulations.

Hot Sensors & Hot Effectors: While the brick is connected to the programming environment, it should be possible to switch sensor and effector ports that are part of the simulation between connected (hot) and simulated (user defined). For instance, in the case of a Braitenberg vehicle consisting of one light sensor and one motor, it should be possible to switch the light sensor and the motor between hot and user defined. A hot light sensor can reveal the range of typical values coming from the sensor at different levels of brightness. Allowing the user to set the value of the motor by increasing or decreasing it (with the cursor keys), on the other hand, is a good way to experience the range of values and how they correlate to speed and direction of the motor. This opportunity to experience the range of values for sensors and effectors is an efficient means to develop an understanding of the mapping between abstract values and physical dimensions.

Projects

The Hallway Explorer

"Visited CMS on Wednesday, and worked with the Brick Logo. Had a great time. Built a vehicle that "bounced" off the walls - together with Greg, Lindsay and Chris (Note: Chris is a graduate student from C.U., who is interested in this project and has participated in some of our visits to CMS). The kids have great ideas, but their skills in building with LEGOs impair them a bit. It takes a long time for them to build a model. Greg, who did the programming, had some trouble with the semantics/syntax of how Logo works, but I think that was nothing but normal confusion for somebody starting to program. When we debugged the program, both Greg and Lindsay figured out the problems when Chris and I explained to them how the Brick was working. For example, why the vehicle kept hitting the wall after one motor was turned off instead of reversing the direction. I told them to look for the red/green direction lights on the motor port and the problem was solved. We were using toggle (on/off) instead of rd. Greg fixed this quick. Learning Logo went really fast".

Figure 4 shows Lindsay with the Hallway Explorer.

Figure 4: Lindsay testing the Hallway Explorer (the doom vehicle).

The final Brick Logo program for the Hallway Explorer follows. It contains a loop with a call to a second procedure called crash.

The Death Project

Insight: One interesting issue in this project arose from the use of the reflectance sensor. Since it was the first time any of us used the reflectance sensor, we did not know what range of values this sensor takes when it is close to an object and when it is far away from any objects. This is where the setup picture of the Dacta Kit proved to be useful. We tested the reflectance sensor by moving it towards and away from objects and observing the value changes that was presented on the screen, on top of the connected sensor. From this, we confirmed the need for 'hot-sensors' that display their value on the screen.

Wackey

First attempt: Christine was doing the writing, and Greg was sitting next to her telling her what to write. Greg has programmed the brick once before and remembered the syntax a bit better.

Christine wanted the car to go backwards for 10 seconds before it tried to go forward again. It turned out that the concept of the timer was not completely clear so after another explanation the kids came up with the 'if' construct. Greg found, when he was shown the manual pages on the commands, that the timer had steps in ms. They then decided that they needed to wait for 100 ms. When the vehicle was tested out it ran forward until it hit something, and then ran backwards never to turn forward again.

It was in no way obvious to the kids that the 'if' statement was only checked once, and thus that this was the reason that the vehicle did not go forward again. Their first reaction was that the timing was too long and that they needed to go down to 10 instead of 100. When they explained the program, both seemed confident that the 'if' would catch the timer, and that the 'if' would wait for the statement to become true.

At this point Alex had joined us (Figure 5).

Figure 5: (left to right) Olav, Christine, Greg and Alex working on Wackey.

After Olav asked Greg if he could remember the other vehicle that he built the week before, Greg remembered the loop construct. But he was not sure what to put inside the loop, and what to leave out. After a few trials and directions the following program was the result:

The program still did not work and the kids were puzzled. The car did bounce off the wall, but it never went forward again. After a short explanation of the semantics of the 'if' statement vs. the 'waituntil' Greg decided to use a 'waituntil' instead of an 'if' construct.

Figure 6 shows Greg testing Wackey in the hallway.

Figure 6: Greg testing Wackey in the hallway.

This did not work either. It turned out that the brick's operating system had to be reloaded, and when that was done, everything worked fine. Except for the fact that the timing still was not correct. Olav suggested that Christine tried to count while the motor was spinning backwards to figure out how long it did that. She could not even get to one before it turned forward again. 100 had to be too short a time, so she wanted to do 1000.

She was satisfied with the one-second backwards run. Both Christine and Greg were very happy when the vehicle behaved the way they wanted it to (Figure 7 & 8).

Figure 7: Greg - very happy with Wackey.

Figure 8: Christine - very happy with Wackey.

The fact that the timer was counting in ms, and not in 1/10ths of a second seemed to confuse the kids. The week before they had been using numbers such as 10 or 20 to wait, and they were not completely confident with the new measure. Also, the use of a loop construct to make the program go on forever was not something they were confident with.

Insight: This experience lead us to the conclusion that it would be better not make the kids think of a loop. Furthermore, the timer should have a resolution in the 1/10ths of a second, or even seconds. The idea of an alarm, or timer that counts down, would maybe be easier for them to grasp.

Traffic Lights

Figure 9: Kendal programming the Traffic Light.

We worked together with the kids and came up with the following piece of code for our traffic light. We implemented both the American and the European traffic lights (since Olav encouraged it)! Figure 10 shows the traffic light in action.

Figure 10: Traffic Light in action.

Insight: It turned out to be really simple to build the traffic light. We expected this because of the sequential nature of the traffic light problem, which seems to map nicely to the sequential model of Logo. The only problem was that the kids were not comfortable with the idea of loops. For some reason, they expected the program to keep on looping by itself. This is one of the reasons that in our system we will provide an implicit loop so that the user will not have to worry about it.

Motor Home

Figure 11: (left to right) Kendal, Ester and Lindsay with the Motor Home.

The final code was the following:

A close-up of the motor home is shown in Figure 12.

Figure 12: Motor Home Close-up.

Insight: When we had to use the 'or' operator in the 'waituntil' statement, since none of us knew the Logo syntax for it, we suggested that the kids look it up in the manual (Figure 13). It was interesting to see their reaction: they refused to get the book and look it up! "No way!", was somebody's response. And the rest expressed their dislike for manuals in similar ways. Especially in a social context, the act of looking up things in a manual is considered "uncool." Therefore, alternative ways of doing this should be explored during our project.

Figure 13: Andri helping Kendal with the Logo Reference Manual.

LEGO Dacta versus the Programmable Brick: No more cables

The majority of the models that the kids want to build are movable models. Naturally, this leads to frustration when the models are connected to the control board via wires at all times. We tried to solve the problem by making the connections longer using series of wire connectors to make our models move further away, but this left us with even more wires to handle. The kids soon get annoyed by this situation and frequently express their preference for the Brick that disconnects completely from the computer and can move around freely (Figure 14).

Figure 14: Wires "SUCK!!!"

The Parallel Sensor Vehicle

Insight: The two sensors would need to be polled in parallel. Worse yet, different actions would be triggered depending on what sensor went off. This calls for a change of plan from Logo to one in which the sensors are conceptually polled in parallel. This is a good argument for our rule structure, which operates in a seemingly parallel manner, while still enabling sequential operations.

Interviews

Operator Precedence

It is interesting to note that Brick Logo does not use operator precedence for mathematical expressions. All expressions are evaluated from left to right. We have a feeling there was a very good reason for doing it this way, and would like to find out more about why this decision was made.

Jennifer interviewed Lindsay (8th, Honors 8th-gradeMath) and Greg (6th, Honors 6th-grade Math) about how easy it is for them to understand our current way of dealing with equations (formulas) and their sense of ordering the rules according to their importance.

Following are the notes taken by Jennifer, during the interviews with two of the CMS kids:

1) Lindsay had a little trouble with the precedence of operations, and forgot to put in the () when rewriting the equation

3 + 8*1

_____

3+1

to a one-liner, 3+ (8*1)/(3+1). She also had some trouble evaluating 8*2/(4-3)*2/(3-2); she reduced it to 16/1*2/1 (which she remembered to do the ()precedence, there are still many children in our target age group that can not. Furthermore, we feel even younger children should be able to use LEGOsheets; therefore, we are convinced that we need some type of system that helps younger children build formulas. We are also not convinced that we should not investigate using Brick Logo's method of evaluating expressions from left to right, although it is not mathematically sound.

Calculator Metaphor as a Formula Builder

All the students we interviewed seemed to like using calculators. We presented all students with the following problem:

5 + 3

_____

6 - 2

First we asked all children to work the problem out in their head and tell us the solution. All did, and all told us the correct solution.

Next, we asked all to solve the problem using the calculator. Although this is a trivial problem to solve manually, we asked all students to work it out on the calculator as though it were not trivial (no shortcuts).

All of the children, except Christine, used the same procedure:

They all started by typing in "5 + 3" and pressing "=".

After this, all of them realized there was probably going to be trouble. After thinking about it for a few minutes, they decided to go ahead and try their first method. They pressed the division operator and then typed in "6 - 2" and hit "=". Of course, they all realized, as they expected, that the answer was wrong, so they started over. Next, all of them decided that they should store the first result, so they wrote it down on paper. Next, they solved "6 - 2" and wrote it down, then they got the solution using the intermediate results of "8" and "4".

Christine used the parentheses on the calculator to surround the "5 + 3" and the "6 - 2" and therefore got the correct answer the first time.

We asked all students that wrote intermediate results on paper if they would find it useful if the calculator had a memory so they could store the intermediate results in the calculator, and all universally agreed it would be a nice feature (which of course the calculator has anyway).

We felt this was fairly strong evidence that our calculator metaphor may be useful. We prototyped a Formula Builder, which looks just like a calculator, except it also has text boxes that act as memory cells. At any time, the user can move an expression from the main cell to one of the memory cells. When the expression is moved from a memory cell to the main cell, it is surrounded by parentheses. The calculator also restricts which keys can be pressed at any time and also dims the 'OK' button when necessary. This has the effect of forcing the user to enter a correct formula from the start, and also guides them as they build the formula by not allowing them to press keys that will make an invalid formula.

Insight: Children like to use calculators, and we feel this may be a suitable alternative for those who have trouble dealing with typing formulas out by themselves. However, we are not sure if the memory function helps or not. Unfortunately, we have not had a chance to do any user testing on our prototype.

Children's Reaction to Rules for Defining Behavior

All the children found rules a little weird at first. Most did not know at what level they should start, and Jim told them to pretend that the robot knows how to peddle and stay balanced and the such, but does not know the rules of the road. Most came up with a first rule like: "If you are on a bike, peddle." For each rule they came up with, Jim would pretend he was the robot and was riding a bike and would run into a wall or get hit by a truck or something to illustrate the need for an additional rule. The children quickly learned how to solve the problem he illustrated by introducing a new rule, such as "IF there is a wall in front of you, stop peddling and apply the brakes." Although apprehensive at first, the children seemed to become comfortable with using rules to define behavior, although they admitted that it was still a different way of thinking.

Insight: Most children find using rules to solve problems a little strange at first, but soon learn how to use them effectively to solve their problems.

Case: Rules for Robots driving cars

With this scenario, where Greg had to teach his robot what to do when comes to a traffic light while driving a car, the following are the four rules that he came up with:

2 IF: Robot sees a red light

THEN : Push on brake

1 IF: Robot sees a yellow light

THEN : Push on the gas

4 IF: Robot sees a car in front

THEN: Push on brake

3 IF: Robot sees a green light

THEN: Continue going at same speed

Introduction to the LEGOtalk Rule Structure

Christine (8th grader) had been exposed to both the LEGO Dacta Kit and the Brick and experienced programming in Logo. She was asked to rewrite a program that she helped writing earlier in Logo, into our first phase design of the LEGOtalk Rule Editor on paper. The program was 'Wackey', which is described in an earlier section.

When she started rewriting the program in LEGOtalk Rules, at first, she had a little trouble understanding the Sequencer used in the LEGOtalk Rules to keep track of the different states and their timing. After explaining to her what the Sequencer does, and what it is used for, she picked it up rather quickly. She then used it for the backing up state for the vehicle and had a 2 second timing associated with it.

The LEGOtalk Rule Editors were shown to Christine a little out of order when we did this user testing, since we only had the different Rule Editors on paper. Christine was a little confused about which Rule Edito r she would see at what point in time. But this should be much more clearer to children once we get the LEGOtalk Rule Editors prototyped and they are shown to the kids on screen.

Insight: The positive feedback we got from Christine was that the LEGOtalk Rule Editors were structured in a way that she could just read through the items in the Editor and it would make sense to her what was going on. She did not have to memorize, or look up, any syntax involved with a typical programming language, such as Logo, when she was using the LEGOtalk Rules. Greg also liked using the rules to solve the problem better than using Logo because "you do not have to remember all the syntax." He was able to solve the problem without intervention. This was strong evidence, in our opinion, that we made be headed in the right direction with our rule structure.

Future Work

Acknowledgments

Go Back to the LEGOsheets Home Page