Greenfoot LIVE

In order to provide more ways to support teachers who are using Greenfoot (or thinking about using Greenfoot), as well as anyone else interested in Greenfoot, we are starting a series of live chat sessions:

Greenfoot Live
Programming Education Chat With The Greenfoot Team

Greenfoot Live will be a regular chat event where members of the Greenfoot team will be live online and talk about Greenfoot, among ourselves and with you – the users of Greenfoot. The event is aimed mostly at teachers who use Greenfoot in their classes, but also at general Greenfoot users.

We will discuss educational aspects, as well as general programming topics, related to Greenfoot.

You will have a chance to listen to us talk, as well as ask questions.

The first Greenfoot Live event will be held on

Monday, 8 May 2017, at 5pm UK time

That is

  • 5pm in the UK
  • 4pm GMT
  • 9am in San Francisco
  • 12noon in New York
  • 18:00 in Germany, Scandinavia, Italy, France, …
  • 2am in Sydney (sorry…)

You can join us here.

After this first event on 8 May, we will host Greenfoot Live every two weeks. Recordings of these events will be accessible afterwards for viewing retrospectively.

Don’t forget to mark this date in your diary with a big red pen and join us in a couple of weeks!

Stride: With a little help from my editor

In the third part of our series introducing Stride and frame-based editing, we look at the various ways in which the editor can provide you with help in writing your program. If you consider using Stride, it will come handy to know these sources of information.

Stride is implemented in the Greenfoot environment, available from here.

Stride: Creating a game in 7 minutes

This video is mostly for those who want to get a first impression of Greenfoot. We write a simple game in seven minutes (realtime; no cuts!), using Stride. For those who already know Greenfoot with Java: You will see that writing in Stride is not very different to writing in Java. For those new to Greenfoot: This is a quick introduction to Greenfoot and Stride at the same time.

As always, Greenfoot is available for free download.

Stride – A new programming language for beginners

At the Greenfoot headquarters, we – that is: Neil Brown, Amjad Altadmri and myself – have recently worked on creating a new language within the Greenfoot environment: Stride.

The interesting thing about Stride is not so much the language design itself, but its interaction design: editing programs involves different interactions than existing editors.

The goal is that Stride sits halfway between block-based systems (such as Scratch, AppInventor, PencilCode, Alice, etc.) and text-based editors (such as Java or Python), maintaining advantages of both.

I will start a series of posts (text and/or video) here over the next few weeks trying to tell you what Stride is and why you should care. In the meantime, you can get Greenfoot, install it, and have Stride ready to go when the introduction here starts. Stride is built into Greenfoot from version 3 onwards.

Check back soon for the first overview video.

Use the Microsoft Kinect with Greenfoot

Those of you who know Greenfoot know that one of its aims is to make programming for beginners exciting and engaging. (Those of my readers who don’t know it should have a look here.)

The most recent addition to Greenfoot is a library that allows programmers to easily use the Microsoft Kinect module with their Greenfoot scenarios. This means that you can now write simple Greenfoot games that are controlled by players body movements.

Probably the easiest way to show what I mean, is to show you what I mean. Here’s a short video:

Programming the Kinect with Greenfoot is probably the easiest way to write programs with the Kinect module. Neil Brown, one of our developers on the Greenfoot team, has adapted open source server software that communicates with the Kinect and designed and implemented a Greenfoot library that makes access surprisingly simple.

If you are interested to try it yourself — here are the detailed instructions. But beware: you might stand in the middle of your room waving your arms around for the next few days! Some people might look at you strangely, but it’s great fun.

Sharing of teaching resources – it’s about people, not about stuff

iconAt the beginning of April this year, we opened a new web site: the Greenroom.

The Greenroom is a web site where teachers who teach with Greenfoot can share resources and have discussions. It was clear for a while that sharing of resources was a powerful thing that was urgently needed for the Greenfoot community. Greenfoot is different from many other environments, teaching with it requires different projects and different ideas, and thus getting started with it, as a new teacher, is challenging. Having a community to talk to, to ask questions, to get ideas, to get tried and tested material, makes a huge difference.

Yet, this is a space where many have failed.

It is often said, with only slight exaggeration, that there are more teaching resource repositories than there are teaching resources. The fact is, countless resource repositories have been created, and most of them have tumbleweed blowing down the main street.

The typical pattern is this: A repository is opened, a flurry of activity follows, resources are submitted (often by the creators and other people personally involved or contacted), and then it dies down. A few months later, little is happening, resources are not maintained, few new resources are added, you can hear the cold wind blowing through empty spaces.

A high profile example is the repository of resources on the ACM SIGCSE website (one of the largest organisations in computer science education). It was – as far as I know – opened in early 2004, and initially attracted a good number of submissions. However, this quickly died down. Looking at the recent submissions, it seems that only four resources were submitted in all of 2008. This went down to three in 2009, with one single submission (so far) in 2010.

