Designing Educational Environments. Quicksand for Developers?

 

Andrej Blaho and Ivan Kalas
Department of Informatics Education
Comenius University, 842 15 Bratislava;
Slovak Republic
tel/fax: + 421 7 724 826,
email:
blaho@fmph.uniba.sk

Abstract

Having developed educational software for many years we are trying to think about the designing process from more general perspective. It is overwhelming how easily computer jumps from country to country, from culture to culture. How should education profit from the magic power that attracts children to computers all over the world? Are there any general rules to be kept by the developers to create successful educational software? We put forward several general and technical questions that every educational developer is likely to encounter. Although we are aware of the fact that there are no unique answers to many of them, we hope it is worth considering them carefully. Indeed, to recognise these question and to answer them is the most difficult part of the development process, we believe. We give possible answers to our questions taking Tomash the Clown package, see [1] and [2] as an example of our recent work in Comenius Logo.

Keywords

designing educational software, Logo, multimedia, computer goes through frontiers between nations and cultures

1 Introduction

In our country no child would pass over a chestnut which has just fallen down from the chestnut tree in autumn. Somehow, they feel they have to bend down and take it because of its colour, its shape, its surface, its magic… Something very similar is true with computers all over the world. Children are in love with them since for ever, see [3]. They want to use computers because doing so is very realistic, very true: they are in charge, they are responsible, they are in power, they are free to decide (when, what, how long ... ).

Therefore it is quite natural that school (and family) wants to apply this efficient tool in education as well. Computer gives us (or better: it has a potential to give us) an excellent space for developing children’s creativity, personality, logical mind, problem solving skills and algorithmic thinking. It is an unused space for cross-curricular projects, for exploratory and co-operative work (of students and teachers), for discoveries and inter-cultural activities.

And more: computer teacher is in an exceptional position. He or she knows that computer with very short educational tradition is the most dynamic tool – evolving and maturing literally every day. Traditional approach of a teacher who "knows everything" and passes knowledge to his or her students doesn’t work any more with computer! Smart computer teacher knows that know-all computer teacher doesn’t exist at all! He or she is deliberately and inevitably situated in a position of a partner among students, among other equal partners to discover together. This inherent position of partnership is probably the most exciting in using computer in education and is highly appreciated by children and students.

Professor Papert claims in his book The Children’s Machine [3] that no one can ignore the level of intellectual effort that children put into work done with computers outside the classroom. For educational software designers this is a challenge! Is it possible to initiate similar intellectual effort of children also in education? Are there any common rules to be kept when developing educational environments (microworlds) so that the results are effective and creative software laboratories for children?

We don’t know for sure. However, after many years spent in this field of the development we believe that some rules seem to emerge from this work. In [4] we presented our educational conception of Logo users – children, students and teachers – as developers. We argued there that any educational computer application with ambitions to become active teaching/learning environment should be highly interactive, open and visualised. In this paper we want to generalise our experience and present a series of questions which every designer of educational environments is likely to encounter – and probably will spent considerable part of the development process by finding the answers. Although many of these questions probably do not have unique and correct answers, we believe that it is very important even to recognise them and try to answer them. Also, we are aware that our viewpoint has evolved from our previous educational projects devoted mainly to pre-school and early school aged children. Therefore, it is probable that we ourselves have not recognised other questions important for other ages, approaches etc.

As an example later in the paper we illustrate possible answers to our questions taking Tomash the Clown multimedia package for children, see [1] and [2] as an example of our recent work in Comenius Logo (SuperLogo, MegaLogo, MultiLogo in other countries). In the following paragraphs we shortly mention four conceptual questions and in detail study the question of the architecture of the educational application.

1.1 What is the general educational goal of the environment?

Obviously, this is the most important point and should not be substituted by any technical features and options. The danger of using exciting features (sound, video, animations, network connections) without any exciting educational contents is real. The commitment of children to an application without clear educational conception – if it survives at all – is outside our interest here.

1.2 What kind of activities are children expected to do to meet the goal?

