making a branded “Sugar on a Stick” USB key. We could even sell them on the website.
X: What about getting Sugar onto other platforms?
WB: We’re continuing to work closely with OLPC on all their deployments. The talk about putting Windows on the XO has been going on for 18 months and there is not a single Windows deployment on OLPC hardware anywhere in the world, because it doesn’t work yet. So OLPC and Sugar are still very tightly related. But we’re also working with a number of other laptop manufacturers. For example, there is a MIPS-based machine called Gdium . They’re building some exciting hardware, and we’re talking with them about how to get Sugar on that. We’ve also ported Sugar to all the major netbook configurations, so it now runs on the [ASUS] Eee PC, the [Intel] Classmate, on any of those devices, essentially. So again, what we’re trying to do is broaden the choice of hardware, so that people can use Sugar on whatever hardware they can get their hands on.
X: You also have a major new release of Sugar coming out—Sucrose 0.84. What’s new and interesting in that release?
WB: Yes. We are actually about to have our second major release since we’ve been standing on our own. It’s coming out in March. The new features coming in 0.84 are mostly in the area of what we call the Journal. The Journal is a core Sugar idea; it keeps track of everything you do. It’s your diary. What we’ve done with this new release is, we’ve just done a much better job of integrating the Journal into Sugar as a whole. We’ve separated the Journal into two components. One is actions or verbs, and the other is objects or nouns, to make it easier to organize.
X: What do you mean by verbs and nouns?
WB: Right now, we record in your journal not just what you make but how you make it. But in the earlier version, people were a little bit confused about whether they were actually accessing the program they used to make an object, or were accessing the object itself. We’ve brought more clarity to that. We’ve also made it a lot easier to retrieve things you’ve been working on. In earlier versions, you had to go into the Journal to get a recent document, and now the recent documents are directly accessible from the Sugar equivalent of the Start menu. It makes it a lot more fluid and accessible.
But there’s a pedagogical aspect to the work as well. I’ve been working very closely with a Boston University professor, Evangeline Harris Stefanakis, on a portfolio activity. The idea is that you don’t just have this collection of things, but you also have a tool that allows you to make a presentation. Maybe it’s once a month or once a semester—however often the teacher wants to do it–but the idea is you can go in and select the things that were the important moments from that term and make a portfolio presentation of those moments. It’s a nice balance to the standardized testing that seems so prevalent in the world these days. There are actually whole nations moving toward portfolio assessment, including the UK, and it’s becoming much more prevalent in this country.
So we have a really nice portfolio tool built into Sugar that allows you to take this history of what you’ve learned and use it as the focal point for a conversation between the learner, the teacher, and the parent…We don’t just capture what you have made, but we also capture the process. So we have a little thumbnail associated with everything you do. A description of what you did in the journal automatically becomes the text of your slide. When I give conference talks now, I use the Sugar portfolio tool.
X: Both the Journal improvements and the portfolio tool sound like they’re intended to adapt Sugar to fit better with practices in the classroom.
WB: Part of it is to make it fit better into the classroom, and part of it is that these are just sound pedagogical ideas. These are things we’ve had on the plate from the very beginning, but we have finally found the opportunity to implement them. It’s been part of the Sugar master plan from the very beginning.
X: What else is new in Sucrose 0.84?
WB: One thing that’s pretty exciting is that we’ve had this concept in Sugar from the very beginning called “View Source,” yet it was implemented in only a very small number of Sugar activities. We’ve expanded it in the new release so that every activity has a View Source functionality. What we’re trying to focus on is making Sugar a practical tool. One of the things that has happened over the last six months is that some of the teachers involved in Sugar have started to band together and have been quite vocal in the development community. The teachers in Latin America, especially, have been blogging and have been very active in the e-mail lists, and voicing things that they need—saying, wouldn’t it be great if we had this or that. So we’re trying to narrow the gap between what a Sugar developer can do and what a Sugar user can do, and View Source is part of that. As it stands, if all you do is pop into a Python editor, it’s a pretty steep climb for most people. I’ve been working on a series of smaller steps to allow the teachers and learners to acclimate to the idea of making modifications [to a Sugar activity].
X: Can you give me an example?
WB: One of the programs that I’m the maintainer of in Sugar is a programming environment called Turtle Art. It lets you snap together instructions called bricks to teach a little turtle to run around the screen to make pictures. It’s a very expressive program, but it’s also a limited expression, in the sense that all it can do is make graphics, so it’s got a very low ceiling. There are different strategies for letting the learner reach beyond Turtle Art without having the steps be too steep. One of the first things I did was make it so that you could export from Turtle Art into a traditional Logo environment. So that’s a transition path into a full-featured language. But I also decided that there were other things that would be interesting to explore. So rather than having all the bricks be predetermined, I added a brick where you can type in mathematical functions, like a square root function. That was one of the things the Uruguayan teachers had been asking for. It was easy for me to do, but making a brick like that would be a little too difficult for most teachers.
That was fine as far as it went, but it still didn’t get them any deeper understanding of how this thing works. It doesn’t get them inside. So I added another brick called a “no-op” brick that lets you edit that Python module. So you’re writing code in the style that the rest of Turtle Art is written in, and it gets you a little bit closer to the code, and it lets you do essentially anything. You’re not restricted to a simple set of mathematical functions. The idea is that, without having to worry about the mechanics of how the graphics or the user interface elements are handled, Turtle Art is suddenly extensible, so that teachers and students themselves can approach these things.
The Uruguayans I mentioned who had wanted the square-root function then said they wanted to build a program to draw Mind Maps, and this time they did it themselves. In fact, a lot of Sugar development is happening now out in the field and then being shared with the rest of the world. The whole idea of Sugar is to enable that kind of code development.
X: So you’re saying the new no-op brick you added is an example of bringing the View Source function to more areas of Sugar?
WB: Yes, the point of this long-winded story about the no-op brick is that the step from here to there was too big a leap for most people, so we’ve been adding a number of affordances into Sugar to make it easier for people to take advantage of the View Source function. Every activity now has a special case where View Source will go directly into the Python editor—but I’m trying to set a precedent where we have this concept of editing a module as opposed to editing a whole activity, to provide a stepping stone.
I’ve said this over and over again since the early 1990s, but the reason why the Web took off as a protocol is that the Mosaic browser had a View Source menu item, which meant that anybody using the Web could also create things for the Web. The idea with Sugar is that anyone using Sugar should also be able to
