Greenfoot: Further Examination

Greenfoot is a Java framework and IDE designed for introducing high school students to programming. Since I teach just such a course, it's of considerable interest to me. As I mentioned in an earlier article I have started trying it out. I have a pair of summer students who have been using it for the past 3 days, and I have been working with it myself.

I approached Greenfoot with some ambivalence. It looks like more than I could hope for, teaching OO concepts through graphics, allowing easy first-day programming, while teaching a real language and not heading the student into a dead end teaching language.

However, the concern that nagged me was whether Greenfoot was too "candy coated." Would students use it only at its lowest levels and not want to move from treating it as a game console to using it as a development system? Would there be a gap between the demo materials and further progress?

I've worked with several other systems in the past where this has been exactly the case. They do something very limited very well, then require a big jump in knowledge to advance that ends up taking more effort than learning without the system would have.

There's also the matter of how well any knowledge earned within an artificial system translates into skills outside the system. All too frequently students end up knowing the classroom system, but not able to translate that into something useful outside of class.

I work very hard to avoid this. There are a plethora of packaged systems that make the teacher's job easier, but do nothing for the students, or worse, waste their time and energy and leave them discouraged. I prefer using real world materials in class. There are seldom good classroom materials available for these, so it takes more work. Also, I have to be careful about the scope of what we do in class. It would be easy to overwhelm the students and end up doing as much harm as a poorly made pedagogical system.

But I would rather have a class of limited scope that teaches practical methods than one that just fills checkboxes.

Enter Greenfoot. It's made by the same folks who made BlueJ, an educational IDE that I really like a lot. Its mechanisms for interacting with classes, objects, and methods looks like a perfect solution for visually demonstrating these concepts in class. It provides a development framework that lets students jump right in on graphics programming. The developers have stated they want to make learning to program as fun and straightforward as it was in the days of BASIC. If I didn't know better, I'd think they got their specification by reading my mind.

Reality check. I've made mistakes before. I've gotten overenthusiastic about something, and missed obvious flaws. I've got a scar for every point I made about flawed pedagogical systems above. There are gaps between intention and result, between desire and ability. My own judgment is flawed. I'm an experienced programmer, and though I've developed an artificially-derived beginner's viewpoint as an experienced instructor, it's not an actual beginner's viewpoint.

That's where testing with real students comes in.

I've got two students, ages 13 and 16, who have spent three class sessions with Greenfoot now. I haven't been running things the way I would in a normal class. Rather, I've been seeing how much Greenfoot can do for them with the least involvement on my own part.

Both students had made a start in Java before I introduced them to Greenfoot. The younger one had done exercises from a textbook using a graphical editor and command line tools. She had also done some minor programs of her own design, but generally hadn't shown any inclination to develop her own programs even though she has expressed interest in becoming a professional programmer.

The older student has a familiarity with using command line tools, but prefers to work in a simple IDE, either BlueJ or Arachnophilia depending on what she's doing. She hasn't developed as extensive a knowledge of Java and programming, but she's done more with what she knows. She writes her own simple command line applications.

The differences are normal for different ages and dispositions.

Neither student really understood classes, objects, methods, and so on. The younger one has been introduced to them, the older one had heard of them but not studied them formally. In both cases I have been concentrating on getting them through the mechanics of programming to the point where they start having questions about larger issues before we really get deeply into OO. I mention OO concepts frequently as we go, but don't stress them. We use good OO practices right out of the gate, however.

I decided to interrupt our summer session to give Greenfoot a try. They've both been enthusiastic about it. Not only because it looks like getting class credit for playing games. They both have a real desire to write their own programs.

For our first session I let them play with Greenfoot after we watched a presentation on Greenfoot. That was as far as we had gotten as of my last post on Greenfoot. I was hopeful, but my doubts were still intact.

We've since had two more sessions, and I've had more opportunity to assess what the students have learned and get a better sense of where things are likely to go.

Both students started using Greenfoot as a sort of game system. Good enough. As a game system its simplicity invites the student to come up with their own ideas. My experience is that if you sit a student down with a Halo, Mario Carts, Zelda, or other A-grade games there's little or no desire to produce something of their own aside from a bit of daydreaming. If you set them down in front of a 1970s Pong, Pac-Man, or Space Invaders they start developing their own game ideas spontaneously. They'll grab some paper and start drawing out their ideas, or start developing involved game concepts verbally with their peers. What's interesting to me is that these concepts are not derivative ideas. They'll start with the concept of playfield and sprites and start developing ideas completely tangential to whatever games they've been exposed to.

Greenfoot possesses that same quality. Greenfoot's provided scenarios both in the original download and on the web provide the same jumping off point for creative thought as old video games. The integration of scenario downloads into Greenfoot's menus is an excellent little feature. The students don't have to leave Greenfoot to get new scenarios.

A few of the scenarios are somewhat frustrating to play as provided. At first, this can lead to frustration. It also provides an opportunity for the instructor to ask, "Why don't you change it to make it work better?"

The 16 year old began making code changes without prompting in the second session. The younger one showed some mild resistance to shifting gears from playing through the catalog of games to doing something more than changing images. Once over the hurdle, however, she did fine.

This set my mind at ease about whether Greenfoot would become a source of contention in class if I introduced it. If any student were going to turn sullen and resistant toward moving on to programming from pure play, this one would be the one. So, I think I'll be able to steer a full class into using Greenfoot as more than a video game system.

The older student's ideas soon outran her abilities, causing frustration. We reviewed the specific features she wanted to implement, and identified existing scenarios she could look at for examples. Now she has managed to implement some of her ideas, and the confidence she's gained is keeping her from getting frustrated while implementing others.

Once the younger student started modifying scenario logic, she came up with complicated ideas for reworking the ant simulation. She got hung up, then we talked. Now she is progressing with incremental changes of far less scope, and using what she learns to guide her ideas.

My doubts are beginning to be put to rest. I'm still concerned about taking things from within Greenfoot to outside of it. I'm in no hurry, but it's the next major hurdle I see. Meanwhile, I'll be using Greenfoot for more formal learning--teaching with flow control, iteration, and so on.

I'm also interested to see whether either of the students takes what we learn in Greenfoot back to their prior working environment on their own. The older student has a text game of her own she was working on, and it'll be interesting to see if she goes back to it with lessons from Greenfoot.

The students have a firmer idea of the relationships between classes, objects, methods, and fields than before. The younger one was still unclear when we started talking, but Greenfoot gave us a basis for discussion. In just a few minutes, she understood the purpose of a class versus an object, the relationship between the two, how to identify a method, and a had general idea of constructor methods. We're still working on fields.

The older student now has these pretty well down. She understands the relationship between subclasses and their parents well enough to introduce superclass and overridden methods. She said "I know how to create subclasses in Greenfoot, but I don't know how to do that in my programs I write from scratch." A few minutes later, we'd worked through two examples of subclassing using extends and she has it. Magic!

So far I'm extremely pleased with Greenfoot. I'm hoping to get a third student to give it a try. She's a friend of my two present students, and out of classes for the summer. The other two are going to show her Greenfoot and see if she's interested in trying it out outside of class. They're both already using it on their systems outside of class. Another point of view is always welcome, and this other student is very introspective and very outspoken.

I'll post more as we continue. I need to make more time to review the available materials for Greenfoot, and start planning how it'll fit into my class. At this point, I think it's safe to say I'll be using it.