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.

46

Fig 4-4 : A screenshot of the Chancemaker software written in Boxer

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.