This means to choose a proper approach corresponding to our goal. While working within the application, will children simulate, develop, explore, communicate, construct, watch, compare, analyse, browse, play, solve, read? (And enjoy?)

1.3 Which technical tool will be used to create the application?

This means to choose proper development environment. Our choice may vary from general and domain independent environments (programming languages) through education oriented general tools (Logo) to general or specialised authoring systems or specialised editors (for developing hypertexts or Web pages etc.). Specialised system will probably save the effort of the developer because many decisions in it have already been done by the authors. However, this also means that the space of possible conceptions has been constrained in this way.

The choice should also be influenced by the level of interfacing possibilities and the palette of multimedia features offered by the development environment – in the case we intend to make use of them in the application.

1.4 In which way it will be used?

Is it intended to be used in school (for individual or co-operative work), as a source of multiple reference or as a repeated or unrepeated tool for explorations, developments… Is it intended to be used in families, with or without any assistance from a parent? Does it need any additional material (manual), installation, explanation? Is it open, i.e. are the users allowed to enter the application in any sense (to modify the scene, to insert additional assignments)? Is the age and abilities of the users clearly specified?

1.5 What is the architecture of the application?

Structure of the application

If the application contains more than one activity, is the overall structure fixed, with pre-defined order of activities? If the structure is fixed, is it due to our educational goal? Does it have a sound reason? Are the activities of increasing difficulty? Is the concept of difficulty of assignments in this particular application clear (to the developers themselves)? If the structure is complex, is it easy for a child to navigate through it, not to get lost in it? If the activity is quitted one day, is it possible to go on next time from that particular situation? Although it is tempting to include the possibility to continue next time, some other questions must be considered here as well: if more than one child is expected to work with this package, then some extra communication is necessary (record-keeping of all users and their recent activities within the package).

Explaining what to do

How will the user learn what to do? Can he/she read? Is he/she expected to "find by himself/herself"? Is there any demo or intro explaining each activity? Is it the sound or video or animation? Is it possible to skip the introduction – if the user already knows it?

Presenting the assignments

In which way will the assignments be presented? Are partial solutions visualised in the screen? Are the final solutions visualised in the screen? Are the same assignments presented every time? Or are they generated at random (according to some criteria of increasing difficulty)? If the user wants to solve exactly the same assignment once more, is this possible? What is the language of the assignments? Is it fixed, closed, is it text or graphics? (If the user is expected to type in any text, what about the mistyping?)

Evaluating the assignments

How is the solution visualised? How is it evaluated? Is the criterion of "correct solution" well defined? Is it possible to detect wrong decisions immediately? Do we want to prevent children from doing wrong decisions? How can wrong decisions be replaced? Is there any record-keeping of good and wrong solutions?

Control and communication

Is the control simple and clear? Is it unique through all activities? Is it "context dependant"? What is the language of communication? Does it correspond with the age of the users? Are not there any redundant steps in communication (for example, clicking here so that then I have to click there to get a dialog in which I confirm that my first click was right…) Is the application interactive, see [4]


Multimedia features

What is the purpose of using multimedia in our application? What purpose does it serve? Is it possible to pause or skip sounds, video, animation (after having heard and seen them several times)?

Openness

Is the user allowed to step into the application, to modify the set of assignments, to customise the scene, see [4]?

Printing hardcopies of screen and assignments

Is this possible? Can this feature help the user to solve the problem? Does it support the educational goal?

Surprises

Are there any undocumented and unexpected effects, rewards for additional explorations?

2 Tomash the Clown

Actually, this theme is not a new one for us. Between 1988 and 1990 we developed and published an activity book for children ages 5 to 9 years with the goal to make the young reader – or preferably young user – realise the importance of the order in actions and accept the defined picture language. Children learn how to express themselves in this limited world of graphical representation. The assignments in the book require reading, interpreting, verifying, and arranging plans, i.e. short sequences of pictures that represented some real actions (travelling through the country, getting an ice-cream, building a house etc.). Understanding of close relation between a real action and its symbolic description (representation) is thus developed.

