how to evaluate construction kits: ten design principles

update (July 8): The reason this article resonates so strongly with me is that nearly everything it says also relates to how to teach a good lesson, how to design a great curriculum and how to critique wooden curriculum guidelines such as ACARA's Digital Technology.

I think teachers need a guide to evaluate the enormous array of construction kits that have come on stream: Makey Makey, Arduino, Little Bits, Ozobot, Micro:bit, Chibi Chip, Circuit Playground Express, Lilypad, Bee-Bot, Dash and Dot, Sphero, Edison, Drones – add or choose your favourite

Some Reflections on Designing Construction Kits for Kids by Mitch Resnick and Brian Silverman (2005)

This is a 2005 article. In some respects the technologies have moved on. But it remains an elegant guide as to how to both choose and use technology construction kits for learning powerful ideas. I’ve thrown a few of my thoughts into this summary.

1. Design for Designers

Some kits are too finished and polished. With the best kits, the user can design a wide variety of interesting things, it is not finished or limited to a narrow range of functions.

2. Low Floor and Wide Walls

Seymour Papert put forward the slogan “low floor, high ceiling”. The truth is that with Scratch, under the leadership of Mitch Resnick, wide walls were given preference to the high ceiling. There are some things you can’t do with Scratch, that you could do with other, earlier versions of logo. This has provoked criticism (eg. I believe from Alan Kay commenting on Mark Guzdial's blog but I can't find the link right now) as well as other designs to put the high ceiling back (eg. SNAP by Jens Monig and Brian Harvey, watch this video).

Initially, my position was that I wanted it all: the low floor, the high ceiling and the wide walls. But the truth is that Scratch has scaled dramatically (40 million projects on the Scratch website in 2018) whereas other more powerful versions of logo or etoys haven’t. There are a number of reasons for this but its relative simplicity is one of them.

Since I’m now focused on inclusion for all, STEAM for the 99%, I can appreciate more Mitch Resnick’s argument that too many high level features create hurdles that discourage many users.

3. Make powerful ideas salient – not forced

“We have found that trying to teach powerful ideas directly is not very effective. Rather, our strategy is to provide opportunities for kids to encounter and use powerful ideas as a natural part of design experiences.”

This is a huge issue which I won’t try to cover in a shortish blog post. What are powerful ideas and how are they best taught? I think the approach advocated here by Mitch and Brian is one very good way to introduce kids to powerful ideas. I also think that they do have to be taught, even though that is hard, because by their nature they are not easily learnt.

Ask me for articles about this if interested, they were previously at Learning Evolves but this shut down when wikispaces was abandoned, unfortunately.

4. Support many paths, many styles

The authors here relate a story where one group uses the full features of LEGO-logo (their style is described as “patterners” or “hards”) while another group initially doesn’t (their style is described as “dramatists” or “softs”). The patterners were more comfortable doing the coding. The authors took a hands off, non interventionist approach.

“We worried that the students would miss out on some of the powerful ideas underlying the LEGO/Logo activity. But we didn’t interfere”

The way they tell it, it has a happy ending. The dramatists do end up coding their ferris wheel. But what would the authors have done if that group had continued to avoid the coding?

5. Make it as simple as possible – and maybe even simpler

“One reason (PROBLEM) is “creeping featurism”: advances in technology make it possible to add new features, so each new generation of products has more and more features.”

YES!! Personally, I find creeping featurism incredibly frustrating. It often gets in the way of me doing the task I want to do on the computer, not to mention cursing.

“We have found that reducing the number of features often improves the user experience. What initially seems like a constraint or limitation can, in fact, foster new forms of creativity.”

They then describe two of their designs, the first is a programmable brick with 4 motors and 6 sensors which is the size of a kid’s juice box.The second is a cricket with 2 motors and 2 sensors which is the size of a matchbox.

The simpler Cricket proved to be more popular!

“But once we had developed the scaled-down version, which we called a Cricket, people kept finding more and more creative applications for it, in spite of (or perhaps because of?) its apparent limitations. Over time, we shifted our research effort, making the Cricket the centerpiece of our new construction kits”

Once again the KISS principle wins. This echoes the point above about wide walls displacing the high ceiling.

6. Choose black boxes carefully

