non-programmer intro (topic drift)

Ken Kahn kenkahn at toontalk.com
Sat Aug 4 00:51:18 UTC 2001


Roger Kenyon wrote:

> So how does one create a first-person approach applicable to learning
> Squeak? The folks at StageCast have a tutorial  for Creator that
> combines traditional "introduction to the elements" with a guided,
> hand-on approach. That's closer, but not yet there.

And Jecel Assumpcao Jr  replied:

>In my "book vs interactive adventure game tutorial" problem, I would
>say that it is harder to do a hands-on course with a book.

When faced with the same problem for ToonTalk (www.toontalk.com ) I turned
to video games for inspiration. Games often present a rich complex world and
only a minority of players are willing to read anything to learn how to
play. Interactive game tutorials such as those for Incredible Machines and
Lemmings inspired me. A puzzle sequence can be designed to introduce new
elements and techniques and be fun at the same time. While I have lots of
respect for StageCast Creator and I know that its interactive tutorial has
been successful, I would not try to emulate it. There is no fun in it - no
challenge. You just do what you are told.

While interactive game tutorials are my favorite, there are other
alternatives that work better with some learners. Remember that people have
different learning styles and one learning tool can't fit all. I wrote about
this in a chapter in the book The Design of Children's Technology, edited by
Alison Druin, published by Morgan Kaufmann, 1998.

An abstract of my chapter follows. Maybe enough time has passed and I can
get permission to put the whole chapter on my web site. I just sent email
asking for permission.

Best,

-ken kahn

Helping Children to Learn Hard Things: Computer Programming with Familiar
Objects and Actions

Some children, when introduced to something new and complex, will jump in
and explore because they enjoy exploration and are good at it. Others are
much more timid and will explore only if coached or guided. Others ask for
instructions and follow them meticulously. Some children will carefully
watch a demonstration, while others are impatient to try things themselves.
It is possible that there is a style of learning that dominates others in
effectiveness and appeal. The position taken here, however, is that children
differ, and that all these learning styles have their place. Even an
individual child may switch styles as circumstances and experiences change.

Given the wide variety of ways that children learn, how should we design
software for children? This chapter attempts to answer this question by
looking closely at our experiences with the design and testing of ToonTalk.
ToonTalk (Kahn 1996, 1998) is an animated world where children build and run
programs by performing actions upon concrete objects. The child builds real
computer programs by doing things like giving messages to birds, training
robots to work on boxes, loading up trucks, and using animated tools to
copy, remove, and stretch items.

ToonTalk has been tested with 4th grade classes for the last 3 years.
Initially, it supported only an exploratory learning style. Some children
quickly began exploring and tried to figure out what each item does and how
to combine them. Most, however, asked for guidance. This led to the
development of enhancements of ToonTalk that cater to children with
different learning styles. ToonTalk now includes a puzzle game that plays
the role of a tutorial. This appeals most strongly to children who tend to
like to solve problems but are less comfortable exploring on their own. An
animated character named Marty was added to ToonTalk that acts like a coach
or guide in ToonTalk. Some children like to hear suggestions from him and
follow them. Others quickly send Marty away because they find him annoying.
A set of narrated demos of ToonTalk was created for those who like to sit
and passively be shown how to make things. Illustrated instructions on how
to build some programs were produced. These too appeal to a subset of the
children.

Children of different ages, experiences, and learning styles approach the
same software in very different ways. The main lesson we can take away from
this experience is that children differ in the degree to which they are
motivated and effective at exploring (on their own or with an animated
guide), or following instructions, or solving a puzzle sequence. Even the
same child will prefer different styles of interaction depending upon her
prior experience with the software. Ideally, a software program should be
designed so that a wide variety of children might enjoy and benefit from it.







More information about the Squeak-dev mailing list