Active involvement in the assignments of the book support logical thinking, planning activities and general problem solving skills. We wanted to provide a playful and natural contribution to pre-secondary informatics education, see [5]. The child is intended to learn how to:

Read a picture sequence and understand its connection to a real action.

Interpret a plan, that is, a sequence of pictures, which can be interpreted as a set of specific ordered instructions. The child must follow the picture sequence directions in order to complete the task successfully.

Verify a plan by carefully comparing it with the real situation we would like to end up with. Some plans from the book have intentional mistakes.

Arrange a plan in such a way that it will lead to a given result, solve a given assignment, etc.

Later we decided to develop a package of educational software to accompany the pupil’s book. From 1990 till 1996 we made three attempts, often struggling some technical limitations of hardware available for the users: our first implementation was done for an 8-bit monochrome computer with a low resolution monitor. Second attempt was realised in our new implementation of Logo in Windows. In that realisation we made extensive use of animation for:

We also made extensive use of all powerful features of Logo, namely its multiple turtles, strong interface and advanced graphics handling support. Yet, we still were not fully satisfied and decided to try once more: once more in Logo, however this time with full multimedia support and in co-operation with professional artist and animator and supported by experience of A.W.Bruna editors, nice children voices etc.

Why we find broad multimedia support so important? Because by using several levels of communication the interface becomes more transparent and accessible to even younger children. Demonstartions, assignments, continual reactions and evaluations can be done through animation and sound. No text communication is necessary at all. Children’s voices make the whole environment even more friendly. We designers could more deeply concentrate on the educational goal itself.

3 Our answers

The educational goal of Tomash the Clown is to develop and accent the feeling of the order in activities. Because of this the application is designed to make the importance of order quite obvious – when building a tower of wooden blocks, for example, a child must start with the bottom block. Comparing the child’s tower with the tower given in an assignment one can immediately detect whether or not there is a mistake in the order of the blocks. To stress the importance of order, we use only short linear sequences of pictures. Therefore, any undo – i.e. a wrong decision removal – can be done only in the reverse order: the child can delete only the most recent decision, then the most recent but one etc., until the inner mistake in the sequence is removed.

The other goal is to help children learn to accept the simple language of pictures with the simple laws of its usage and to communicate in this language through all assignments. We also intend to encourage the development of spatial problems solving strategies.

In our application children are expected to read a picture sequence and understand it, to interpret it in the screen (as a sequence of instructions), to verify it – that is, to compare it with the real situation in the screen, and to construct such sequence by themselves.

We decided to use Logo environment as a tool to develop our application because:

Our conception of the usage of Tomash the Clown is mostly in families or in school and pre-school settings for individual usage (maybe combined with some additional co-operative activities). As far as it heavily depends on sound, usage in school means that school PC lab must be equipped with sound cards and headphones. The age of users is defined as starting at 4 or 5, up to 8 or 9. The control and communication doesn’t require any reading abilities.

The package contains common introductory screen with a kind of graphical menu to go from here to one of five activities. Although the order of activities is free (depending on a child’s decision), the introduction screen design unobtrusively suggests a natural order in respect with the growing difficulty. Every activity consists of several (2 to 5) levels, the child can omit any of them. Every level consists of 5 assignments generated at random with increasing difficulty. There is no possibility to continue next day from the point where we have finished today. The reason is that in spite of the individual character of work, more than one pre-school child is expected to use it at the same computer at home and we do not want any record-keeping of them.

Each activity starts with detailed video-like animated demonstration with sound in which all objects and relations in the screen are introduced and the goal of the activity is illustrated. Moreover, each level starts with a child’s voice description of what to do now. Every animation and sound can be skipped by clicking the mouse or pressing any key.