Black boxes are chosen to facilitate certain types of learning and to hide other types of learning. Three examples are given:

• building robots – facilitates the learning of gearing, feedback and control (and hides the learning of how motors work)
• turtle geometry – facilitates the learning of the geometry of polygons (and hides the learning of how forward requires trigonometry to implement)
• colour of LEDs – make colour as simply as possible (map it to 0-100) so as to integrate it with other things such as temperature.

7. A little bit of programming goes a long way

KISS works for the 99%

“We continue to believe in the value of everyone learning to program, but we are also well aware of the difficulties of learning to program. Many beginning programmers hit a plateau, able to write simple programs, but unable to go further. We have found that it is difficult to help kids get beyond this plateau. But, over the years, we have begun to realize that being “stuck” on the plateau is not such a big problem: kids can learn a great deal, and benefit a great deal, while they are on the plateau. We have shifted our efforts, trying to leverage what kids can do well, rather than focusing on what they can’t. Kids generally have little difficulty learning to use imperative (action-oriented) commands (like forward and on), simple control structures (like repeat), basic conditionals, and simple procedural abstraction. So we have been developing programming languages and contexts that enable kids to do a lot with those basic elements….

Our new Scratch programming language has similar qualities, enabling kids to manipulate rich media (sounds, music, animations) with simple combinations of commands.”

Once again, they are explaining an important reason for the success of Scratch. If as teachers we become too anxious about forcing higher level thinking then that often backfires and turns kids off coding.

We still want to teach higher level thinking. The challenge is how to develop environments which facilitate internal development of its need, rather than external forcing.

In practice schools just put it into the curriculum (ACARA) and it becomes a sink or swim exercise.

8. Give people what they want – not what they ask for

“Rather than asking users what they want, we have found it more productive to observe users interacting with our prototypes, and try to infer what they want (and don’t want) from their actions. Often, their actions speak louder than their words. It is usually easy to see when users get frustrated, even if they don’t articulate their frustration.”

I see this as a sophisticated and enlightened form of leadership which transcends both a top down preordained blue print approach and a bottom up populist approach. The teacher / designer / leader does know more about the educational goals which are desirable to be achieved. But they do have to pay close attention to both the abilities and desires of their students and factor that into their decision making of what to do next and how to achieve those broader goals in an interesting rather than formalistic manner. This makes teaching an interactive art form.

9. Invent things that you would want to use yourself

I’ve previously called this the “eat your own dog food” approach, a slogan which developed out of the open source movement.

“We aim to build not only new technologies, but also communities of people who can help kids learn with those new technologies. And we have found that it is easiest to build those communities if everyone involved (adults as well as kids) enjoy using the technologies.”

The technologies which I am currently promoting (eg. Scratch3.0, the micro:bit, the Hummingbird:bit, Turtle Art, Makey Makey, App Inventor) are ones that I do enjoy using myself. In the past when I promoted Game Maker I did build games myself with it and used them as part of my teaching.

10. Iterate, iterate - then iterate again

Curriculum guidelines such as ACARA Design Technology put too much emphasis on getting the planning right first before making a product. As the authors argue here it is better to have an idea, build a quick and dirty prototype and then continue to iterate.

“… we put a high priority on “tinkerability” – we want to encourage kids to mess with the materials, to try out multiple alternatives, to shift directions in the middle of the process, to take things apart and create new versions. Kids learn new lessons with each iteration. ...

In developing new technologies, we have found that we never get things quite right on the first try. We are constantly critiquing, adjusting, modifying, revising. The ability to develop rapid prototypes is critically important in this process. We find that storyboards are not enough; we want functioning prototypes. Initial prototypes don’t need to work perfectly, just well enough for us (and our users) to play with, to experiment with, to talk about….

We find that our best conversations (and our best ideas) happen when we start to play with new prototypes – and observe users playing with the prototypes. Almost as soon as we start to play with (and talk about) one prototype, we start to think about building the next….

This process requires both the right tools (to support rapid development of new prototypes) and the right mindset (to be willing to throw out a prototype soon after creating it). Too often, the software-development community seems to follow a paradigm of: plan ahead, design carefully, then implement once ….

We much prefer the paradigm proposed by our colleague John Maeda: imagine, realize, critique, reflect, iterate”