34
4 - Successful constructionist based software
4.1 Principles of educational software development
In the previous chapter I talked at length about the constructionism philosophy of
learning. I now turn my attention to how these ideas can be practically achieved in the
classroom and describe some of the systems, mainly computer based, that have been used
and have been successful. Most of the systems that I will describe are computer languages
or development environments for children to construct their own programs, simulations
or models. They are very different from C or any other high level programming language
in that they have been specifically aimed at empowering children to be able to construct
programs from their own ideas. The work of Papert, Repenning, diSessa and Kahn have
all been geared to providing children with an environment in which they can express their
ideas on computers.
The systems that have been devised by these authors are diverse and are based on
different theoretical computer science backgrounds but their wide diversity and collective
success shows that their visions must have some element of applicability to them. The
aim of this section is to investigate abstract links between educational principles, software
design principles and practical systems, as shown in the diagram below. The dashed lines
represent connections that have yet to be established.
Computer Science theoretical background Definitive notations
Practical systems Empirical Modelling LISP language
Logo
Educational software design
Educational issues Toontalk Animated
Agentsheets Boxer programming
Rule based programming Visual programming
Fig 4-1 : Establishing design principles for educational software using Empirical Modelling
35
I will highlight the key points upon which the systems are founded, the use they have
had by children and the successes that they have achieved. In chapter 5 I will take these
abstract points and discuss whether models developed using the Empirical Modelling
tools have these properties (this is the reason for the dashed arrow on the diagram).
Any piece of software that has education as its major focus must be able to achieve
some, if not all, of the following criteria :-
i) Have a low barrier to entry. The initial effort required to use the software must be low
enough to encourage its use, without getting side-tracked by unnecessary features or error
messages.
ii) The software must have some relevance to the National Curriculum. Although some
authors, notably Papert and Covington, suggest radical uses of their software which
emphasise learning whatever the child likes, to be of any practical immediate use to
teachers in the classrooms now, the product must be able to teach children topics from the
National Curriculum, or be used in a supporting role to reinforce that subject.
iii) Be an environment in which investigations can be undertaken. Investigations which
are open-ended or seek to elucidate general principles which are not obvious from the
start of the assignment are likely to lead to reinforced learning of the concepts. Activities
should be scaffolded so that the children are introduced to a subject gently and their
knowledge is gradually increased by asking relevant questions before leading them to the
brink of the intuitive leap between special case and generalisation and encouraging them
to make that jump.
iv) The boundaries to which the environment can be explored should be large enough so
that the children can broaden their horizons and engage in more complex tasks if they get
in to an activity or if they complete a previous investigation.
v) Ideally a piece of software can be either used for many purposes or tailored to suit each
individual investigation or ability level. This would not only give the teacher a feel of
ownership of the software [a point strongly bought out from the COMICAL workshop]
but allows them to use it in new and imaginative ways for new or different investigations,
or even for new applications altogether.
vi) Be free, easy to use and well documented!
36
4.2 Logo and development environments it influenced
4.2.1 Logo
Seymour Papert can probably lay claim to be the first person to have the vision of
children using computers and also enabling them to program them. During the initial
development of the Logo language Papert wrote about his vision for children and
programming in the future [32,p1], “an educational system in which technology is used
not in the form of machines for processing children but something the child themselves
will learn to manipulate, to extend, to apply to projects, thereby gaining a greater and
more articulate mastery of the world, a sense of the power of applied knowledge and a
self-confidently realistic image of himself as an intellectual agent”. This vision was
written in 1971 before schools started to use computers. He had taken this vision from the
first time that he had sat in front of a computer in the 1960’s and felt the power that it
gave to him. He wanted to give that power to children, probably due to his involvement
with Piaget.
Logo is a computer language that was designed as a subset of LISP and had several
properties that Papert wanted to endow it with. These were :-
i) It had to be very easy to use. Limiting the number of commands that the language
possessed and simplifying the syntax so that it could be used easily by children reduced
the barriers to entry.
ii) It had to be powerful enough so that children could use it to engage with powerful
ideas. This meant that the basic commands had to be combinable in ways that enable
sophisticated outcomes to be achieved.
iii) It had a concrete object, the “turtle” as its output device. The reasons for this were
twofold. In the early days of the Logo language having access to a graphical terminal was
something of a rarity and a physical object being manipulated circumvented display
device technology problems. The second reason was that the use of a physical artefact
enabled the children themselves to visualise and put themselves in the place of the turtle.
This had powerful uses in learning since the child could make their body move how they
37
wished and then work out how to program the turtle to achieve the same movements.
Papert used the idea of how to construct a circle as his primary example of how “playing
turtle” could enable children to figure out how objects were constructed.
The early versions of the Logo language were primarily geometrical based. It had the
following commands which could be entered by the user and were executed immediately
due to the interpreted structure of the language :-
FORWARD X - moved the turtle forward by x units.
BACKWARD X - moved the turtle backward by x units.
LEFT X - turned the turtle x degrees anti-clockwise.
RIGHT X - turned the turtle x degrees clockwise.
PEN UP - took the pen off the paper so the turtle could be moved without it drawing.
PEN DOWN - put the pen back down onto the paper so drawing could recommence.
REPEAT X - repeats a sequence of steps x number of times.
There was one further command BUILD which was the identifier that was used when
specifying a procedure. Groups of Logo commands could be given a name and have
parameters passed to them which allowed sophisticated behaviours to be introduced from
simple commands and the children could then use the procedures in their programs or in
other procedures.
FORWARD 70 RIGHT 90
FORWARD 50 RIGHT 90
FORWARD 70 RIGHT 90
FORWARD 50
Fig 4-2 : Example Logo code and the figure produced by it
Logo has been used in classrooms in many countries and has seen great success in that it
is referenced in the National Curriculum as a way of teaching certain concepts. The
government believes every child should have some access to Logo during their schooling.
This is somewhat ironic given that Papert designed Logo to free children to investigate
with their own ideas and the National Curriculum uses Logo to teach some pre-defined
38
activities. Papert agreed in [31,p31] saying, “the turtle can be used to teach elements of
the traditional curriculum, such as angle, shape and coordinate systems”. His vision for
Logo was of far more widespread use. Papert gave a number of reasons why Logo was
successful after he had seen children using it. These were :-
i) The children actually liked the turtle. For young children the ability to see the physical
turtle and the desire to make it move captured their interest in the first instance.
ii) They took charge and used it for their own purposes.
iii) It leads to invention. Children often produced surprising results by trying new things
that had not been previously thought of.
iv) It leads to the mathematical discovery that the commands FORWARD and RIGHT are
a universal set because they can be combined to produce any possible path or shape.
In chapter 2 I talked about microworlds, mentioning that their simplicity fostered an
environment which was well suited to learning. The simplicity of the Logo environment
need not be stated, with a total necessary command set of two statements. As a
comparison pick any two primitive commands in a high level language and see how many
programs you can write using them.
Logo is still being used in a large number of schools today. This is because as the
elements that “turtle geometry” is being used to teach change in the curriculum, the
flexibility of the Logo environment means that new primitives can be written (by teachers
or children) to reflect the new use to which it is being put. There are hundreds, if not
thousands, of articles that have been written about Logo in various educational
journals/magazines and on the Internet. They are often distributed with actual code in the
article, which facilitates a widespread collaborative community of users who think up
new ways in which to use a powerful open-ended development environment. This is one
of the most important reasons why Logo still maintains a wide user base 30 years after it
was first introduced, even after the enormous changes in the computational technology
available.
As well as many versions of Logo that have been programmed for modern computers
there have been a number of spin-offs from the original Logo language, which attempt to
add to the original Logo language. Some of these are commercial products that are based
39
on top of Logo, such as Microworlds project builder [4] and SuperLogo. Both of these
products operate in graphical environments and have painting programs and facilities for
the creation of widgets such as buttons, sliders, dialog boxes and input boxes. Whilst
these facilities certainly improve the Logo language as an authoring environment, their
focus on the underlying concepts that Papert had in mind seems diluted by the
incorporation of new features which take the focus away from pedagogical aims. The
ability of SuperLogo to compile Logo programs into stand-alone Windows (TM)
applications mean that learning resources and environments can be shared amongst
teachers. This retains the collaboration feature but restricts the program user from
viewing the source code and modifying it to fit their individual needs. The inclusion of a
modern selling point facility I believe actually detracts from the package’s educational
value since some of the flexibility, adaptability and ownership is lost.
There are two languages which are based on Logo that are distinct enough in their own
right to merit further discussion, they are *Logo and Boxer.
4.2.2 *Logo
*Logo was developed in the early 1990’s by Mitchel Resnick who was a graduate
student at the MIT lab working with Seymour Papert. It was based on the Logo language
since Resnick wanted *Logo to possess the constructionist approach that had made Logo
so successful. Resnick’s major aim was to make the investigation and exploration of
systems of colony behaviour accessible to children [44,p33]. Many of the modern Logo
variants allow the users to create multiple turtles which can then interact on the screen (or
floor if you have enough physical turtles and the wires don’t get crossed!) to produce
interesting effects. However this is not sufficient to explore systems with large numbers
of interacting entities. *Logo built on Logo with three major new ideas which are
sufficient to investigate colony behaviour and decentralised systems [44,p33].
i) Perhaps the most significant difference is the ability to have a large number of turtles,
of the order of thousands of turtles instead of the few that are usually provided by Logo
variants. These turtles can all perform their actions in parallel. This was one of the major
40
design criterion, that *Logo was to be a massively parallel language, since colony type
behaviours will only become apparent when a large number of individuals make up that
colony. The first version ran on the Connection Machine which was a massively parallel
computer with thousands of processors, an ideal machine for *Logo to run on. It was
programmed in *LISP, a version of LISP programming language that ran on the
Connection Machine, which was the reason that the * was included in the language name.
Although it is not important to the user what machine the language was implemented for,
because a clear conceptual model of parallelism was the aim, it allowed Resnick to
implement *Logo in a high level language [44,p41].
ii) Turtles have better “senses” in *Logo than the traditional Logo turtles. The motivation
for the original turtles were as “drawing turtles”, whereas *Logo turtles are more
“behavioural” in design. Each turtle comes equipped with senses. They can detect and
distinguish turtles that are close to them and they can identify scents in the world. They
are also provided with a primitive command that lets them turn to face the direction from
which the strongest “scent” is coming. These inter-turtle and turtle-world interactions are
vital for exploring self-organising phenomena, as interesting community behaviours
would not arise out of completely independent individuals within that community.
iii) Lastly, *Logo reifies the turtles’ world. The environment in which the turtle is
operating in in traditional Logo plays no part in determining the behaviour of the turtle.
The only information that it has about its current state is its colour. In *Logo the world is
split up into a grid of patches. The information that can be held by a patch can be
determined by the user and can be operated on by the patch. By this I mean that the
environment can change over time and this can be pre-determined by the programmer.
This presents a far more realistic world for the turtles to operate in because in the real
world the behaviour that phenomena exhibit depends on the environment that they are in.
*Logo therefore provides an environment in which all interactions are possible using a
number of primitives and therefore gives the user the opportunity to think with and
experiment with how these interactions shape the environment and the behaviour of the
turtle, and also with communications between turtles.
41
There is one other technical language related issue I want to mention since it shares
some similarities with the Empirical Modelling approach. *Logo has three different types
of procedures that can be executed. One group are procedures that are executed by turtles,
another group are executed by patches. The third group are executed by an observer of the
simulation. Resnick notes that this is useful for setting up world conditions but it also
shares many similarities with the idea of super-agents in dtkeden who can arbitrate and
generate unexpected events to see how the behaviour of the system changes.
Resnick in [44] describes a number of different systems which have been implemented
in *Logo and some of the experiments that have been performed with these systems by
children to try and explain the behaviour of the system, in terms of the individuals
behaviour. Systems that Resnick and various aged students have implemented include ant
colonies searching for food, traffic jam simulations, slime mould aggregation, forest fires
and turtle geometry from a new perspective. There are many more such situations that
occur in real-life and a number of them are discussed in Schelling’s book [47] where he
talks about how overall behaviour arises through the motives of individuals.
Why does experimentation with *Logo simulations and their construction help children
learn about such systems?
Resnick found that the diversity of simulations which exhibit decentralised phenomena
gave him enough variation to explore how people think about decentralised systems, and
how they come up with their theories about their organisation.
His main finding was, even in the era of decentralisation in which we live (e.g. the fall
of the USSR, new company structures etc.) people naturally attribute centralised causes to
phenomena. Resnick says “the inclination towards centralisation was apparent in many
*Logo projects. When trying to make sense of *Logo programs, people tended to assume
centralised causes. And when trying to construct *Logo programs, they often imposed
centralised control. There was evidence of the centralised mindset in all types of *Logo
users, from the scientifically sophisticated to the scientifically naive. Some were more
successful than others in moving beyond the centralised mindset. But everyone slipped
into centralised thinking at times” [44,p120]. From Resnick’s description of actual
42
projects undertaken and some of the responses and thinking given by children it is
obvious that the language and the underlying philosophical aims have been successful.
4.2.3 Boxer
One of the contributors to the Logo project over the early years until the mid-1980’s was
Andrea diSessa. He took the ideas underlying Logo and became the principal designer of
a new language called Boxer which overcomes some of the shortcomings he believes
Logo has. The philosophy is similar, both projects believe that programming, in some
form, is essential in truly liberating the computer’s power as a learning tool and that
powerful and unconstrained computational resources should be available to “plain folk”
in the service of enhancing learning [23,p8].
Boxer is based on a hierarchy of boxes. A program in the Boxer environment consists of
a number of boxes which can contain other boxes which can also contain boxes. Each
box, which is equivalent to a Logo procedure, can contain pictures, actions, text and
variables. The visual appearance of the environment makes it clear to new programmers
where the boundaries of influence are for each procedure, by the edges of the marked
boxes. Underlying the development environment is a language which was heavily
influenced by Logo but changed to suit the new environment it was situated in. In Boxer
learning by interacting with the code is a very powerful technique by which students can
learn the way in which a program works. By double-clicking on a piece of code it will be
executed, which also makes it a very powerful debugging technique [23,p10].
Fig 4-3 : Two examples of Boxer code
43
What advantages do the Boxer team believe their environment has over Logo?
One of the design criteria of Logo was that it should have a low threshold combined
with a high ceiling. Boxer has a lower threshold and a higher ceiling than Logo, according
to diSessa. He mentions a group of students who in a ten week mathematics course each
produced a cogent and personally meaningful project [23,p10]. The ability to see what a
procedure does at the same time as watching its effects is a powerful tool for
understanding the environment. Another advantage comes when working with variables.
In Logo you have to interact with a variable in a “conversational” manner, in Boxer you
can do this directly. diSessa says “It is an interactive notation for the fact of a variable
having a value, as opposed to a notation for the fact of changing a value or the fact of
doing something with it” [23,p11]. Boxer has the principle of naive realism. What you
see on the screen is the computer system; there is no need for the user to abstract the
context. There is also the notion of spatial metaphor. Boxer can represent abstractly
spatial relations because of the way space is used and relations between entities are
determined visually. Boxer’s higher ceiling comes from being aimed at a different
audience to Logo. It was designed so that it could be used across a wide range of ages and
would suit the purpose of people of different ages and abilities. People ranging from
school children to graduate research students and academics have written serious software
in the Boxer environment. One such example I will look at in detail shortly is
Chancemaker, which was the product of a research project that investigated how children
view random processes. It attempted to provide an environment in which they could
investigate stochastic ideas. Some of the other facilities in Boxer are described briefly
below :-
i) Closets - The programmer can hide away the code that represents a box on its opposite
side, which can be flipped over and inspected if the user knows about this. This provides
an excellent way to hide entities in a box that are not important to the user or that they are
unlikely to want to change. However it retains flexibility and openness since these items
44
can still be accessed. It does not restrict the programs usage to the purpose and limitations
the original developer gave it.
ii) Other modes of programming - In addition to the procedural approach, which Boxer
shares with Logo, facilities for other types of programming exist within Boxer. Object-
oriented ideas can be used in the development environment, but in a far more visible
concrete way than most object-oriented languages since the boundaries of the objects and
functions which act on objects can be seen on the screen. The other type is activation-
oriented programming. This operates the same way as triggers in EDEN work. When a
certain action takes place then other actions can be then automatically guaranteed to
happen. In Boxer a trigger can be set whenever a box is changed either directly or by the
user.
iii) Tool building and sharing - Collaboration is far easier in Boxer than in Logo due
partially to the visual presentation but also because a box can be copied into a program
and used to perform an operation until its operation is understood. Then it can be opened
up and inspected and modified to suit the purpose of the new user. One such example was
a vector toolkit that was programmed for a physics course but can then be re-used in
numerous microworlds that require vector operations. This community-wide
collaboration means that establishing a critical mass of users to ensure the success of the
language is easier [40,p43].
These comments about tool building, sharing and user collaboration were extended by
diSessa [22]. He claims that the best way of delivering educational software is as a
collection of small, highly modifiable and extendable tools that are combinable with each
other and any others added to the system in the future. He calls this idea open toolsets.
diSessa talks about his vision for the future where children and teachers can design and
modify activities for their own particular situation sharing them with other users to create
a community of developers [this was also raised during the COMICAL workshop]. One
way of achieving this aim would be to have each tool as an application in its own right.
However, diSessa writes “In terms of interaction, it is currently very difficult to connect
different tools-as-applications. Suppose you want to connect a nice simulation, say of an
ecological system, with a statistical analysis tool and a graphing tool. This is sometimes
45
possible these days, but is often awkward, and too often it is just impossible” [22,p51].
There have been many ways proposed and experimented with to try and fulfil this vision.
Microsoft’s OLE (Object-linking and embedding) was one attempt to be able to pass data
efficiently between applications in a seamless integrated fashion. The use of “scripting”
with a programming language to control an application is another way in which
applications can share resources. diSessa believes that this is in the spirit of the open
toolsets idea, “You could, for example, have a script that sent some data to an analysis
tool, and returned a graph-as-picture to your “home” environment” [22,p52]. I will return
to this notion of open toolsets in chapters 5 and 6 as I believe that any environment
should be open-ended enough for new tools to be added to it, or existing ones modified as
new purposes are thought of for a program.
4.3 Chancemaker
The next system I describe is called Chancemaker and was programmed in Boxer by
Dave Pratt as part of his PhD thesis [38]. The reason for looking at this piece of research
is that it attempts to answer questions which I had been asking myself about how we
should design constructionist based microworlds for children using computers. The area
of mathematics that formed the focus for this study was the nature of random processes
and how children learn about them.
The design of the microworld was conducted in parallel with study of the way in which
children view random processes and how they learn about them. This was done because
of the “deep and dialectic relationship between learning and the tools for learning”
[37,p3]. The actual practical implementation of the Chancemaker microworld was a
process of iterative refinement, over a number of stages, where at each stage there was a
process of development of the microworld and use of the microworld by the children. In
this manner he could assess the suitability of the system as a pedagogical tool by
observing how the children used the microworld and their subsequent comments on it. A
screenshot of the Chancemaker software is shown on the next page.
47
There were four iterations that Pratt undertook, and they were [37,p9] :-
i) Bootstrapping - No prior tools except those provided within Boxer, the computational
development environment used. The major aim was to attempt to guess what appropriate
tools for investigating stochastic processes might look like. The test group numbered 2
children.
ii) Exploratory - The first stage gave rise to some ideas of how the tools might be
developed and some additional tools that might be needed. The emphasis at this stage was
still on development of the microworld rather than its use. This stage used 4 children for
testing.
iii) Developmental - The tools were sufficiently advanced for there to be meaningful
progress in the understanding of how the tools were shaping the children’s intuitions of
chance. There were now 8 children involved in the testing process.
iv) Analytical - This stage involved only minor modification of the tools but much more
careful and systematic analysis of how the tools impacted upon the children’s’ intuitions.
The tools were used by 16 children in this final stage.
By involving children at all stages Pratt could be sure that the final tools would be
meaningful and useful to children exploring a stochastic microworld. The iterative design
has as one of its major strengths this “proof of the pudding is in the eating” approach [37,
p11].
The development of the microworld led Pratt to draw a number of key principles that
should be adhered to when designing mathematical microworlds for children to explore.
They are :- [37,p19]
i) Familiarity - The abstract nature of the computer can be daunting for children. As
designers we must try and give the microworld a degree of cultural familiarity with
entities that look and behave as real world objects.
ii) Purpose - When designing a microworld we have to think about the uses to which the
children might put the tools to. To be effective we have to have the learning goals
sufficiently close to the path that children’s interactions may take.
48
iii) Utility - A balance needs to be achieved between why children actually want to use
the microworld and the learning that they undertake when using it.
iv) New control mechanisms - The designer should offer the children facilities to
experiment with those factors that they believe impact on the workings of the
microworld. These may or may not be factors which actually influence the behaviour but
if the children think that they do then facilities need to be provided so that they can test
their theories on these unimportant factors.
v) Meaning - Children can use a computer based mathematical microworld like
Chancemaker before understanding the mathematics that they are actually engaging with.
They can then come to understand the mathematics by learning in an informal way what
the concepts mean.
vi) New formalisms - Mathematics is a formal subject presented in terms of theorems and
proofs. However the microworld can be an informal environment in which to encounter
and intuitively understand the concepts and make connections with their formal
representations.
I will return to discuss these concepts in greater detail in connection with the practical
modelling undertaken for this project in chapter 6 to discuss to what extent my work
addresses these design issues identified by Pratt.
4.4 Agentsheets
Agentsheets is an authoring environment developed by Alexander Repenning and a
number of students at the University of California in Boulder. They have created
numerous simulations including bridges, fish tanks, ice melting and water flow
simulations. The research group claims that “obvious applications for Agentsheets are
simulations and visualisations of dynamic processes and their factors. The added value is
the capacity to interactively change the behaviour of the simulation by modifying agents’
rules” [41,p12]. An example sheet is shown on the next page.
49
Fig 4-5 : The bridge simulation in the Agentsheets environment
It is certainly the system with the closest connections to Empirical Modelling that I will
discuss. It is a visual design environment based around a grid system, similar to a
spreadsheet. An Agentsheet is a grid with agents that can act and perceive in their
environment. The environment can be used to create simulations which are interactive,
domain-oriented and graphically based. Repenning decided to opt for a grid based system
which would have the advantages that have been postulated for the success of
spreadsheets [28]. These include visible program state, compact formalisms, regular
structure and conceptually simple spatial relationships between cells. A diagram showing
the layers of abstraction in the design of the Agentsheets environment is shown on the
next page.
50
Fig 4-6 : The layers of abstraction in the Agentsheets environment
The environment has its own language called Visual Agent Talk (VAT) which is a rule-
based visual programming language which is used to program the behaviour of agents
within the system. The language was carefully designed and has evolved over time
through repeated use with children and refinement after consideration of the problems
that they encountered when using the system. Visual programming has been claimed to
give a number of advantages including [28,p62] :-
i) Pictures represent a higher level of abstraction, so no syntax is involved.
ii) When properly designed, people can understand pictures regardless of what language
they speak.
iii) Pictures can convey meaning in a more concise unit of expression than text.
iv) They exploit 2 dimensions, which can convey more information about structure than
1-D text.
51
The actual design of VAT was aimed to maximise domain- and problem- orientation
while minimising the programming language overhead [41,p11]. The picture below
shows an example of a VAT rule.
Fig 4-7 : A Visual Agent Talk rule in the Agentsheets environment
It is immediately noticeable that the user programming the system is provided with the
syntax in fixed boxes so the possibility of generating syntax errors is avoided. To
represent an agent its icon is dragged into a relevant box and to represent cells
neighbouring the agent an arrow is used to signify direction. A number of primitives are
provided for the user to specify what action should be taken if the conditions hold and
again iconic representations of agents are used along with the direction symbols.
52
There were five principles that guided the design of the VAT language [39,p2] :-
i) Syntonicity - Programmers will be more successful if they can identify with the object
they are programming. Representations which allow novice users, like children, to
identify with the internal state of an agent make program comprehension and composition
simpler.
ii) Phrase structure - The language was designed so that a command was structured as a
phrase to increase the readability of the program. By designing at a phrase level the
designer is moved closer to the realm of the end user.
iii) Sets - Keeping the number of rules to a manageable level can be achieved by allowing
users to specify rules for sets of agents. For example in the fish tank simulation only one
rule needs to be defined for the behaviour of the same type of fish.
iv) Domain orientation - A program stated in terms of the language of the target domain
will be easier to understand since it will more closely match the language that the user
uses to talk about that domain. It also reduces the conceptual distance between the
problem-domain semantics and the program itself which is beneficial for end users
v) Selection and polymorphism - Composition is supported by offering users a large
number of powerful commands and clustering them appropriately. For example an action
command can be applied to one agent, a few agents or a large number of agents who
satisfy certain criterion. The language is large and complex with specialised features but
this elaboration has moved the language closer to children’s conceptions of their
problems.
The Agentsheets system was the result of trying to find a solution to the expressiveness
against ease of use paradox that exists with programming languages. High level
languages such as C are highly expressive and can be used to create complex
computational artefacts, but only a minority of people can use them. Visual and end user
programming languages tend to be far easier to use but at a cost of reducing the power of
the language [42,p1]. Repenning identifies three key factors he believes a suitable
paradigm to solve this trade off should have [42,p2] :-
53
i) Comprehension - Users should be able to easily determine the effects of programs and
program components within their application.
ii) Composition - It should be easy to compose complex programs and behaviours by
composing them from simpler ones.
iii) Sharing - Environments should allow users to share programs and program fragments
with very little effort that will work in other user’s applications.
He talks of tactile programming which is a paradigm in which non-textual visualisation
is used to represent programs with facilities for perception and understanding through
manipulation of objects in that program.
In a similar idea to Boxer objects can be executed and understood by dropping them into
contexts and seeing what happens. This is a powerful tool for program comprehension
through perception manipulation.
The Agentsheets research team have been involved with a project in schools called the
Science Theater (misspelling is correct) project in which they have been investigating the
educational value of model creation by students. Since this is similar to a view I have for
Empirical Modelling it is worth discussing this further. A key idea is to introduce the
language and development environment through a specific learning context. By using a
particular model their knowledge of the language is being improved to a level where they
can construct models of their own. This process is known as scaffolding [39,p2]. From
the study a number of general principles they believed were important were given that
resulted from observing closely the children using the models [27,p4] :-
i) Shape the task, not the system - In a normal program setting the designers are clear
about the tasks that the user wants to carry out. In an educational setting, contrastingly, if
redefining the learner’s task enhances its pedagogical value then we are free to do this.
ii) Incorporate guiding knowledge into the task specification, not just into the background
information - We can include information in the task itself which is not related to the
computer model but helps the child conceptually in understanding the task. The designer
has the freedom to attach specific knowledge to the task.
54
iii) Design in failure - This was the idea behind the strength control in the Chancemaker
microworld described earlier. When creating user interfaces the designer has the task of
minimising the user’s chances of failure. In an educational setting designing for failure
may be necessary to make the child actively engage with the task.
iv) Design for creative scope - When designing a standard user interface the number of
possibilities that are presented to the user is kept as small as possible. In designing for
pedagogical tasks often to engage the learner a large number of options should be given.
v) Draw support from other activities - To ensure that children do not have suffocating
problems with the task design of activities to take place before or in parallel with the
computational exploration can be beneficial. It gives the child the necessary prerequisite
knowledge and gives them some confidence to engage with the ideas.
vi) Motivate software mastery by links to content domain - When choosing activities for
children to pursue when they first meet a new software environment thought should be
given to structure the task so that the language features which the designers want the
children to use occur as a natural part of the task they are doing.
vii) Design to avoid generating misconceptions - Using simple modelling tools that are
aimed at children can mean that complex physical phenomena are not represented
faithfully. When designing an activity care should be taken to avoid presenting
misleading models to the children.
4.5 Toontalk
The last of the computer based systems that I am going to discuss is Toontalk [48]
which was programmed by Ken Kahn. He has made many attempts at writing software
for children, each time taking as his paradigm the philosophy that was available at the
time and, in his opinion, most suitable for children. His previous systems were based on
object-oriented programming, logic programming and visual programming. His latest
creation, Toontalk, he describes as an animated programming system. The child takes the
part of a child in a world on the screen who can explore various houses in a street and can
sit down and play with items on the floor with tools in his toolbox. The programming that
55
the children do is by manipulating concrete objects inside this world. There are a number
of robots that can be trained to perform calculations and actions, in procedures. The
language can be thought of as communicating independent processes which use birds and
nests to represent communication primitives. There is a heavy use of animation in the
programming to try and ensure a sense of fun, with Sucky the garbage collector and a
mouse with a hammer that performs arithmetic.
Fig 4-8 : A screenshot of communication in the Toontalk environment
The use of visual metaphors that represent real-world objects that are familiar to
children, but also represent fundamental computational processes means that children
become able to express themselves in a sound computational sense through the use of
56
these intermediary objects. Although Toontalk is relatively new, a large European study
comparing children learning with Logo and Toontalk through building “playgrounds” (or
microworlds) on top of the computational environments will start in September 1999
[49].
4.6 Logiblocs
This is the final system that I will talk about, and it is the only one that is not computer
based. There are two reasons why I have chosen to write about this system. The first is
that it fosters an environment in which constructionist activities can take place. The
second is that I have used the product with children and designed effective activities and
scaffolding processes to introduce them to the topic and achieve the pedagogical aim of
the activity. The aim of the product is to introduce electronics and circuit ideas to upper
primary (9-11) children.
Logiblocs (TM-Logiblocs Ltd.) are a set of brightly coloured blocks, which can be
joined together to form larger circuits. They have inside them some complex wiring but
the outside of the block shows a clear conceptual picture of the circuit inside the block.
This removes one of the obstacles that circuitry usually gives. The actual fiddling with
wires puts children off, but manipulating little jigsaw pieces seems to be fun. The pieces
have some restrictions as to how they can be used but as long as a power supply is used
circuits can be built up that include junctions, logic gates, input devices, output devices
and switching devices. A picture of the Logiblocs construction kit is shown on the next
page.
The Logiblocs construction kit comes with a project manual and teacher’s handbook.
These are meant to give the children a number of interesting projects to build, including
Catherine’s wheels, traffic lights and lighthouses. Each project has occasional questions
to query the children’s understanding of what is going on. However despite this,
observing groups of children actually using the kit that were unsupervised by the teacher,
it was noticeable that they were building the circuit, admiring it, then dismantling it.
57
There was no actual pedagogical benefit for the children since they did not understand
how the circuits they had built worked.
Fig 4-9 : A picture of some of the components of the Logiblocs kit
I designed a number of activities for the children which scaffolded the topic for them by
starting off at a very low level progressing to very tricky problems in an attempt to
provide work that would stretch all the children if they were given long enough to use the
blocks. This approach worked for two reasons. Firstly it captured the children’s interest
by starting with easy problems and increasing the complexity slowly. By asking them not
to try out the circuit until they had (as a group) decided on the outcomes provided an
environment for group discussion and plenty of multivocal explanation situations. The
final result was that I had children talking to me in a knowledgeable manner about how
certain combinations of logic gates would produce output and reasoning with me and
each other when there was a disagreement. I myself was only introduced to logic gates
when I was 17 in an A-level physics classroom.
This experience made me conclude that :-
i) Scaffolding the task to a wide range of abilities was vital if success was to be achieved
in a primary classroom with mixed ages and abilities (as was the class I tried it in).
ii) The provision and design of suitable activities to go with the educational product is
vital since it reduces the strain on the teacher having to prepare more material for the
class and gives immediate use for the product within the classroom. It also gives an
insight into what the designer believes the product can be used for and this could lead the
teacher to realise that they could use it for something similar. Although the Logiblocs
58
were distributed with activities they were not immediately suitable for their targeted
users.
iii) The importance of designing activities that produce group discussion and group
learning, especially at primary level, is fundamental to that activity being a success.
4.7 Design principles for learning activities
A number of principles for the design of learning activities can be drawn from the work
described in this chapter. These are :-
i) Anchor all learning activities to a larger task or problem. The learner should clearly
perceive and accept the relevance of the specific learning activities in relation to the
larger task complex.
ii) Support the learner in developing ownership for the overall problem. Solicit problems
from the learner and use those as the stimulus for learning activities, or establish a
problem such that the learners will readily adopt the problem as their own.
iii) Design an authentic task. An authentic learning environment is one in which the
cognitive demands are consistent with the demands in the environment for which the
learner is being prepared.
iv) Design the task and the learning environment to reflect the complexity of the
environment in which they must function after the learning has occurred.
v) Design the learning environment to support and challenge the learner’s thinking.
vi) Encourage testing ideas against alternative views and alternative contexts.
vii) Provide opportunity for and support reflection on both the learning content and the
process of learning.
This chapter has drawn a wide amount of information from various sources describing
ways in which to design educational activities. A lot have common ground, but there are
also differences. In the next chapter I will take the key points to emerge from this chapter
and see how the Empirical Modelling approach addresses them. This will point the way
towards the practical modelling that I have done.