The assignments are presented by animation in (hopefully) very clear and motivating way. All solutions are visualised in the screen so that the evaluation is obvious. The whole control is done by the mouse. The language of communication is always a fixed picture language with three to six different symbols. No texts are used. The only space for some openness in Tomash the Clown package is provided by first levels of the second, third and fourth activities where the child is free to choose, construct and draw. In general, however, we have to classify the package as nearly closed. Hard copy printing is possible any time (even in the middle of animation) and there are some surprises hidden in the screens of the activities.

4 Faces in Pieces

Tomash the Clown’s little monkey is not very dutiful. He has cut the photographs for Tomash’s billboard into pieces. The goal of this activity is to re-create original photographs (these are assignments of the activity) by combining two or three big pieces from the panel. If three pieces are necessary (that is, if a kind of overlap is necessary), then the order of choosing them is very important (level 2) while with two pieces (level 1) it is not important at all. This activity is in fact pre-activity for four others: it introduces the world of Tomash, the control and communication, the atmosphere, the notion of order… Assignments are generated out of the set of 81 possibilities.

5 Tomash the Postman’s Colourful Journey

In the coloured kingdom Tomash the Postman carries messages from the prince to the castle, from the castle to the dragon etc. Tomash orients himself according to the different colours of the roads. The goal is to find the proper sequence of road colours which will lead Tomash from a given place to a given goal. To do this, a child observes a map of the kingdom in the screen. The linear sequence of colours corresponding with the choices is created at the "curtain" as the picture representation of the trip. The longest travelling plan (representation) may consist of 8 colour choices.

In the first level the child directly controls Tomash: when he/she chooses one of three possible colours, Tomash follows the road of the selection on his bicycle. An assignment of this level is successfully completed when the child brings Tomash to any of the five end points – except the starting one. Incorrect choices are not accepted, therefore there are no wrong solutions.

In the second level the child is given not only the starting point of the trip, but a goal as well. In this level wrong choices of colours are accepted, so that some undo operations in reverse order may be necessary. However, the child is not allowed to bring Tomash to an end point different from the goal specified in the assignment.

In the third level the child is given the whole travelling plan. However, one choice of colour in it is not filled in. The problem here is to read the plan and understand which real trip should it represent – and fill in the missing colour. In the fourth level the child is to arrange the whole plan in advance for Tomash. Conceptually, this is the most complex problem of each activity. In this one, however, the wrong choices are being recognised immediately and the child gets warning so that no wrong plans can be constructed at all. As soon as the plan is complete, Tomash by himself starts to interpret it.

6 Ice Cream Break

There are five bears with different ice cream carts in the arena: one offering strawberry, one offering banana, one with lemon, one with chocolate, and one with red currant ice cream. By clicking a bear the child tells Tomash, which kind of ice cream he or she wants to buy. When this happens, another helping of the ice cream appears on top of the big ice cream on the panel. At the same time, Tomash will follow the child’s choice of the bear and move on his unicycle to the corresponding cart – his wheel thus leaves a track in the sand of the arena. In this way, a connection between the ice cream the child wants to get and the course to follow in the arena (a drawing) is developed. Moreover, no line in the send between any pair of bears can be followed more than once.

In the first level the child can choose the flavours in any order, the only limitation is the size of the big ice cream on the panel. After drawing all possible lines in the send the child can either move to the next assignment or undo his/her recent choices in reverse order.

In the second level a dotted line drawing is given to the child. When Tomash now goes along the dotted line, the wheel changes it into a dark line. Wrong choices are accepted here. However, when all dotted segments are covered (and there are also some extra segments which should not have been covered), the solution is evaluated as wrong and the same assignment is presented again. In the third level the dotted line is given to the child as well. But now, Tomash does not follow the choices (instructions to move) immediately: he waits until the child prepares the whole plan for him and clicks Tomash to let him interpret the plan. We see that in this activity it is the child who decides that the plan is already complete and can be interpreted (unlike in the previous activity).

7 Mixed up Buildings

On the platform there is an offer of wooden blocks. The child may take any number of them from here and the inventory never runs out. The assignments – pictures of small buildings – are presented by Tomash’s monkey in the screen. The goal is to build the same building out of the big wooden blocks from the platform. The order of selections is the main concern, although in this activity more than one sequence is possible for most assignments.