Now, I don’t want to pick on that one particular repository specifically. This pattern is not unsusual. I am pointing to it here as a typical example. Making repositories thrive is hard. (We have recently published a paper about this.) So, when we designed the Greenroom, we were very worried about meeting the same fate: spending a whole lot of effort in creating a repository site, only to have it die a slow, quiet death after a few short months.

I am happy to say that we seem to have avoided that fate. The Greenroom is alive and well.

From September 2009 to March 2010, the Greenroom existed as a Google Group. This gave us an excellent discussion forum, and quite poor storage of resources. Over these first six months, about 170 people signed up. Then, at the end of March 2010, we finished our custom implementation of the new Greenroom, and we were amazed at the result: even though only half of the Google Groups subscribers moved over, we surpassed the old subscriber numbers within two weeks, and then they continued to climb. Now, after eight months, we have about 900 people signed up. Lots of resources have been posted, and many interesting discussions are going on.

subscriber graph

Subscriber numbers of the Greenroom; old (red) and new (orange)

So, what makes this site work, when so many others have failed?

I think, in building such a site, you need to address a number of questions:

  • Who is allowed to upload resources? Everyone, or only trusted people?
  • How do you ensure quality? By prior review (work-intensive, hard), or do you let everything in (and risk flooding by poor quality, untried material)?
  • Do you restrict access? (If only teachers can access, you can also post exercises with solutions, exams, etc. But then you need verification.)
  • How do you maintain the resources? Who looks after them?
  • Do you store local copies of resources (which may go out of date) or links to outside resources (which may break)?
  • How do you organise searching and browsing? This requires relating resources to each other – who does that work?

And most importantly:

  • How do you make people come and submit interesting material, and participate in interesting discussions?

I think there are some design choices you can make to address many of these things. As a result, we have built a repository site that is quite different from others. We decided to not use a standard platform (because they only gave us the same old stuff that we didn’t want) and build our own from scratch. The main design choice, which makes most of the difference is this:

The site must be about people, not about stuff.

So we designed a site that is primarily about community, and then about material. There are many design details that embody this idea:

  • The main page of the site shows activities of people, not lists of things.
  • People sign up to the site, and have an ongoing relationship with it. It’s not something where you go once every two years when you redesign your course, it’s a place where interesting things are happening every week or maybe even every day.
  • People sign up with their real names, and are encouraged to post profile pictures. In the Greenroom, you move in a community of peers, not in a big, anonymous black hole.
  • The mental model is that of a staff room in a school, not of a library. It’s about meeting people, not about searching through piles of stuff.
  • Submitting unfinished resources is welcomed. We all know that most things never get finished – submitting something is better than submitting nothing.
  • The resources are owned by the community, not by single people. The edit rights follow a wiki model: everyone can edit everything. (I remember the moment in our design discussions when Neil Brown, one of our team members, suggested this. This changed almost everything. Many of the questions posted above are affected by this. Like many good ideas, it seems obvious in retrospect, but wasn’t at the time.)
  • Small contributions are welcome. Linking some related resources, for example, is a good thing. It’s quick, anyone can do it, and the wiki model allows everyone to do it.

In short: I think people should re-think teaching repository design. It has worked for us. (More details about this are in our paper.) There is daily activity in the Greenroom, many people visit regularly, we have frequent interesting discussion in our forum, and a large number of excellent resources. It has been going much better than we dared to hope.

So, if you think about designing a resource repository, think about the people, not about things. And if you are a teacher interested in Greenfoot, join the Greenroom. There are many friendly people there happy to help.

Comparing Scratch, Alice and Greenfoot

logosAt ITiCSE 2009 and again at SIGCSE 2010, we had panel session: Comparing Alice, Greenfoot and Scratch. The session came about because all three development teams – the Scratch, Alice and Greenfoot teams – were regularly asked one question: What’s the difference?

All three systems aim to let young people learn about programming. Many teachers (as well as parents or kids) have heard of more than one of them, but deciding which one to use can be difficult. While there are clear differences, the time it takes to evaluate all three of them is not trivial.

The panel session turned out to be very popular. The room was packed full, and we got plenty of questions afterwards. So we decided to create a written version of this session. And it’s now available.

We wrote a set of papers, which have now been published in a special issue of the ACM Transactions of Computing Education (TOCE). Each paper was written by a key member of the design team of one of the environments. The papers are more extensive and more in depth than the panel was (we all took the chance to write about various aspects our systems, which we had intended for some time, but never got around to doing), but they also aim to record some of the discussion that we had at the time.

Target age groups for Alice, Scratch and Greenfoot

The TOCE special issue consists of an introduction, three papers (one each) about the three environments, and a discussion section at the end. They are

(NOTE: All papers are available in the ACM digital library. ACM allows authors to also publish the papers on their own web sites. I will link to those freely available copies when they have been made available by the authors. So check back in a little while if you could not get all you were interested in.)