In the first level any building can be constructed – by choosing a colour, a shape and an exact place for the block. At the same time, a corresponding instruction card is constructed at the bottom of the screen. There are no limitations of the shape of the building (except the total number of blocks which cannot exceed 14). In the second level the child is given a picture of a building to be constructed. Now only the order, colour and shape of the blocks is important, correct place for a block in the screen is decided by Tomash himself. All choices are interpreted immediately – if it is wrong, Tomash demonstrates the mistake by unsuccessfully trying to use this block.

In the third level the child has to construct an instruction card for Tomash in advance, to prepare a plan. The child also has to recognise (by clicking Tomash) that his/her plan is complete and can be executed. In the fourth level the child is not only given the small building but the corresponding instruction card as well. However, one square in the card is not filled in – the child has to find out which block is missing. If he/she takes a wrong decision, it will be visualised only when the instructions of the card are being executed by Tomash.

In the last level the child once more gets both a building and a corresponding instruction card. But there is a mistake in it – the assignment is to locate the mistake and fix it. Once more: a wrong decision will be visualised only during the process of interpretation.

8 A Strawberry-Picking Robot

A small garden is divided into 3 x 2 strawberry patches (later 4 x 3) with one plant on each. Strawberries are getting ripe these days so Tomash has constructed a robot to help him with the crop. However, the robot’s help must be thoroughly controlled. The task is to give the robot the correct orders so it can enter the garden, pick up all ripe strawberries, and exit the garden. By clicking the control sings, the child gives the robot a directional order or an order to pick up the strawberry. The sequence of these orders (a program) is constructed on the display.

In the first level the robot immediately executes the orders. If the order cannot be executed, the robot unsuccessfully tries to do so, just to visualise the mistake. The maximum number of orders (instructions) is 28. In the second level the robot sits down in front of the entrance and waits until the child constructs a program for him. Any wrong decision will be visualised only while executing the program. In the third level the assignments are the same, however the size of the garden is 4 x 3 and there are more ripe strawberries. In the fourth level the child is given a program for robot. However, one or two orders in it are missing – the assignment is to fill them in so that when the program is then executed by the robot, it will work correctly. The length of a sequence to be read here and completed is much longer than in Mixed up Buildings activity.

 

9 Conclusion

When developing Tomash the Clown microworld, we materialized in it our belief that planning activities in complex multimedia environment develop logical thinking and the ability to understand the relationship between real actions and their symbolic descriptions. During the process we faced many questions important to decide how to support our educational goal with concrete environments, assignments, control, communication etc. We think that similar questions may be well known to other educational software designers as well and therefore, it is worth discussing them.

It seems that carefully designed educational applications may encourage trial and error approaches and the use of exploratory problem solving strategies. And, hopefully, attract children to perform intellectual effort typical for their outside-the-school love affair with computers. Love affair very similar to that of developers of educational environments. What else could make them stay in quicksand, so dangerous and changing the shape every day?

 

References

  1. Blaho, A., Kalas, I. and Toth, d.: Tomas de Clown. A.W.Bruna Informatica, Utrecht 1996
  2. Blaho, A. and Kalas, I.: Tomash the Clown’s Circus: Order in Action in Picture Languages, in: Johnson. D.C. and Samways, B. (eds.): Informatics and Changes in Learning. IFIP Transactions A–34, IFIP, Nort-Holland. pp. 79 – 86, 1993
  3. Papert, S.:The Children’s Machine, New York, Basic Books 1993
  4. Kalas, I. and Blaho, A.: New Implementation of Logo Opens What Should be Open (Developing and Implementing Active Learning Environments). Komputer w Edukacji, No. 2, pp. 5 – 14, 1995 (in Polish)
  5. Taylor, H. G., Aiken, R. M. and van Weert, T. J.: Informatics Education in Secondary Schools, Guidelines for Good Practice. IFIP WG 3.1, Geneva, Switzerland 1992