Research > Internet & Technology, children e kindergarten">
Framework For Computer Programming in Preschool and Kindergarten
Framework For Computer Programming in Preschool and Kindergarten
Framework For Computer Programming in Preschool and Kindergarten
and Kindergarten
Acknowledgments
When I embarked on the journey of developing this thesis and its supporting research, I could
hardly imagine the effort and commitment it would require. It wouldn’t be easy, that much I was
fully aware, but only now I can I look back and realize the many obstacles, difficulties, frustrations,
and rocky roads it would imply. Fortunately, I can also now realize the many joys of discovery, of
achievement, of child-play, of making blunders and correcting them. And even though learning has
always been a pleasure for me, this thesis has also been a personal, intimate reminder of that.
The completion of this thesis is due to many people, who have supported me in countless
ways, both directly with the research and with this thesis, and indirectly in providing my with the
supportive environment and frame of mind to overcome the hardships and enjoy the satisfactions.
Obrigado, Prof. Bulas Cruz, por me ter expressado a sua confiança na minha capacidade para
avançar com este trabalho, antes ainda de eu próprio ter contemplado a possibilidade de o fazer.
Deu-me sempre todas as condições para poder continuar a trabalhar sistematicamente nesta obra,
mesmo perante outras prementes exigências profissionais e académicas que eu igualmente não
podia descurar. E obrigado também por me recordar regularmente da necessidade de concluir este
trabalho, mantendo-me em boa rota.
Thank you, Ken, for having been available from the very start to be my thesis advisor, always
ready to comment and counsel, always patient to analyze my ideas, no matter how far-fetched, and
scrutinize all of them in detail, pointing out issues and requiring my clear explanations and
demanding clear thought-out ideas. And all this with a terrific turnaround time! Thank you for all
the bug-sorting, the analysis of crash dumps and continual development of ToonTalk features.
Obrigado, Prof.ª Maria Gabriel, por me ter ajudado, um informático, a traçar uma rota através
do pensamento e prática na educação de infância, sempre pronta a aconselhar-me e a esclarecer-me,
a apoiar-me no relacionamento com educadores de infância, com os jardins-de-infância e com as
ideias educativas. Obrigado por me ter facultado o apoio do projecto ICEI e pela confiança,
encorajamento e apoio no desenvolvimento da minha actividade lectiva na Licenciatura em
Educação de Infância. E por sempre me centrar nas questões essenciais à investigação em curso,
ajudando-me a evitar questões menores nas quais facilmente eu me podia ter enleado.
Obrigado, Rosa, por constantemente partilhares comigo a tua paixão, inspiração, saber e
experiência em educação de infância, tanto com computadores como sem eles. E por partilhares o
caminho comigo durante todos estes anos, dando-me a insubstituível confiança no futuro.
Obrigado Zoé, por me teres dado imensas alegrias durante o meu último ano de trabalho nesta
tese, e por me lembrares constantemente, enquanto gatinhavas pela sala ou te atiravas à minha
cadeira, que precisava de concluir esta tese para te poder dar toda a devoção que mereces.
Obrigado mãe, obrigado pai, por sempre me terem dado não só o apoio para ir em frente,
como também por sempre deixarem incondicionalmente por minha conta a decisão sobre o meu
caminho. E por me terem desenvolvido o sentido da responsabilidade, do esforço e do empenho.
Thank you Yishay and Lennart, for your comments on the cookbook. Thank you Mikael, for
your comic-strip ideas. Thank you, Playground and WebLabs teams, for letting me share your
efforts for the continual development of ToonTalk and programming-based education, the latest
ToonTalk versions and bug fixes, and other technical support.
Por fim, obrigado educadoras, pelo acolhimento que sempre tiveram pela minha investigação,
obrigado profissionais do projecto ICEI, pelo empenho que cada um colocou; obrigado, meus
alunos de educação de infância, pelo contacto rico com as vossas perspectivas do mundo e pelos
vossos esforços no desenvolvimento de actividades educativas, em particular à Irina e à Liliana pelo
empenho em desenvolver a vossa actividade, thank you Frank Berthold, for your reports on N.
Por fim, um obrigado muitíssimo especial a vós, crianças que participastes com alegria!
Abstract
This thesis aims to be a contribution to the integration of activities with computer
programming into preschool education contexts. It is based on experiences and observations of
children aged 3, 4, and 5 years olds programming computers, using an animated programming
language, ToonTalk, held between 2000 and 2004 in seven different settings, typically in weekly
session held over the course of several months in each year, involving approximately 150 children
and 10 educators, including early childhood teachers and computer-activities teachers.
Background information on the use of computers and computer programming with preschool
children are included, as well as an extensive survey on existing computer programming
environments for children. I also provide introductory information about the fields of computing
and programming, for the benefit of readers from outside the computing field; for the benefit of
readers external to the educational field, and introduction to preschool education is provided.
The research results are provided in various forms: sample activities for integration of specific
computer-science concepts into preschool education contexts; an analysis of hurdles faced by
preschool children in the process of programming, and suggestions of approaches to help overcome
them; an analysis of issues faced by educators in the process of using programming; and finally, a
framework for integration of computer-programming activities in preschool education contexts, to
assist preschool teachers and educators wishing to employ this resource.
Hopefully the insights from this thesis may prove also helpful for the computer scientist in
research on the field of human-computer interaction, particularly regarding the use of computers in
the development of cognition.
Resumo
Esta tese pretende ser uma contribuição para o enquadramento das actividades de
programação de computadores no contexto da educação pré-escolar. Baseia-se em experiências e
observações de crianças de 3, 4 e 5 anos a programar computadores, utilizando uma linguagem de
programação animada: ToonTalk, realizadas entre 2000 e 2004, em sete ambientes de investigação
diferentes, essencialmente através de sessões semanais ao longo de vários meses de cada ano, que
envolveram cerca de 150 crianças e 10 educadores, incluindo educadores de infância e animadores
infantis de informática.
São apresentadas as áreas de utilização da informática e da programação de computadores
com crianças em idade pré-escolar, bem como um vasto levantamento dos sistemas actualmente
existentes para programação de computadores por crianças. Como apoio a leitores exteriores à área
da informática, forneço introduções aos campos das computação e da programação; como apoio aos
leitores exteriores ao campo da educação, forneço uma introdução à educação pré-escolar.
Os resultados da investigação são apresentados sob diversas formas: exemplos de actividades
para integração de conceitos específicos da informática em contextos de educação pré-escolar; uma
análise das dificuldades enfrentadas pelas crianças desta faixa etária no processo de programação, e
sugestões quanto a abordagens que apoiem a ultrapassagem dessas dificuldades; uma análise das
dificuldades enfrentadas pelos educadores no processo de uso da programação; e por fim, um
enquadramento da integração de actividades de programação de computadores em contextos de
educação pré-escolar, que visa servir de apoio aos educadores de infância e outros profissionais de
educação que pretendam utilizar este recurso.
Espero igualmente que as percepções e discernimentos incluídos nesta tese possam revelar-se
úteis aos cientistas informáticos, na investigação no campo da interacção humano-computador,
muito em particular relativamente à utilização de computadores para desenvolvimento da cognição.
Short summary
Having picked up this thesis, I assume the reader has already developed an interest, or at least
some curiosity, for the fields of research and practice of computer programming with young
children. My own engagement with this field came from my personal interests and motivations, and
these are inseparable from my personal history and background on the use of computers. Chapter 1
deals with my personal view of the three areas that meet in this thesis: teaching & learning,
computers & programming, and computer programming in education.
Before delving into the particulars of computer programming proper, I wish to share with the
reader some or my overall understanding of the field, its main issues, and its history and evolution,
and this is the purpose of Chapter 2. Those acquainted with the history and evolution of computers
and computer programming may wish to skip section 2.2, Brief history of computer programming;
for other readers, this section isn’t absolutely essential, but I hope it dispels potentially confusing
ideas of computers as calculators, by providing an enjoyable narrative pathway of how machines
developed for calculations transformed into machines for working with ideas. For all readers,
section 2.1, Body & Mind: hardware and software, aims to provide the perspective I employed
when discussing programming, and the background relationship I have considered when speaking
of software and hardware. In section 2.3, Computer programming in our society, I present instances
and uses of programming by people other than those whose job descriptions mentions
“programmer”, and even some cases which aren’t often regarded as programming at all. To
conclude this chapter, section 2.4, Computer programming in education, presents the major
approaches in the use of computers in the field of education, so that all readers can be acquainted
with the position of programming itself in this context.
The central issues of computer programming are the focus of Chapter 3. It presents to all
readers the two areas of programming employed in this thesis, which are not usually discussed in
the educational field. Section 3.2.1 presents the notions behind programming several actions to take
place concurrently, and section 3.2.2 may prove particularly interesting to computer scientists, for it
presents the field of constraint programming, which is not one of the most common computer
science topics. Section 3.3, Programming languages, should not be disregarded by education
professionals, for it addresses several central issues in the use of programming with children.
Particularly important in this section is the discussion on the relationship between abstract and
concrete concepts, in section 3.3.3. It also contains a lengthy survey of computer-programming
systems devised for children to use (section 3.3.4), and an extensive description of the language
ToonTalk, employed in the field work of this thesis, which is not found elsewhere in any single
document. This chapter also presents one of the first results of my research, in section 3.4, in the
guise of a “cookbook” of activities for preschools, each focused on a specific topic of computer
programming. Thus, these technical concepts of programming are not simply presented, but
exemplified in their applicability in preschool settings.
Chapter 4 includes a first section, introducing the field of preschool education and its
background; I hope that educators from other educational backgrounds benefit from this selection of
perspectives on the specific issues of theory and practice in preschool education, as should
computing professionals less acquainted with preschool education theory and practice. The second
section, Computers in preschool, provides the thought and background on the use of computers in
preschool, and computer programming in particular. Of particular importance as a theoretical
background is the presentation of the educational thought of Seymour Papert, in section 4.2.2.
The final chapters deal with the actual research description and the core results (apart from
section 3.4). Chapter 5 details the progress and settings of the research and data collecting,
including references to the appropriate annexes, where accounts, reports, and other raw data is
presented. In Chapter 6, I provide an analysis of the problems and difficulties faced by both
children and their teachers in the use of programming, as well as the results of different approaches
used against those problems and difficulties.
Table of Contents
1. Thesis overview.............................................................................................................................17
1.1. Of teaching and learning ........................................................................................................19
1.2. Of computers and programming.............................................................................................21
1.3. Of computer programming in education ................................................................................24
2. Computer Programming: conceptual foundations.........................................................................25
2.1. Body & Mind: hardware and software ...................................................................................27
2.2. Brief history of computer programming.................................................................................30
2.2.1. Historical overview.....................................................................................................30
2.2.2. The first programmable computer device...................................................................31
2.2.3. The electric and electronic programmable machines .................................................34
2.2.4. The appearance and evolution of computers ..............................................................40
2.2.5. The first programs ......................................................................................................42
2.2.6. Programming languages are developed......................................................................46
2.3. Computer programming in our society...................................................................................51
2.3.1. Pervasive programming ..............................................................................................51
2.3.2. End-user programming ...............................................................................................53
2.3.3. Advanced programming .............................................................................................58
2.4. Computer programming in education.....................................................................................64
2.4.1. Introductory remarks on computers & education .......................................................64
2.4.2. Framing computer use in education............................................................................64
2.4.3. Learning from computers ...........................................................................................66
2.4.4. Learning with computers ............................................................................................77
2.4.5. Learning about thinking, with computers...................................................................87
3. Introduction to computer programming ........................................................................................97
3.1. Aims of this chapter................................................................................................................99
3.2. Computer programming styles .............................................................................................101
3.2.1. Sequential vs. Concurrent programming ..................................................................101
3.2.2. What You Want vs. What To Do:
constraint programming vs. procedural programming .............................................114
3.3. Programming languages .......................................................................................................119
3.3.1. Perspectives in view of selection for preschool........................................................119
3.3.2. Textual vs. Visual programming ..............................................................................119
3.3.3. Visual programming for children: concrete vs. abstract...........................................128
3.3.4. Survey of programming languages for children .......................................................138
3.3.5. Animated programming and ToonTalk ....................................................................195
3.4. Cookbook of computer programming topics........................................................................218
3.4.1. Computability ...........................................................................................................219
3.4.2. Programming environment .......................................................................................221
3.4.3. Syntax .......................................................................................................................222
3.4.4. Declarations, expressions, and statements................................................................223
3.4.5. Conditional expressions............................................................................................225
3.4.6. Compound procedures..............................................................................................226
3.4.7. Parameter passing .....................................................................................................227
3.4.8. Type checking...........................................................................................................228
3.4.9. Higher-order procedures...........................................................................................229
3.4.10. Parallel/Concurrent execution ..................................................................................230
3.4.11. Parallel/Concurrent statements .................................................................................231
3.4.12. Message passing / Communication channels ...........................................................232
3.4.13. Speed independence .................................................................................................233
3.4.14. Synchronous/asynchronous communication ............................................................234
3.4.15. Recursion ..................................................................................................................235
Framework for Computer Programming in Preschool and Kindergarten 5
Universidade de Trás-os-Montes e Alto Douro
3.4.16. Guards and alternative commands ........................................................................... 236
3.4.17. Input guards.............................................................................................................. 237
3.4.18. Clients and servers ................................................................................................... 238
4. Introduction to preschool education and computers ................................................................... 239
4.1. Early childhood education philosophy(ies) ......................................................................... 241
4.1.1. Brief history of early childhood education............................................................... 241
4.1.2. Main current theories ............................................................................................... 250
4.1.3. Pedagogic models .................................................................................................... 265
4.2. Computers in preschool ....................................................................................................... 279
4.2.1. Non-programming use ............................................................................................. 279
4.2.2. Seymour Papert and constructionism....................................................................... 283
4.2.3. Computer Programming in Preschool and Kindergarten......................................... 297
5. Exploratory activities on preschool computer programming...................................................... 317
5.1. Finding a suitable tool.......................................................................................................... 319
5.2. Finding a style for introducing programming...................................................................... 322
5.2.1. Focusing the research............................................................................................... 322
5.2.2. The initial session duration assumption ................................................................... 322
5.2.3. Preparations for acquisition of preliminary data and information ........................... 324
5.2.4. Preliminary data and information ............................................................................ 329
5.3. Outlook of the exploratory research activities ..................................................................... 333
5.3.1. Settings for the exploratory activities ...................................................................... 333
5.3.2. Setting 1 summary ................................................................................................... 334
5.3.3. Setting 2 summary ................................................................................................... 334
5.3.4. Setting 3 summary ................................................................................................... 335
5.3.5. Setting 4 ................................................................................................................... 335
5.3.6. Setting 5 ................................................................................................................... 337
5.3.7. Setting 6 ................................................................................................................... 337
5.3.8. Setting 7 ................................................................................................................... 338
6. Programming isn’t magic............................................................................................................ 339
6.1. Conceptual hurdles for children while programming .......................................................... 341
6.1.1. Of hurdles................................................................................................................. 341
6.1.2. Descriptions and strategies....................................................................................... 344
6.2. Lessons from Working with Kindergarten Teachers ........................................................... 351
7. Framework for computer programming in preschool ................................................................. 355
7.1. Guidelines for computer programming in preschool ........................................................... 357
7.2. Integrating the computer in off-computer activities ............................................................ 360
7.2.1. Overview.................................................................................................................. 360
7.2.2. Computer as a destination – “I drew that tail”!........................................................ 361
7.2.3. Computer as source – “The larder is well-stocked!” ............................................... 363
7.2.4. Mingled computer – “Who asked for bread!?” ........................................................ 364
7.2.5. Programming in context – “You’ve got it all, you can swim”................................. 366
7.3. Typology of approaches to the programming environment................................................. 368
7.3.1. Usage typology 1: space for self-expression............................................................ 368
7.3.2. Usage typology 2: sorting and organization ............................................................ 370
7.3.3. Usage typology 3: exploration of constructs and behaviors .................................... 373
7.3.4. Usage typology 4: instant programming = show how it is done.............................. 377
7.3.5. Usage typology 5: combining programs .................................................................. 379
8. Final remarks .............................................................................................................................. 381
9. References................................................................................................................................... 387
Annex I — A robot that writes “MARIA” ...................................................................................... 441
Annex II — E-mail exchanges ........................................................................................................ 445
Annex III — Reports detailing the sessions of May-June 2000...................................................... 457
Table of AcronymsCases
a.k.a., also known as .......................................................................................................................... 54
AA, “As Árvores” preschool ........................................................................................................... 323
ACM, Association for Computing Machinery ................................................................................ 428
APEI, Associação de Profissionais de Educação de Infância.......................................................... 403
AR, “Araucária” preschool .............................................................................................................. 323
ARPANET, Advanced Research Projects Agency Network............................................................. 90
ASCC, Automatic Sequence Controlled Calculator .......................................................................... 36
BASIC, Beginner’s All-Purpose Symbolic Instruction Code............................................................ 22
CAI, Computer-Aided Instruction ..................................................................................................... 65
CAL, Computer-Aided Learning....................................................................................................... 65
CBT, Computer-Based Training........................................................................................................ 65
CCC, Computer Curriculum Corporation.......................................................................................... 69
CD-ROM, Compact Disk – Read Only Memory .............................................................................. 65
EDVAC, Electronic Discrete Variable Automatic Computer ........................................................... 40
ENIAC, Electronic Numerical Integrator and Computer .................................................................. 30
FIFO, First-in, First-out ................................................................................................................... 202
FORTRAN, FORmula TRANslation/FORmula TRANslator........................................................... 48
GUI, Graphic User Interface.............................................................................................................. 23
HTML, HyperText Markup Language .............................................................................................. 53
IBM, International Business Machines Corporation ......................................................................... 36
ICEI, Informática em Contextos de Educação de Infância.............................................................. 335
IMSSS, Institute for Mathematical Studies in the Social Sciences (Stanford University) ................ 69
ITS, Intelligent Tutoring Systems...................................................................................................... 75
K&P, Kelleher & Pausch, 2003....................................................................................................... 155
LabVIEW, Laboratory Virtual Instrument Engineering Workbench .............................................. 121
MIT, Massachusetts Institute of Technology .................................................................................... 92
MUD, Multi-User Dungeon............................................................................................................. 181
NAEYC, National Association for the Education of Young Children............................................ 279
PLATO, Programmed Logic for Automated Teaching Operations................................................... 77
RAM, Random-Access Memory ....................................................................................................... 22
SPP, “São Pedro Parque” preschool ................................................................................................ 323
TEL, Technology-Enhanced Learning .............................................................................................. 77
TT, ToonTalk................................................................................................................................... 321
USA, United States of America......................................................................................................... 21
VAT, Visual AgenTalk.................................................................................................................... 179
VCR, VideoCassette Recorder .......................................................................................................... 21
VV.AA., Various Authors ................................................................................................................. 22
Table of Figures
Figure 1 – Sinclair Research ZX81 computer....................................................................................21
Figure 2 – Sinclair Research ZX Spectrum computer........................................................................22
Figure 3 – Charles Babbage, 1791-1871............................................................................................32
Figure 4 – Augusta Ada Byron King, 1815-1852 ..............................................................................32
Figure 5 – Konrad Zuse, 1910-1995 ..................................................................................................34
Figure 6 – George Stibitz, 1904-1995................................................................................................35
Figure 7 – Howard Aiken 1900-1973 ................................................................................................36
Figure 8 – John V. Atanassof 1903-1995...........................................................................................36
Figure 9 – Helmut Schreyer 1912-1984.............................................................................................36
Figure 10 – Colossus ..........................................................................................................................37
Figure 11 – Maxwell Herman Alexander Newman (1897-1984)
and Thomas H. Flowers (1905-1998) ........................................................................................37
Figure 12 – ENIAC ............................................................................................................................38
Figure 13 – John Mauchly & John P. Eckert (1907-1980) and (1919-1995).....................................38
Figure 14 – EDVAC...........................................................................................................................40
Figure 15 – Alan M. Turing 1912-1954.............................................................................................40
Figure 16 – János Neumann 1903-1957.............................................................................................41
Figure 17 – Preparing input and output for the Analytical Engine ....................................................42
Figure 18 – Analytical Engine program.............................................................................................42
Figure 19 – Reprogramming ENIAC .................................................................................................43
Figure 20 – Your Spectrum issue 12..................................................................................................45
Figure 21 – Mac Man playing screen.................................................................................................45
Figure 22 – Finding and replacing with regular expressions .............................................................54
Figure 23 – Defining e-mail rules ......................................................................................................54
Figure 24 – Word processor preferences (automatic text) .................................................................56
Figure 25 – AutoCAD manual entry ..................................................................................................58
Figure 26 – Macromedia Flash timeline control ................................................................................58
Figure 27 – Programming with ActionScript.....................................................................................59
Figure 28 – Computer-generated characters combined with live images ..........................................59
Figure 29 – Structure of a typical domotics system ...........................................................................60
Figure 30 – Roman Verostko, “Cyberflower V. 1, 2000”, pen plotted drawing................................61
Figure 31 – Plotter with an oriental brush installed ...........................................................................61
Figure 32 – Roman Verostko, “Lung Shan II”, pen+brush plotted....................................................61
Figure 33 – Robert H. Russ, “Whisper”, 3-D rendered algorithm .....................................................61
Figure 34 – Robots at work and painting in progress (30, 60, 120 and 240 minutes) .......................62
Figure 35 – EuroPreArt sample data-entry form and Web results.....................................................62
Figure 36 – Comparison of two tasks: with and without just-in-time programming .........................63
Figure 37 – Edward L. Thorndike 1874 – 1949.................................................................................66
Figure 38 – Pressey Teaching Machines............................................................................................67
Figure 39 – Burrhus Frederic Skinner, 1904 – 1990..........................................................................68
Figure 40 – Skinner’s teaching machine ............................................................................................68
Figure 41 – IBM 838 Inquiry Station for the IBM 650......................................................................69
Figure 42 – IBM 650 Console Unit....................................................................................................69
Figure 43 – Patrick Suppes 1922 –.....................................................................................................69
Figure 44 – Boxes of Civilization III .................................................................................................72
Figure 45 – Civilization III entry screen ............................................................................................72
Figure 46 – Civilization III’s first bit of information: initial situation and goals ..............................72
Figure 47 – Civilization III’s first directions: find a good site for the capital city ............................73
Figure 48 – Civilization III’s tutorial explanation of interface elements ...........................................73
Figure 49 – Civilization III’s sample screen with hyperlinked information ......................................74
Figure 50 – Civilization III’s suggestions and directions in mid-tutorial game.................................74
Framework for Computer Programming in Preschool and Kindergarten 9
Universidade de Trás-os-Montes e Alto Douro
Figure 51 – Robert B. Davis, 1926-1997........................................................................................... 77
Figure 52 – Screen from an educational PLATO application, in the 1970s...................................... 77
Figure 53 – Screen from PLATO Learning’s “The Quaddle Family” .............................................. 78
Figure 54 – Screens from PLATO Learning’s “The Three Decoders” ............................................. 79
Figure 55 – Donald L. Bitzer............................................................................................................. 80
Figure 56 – PLATO IV station with touch-sensitive plasma display................................................ 80
Figure 57 – David Jonassen............................................................................................................... 82
Figure 58 – Thomas Kurtz & John Kemeny...................................................................................... 87
Figure 59 – Seymour Papert .............................................................................................................. 92
Figure 60 – One billiard ball............................................................................................................ 101
Figure 61 – Two billiard balls ......................................................................................................... 103
Figure 62 – Mitchel Resnick............................................................................................................ 105
Figure 63 – Edsger Wybe Dijkstra, 1930 – 2002 ............................................................................ 107
Figure 64 – Typical concurrent transformational program.............................................................. 111
Figure 65 – Typical concurrent reactive program ........................................................................... 111
Figure 66 – Colliding billiard balls.................................................................................................. 112
Figure 67 – Wrong result of collision.............................................................................................. 113
Figure 68 – Moving furniture involves goals and constraints ......................................................... 114
Figure 69 – Moving a table.............................................................................................................. 116
Figure 70 – Vijay A. Saraswat......................................................................................................... 116
Figure 71 – Sample flowchart specifying the program in Table 8 .................................................. 120
Figure 72 – Sample pictorial flowchart specifying the program in Table 8.................................... 122
Figure 73 – Programming in the PIP visual language ..................................................................... 124
Figure 74 – LabVIEW programming examples:
generating an array of random integers and using dataflow to determine execution order..... 125
Figure 75 – Pictorial Janus, execution example:
appending the lists “a b c” and “d e f” to produce “a b c d e f”............................................... 127
Figure 76 – Uriel Wilensky ............................................................................................................. 130
Figure 77 – Sample program in traditional textual syntax and in child-oriented syntax................. 137
Figure 78 – Children working at BBN with one of the first wireless turtle-robots (named
“Irving”) in the early 1970s ..................................................................................................... 143
Figure 79 – Turtle graphics.............................................................................................................. 144
Figure 80 – Alan Kay ...................................................................................................................... 146
Figure 81 – Etoys object properties ................................................................................................. 147
Figure 82 – Etoys script creation ..................................................................................................... 147
Figure 83 – Circular motion in Etoys .............................................................................................. 148
Figure 84 – Etoys: controlling a car with a steering wheel ............................................................. 148
Figure 85 – Etoys: partial property list and categories of properties............................................... 149
Figure 86 – David Canfield Smith & Allen Cypher ........................................................................ 151
Figure 87 – Defining a rule in Stagecast Creator (climbing on top of an ice block)....................... 152
Figure 88 – Conditional rule in Stagecast Creator........................................................................... 153
Figure 89 – Updating variables in Stagecast Creator ...................................................................... 153
Figure 90 – Analyzing which rules apply or don’t apply in Stagecast Creator............................... 153
Figure 91 – Testing a rule in Stagecast Creator............................................................................... 154
Figure 92 – Boxer program for finding phone numbers.................................................................. 156
Figure 93 – Boxer program: controlling graphical elements........................................................... 156
Figure 94 – Playground programming environment ....................................................................... 157
Figure 95 – Liveworld environment ................................................................................................ 157
Figure 96 – HANDS programming system ..................................................................................... 158
Figure 97 – Function Machines program......................................................................................... 159
Figure 98 – Show and Tell programming........................................................................................ 159
Figure 99 – PervoLogo opening screen and newer versions ........................................................... 160
Table of tables
Table 1 – Machine programming in binary and hexadecimal............................................................44
Table 2 – Machine programming with assembler mnemonics ..........................................................46
Table 3 – User programming with word processing styles................................................................53
Table 4 – Sequential and concurrent approached: moving one ball ................................................102
Table 5 – Sequential and concurrent approached: moving two balls...............................................103
Table 6 – Concurrent programming: moving balls with communication ........................................109
Table 7 – Concurrency: synchronicity problems .............................................................................112
Table 8 – Impact of indenting in code readability ...........................................................................119
Table 9 – “Hello world!” code in Lisp and in Logo.........................................................................139
Table 10 – Turtle graphics subset of commands..............................................................................144
Table 11 – GRAIL code for defining a record type and a record,
assigning values, and displaying them on the screen ...............................................................157
Table 12 – Algorithm with motor behavior .....................................................................................176
Table 13 – Petting a dog called Rover, in three languages, including MOOSE ..............................181
Table 14 – Sample AlgoArena program (English-language version) ..............................................187
Table 15 – ToonTalk tools and their purpose ..................................................................................201
Table 16 – ToonTalk static primitives .............................................................................................203
Table 17 – ToonTalk main animated primitives ..............................................................................204
Table 18 – Main results in ToonTalk of using the “drop on” primitive...........................................208
Table 19 – Summary of constraint-matching rules in ToonTalk .....................................................211
Table 20 – Sample ToonTalk controls and sensors..........................................................................217
Table 21 – Main cognitive development theories and theorists.......................................................250
Table 22 – Erikson’s psychosocial stages ........................................................................................254
Table 23 – Piaget's Stages of Cognitive Development ....................................................................258
Table 24 – Piaget's limitations of preoperational thought................................................................259
Table 25 - Levels of quality of ICT use in an early childhood education setting ............................281
Table 26 – Systems potentially usable by preschoolers, for which there is record of such use.......297
Table 27 – Summary on preschool-age use of systems for which there is scarce
(or unreliable) information .......................................................................................................298
Table 28 – Time occupation along the several sessions...................................................................323
Table 29 – First year research, detailed by preschool. .....................................................................324
Table 30 – Children identification and ages.....................................................................................325
Table 31 – Preschool rooms computer environments ......................................................................325
Table 32 – Result of issuing instructions in the wrong order...........................................................328
Table 33 – Research settings............................................................................................................333
Table 34 – Strategy devised for teaching robot programming.........................................................353
1. Thesis overview
1
Cf. “As the ancient mythmakers knew, we are the children equally of the sky and the Earth” (Sagan, 1983, p. 264).
2
This was first theorized by Jean Piaget (Spodek & Saracho, 1994, pp. 73-78; Fosnot, 1996) but is also part of the
educational theories of Paulo Freire (1997) and Leo Vygotsky (Oliveira, 1997; Papalia et al., 1999, p. 339). More
information is available in section 4.1.
3
The information-processing theory was initiated by George Miller (1956) and developed by several researchers, such
as Katherine Nelson (an excellent description of the information-processing approach to the development of cognition
can be found in Papalia et al., 1999, pp. 328-333). In this thesis, more information is presented in section 4.1.
From then on, through that ZX Spectrum computer, I ended up exploring several areas of
programming using the BASIC programming language. But the desire to understand how “real”
games where made even led me to a brief reading on the concept of assembly-language
programming, a few years later. I even resorted to an advanced computer-science concept
unknowingly – using overlays to run programs bigger than the available RAM.
In retrospect, I believe that I was lucky enough to benefit from a situation where three current
educational ideas were very much present. These are presented here in a simplistic view, but will be
explained in more detail and background later on.
The first idea is that the most significant moments of learning computer programming didn’t
involve structured “teaching” or structured “learning”: I was going on my own, driven mostly by
coming up with ideas about what would be “fun” to try, but also about how to assist me (my biggest
project in those years was creating a system for simplifying the tedious process of character creation
in role-playing games). Each achievement was felt as a tremendous success, each failure was either
a challenge to overcome or simply forgotten, since there was so much to explore4.
The second idea is that I didn’t manage to program a thing until I got hold of both a book
structuring the knowledge about programming AND a book making clear that pretty fast I could be
doing something worth my troubles: programming adventure games5.
The third idea is that my efforts weren’t disregarded as useless or serving as a mere method
of keeping me occupied or “studying”: from the very first moment, I was doing something useful,
my tasks were valued: I was helping my father do something he had trouble doing himself. Later
on, even if just to amuse me, each program had a purpose beyond mere “training”6.
These ideas permeate my research as background beliefs: learning needs an open
environment, where children can follow their ideas and interests, not just someone else’s; children
need some structure and support that helps them realize what they can achieve and how; children
take their actions seriously and adults should respect that (Santos, 1999), to the point of involving
them in activities that are useful and meaningful for all, not just for “training” or “practicing”.
4
“The best learning takes place when the learner takes charge” (Papert, 1980, p. 214).
5
“(…) an intellectual culture in which individual projects are encouraged and contact with powerful ideas is
facilitated” (Papert, 1999, p. XV).
6
“We believe in making learning worthwhile for use now and not only for banking to use later” (Papert, 1999, p. XVI).
22 Framework for Computer Programming in Preschool and Kindergarten
Thesis overview
But looking at these settings in my personal account, I can also point out that they couldn’t
have occurred much earlier in my life. And the reason for that isn’t a matter of intelligence or
cognition, but a very real barrier: I needed to know at least a bit of English to start, and that learning
only started in October of 1980, when I was 9 (almost 10). It is reasonable to say that if the
instructions of VCRs and the BASIC instruction set were available in Portuguese, I probably would
have been able to learn how to program earlier: numerous accounts and research of programming
with young children demonstrate that young children can program7.
Since that time, numerous barriers to computer use – and programming – have fallen:
programming can be done in a child’s mother tongue; computer use has been greatly simplified due
to new software and hardware interfaces (GUI, mice, etc.); the production of physical results has
been greatly simplified and enhanced (better and cheaper printing or robotics). A decisive moment
for initiating this research was when I realized that two such barriers had been broken.
The first such barrier is that programming can now be done entirely without writing or
reading of words. Several programming systems, described in chapter 3.3, allow the programmer
(and children) to issue commands and create programs by selection and organization of visual or
physical elements. The tearing down of this barrier meant that children could try to program before
they were able to comfortably read or write commands.
The second barrier is that programming can now be performed in connection with concrete
concepts and elements, most notably using techniques of programming by demonstration, which I
describe in section 2.3.2. The tearing down of this barrier means that children could try to program
early in their mental development.
The realization that this latter barrier had been at least partly overcome was a decisive
moment for me, leading to the initiation of this research: I grew curious to know whether very
young children could or could not start to program computers.
7
Papert’s books and papers contains numerous accounts, mostly of mid-elementary school age, between 9 and 12 years
old: e.g., fourth-graders (1993, pp. 68-69; id., ch. 6, “An Anthology of Learning Stories”, pp. 106-136); a fifth-grader
(1980, p. 100); a sixth-grader (id. p. 118). Reports for first graders are also available (e.g., Degelman et al., 1986), for
all years of elementary school (Papert, 1993, pp. 75-76), and even a few for children as young as four (Perlman, 1974).
More recently, the Playground project involved children aged 6 to 8 in programming activities in different programming
environments (Playground Project, 2001).
8
“seeing ideas from computer science not only as instruments of explanation of how learning and thinking in fact do
work, but also as instruments of change that might alter, and possibly improve, the way people learn and think” (Papert,
1980, pp. 208-209)
24 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
9
On the lighter side, being “nerd” in current days has acquired some glamour. Kelly says, in this same essay: “Call it
nerd culture. For the last two decades, as technology supersaturated our cultural environment, the gravity of
technology simply became too hard to ignore. For this current generation of Nintendo kids, their technology is their
culture. When they reached the point (as every generation of youth does) of creating the current fads, the next funny
thing happened: Nerds became cool. Nerds now grace the cover of Time and Newsweek” (Kelly, 1998). A more recent
account of this new social status of the “nerdish” tastes is given by The Guardian’s newspaper headline after two highly
successful movies in the “Lord of the Rings” trilogy: “We are all nerds now” (Brooks, 2003, citing interviewee).
10
An interesting corollary of this idea is that a computer can be programmed to simulate the operation of another
computer, i.e., turning a general computer-tool into another general computer-tool. This is what occurs, for instance,
when implementing a programming language.
11
This definition is similar to Dijkstra’s “We can view the program as what turns the general-purpose computer into a
special-purpose symbol manipulator, and it does so without the need to change a single wire” (Dijkstra, 1989, p. 1401).
12
A “complex” is a construct of a pair of numbers: one of the numbers is called the “real” part of the complex; the other
is called the “imaginary” part. To write these numbers, usually the letter “i” (sometimes “j”) is used to indicate the
imaginary part. Thus a complex whose real part is 3 and whose imaginary part is 4 is written as 3+4%i (or simply 3+4i).
This construct is called a “complex number”, because if one considers i to be a number, whose value is − 1 , then all
arithmetic used for real numbers is also valid for “complex numbers” such as 3+4i.
13
Logical operations are conducted on logical values (typically, TRUE and FALSE) rather than on numerical values.
Schreyer’s initial circuit could perform AND, OR and NOT operations on three separate inputs.
14
A Victorian estate about fifty miles north of London (Ceruzzi, 1990, p. 232).
36 Framework for Computer Programming in Preschool and Kindergarten
Computer Programming: conceptual foundations
Alan Turing, a mathematician who was
also involved in the wartime code-breaking
effort of the British Foreign Office, and had
earlier written a fundamental paper with the
mathematical analysis of a general-purpose
computational machine (as I explain in
sections 2.2.5 and 2.2.6), suggested that
Newman contact another person working for
the Foreign Office, engineer Thomas
Flowers (Copeland, 2000). Flowers designed
“a fully electronic machine with a similar
function to Heath Robinson. [He] (…)
received little official encouragement (…)
Figure 10 – Colossus
but proceeded nonetheless, working From: http://www.computersciencelab.com/ComputerHistory/HtmlHe
independently at the Post Office Research lp/Images/Colossus.gif
Station at Dollis Hill. Colossus I was installed at Bletchley Park on 8 December 1943” (id.). Its job
was to compare two paper tapes, one with an encrypted German message, and the other with a
previously-deducted mathematical supposition about what the encoding on that message might be.
This comparison would yield a “clue” about the exact code used on the encrypted message, and that
clue would lead to another tape and so forth, until the message was decoded (Ceruzzi, 1990, p. 233).
The main feature of the original Colossus was its operation at the speed of five thousand characters
per second, relying on electronic components for both calculation and also to read in data at high
speed, keeping synchronized the two different paper tape sources. A second version, built in 1944,
brought with it another important development, “consequent upon a key discovery by cryptanalysts
Donald Michie and Jack Good” (Copeland, 2000): it “contained circuits that could automatically
alter its own program sequence. If it sensed a potentially meaningful pattern, a circuit permitted it
to redirect its stepping through the internal table in such a way that would more quickly find a path
to a solution” (Ceruzzi, 1990, p. 234-235). The Colossus machines, however, despite all these
advances, could only deal with the specific problem of decoding encrypted messages, and only
messages encrypted in the style employed by the German military at the time of World War II.
They “did not perform ordinary arithmetic, nor (…) solve other logical problems not cast in the
same mold as those for which [they were] designed” (Ceruzzi, 1990, p. 235).
Figure 12 – ENIAC
From: http://www.computersciencelab.com/ComputerHistory/HtmlHelp/Images/eniac1.jpg
15
In fact, it was even a step back in one aspect: it embraced a decimal notation for recording numbers internally, instead
of the much faster binary notation already developed by then and still in use today.
38 Framework for Computer Programming in Preschool and Kindergarten
Computer Programming: conceptual foundations
« Charles Babbage first conceived of the idea of an automatic digital
computer. John V. Atanasoff, together with Helmut Schreyer and perhaps
others [most notably Konrad Zuse], first conceived of an electronic digital
computer. John Mauchly and J. Presper Eckert, as leaders of a skilled team
at the Moore School, invented the first working electronic numeric digital
computer. »
(Ceruzzi, 1983, p. 111)
« It deserves its fame not for its electronic circuits, which several other
machines already had, nor for its architecture, which although ingenious
and full of promise was rejected by subsequent designers. One should rather
remember the ENIAC as the first electronic machine to consistently and
reliably solve numerical problems beyond the capability of human and in
many cases relay computers as well. »
(Ceruzzi, 1990, p. 236)
« It was not fully a " "general-purpose computer" – for example, it could
not solve large systems of linear equations as Atanasoff's machine was
designed to do. But its ability to be reconfigured to perform an almost
limitless sequence of steps, including iterative loops of operations, sets the
ENIAC apart (...), and places it astride the categories of "calculator" and
"computer." »
(Ceruzzi, 1990, p. 241)
16
“(…) these columns are designated (…) the Variables. The origin of this appellation is, that the values on the
columns are destined to change, that is to vary, in every conceivable manner. (…) The columns are called Variables on
a ground wholly unconnected with the analytical distinction between constants and variables.” (Byron-King, 1843,
Note B).
42 Framework for Computer Programming in Preschool and Kindergarten
Computer Programming: conceptual foundations
For instance, in the table presented in Figure 17, on the previous page, the variables V1, V2,
and V3 have been loaded with the values 5, 7, and 98. The notes inside the squares below these
columns tell that these are values for the algebraic elements a, x, and n. Finally, the variable V4 is to
receive the result, and the notation tells us that the original elements are to be combined into the
expression axn. (The values in variable V4 could be referred to just as those in the other variables,
and thus employed in other calculations.)
The rest of the program would specify the sequence of operations to perform in order to
achieve the desired results. For instance, in the axn example there would have to be 6
multiplications (to produce 987), and a seventh multiplication (to multiply the previous result by 5,
the value of a). The tables necessary for this kind of elaborate specification could easily grow quite
large, and the programmer had to keep in mind the actual way in which the machine would interpret
the control cards, rather than just the mathematical notation, as is demonstrated by Figure 18, on p.
42, which presents the program for the calculation of the following two simple functions, x and y:
dn′ − d ′n d ′m − dm′
x= y=
mn′ − m′n mn′ − m′n
Since the actual instructions were not stored in variables or otherwise accessible to the
program execution itself, in effect this programming of the Analytical Engine was an advanced
planning methodology for what I referred to, in section 2.2.1, as the reorganization of the physical
elements of the computer. In other words, the control and variable cards were the last pieces of the
machine: programming was the planning of their proper placement, as if one would be, each time,
re-assembling a bit of the machine.
This style of programming, i.e., using some planning for determining the sequence of
operations to be conducted by the specific elements of the machine, was also a fundamental
consideration of the programming process of early computers such as the ENIAC (vd. p. 38):
« To reprogram the ENIAC you had to rearrange the patch cords that you
can observe on the left in the prior photo [(Figure 12, on p. 38)], and the
settings of 3000 switches that you can observe on the right. (…)
Circumference = 3.14 * diameter
To perform this computation on ENIAC you had to rearrange a large
number of patch cords and then locate three particular knobs on that vast
wall of knobs and set them to 3, 1, and 4. Reprogramming ENIAC involved a
hike. »
(Kopplin, 2002)
This planning approach was only replaced by one more focused on requesting a machine to
conduct specific operations, without having to physically change, when computers were developed
17
Alan Turing, in his theoretical analysis of 1937, didn’t restrict the symbols processed by computing machines to be
only numbers (Turing, 1937).
44 Framework for Computer Programming in Preschool and Kindergarten
Computer Programming: conceptual foundations
converted the numbers into binary, carried out the sequence, and displayed
the result on the lamps after reconverting it back to decimal notation. »
(Ceruzzi, 1990, p. 206).
One advantage of entering decimal numbers with a keyboard is that it's much less error-prone
to use decimal (or hexadecimal) notation than it is to enter long sequences of 0s and 1s.
Before moving on to the next section, I’d like to present a
personal note. My first contact with this reality was in September
1985, when I bought my first computing magazine, a British
magazine called Your Spectrum (Figure 20). At the end of it,
there was a program by Stuart Jamieson (Jamieson, 1985), for a
game called “Mac Man” (a Pac-Man18 clone, Figure 21). This
was the exciting presentation of the process of entering
hexadecimal instructions and data:
« Before giving you the details of the game (Only
hermits won't know what it's all about! Ed.), here's
how you get that code into your Speccy19. First type
in the machine code loader and SAVE it to tape. Next
type in the Hex loader program and RUN it. It'll
accept eight bytes at a time (without spaces) and then
ask for a checksum (which is given after the eight
Hex pairs). You'll then be asked to SAVE the code
after the short loader program. This done, reset the Figure 20 – Your Spectrum issue 12
Spectrum, rewind the tape to the beginning, enter From: ftp://ftp.worldofspectrum.org/pub/si
LOAD "" and press the Play button on your cassette nclair/magazines/YourSpectrum/Issue12/Y
RCover12.jpg
machine. It's as easy as that! »
(Jamieson, 1985)
Piece of cake, indeed! I tried four times to enter the code
into my ZX Spectrum, each time carefully entering each number
– but still something would fail, and the program wouldn’t run!
And the magazine printing of code wasn't that perfect, so I
couldn’t be too sure I was reading the numbers right, and I
eventually gave up (on Mac Man, not on the Spectrum or on
machine code).
Figure 21 – Mac Man playing
Here’s a sample of the code to be entered in that “hex screen
From:
loader” program. Thanks to the Internet, I now have access to it http://www.users.globalnet.co.uk/~jg27pa
without having to enter it all from printed matter! w4/pourri/mac_man.gif
26490 3E 07 32 48 5C 32 8D 5C =566 26570 68 75 21 28 68 01 0E 01 =414 26650 C9 01 20 00 09 06 20 7E =407
26498 32 8E 5C 32 8F 5C 32 90 =763 26578 C5 E5 C5 06 08 C5 CD 01 =1040 26658 17 77 2B 10 FA C9 20 4D =761
26506 5C AF D3 FE 21 00 40 11 =846 26586 68 C1 10 F9 C1 E1 7E 23 =1141 26666 41 43 4D 41 4E 20 57 52 =553
26514 01 40 36 00 01 00 18 ED =381 26594 E5 CD 36 69 E1 3E F7 DB =1346 26674 49 54 54 45 4E 20 42 59 =575
26522 B0 21 00 58 11 01 58 36 =457 26602 FE CB 47 28 10 3E BF DB =1056 26682 20 53 54 55 41 52 54 20 =547
26530 07 01 00 03 ED B0 CD C2 =823 26610 FE CB 47 28 08 C1 0B 78 =900 26690 4A 41 4D 49 45 53 4F 4E =598
26538 67 3E F7 DB FE CB 47 C8 =1359 26618 B1 20 D5 18 CD C1 C9 21 =1078 26698 20 7F 31 39 38 34 20 2E =451
26546 3E BF DB FE CB 47 CC 78 =1324 26626 1F 50 CD 0E 68 21 3F 50 =610 26706 20 47 55 49 44 45 20 4D =507
26554 69 06 C8 76 10 FD 18 CC =926 26634 CD 0E 68 C9 06 08 C5 E5 =964 26714 41 43 20 4D 41 4E 20 52 =498
26562 11 CD 76 0E EE 06 27 CD =842 26642 CD 1B 68 E1 24 C1 10 F6 =1052 26722 4F 55 4E 44 20 54 48 45 =567
(Jamieson, 1985, 5% of total code)
18
An excellent history and description of the original Pac Man game and its sequels can be found on the Web
(Robertson, 2002).
19
The name by which ZX Spectrum fans caringly referred to their computers.
20
The programmer would note down the actual memory addresses represented by the textual labels.
46 Framework for Computer Programming in Preschool and Kindergarten
Computer Programming: conceptual foundations
« When these techniques were first introduced, programmers used such
notation when designing a program on paper and later translated it into
machine-language form. It was not long, however, before this translation
process was recognized as a procedure that could be performed by the
machine itself. Consequently, programs called assemblers were developed to
translate other programs written in mnemonic form into machine-compatible
form. (…) Mnemonic systems for representing programs were in turn
recognized as programming languages called assembly languages. »
(Brookshear, 2003)
These assembly languages were thus the first programming languages, but they possessed a
major limitation: they were completely tied to the hardware architecture of the machine where they
were intended to be run. One could not pick up an assembly-language program intended for a
hardware architecture and input it in an assembler program for another hardware. The next step in
the evolution of programming languages was the realization that the programmer could program
independently of the hardware architecture, at least for expressing simple ideas such as Price +
Shipping Charge = Total Cost.
As is often the case, the mathematical background supporting this process of automatic
conversion from human-readable form to machine-readable form had been developed much earlier.
And once more, the people that took this missing step did it independently. Heinz Rutishauser (who
worked with Konrad Zuse), recognized such need in his 1951 lecture “Automatische
Rechenplanfertigung bei programmgesteuerten Rechenmaschinen” (Bauer, 2002; Ceruzzi, 1983).
And Rutishauer was rediscovering a concept first formulated by Alan Turing in 1936. Before
general-purpose computing machines existed, Turing mathematically described and analyzed the
functioning of such a machine, and due to this achievement general computing machines are also
frequently referred to as “Turing machines”.
« It is possible to invent a single machine which can be used to compute
any computable sequence. If this machine U is supplied with a tape on the
beginning of which is written the S.D [(standard description)] of some
computing machine M, then U will compute the same sequence as M. In this
section I explain in outline the behaviour of the machine. The next section is
devoted to giving the complete table for M. »
(Turing, 1936, pp. 241-242)
Turing’s conception and its analysis are a mathematical proof of the possibility of
programming the resolution to a problem, not caring about the technological specification of the
machine where that resolution will be executed: it suffices that the resolution first feeds the actual
machine with the specification of the virtual machine it was conceived to run upon.
In other words, it means that instead of worrying about issues such as “in which electronic
register or memory address should I save the values I want to add” or “which electronic register or
memory address will receive the resulting values”, a programmer can think in terms such as
“TotalCost will receive the result of adding the values Price and ShippingCharge” – a considerable
advantage, allowing the programmer to focus more in the problem at hand, and less on the machine
that will execute the program intended to solve that problem.
In practice, this is not absolutely so, because real machines have physical limitations, while
Turing’s conception may not have21, and therefore a professional computer program, no matter how
21
“If a computing machine never writes down [on the tape] more than a finite number of symbols of the first kind, it will
be called circular. Otherwise it is said to be circle-free. (…) A sequence is said to be computable if it can be computed
by a circle-free machine. A number is computable if it differs by an integer from the number computed by a circle-free
machine” (Turing, 1936, p. 233).
22
Which are still used today, but only when performance requirements or low-level hardware management concerns
require the programmer to think in hardware-specific terms.
23
These included instructions to “force” the execution to proceed from a specific point in the list of instructions, a
method which later was mostly abandoned (Dijkstra, 1968), and for organization of the flow in a structured form, such
as subprocedures (sets of commands with a specific purpose, that can be called upon to complete that purpose, before
proceeding) and cycles (repeating a set of instructions a number of times or subject to specific conditions).
24
International Algebraic Language (Perlis & Samelson, 1958).
25
Wirth, 1993.
26
Ritchie, 1993.
27
Gargaro, 1993.
48 Framework for Computer Programming in Preschool and Kindergarten
Computer Programming: conceptual foundations
known by the widely used language COBOL, created in 1959 (Sammet, 1978), which was inspired
by the language B-0 (later known as Flow-matic). This, in turn, was created in 1956 by Grace
Hopper (Gorn, 1957), culminating a development initiated in 1951 with the A-0 compiler, a project
that also produced a language released in 1957, under the name Math-matic (Sammet, 1972).
Another early verbose language was the APT language, developed in 1957 for use in industrial
machines with numerical controls (Ross, 1978). There have been many specialized languages for
machine control and information processing, most notably the current standard language for
database querying, SQL28.
A distinct approach was employed in the Lisp programming language, developed between
1956 and 1962 (McCarthy, 1979). This approach, known as the functional paradigm, is entirely
centered on the manipulation of functions, seen as expressions which receive parameters and
manipulate them, producing a result. This was in contrast with the approach used in Fortran, which
basically was a set of commands for manipulating stored values, rather than for organization of
code itself – those would later be introduced to imperative languages by the Algol branch,
mentioned in the previous paragraph. In a functional language, functions can be passed as
parameters to other functions, and in fact even values are seen as the results of functions that
provide always the same value: the entire language is composed by simple operators and a notations
for defining functions in terms of other functions and the basic operators (McCarthy, 1979). Many
technical contributions originated in functional languages and then were incorporated into
imperative languages, such as conditional execution29 (Graham, 2002).
Among several other languages based on the functional paradigm of Lisp, one finds Logo,
with a long history of educational programming use, which is described on pp. 139-146. Other
famous languages that follow this paradigm are ML30, Erlang31, and Haskell32. Yet, possibly the
most widely used functional languages are those of a specific type (one might almost call it a
subparadigm), called data-flow (Johnston et al., 2004, p. 9). These languages allow the
programmer to conceive the program as a graph, with data flowing between nodes, for processing.
The programmer defines those processing “nodes” for data, the actual processing methods and
syntaxes varying (inside a node, a pure data-flow language would only employ primitive
instructions such as arithmetic or comparison operations, but actual data-flow languages frequently
employ techniques from other programming paradigms33). It is also the programmer’s task to define
the connections between the various nodes, specifying how the data flows from one node to the
next; at each node, the computation waits until all data sources are available, and then its processing
takes place. Possibly the earliest such language was TDFL, from 1975 (id., p. 10), but their
popularity is due to the various data-flow visual programming languages developed since the 1980s.
Examples of such languages include LabVIEW (vd. Figure 74, on p. 125), its children-oriented
derivative RoboLab (p. 162), and the language used in the MindRover game (p. 188); but their
widespread use is due to the fact that this is also the paradigm employed in the programming of
business spreadsheets34 (Kay, 1984), such as Microsoft Excel (Microsoft, 2004a).
A radical departure from both the imperative and the functional paradigms is to program
without specifying any manipulation of data at all, neither by direct orders, nor by definition of
functions. Such a departure was originated by the Prolog language, created by Philippe Roussel and
28
Hoffman, 2001.
29
Determining a condition and from it determine whether a set of instructions should be executed – or which set, if
several sets are available.
30
Harper, 2005.
31
Armstrong, 1997.
32
Hudak & Fasel, 1992.
33
“Most dataflow architecture efforts being pursued today are a form of hybrid, although not all (…). (…) it seems that
dataflow languages are essentially functional languages with an imperative syntax” (Johnston et al., 2004, pp. 2, 10).
34
Even disregarding the fact that the data-processing instructions in spreadsheet cells are textual, one might still
consider these languages only halfway visual: the editing of nodes is visual, and sometimes their selection too, but the
arcs of the dataflow graph are not represented, being defined by way of textual references in the nodes’ code.
35
Stroustrup, 1993.
36
Chandra & Chandra, 2005.
37
Id.
50 Framework for Computer Programming in Preschool and Kindergarten
Computer Programming: conceptual foundations
Typically, the user would now stop recording and assign this macro to a key such as “F8” or
to a toolbar button labeled “Remove >”. While time-consuming, it’s easier to click consecutively on
F8 or on a single button than it is to be moving the mouse and using a few keys for each line. (With
a little bit of actual programming language use, even this much trouble could be avoided.)
Now, suppose that for some reason the original message had more than a single space at the
start of each line:
>•Hello,
>••Is everything fine with you?
>••I went to the game last night.
…
Using the previous macro in this message would result in:
Hello,
•Is everything fine with you?
•I went to the game last night.
…
This happens because the recorded action was “press Delete twice”, and it was only by
coincidence that deleting two chars in the first message was the action that removed the prefixes.
An experienced user would have rather used “press-and-hold Ctrl and press →. Then press
Delete”. This would select all spaces from “>” to the beginning of the first word, therefore being
applicable to larger number of situations. While this is usually called “advanced use”, or something
for this effect, such care in specification of actions, considering possible future situations, is a
programming skill and activity.
Another of Cypher’s categories, preferences, is extremely common: most applications have
some kind of “options” or “preferences” section where users can customize the operation of the
application. However, these often include a certain degree of programming. One such example can
be found in modern word processing packages, where users can set a large number of options for
automated processing of text. For instance, a user can set “(c)” to display as “©”, besides many
38
In this case, this classification is fuzzy; rather than reproducing the operator’s movements precisely, the robots can
use sensors to fine-tune of the original motions. Thus, one can state that the robot generalized of the original
instructions, and this would be a case of programming by demonstration, rather than macro programming.
58 Framework for Computer Programming in Preschool and Kindergarten
Computer Programming: conceptual foundations
typical of end-user multimedia-authoring To draw a shape:
programs, such as timeline controls 1. Use MovieClip.createEmptyMovieClip() to create an
(Figure 26). However, for full control of empty movie clip on the Stage. The new movie clip is a child
of an existing movie clip or of the main Timeline, as shown
the animations and user interactions, Web in the following example:
graphic designers need to use textual this.createEmptyMovieClip ("triangle_mc", 1);
scripting languages: for instance, in 2. Use the empty movie clip to call drawing methods. The
Macromedia Flash, the scripting language following example draws a triangle with 5-point magenta
lines and no fill:
is called ActionScript (Macromedia, with (triangle_mc) {
2004b), as shown in Figure 27. lineStyle (5, 0xff00ff, 100);
moveTo (200, 200);
Still in the area of graphics, many lineTo (300, 300);
modern movies routinely employ lineTo (100, 300);
lineTo (200, 200);
computer-programming techniques as part }
of their development. For instance, in
Figure 27 – Programming with ActionScript
Disney’s 1985 movie The Black Cauldron, From: Macromedia, 2004b, p. 217
“computers made inroads in the
manipulation of solid inanimate objects on the screen. The dimensions and volume of objects were
fed into a computer and their movement was generated by programming” (Magical Ears, n.d.). The
professional process of creating computer animations for movies frequently involves a combination
of use of specialized end-user animation tools and programming, to determine the specific rendering
of visual features, such as surface textures under different lighting, blurring to improve the illusion
of motion, and so on. Further, behaviors and movements for characters need to be modeled, and
while this can be achieved by several traditional techniques, involving multiple images to convey
the idea of motion, the use of procedural techniques is attaining large popularity.
« Current technology is not capable of
generating motion automatically for arbitrary
objects; nevertheless, algorithms for specific
types of motion can be built. These techniques are
called procedural methods because a computer
follows the steps in an algorithm to generate the
motion. Procedural methods have two main
advantages over keyframing techniques: they
make it easy to generate a family of similar
motions, and they can be used for systems that
would be too complex to animate by hand, such
as particle systems or flexible surfaces. »
(Hodgins et al., 1999, p. 6)
A particular use of these techniques is the control of
vast numbers of characters, where each computer-generated
figure must display a singular, individualized behavior. One
often-cited example are the crowd scenes in Walt Disney’s
“The Hunchback of Notre Dame” (e.g., Hodgins et al., 1999,
p. 7), or more recently the huge armies in the three “The Lord
of The Rings” movies of New Line Cinema (vd. Figure 28).
In this last case, in particular, the large numbers of
computer-generated figures in the armies were programmed
not only to display individual behavior, but also to respond to Figure 28 – Computer-generated
characters combined with live images
the behavior of other nearby figures – to such an extent that From: http://www.warofthering.net/ahobbitstale
sometimes complex group behaviors emerged: /extras/extras_sfx1.jpg
39
Typical examples are: electrical appliance control (pre-heat oven on certain conditions, start dishwashing cycle at
specific hours), lighting control (on/off, intensity and mood), windows blinds and curtains, heating or cooling levels and
profiles, automated hi-fi or home cinema, and operation of garden sprinklers (Smarthome, 2005).
60 Framework for Computer Programming in Preschool and Kindergarten
Computer Programming: conceptual foundations
Artists are also exploring novel approaches to the creation of art, by integrating computer
programming – and even robotics – in their work. In particular, the field known as algorithmic art
(Verostko, 2004) has long taken advantage of the possibilities brought about by computer
programming in the production of art, its practitioners known as “algorists”.
« As computers became more accessible to artists in the 1970's and
1980's some artists began to experiment with algorithmic procedure. The
new technology offered them methods of working algorithmically that were
unavailable before the advent of computers. By the 1980's a number of these
artists were working with the pen plotter, a machine with a "drawing arm".
By the end of the 1980's algorists like Harold Cohen, Mark Wilson, Manfred
Mohr, Jean Pierre Hebert and this author had already achieved a mature
body of work. Each in their own way had invented algorithmic procedures
for generating their art. By doing so each created their own distinctive style.
Clearly style and algorithm were linked in a very important way. »
(Verostko, 2004)
At this level, the specific applications of programming are diversified. For instance, Some
artists use their algorithms to have computer plotters draw the result of their algorithms (Figure 30),
sometimes replacing the typical print heads of plotters by brushes or other artistic tools (Figure 31).
Figure 34 – Robots at work and painting in progress (30, 60, 120 and 240 minutes)
From: http://www.lxxl.pt/artsbot/atwork.jpg and http://www.lxxl.pt/artsbot/image005.jpg
Conversely, some people have started to inquire on the artistic potential of programming
itself40, as a novel form of human endeavor, both from the perspective of an elaborate craft
(Fishwick, 2000; Hunt, 2001), and from that of an artistic form in its own right:
« (…) some programmers have adopted a literary approach to coding,
describing carefully crafted code as “beautiful,” “elegant,” “expressive,”
and “poetic”; writing and reading programs as literary texts; and even
producing hybrid artifacts that are at once poems and programs. »
(Black, 2002, p. v)
Returning to non-artistic examples, in various professional fields there are occasions when
some time-consuming task lends itself adequate for the use of small customized programs, or there
is an intention to provide computer-based support for its execution. Sometimes, however, people
that are not professional programmers take up the task
of programming. The circumstances leading to this can
be varied, but to point just two: there may be no budget
to hire the services of a professional programmer or
software-development company; or special subtleties of
the data to be processed may cause professional
programmers unacquainted with it to misunderstand
specifications, leading to the failure of the development
project, and such a frustrating experience may cause the
people involved to decide and program the software
themselves.
In cases such as these, professionals from various
areas besides programming end up dusting off
programming skills learned in undergraduate course or
training sessions (or even deciding to outright learn
programming from scratch), in order to produce
themselves the necessary software. For instance, I once
came across a program for management of a surgery
waiting list, developed by the surgeon himself; and the
development of a large on-line European Prehistoric Art Figure 35 – EuroPreArt sample data-entry
Database, presented in Figure 35, has been conducted by form and Web results
From: http://www.europreart.net/eurodb1.gif and
one of its participant archaeologists (Arcà, 2002). http://www.europreart.net/preart.htm
40
As a final comment under this arts theme, it’s interesting to note that Logo, the first computer programming language
for children (vd. p. 139), owed much of its success to a subset of commands designed to allow children to perform
drawings procedurally (vd. p. 144). Also in this thesis, the very first of my proposed usage typologies of computer
programming in preschool education involves its use as a space for self-expression (vd. section 7.3.1).
62 Framework for Computer Programming in Preschool and Kindergarten
Computer Programming: conceptual foundations
While the programming of complex and demanding applications by non-professionals can be
a bad option, likely to produce awkward contraptions suffering from well-known and easily-
avoidable programming pitfalls, the use of programming to automate small repetitive tasks as they
pose themselves – or even slightly before that, when one manages to anticipate them – can be a very
good option, leading to increased productivity, and has been called just-in-time programming:
« the goal of just-in-time programming is to allow users to profit from
their task-time algorithmic insights by programming. Instead of automating
with software that was carefully designed and implemented much earlier, the
user recognizes an algorithm and then creates the software to take
advantage of it just before it is needed, hence implementing it just in time. It
is worth emphasizing that the user's task could be from any domain (e.g.
graphic drawing, scientific visualization, word processing, etc.) and that the
algorithm to be implemented originates with the user. Obviously, a user
with more programming experience will be able to envision a more complex
algorithm than a novice user. »
(Potter, 1993)
Basically, programming just in time can be a good option when the time and effort invested in
the programming diminishes the overall time and effort spent on the entire task (Figure 36). Such a
decision is dependent on the programming skills of the individual, on the features of the
programming tools available, and on the level of programmatic access to the data (id.).
To conclude, I’d like to briefly mention a group of professionals who are, possibly, the ones
closest to professional programmers in their use of computer programming in their jobs. I am
referring to people whose jobs require them to use programming virtually on a daily basis,
employing programming skills identical to those of professional programmers: people who
constantly analyze novel situations, for which no adequate computational tool is (or can be)
available, other than a programming-based tool.
These professionals are found working in fields employing calculus, the creation and analysis
of simulations, or the creation and analysis of decision-making scenarios. Such fields include
engineering, biotechnology, financial analysis, mathematics, and scientific research, using
programming-based tools such as Mathematica (Wolfram Research, n.d.), ChemCAD
(Chemstations, n.d.), Simulink (The MathWorks, n.d.-1), and MATLAB (id.), among many others.
41
An example program of self-instruction for classroom use for instructors, following this method, is available on-line,
for Microsoft Windows personal computers, from the Web site of the B. F. Skinner Foundation, at this address:
http://www.bfskinner.org/instruction/setup.exe.
42
CCC was purchased by Simon and Schuster Publishing, which then became part of Viacom and was then sold by
Viacom to Pearson plc (Viacom, 1998). Currently (July 2004), its know-how is part of Pearson’s division named
Pearson Digital Learning (http://www.pearsondigital.com).
Figure 45 presents the tutorial option highlighted amidst the options in the game entry screen.
After selecting it, the player initiates the game normally, being presented with just a small bit of
information, about the starting situation and goals (Figure 46).
Figure 46 – Civilization III’s first bit of information: initial situation and goals
Figure 47 – Civilization III’s first directions: find a good site for the capital city
As the play progresses, the tutorial system will point to elements in the screen that the user
needs to use at that moment and provides explanations (Figure 48).
43
Programmed Logic for Automated Teaching Operations
Under the discovery learning strategy, “a teacher might call attention to a problem, but the
task of inventing a method for dealing with the problem was left as the responsibility of the student”
(Solomon, 1996, p. 44, quoting Davis). Teachers support such discovery strategies by providing
hints and help. This approach aims at enforcing children’s use of mental reasoning over canned
methods, thus helping the child develop his/her own internal knowledge structure. The teacher
interaction provides help in this process, both during build-up and during correction of wrong
assumptions, when things don’t turn out right. For instance, Figure 54, on page 79, shows a
software program intended for this strategy: children explore concepts in a specific context (in this
case, an archaeology exploration where word decoding is necessary), and then must solve several
problems, with the possibility of trying several strategies.
The publisher’s promotional video gives a summary of activity content:
« This complete phonics program offers the opportunity to begin with
phonemic awareness activities, involving the blending, segmenting, rhyming
and isolation of sounds.
In comprehensive phonics activities, students participate in decoding
exercises, in which they study words to identify initial, final, and medial
consonant sounds, as well as long and short vowel sounds.
78 Framework for Computer Programming in Preschool and Kindergarten
Computer Programming: conceptual foundations
In the "word family" activities, students use word family patterns to build
their own interactive word walls, and then practice sorting words by word
families. »
(Plato Learning Inc., 2004)
Obviously, Davis’ early software had the look of Figure 52, not the modern look of the
applications presented in Figure 53 and Figure 54, but the main educational ideas presented in the
previous paragraphs were already developed from the start.
44
“Total videogame software and hardware sales in the United States reached $8.9 billion, versus $7.3 billion for
movie box-office receipts; $6.6 billion of the videogame receipts were from software sales, retail and online” (Poole,
2000, p. 6).
45
In his 2003 book, James Paul Gee goes on to deduce, analyze and present 36 “learning principles” that can be
extracted from video and computer games.
46
Some teachers employ videogames that aren’t labeled as edutainment in their classes. E.g., for a first-hand account
with college students see Amory et. al. (1999).
82 Framework for Computer Programming in Preschool and Kindergarten
Computer Programming: conceptual foundations
Of course, not all word-processing tasks are literary ones, and even for those this view is
perhaps too strict. For a regular writing task, by a regular writer, I find it likely that a simple feature
such as “search” can immensely improve a writer's product. Considering that any line of dialogue
by a character can be prefaced by something like “[Butler]”, for instance, means that a writer can in
a short time check all the character’s lines and more easily refine his/her manner of speaking, for
instance. Or find the places and circumstances where a specific adjective was used – something that
would require a prodigious memory for a traditional writer. This is but one example of how a
simple tool like a word processor can seriously impact the user’s process. But whether these
impacts are “radical” is debatable. Also, this observation doesn’t change the point that some tools,
such as word processors, are mainly devoted to improving and rendering easy the execution of some
task.
By contrast, mindtools provide alternative ways of thinking. This is part a feature of the tools
itself, part a matter of the way it is used. So, an example is helpful to clarify what a mindtool is: a
spreadsheet, for instance, can be used both as a productivity tool and a mindtool (spreadsheets were
already mentioned in section “2.3.2 – End-user programming”).
In a spreadsheet, a user can enter numerical data in specific cells in a grid. Typically,
spreadsheets are used for accounting, allowing the automation of multiple calculations. The user
can enter, for instance, the prices of all products sold in a given circumstance, and get the resulting
sum in another cell; if there is a mistake in one of the entered numbers, it suffices to edit its cell and
the resulting sum is updated instantly. Quite often, this ability for effortlessly production of
calculation results is used also to support decision-making: instead of adding known values, for
instance, several different values can be entered in the same cell, to analyze the resulting impact in
the result.
When being used to automate calculations, a spreadsheet is a productivity tool: what it does
could also be done by hand (and had been done by hand for centuries). However, when used to
analyze the impact of different values, this implies a serious change: the user-accountant is no
longer just a calculator, but also a “hypothesis tester (playing ‘what if’ games)” (Jonassen, 2000, p.
87).
But spreadsheets even go a step beyond, since most users have to construct their own
spreadsheet formulas. When a spreadsheet cell (for instance at column A, row 10) presents the sum
of all cells above it (column A, rows 1-9), that's because someone entered a summing formula in
that A10 cell (probably "=SUM(A1:A9)"). When such operations are commonplace, customized
accounting or decision-making applications are usually developed and sold, so that computer users
can benefit from this behavior, without having to know how to build such formulas. So people that
use spreadsheets, rather than specific accounting applications (or other numeric processing
applications) usually end up resorting to them for those tasks that bear some particularity, some
feature specific to the user's situation, for which there is no specific software application. This
means that spreadsheet users must enter their own formulas, to produce the desired calculation
results. To do so, they “engage a variety of mental processes (…) to use existing rules, generate
new rules describing relationships, and organize information (…). The emphasis in constructing a
spreadsheet is on identifying and describing those relationships in terms of higher order rules”
(Jonassen, pp. 87-88).
So, in short, using software as a mindtool involves using its abilities to attain a deeper
understanding of the matter being studied or worked upon. This requires teachers to prepare
activities that propel students to use the software in such a fashion, by analyzing content domains,
guiding study, and coaching the use of the software, by helping students plan, adapt existing models
of using the tool, creating and completing specifications, extrapolating and reflecting (Jonassen,
2000).
« Mindtools are knowledge representation tools that use computer
application programs such as databases, semantic networks (computer
Framework for Computer Programming in Preschool and Kindergarten 83
Universidade de Trás-os-Montes e Alto Douro
concept maps), spreadsheets, expert systems, systems modeling tools,
microworlds, intentional information search engines, visualization tools,
multimedia publishing tools, live conversation environments, and computer
conferences to engage learners in critical thinking. (…) They can be used
across the school curricula to engage learners in thinking deeply about the
contents they are studying. »
(Jonassen, 2000, p. 19)
As a final note, it’s interesting to realize that there are several connections between what
Jonassen refers to as “mindtool” use and the instances of computer programming I presented in
section “2.3.2 – End-user programming”. In his 2000 book, he gives up on finding mindtool use for
word processors, leaving open only the possibility that his concept of a mindtool may be less
inclusive than his reader's. But I believe that style-definition activities for text, such as those
described in section 2.3.2 fall within Jonassen’s concept of a mindtool. And in fact several parts of
what he calls “mindtool” use could in fact be related to computer programming skills.
However, Jonassen objects to considering computer programming languages as mindtools
(his remark refers just to Logo, but his motives are applicable to other languages), because they fail
one of his rules for defining mindtools, which is that they should be easily learnable:
« Although Logo is a syntactically simple language, it still requires
several months of practice to develop skills sufficient for easily creating
microworlds. »
(Jonassen, 2000, p. 156)
As it happens, the creation of microworlds is not the goal of using a programming language in
education, although it is one of the methodologies for their use. There are more than a few uses of
computer programming that can be learned and applied effectively in well under 1 or 2 hours, so
this objection is debatable in face of Jonassen's own definition for the rule of being “easily
learnable”, which I transcribe here in its entirety, for the sake of debating it:
« The mental effort required to learn how to use the software should not
exceed the benefits of thinking that result from it. If weeks of effort are
required to learn software, the software becomes the object of learning, not
the ideas being studied. The syntax and method for using the software should
not be so formal and so difficult that it masks the mental goal of the system.
Software programs that are overly complicated to use are not good
Mindtools. The basic functionality of the software should be learnable in 1 to
2 hours. You may want students to think causally about information in a
knowledge domain, but if the system requires weeks of agonizing effort to
learn, the benefits of thinking that way will be outweighed by the effort to
learn the system. »
(Jonassen, 2003, pp. 18-19)
I propose analyzing reading and writing as mindtools, albeit not computer-based ones.
Jonassen indirectly acknowledges them as such when he categorizes language as a “cognitive
technology” (2003, p. 13), when discussing the attributes of mindtools. But you can’t master
reading or writing in 1 or 2 months, (for some children, not even in 1 or 2 years) let alone 1 or 2
hours. And for a few children, the words “agonizing effort” would certainly serve as an apt
description of their feelings as they struggle in school to learn how to read and write. So, are
reading and writing not mindtools, or at least bad mindtools? And are they being learned by their
own sake? Rather, they are being learned (from the point of view of the individual) to prevent
children to be limited in their adult lives by lack of literacy, with all assorted consequences
(personal, professional, social, etc.).
48
From 1982 to 2000, the percentage of USA households with personal computers grew from around 2% (U.S. Bureau
of the Census, 1988) to approximately 51%. This growth was faster in recent years than during the 1980s, when this
figure grew from 2% to 15%. However, that decade represents the first period of this explosive growth (General
Motors, 2003; U.S. Bureau of the Census, 1993). In schools, however, this growth is indeed remarkable in the 1980s: in
1981 only 18.2% of all public schools had microcomputers, but this value had already grown to 97% by 1989 (U.S.
Bureau of the Census, 1993).
Statistics for Portugal and the European Union:
Portuguese households with computer in 1995: 11%; in 2002: 28% (INE 2002).
European Union households with computer in 2000: 35% (INRA 2000).
88 Framework for Computer Programming in Preschool and Kindergarten
Computer Programming: conceptual foundations
All along, the BASIC language developed by Kemeny and Kurtz had evolved from its
primitive form, incorporating advanced computer science topics that were appearing in languages.
But since each computer manufacturer had its own version of BASIC, which as I referred above
was often limited due to hardware constraints or mere carelessness, the BASIC language that most
people used was but a pale image of this.
« So the BASIC in our family was a sophisticated language with a good
collection of structured constructs, sophisticated graphics, all the good
modularization tools, etc. What a far cry from what most of the rest of the
world had to use. (…) To give you an idea of how others had prostituted our
beautiful language (…) »
(Kemeny & Kurtz, 1984)
In fact, the BASIC that was used in schools throughout those years was some form or other of
the limited versions that Kemeny and Kurtz dismissed as “street BASIC”. And those forms of the
language clearly showed their origins from the mathematical and calculus worlds:
« BASIC was designed for a specific audience to replace FORTRAN. The
audience was to be calculus students, scientists, or engineers who needed to
compute complex series of calculations repeatedly. (…) What of the people
who do not understand the math and science algorithms? What of the people
who want to use the computer for nonnumeric programming?»
(Solomon, 1986, pp. 90-91)
In the quote above, Solomon was talking about the language versions commonly found and
used in microcomputers. It mattered little that BASIC was evolving steadily in Kemeny and Kurtz's
laboratories, incorporating features such as modularity and graphic commands: the language in
hand was not matched to the needs of millions of potential users (children, teachers, and parents) by
whom it was being used in homes and schools.
« Teachers are finding BASIC difficult to use with their students. (…)
One of the problems teachers have in teaching children to program is that
they emphasize learning the vocabulary and the grammar of a programming
language instead of emphasizing the process of exploring ideas. »
(Solomon, 1986, p. 92)
This account remarkably echoes Jonassen’s concerns regarding the time and effort involved in
learning a programming language, presented at the end of section 2.4.4. But Jonassen (2000, p. 156)
was referring to the Logo language, not to BASIC. The irony is that Logo, which I’ll present later in
this section, is a language that was developed and evolved with the specific aim of being used by
children, rather than non-professional (but adult) users. And yet one can find accounts regarding
Logo that bear a resemblance to Solomon’s remark above, albeit at a higher level of analysis.
« Young children and their teachers [using Logo] very soon hit a ceiling
of what is possible for them within reasonable time and expertise
constraints. (…) the set of tools and metaphors which are appropriate for
navigating around the interface level are not functional below that level – to
get below, one has to enter a new world of arcane (usually textual) difficulty
that is disconnected from most of the things which made introductory work
so engaging. One way round these problems has been the development of
microworlds. »
(Hoyles & Noss, 1999)
But this ironic situation is food for thought: as computers evolved, bringing programming to
end-users has been a recurrent effort on the part of several researchers, technicians and even
49
A programming language described in section 3.3.5, which I employed for my field activities.
50
In 1970, in the USA, 95.3% of all households had at least one television set (U.S. Bureau of the Census, 1988, p.
561).
90 Framework for Computer Programming in Preschool and Kindergarten
Computer Programming: conceptual foundations
This imperfect match of tool and purpose51 has important consequences for the use of
programming languages in education: what programming languages are nowadays is certainly but a
glimpse of what they will become, not merely technically but also conceptually, i.e., in the type of
mind-frame that programming will require or allow. One of the first educational researchers on the
use of computer programming for educational purposes, Thomas Dwyer, once said:
« (…) it seems to me that attempting to innovate with supportive systems
that don’t begin to match the sophistication of the human learner should be
viewed as a betrayal, not a consequence, of a humanistic approach to
education. »
(Dwyer, 1971, p. 100)
There is thus nowadays still the need for the educator employing computer programming to
strive to adapt, change, and indeed recreate the programming tools being used, in order to maintain
the focus of each student’s reasoning on the reasoning itself52.
The computer’s educational role in this regard is to interpret the student’s reasoning expressed
through a program, exposing to the student the relativity of one's statements, but also one’s
misconceptions or unconsidered paths that are required to achieve the intended goal. Another way
to put it is that the computer can present to the student a reflection of his/her ideas, statements, and
activities. This reflection can thus be used by the student to gain insight on his/her idea, statement
or activity. A particular feature of this computer-based reasoning process is that the computer can
iterate one’s ideas thousands or millions of times, and help the student achieve a realization or
understanding of long-term or widespread impacts of an idea
In the previous paragraph, I presented just one educational role for computers, but used two
completely different formulations. And possibly other formulations could be made. These
formulations can also be seen as distinct viewpoints on computer use. And viewpoints usually
dictate the viewer’s style of action. The consequence is that the “imperfect match of tool and
purpose” I mentioned above is impacted by different human styles of approaching and using the
tool to achieve the purpose (the tool here being the use of programming languages). These two
complex relationships, tool↔purpose and tool↔style, drive the use and misuse of computer
programming as an educational model.
51
Regarding this tool↔purpose problem, a researcher referred to it as a gap, saying that “for novices, this gap is as
wide as the Grand Canyon” (Norman, 1986, as cited by Smith et al., 2001).
52
Alan Kay stated, in 1984: “The computer field has not yet had its Galileo or Newton, Bach or Beethoven,
Shakespeare or Molière. What it needs first is a William of Occam” (p. 43). I believe that this can also be said of
educational computing, but that, fortunately, both computers and educational computing have had a nice share of their
Pythagoras and Socrates.
53
It is therefore little wonder that he followed on Piaget’s constructivist educational philosophy, presented in section
4.1.2. In his book Mindstorms, Papert states: “I left Geneva enormously inspired by Piaget’s image of the child,
particularly by his idea that children learn so much without being taught” (Papert, 1980, p. 215). But rather than being
a mere follower, he provided new insights and contributions, under the urge noticeable from the continuation of the
above quote; “But I was also enormously frustrated by how little he could tell us about how to create conditions for
more knowledge to be acquired by children through this marvelous process of ‘Piagetian learning’ ” (id., ibid.).
54
From the Ancient Greek word λόγος, meaning “word thought” (Kypros-Net, n.d.).
55
“The initial design of Logo came about through extensive discussions in 1966 between Seymour Papert, Dan Bobrow
and myself. Papert developed the overall functional specifications for the new language, and Bobrow made extensive
contributions to the design and did the first implementation. Subsequently, Richard Grant made substantial additions
and modifications to the design and implementation, assisted by Cynthia Solomon, Frank Frazier and Paul Wexelblat. I
gave Logo its name” (Feurzeig, 1984).
56
By Wallace Feurzeig (see footnote 55, on page 92).
92 Framework for Computer Programming in Preschool and Kindergarten
Computer Programming: conceptual foundations
Logo is contemporary of the use of computers in CAI (section 2.4.3) and of BASIC. Given
the limited graphical capabilities of computers in the 1960s, it was a language based on written
commands, like all other languages at the time. But its specific aim, right from the initial design
phase onwards, was to be used by children programmers. This meant that several of its key features
were planned, rather than being added as workarounds, in order to allow the programmer to focus
more on the idea of the program, and less on its written implementation (in computer-science terms,
to spend more time programming and less time coding).
« In many schools today, the phrase "computer-aided instruction" means
making the computer teach the child. One might say the computer is being
used to program the child. In my vision, the child programs the computer
and, in doing so, both acquires a sense of mastery over a piece of the most
modern and powerful technology and establishes an intimate contact with
some of the deepest ideas from science, from mathematics, and from the art
of intellectual model building. »
(Papert, 1980, p. 5)
Examples of such features are simplified syntax and semantics, well-designed error messages,
transparent definition of procedures and direct interpretation of code.
Since 1967 and throughout the 1970s, Papert was involved with children programming in
Logo, in different research-related educational environments57, in and out of school, with a few
young children, older children, and adults. Thanks to his previous interests in education and
thinking, this involvement of Papert consolidated his ideas on the educational significance of
computer programming, which first gained widespread dissemination thanks to his book
Mindstorms (1980).
In that book, Papert focused on his educational ideas, the philosophy behind the use of a
programming language such as Logo. I present his educational ideas in section 4.2.2 – “Seymour
Papert and constructionism”, but for the sake of clarity I’ll mention a few here. They include:
syntonic learning (Papert, 1980, p. 63) or learning in syntonicity with the learner, i.e. when
learning is related to the sense and knowledge of children about their own bodies (body-syntonic) or
consistent with children’s sense of themselves, their likes, dislikes, goals, and intentions (ego-
syntonic); procedural knowledge, or using programming as materials for thinking about and
talking about procedures – all kinds of procedures, not just computer procedures (Papert, 1980, p.
223); microworlds as “incubators for knowledge”, content environments limited so that their
principles can be simulated, experienced, and analyzed (Papert, 1980, ch. 5, pp. 120-134); and
debugging as a way to instill the notion that something that goes wrong is an opportunity “to study
what happened, to understand what went wrong, and, through understanding, to fix it” (Papert,
1980, p. 114).
In the late 1970s, the Logo audience started to grow, with the appearance of microcomputers:
until then, it had been confined to research sites and a few schools. Pilot projects launched in 1980
involved hundreds of children and extensive teacher training. Over the 1980s, Logo use increased
and newer versions by different producers were introduced (Logo Foundation, 2000).
During this period the Logo philosophy and programming language benefited from exposure
to large number of children and adult users, and Papert focused more on the problem of the different
styles of using the tool – the tool↔style problem.
Already in his 1980 book he had laid several thoughts regarding individual patterns and styles
of reasoning (e.g., Papert, 1980: ch. 1, “Computers and Computer Cultures”, pp. 19-37; styles for
57
Research sites were located in MIT (USA), Edinburgh (Scotland), and Tasmania (Australia) (Logo Foundation,
2000).
58
Cf. Papert’s remarks in 1980 (p. 104) regarding approaches to structured programming and his view on the subject in
1990 (Turkle & Papert, 1990, pp. 138-140).
94 Framework for Computer Programming in Preschool and Kindergarten
Computer Programming: conceptual foundations
« These [Logo programming] experiments express a critique of
traditional school mathematics (which applies no less to the so-called new
math than to the old). A description of traditional school mathematics in
terms of the concepts we have developed in this essay would reveal it to be a
caricature of mathematics in its depersonalized, purely logical, "formal"
incarnation. Although we can document progress in the rhetoric of math
teachers (teachers of the new math are taught to speak in terms of
“understanding” and “discovery”), the problem remains because of what
they are teaching. »
(Papert, 1980, p. 205)
Papert’s educational ideas discussed here came into a global form under a new educational
philosophy with the name constructionism; this was first presented in 1991 (Papert & Harel,
1991). An attempt to synthesize it (albeit lacking the important ideas referred above) is to say that
the construction of personal knowledge is particularly supported when the learner is involved in
constructing personally meaningful artifacts (Papert, 1999). Constructionism is presented in section
4.2.2, “Seymour Papert and constructionism”.
For Papert, the consequence of this line of reasoning is that the current schooling system is
inadequate and can’t be reformed, but rather changed, radically:
« One could not move from a stagecoach to a jumbo jet by making a
series of small improvements. Is it possible to go from the school of
yesterday to the school of tomorrow by a series of incremental
improvements? (...) as long as schools confine the technology to simply
improving what they are doing rather than really changing the system,
nothing very significant will happen. »
(Papert, 1998)
Constructionism is also sometimes referred to, indirectly, as “the Logo philosophy”, but part
of this logic that I have been presenting is that the Logo programming language itself is just a
technology: a step in the right direction, but not a definitive achievement. The name Logo can thus
often be found meaning Papert’s educational ideas, representing an educational philosophy, not just
a programming language. The following quotes show just this, since the first is from 1982, nine
years before publication of the book “Constructionism” (Papert & Harel, 1991), and the second,
besides being from Papert himself, is from 1999, eight years from the publication of
“Constructionism”.
« Logo is the name for a philosophy of « The Logo programming language is far
education and a continually evolving from all there is to it and in principle we
family of programming languages that could imagine using a different language,
aid in its realization. » but programming itself is a key element of
this [Logo] culture. »
(Abelson, 1982 acc. Logo Foundation,
2000) (Papert, 1999, p. xv)
Several modern alternatives to Logo were developed. They can and have been used under the
Logo philosophy, and are presented in sections 3.3.4 and 3.3.5. These include:
Stagecast Creator (formerly Cocoa, formerly KidSim), aimed at development of rule-based
animated simulations and games (a description of activities and an education-oriented
discussion is found in Lewis et al., 1997);
Squeak, an implementation of an object-oriented programming language, Smalltalk-80,
intended to be highly-portable, by including platform-independent support for color, sound,
and image processing; its community originated Squeak Etoys, “computer environments that
help people learn ideas by building and playing around with them” (Kay, n.d.);
Framework for Computer Programming in Preschool and Kindergarten 95
Universidade de Trás-os-Montes e Alto Douro
ToonTalk, aimed at providing a new metaphor for describing programs, by using animated
cartoons: there is no “static” code: the entire program is an animation (its relation to the
Logo philosophy and culture is debated in Kahn, 2001a).
A final realization is that since a crucial point is the construction of artifacts, this is something
achievable not only in programming, but also in design of artifacts: “Constructionism theory
suggests a strong connection between design and learning: it asserts activities involving making,
building, or programming – in short, designing – provide a rich context for learning” (Kafai &
Resnick, 1996, “Introduction”). Each designed artifact exists outside the learner’s mind and must
pass the scrutiny of the physical, cultural, and further constraints of reality: it becomes
something that “can be shown, discussed examined, probed, and admired. It is out there” (Papert,
1993, p. 142). These realizations provide the connection between this section, “Learning about
thinking, with computers”, and the previous, “Learning with computers”. And thus, as promised
then, a full circle between them is complete.
« The argument (…) isn’t that (…) computer programming in general, is
unique in providing an environment for learning these thinking skills. (…)
But it is a very rich environment where these kinds of thinking skills are
“exercised” frequently in a natural context. »
(Kahn, n.d.)
59
See sections 2.4.5 and 4.2.2.
60
Many other approaches could be imagined, that’s the beauty of programming: one can reason around a problem in
any desired way and try out hypotheses, to see how they work. But these approaches serve the purpose of rendering
clear the intended distinction in programming styles for the present section.
61
Conceptually. In reality, the computer will be rapidly switching from task to task; but given enough computational
power, this can appear to be simultaneous. Only computer systems with more than one execution unit can really do
more than one thing at the same time, but that's at a different level, disconnected from this abstraction.
102 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
To make clear in what situations that may happen,
I’ll consider the following case: on that billiard there were
two balls to be moved, instead of one (Figure 61).
The sequential approach runs into trouble, now,
because the two balls are supposed to be moving at the
same time. If I command them separately, the global result
won’t be simultaneous movement:
“Move the white ball in the direction of the first part
of its arrow, and when it hits the side of the table, change
the direction of movement to that of the second part of its
arrow. Move the red ball in the direction of the first part of
its arrow, and when it hits the side of the table, change the
direction of movement to that of the second part of its Figure 61 – Two billiard balls
arrow.”
This sequence of commands will only work out right if BOTH sentences are executed
simultaneously. Otherwise, if one is executed after the other, the white ball will complete its course,
and only then will the red ball start to move.
But in order to implement this using the sequential model, it's necessary to switch back and
forth between both balls, moving them a bit and checking to see if there is a collision or not. Such
code is much harder to program, complex, error-prone, and difficult to scale62.
Sequential approach Concurrent approach
1. Move white ball Red
White ball
forward a bit. ball
2. Is the white ball Ball “brain” Ball “body” Ball “skin” Same
colliding? If not, I’ll put the skin I’m just moving I’m just thing.
proceed with step 3. looking for forward until checking to see
If it is, change its touch, and the someone tells if I’m touching
direction of body moving; me to stop or something, and
movement and then I’ll just be change then I’ll let the
proceed with step 3. waiting for the direction. brain know and
3. Move the red ball skin to tell me keep on
forward a bit. of a collision. checking.
4. Is the red ball At that time, I'll
colliding? If not, tell the body to
begin it all again change
from step 1. If it is, direction.
change its direction
of movement and
begin it all again
from step 1.
Table 5 – Sequential and concurrent approached: moving two balls
As the example above shows, when the goal of programming is modeling separate “entities”,
which behave separately, it’s simpler to picture those entities separately in programming also, rather
than ensuing with this process of intercrossing their tasks.
62
One could consider the task of getting all 15 balls on the table, moving at the same time, just to have a better notion
of this complexity. In many cases, this complexity is overcome by using techniques such as iteration, in which the
problem is considered with 2 or 3 balls and code is written to cycle them performing the same procedures – doing this
requires some planning, but then it can be scaled quickly to 1,000,000 balls or more, if necessary.
63
According to Hansen (2001), this quote is from himself: Hansen, Per Brinch (1971). An Outline of a Course on
Operating System Principles, in C. A. R. Hoare and R. H. Perrot, eds., 1972, “Operating Systems Techniques”,
Proceedings of a Seminar at Queen’s University, Belfast, Northern Ireland, August-September 1971, 29-36, article 6,
Academic Press, New York, NY, USA.
104 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
Not necessarily. Usually, students are introduced to programming with the traditional,
sequential, programming. Going from their experience with it to concurrent programming involves
a change of thinking style, so it is little wonder that such change is not smooth, to say the least.
« It is possible that some students had trouble decomposing problems into
concurrent subtasks precisely because of their expertise in traditional
programming. »
(Resnick, 1990)
The above remark comes from a study on the relative
ease or difficulty of sequential vs. concurrent programming,
done by Mitchel Resnick (Figure 62), while developing a
version of the Logo programming language for children,
called MultiLogo.
In that paper, Resnick starts to address this theme by
noting previous research reports on novice programmers, who
while using traditional sequential languages, often assume
parallelism (another way of referring to concurrency) where
none exists. The natural question is thus whether such novices
wouldn’t have found concurrent programming more natural
and intuitive to learn.
However, in his research for that paper, Resnick worked
with children (4th and 5th graders) that had already one full
year of (sequential) Logo programming experience, so some
of his conjectures would need further research support, by
conducting activities on concurrent programming with Figure 62 – Mitchel Resnick
children that haven’t learned sequential programming From: http://alumweb.mit.edu/opendoor/20030
9/images/resnick.jpg
beforehand64.
One particular case, however, was close to the desired
research situation of no previous contact with sequential
programming, and constitutes a promising indicator:
« I asked NL and FB65 to explain how they would coordinate a “real-life”
situation in which two people execute tasks simultaneously, and (at least
initially) they both stuck with their time-slicing approaches. (…) NL’s and
FB’s initial “solutions” to the real-life problems are an indication of just
how strong their sequential-thinking models are.
(…)
BW, who worked together with FB during FB's final session, (…) thought
a good student, had limited Logo programming skills and had never seen
MultiLogo. Nevertheless (or perhaps as a result), her instincts on agency
decomposition were quite good. (…) It is possible that BW’s lack of Logo
skills made it easier for her to embrace the new paradigm. BW would have
had great difficulty writing the program to implement her idea, but she
grasped the overall concept of concurrent programming very quickly. »
(Resnick, 1990)
64
This would be tricky to do in a language such as Logo, which is sequential at heart.
65
NL, FB and BW are initials of three children Mitchel Resnick worked with.
66
Soloway, E., J. Bonar, J. Greenspan, K. Ehrlich (1982). What Do Novices Know About Programming?, in “Directions
in Human-Computer Interactions”, edited by Ben Shneiderman and Albert Badre, ISBN 0893911445, Ablex Publishing
Company, Norwoord, NJ, USA.
67
Pea, Roy D. (1986). Language-independent conceptual ‘bugs’ in novice programming, in Journal of Educational
Computer Research, vol. 2 (1), pp. 25-36, ISSN 0735-6331, Baywood Publishing Company, Inc., Farmingdale, NY,
USA.
106 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
logic of programming languages increasing expressiveness and abstraction from the particularities
of the underlying hardware, concurrency in programming should be above all a method of
reasoning over a problem, and having to depart from that level to the hardware level would be a
step back in time and evolution.
An answer to this concern came from Edsger Dijkstra (Figure 63), who wrote:
« In the literature one sometimes finds a sharp distinction between
“concurrent programming” – more than one central processor operating on
the same job – and “multi-programming” – a single processor dividing its
time between different jobs. I have always felt this distinction was rather
artificial and therefore confusing. In both cases we have, macroscopically
speaking, a number of sequential processes that have to co-operate with
each other, and our discussions on this co-operation apply equally well to
“concurrent programming” as to “multi-programming” or any mixture of
the two. What in concurrent programming is spread out in space (e.q.
equipment) is in multi-programming spread out in time: the two present
themselves as different implementations of the same logical structure (…) »
(Dijkstra, 1965, “Concluding remarks”)
Thus, the point is that it doesn’t matter how many processors
are available in the computer running the program. If there are
enough to conduct separate operations, they can be used
concurrently. But if there aren’t enough processors, the ones
available – even if it is a single one – can simply move back and
forth between tasks, executing a little bit of each at a time, thus
providing an illusion of concurrency.
In that same paper, Dijkstra presented a full basis for what
became the most common style of concurrent programming, used by
millions of programmers worldwide. Most of the concepts employed
in concurrent programming were first presented in that paper.
The most important of those concepts is the notion of each
separately-executing task as an entity in itself. Dijkstra called such
Figure 63 – Edsger Wybe
tasks a process, but other names that are commonly used for this Dijkstra,
notion, under different programming paradigms are task68, thread69, 1930 – 2002
agent70, and actor71. For convenience, I will use the term “process” From: http://www.cs.utexas.edu/users
/EWD/EWDwww.jpg
throughout this section.
This notion of a program as a collection of separate processes has a direct consequence: if
they are separate, but something is to be achieved together, they must cooperate. This, in turn
implies that they need to communicate, but such communications are also independent (i.e.,
asynchronous): one of Dijkstra’s most important realizations in this regard is that since processes
are independent, conceptually each process is working alone within a single, private, virtual
computer. And so, since one virtual computer and its process compose an autonomous entity, there
is no way to assume relative speeds for execution of processes. This concept is known as speed
independence.
« (…) apart form the (rare) moments of explicit intercommunication, the
individual processes themselves are to be regarded as completely
68
E.g., in the Ada language (Burns & Davies, 1993, p. 160).
69
E.g., in the Java language (Brookshear, 2003, p. 252). Threads are often considered a special case: different lines of
execution inside a process, but such distinctions aren’t relevant for this discussion.
70
Agent-oriented programming (Shoham, 1993).
71
Actor-oriented programming (Hewitt, 1976; Agha & Hewitt, 1986).
72
A concept known as fair scheduling; this won’t be addressed in this thesis for lack of relevance as a computer-science
concept for preschool.
73
This method of synchronization is technically known as a “barrier” (Tanenbaum, 2001, pp. 123-124).
108 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
This way of synchronization renders clearer the metaphor I employed earlier in this section,
about concurrent programming being more like conducting an orchestra. Another way to put it is
like managing people or refereeing a football74 match.
One should be aware, however, that in concurrent programming there is no need for a process
(or even the programmer) to act as an actual “conductor”, “manager” or “referee”. Rather, each
process can have its own, specific rules, and act in absolute independence. Metaphors for such
programs are ants harvesting food, water molecules forming clouds, bacteria reproducing, cars
moving in roads. To understand how such a program may generate a meaningful behavior, one must
keep in mind that these metaphors are themselves examples of self-organizing behaviors from rules
applied to independent particles/actors/processes. An entire scientific field is devoted to the analysis
of such kinds of self-organization, known as the analysis of cellular automata75.
Using communication, a concurrent program for the ball could resemble this:
Billiard ball
Ball “brain” Ball “body” Ball “skin”
1. "Hey, body, here’s a nudge-length
move ticket! Do it and let me know.”
No need to bother
2. Now I’ll wait for the move to
I’m waiting for a checking for
complete.
ticket, so that I collision unless the
3. “Hey, skin, can it let me know if
can move forward brain asks me to. (I
we're colliding?”
a bit. just hope nothing
4. If the skin says we’re colliding, I’ll
collides against us!)
change the direction before resuming
movement, from step 1.
Table 6 – Concurrent programming: moving balls with communication
Taking a hint from constructionist theory, I have included two contradicting elements in the
above example, to provide for further discussion now:
in the ball’s “brain” process, I’ve included sequence numbers, to emphasize its
internal sequential structure;
in the ball’s “skin” process, I’ve included another anthropomorphism – a worry – to
shed some doubt on the correctness of this particular programming model for a ball.
The sequential aspect of the brain process could easily have been included in the remaining
processes as well. It was included here to make the point that concurrent programming doesn’t
imply, necessarily, the total absence of sequential reasoning: after all, one frequently engages in
sequential reasoning. Rather, concurrent programming provides mechanisms to knowingly specify
concurrent behavior.
74
Soccer (not that the distinction matters, in this thesis).
75
The most well-known case is John Conway’s “Game of Life” (Callahan, 2000, presents a description, background
information and a playable applet), but this concept first emerged in 1949, in John von Neumann’s paper “Theory and
Organization of Complicated Automata” (in Burks, Arthur W., 1966, Theory of Self-Reproducing Automata, pp. 29-87,
University of Illinois Press, Urbana, IL, USA). A large recent (2002) volume in this field is Stephen Wolfram’s “A New
Kind of Science”, ISBN 1-57955-008-8, Wolfram Media, Champaign, IL, USA.
Request
Request
Request
Request
Reply
Reply
Reply
Reply
I need to
Event know this…
Do
this.
Request
Do
this.
Request
Request
I need
I needto to
know
know this…
this…
Do
this. Event
78
E.g. by specifying precedence, priority, and mutual exclusion (Hansen, 2001, p. 22) or coincidence (using the
methods referred in footnote 86, at the bottom of page 113).
79
This example was inspired by an actual event at London’s Institute of Education in 2002, when Yishay Mor, Gordon
Simpson and I were trying to create a simple high-school physics example using ToonTalk.
112 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
After those 6 time slots have elapsed, it’s fair to say
that the assignment of computer power was fair: the
processes in charge of each ball manage to run four times
each. However, due to speed independence, this situation
causes a strange behavior to occur (Figure 67).
It looks as if the white ball had crashed into the red!
The reason is that the velocity for the red ball (the red
arrow in the figure) was wrongly calculated. What
happened was this: during time-slots 1-3, the white ball did
everything it need to, including the update of its velocity.
So, when the red ball finally got a chance to get the white
ball’s velocity, in step 4, it was no longer the original
velocity, heading towards the red ball, but the new one, Figure 67 – Wrong result of collision
moving away from it!
So, in time-slot 4, from the perspective of the red ball, it didn’t collide head-on with the white
ball: it crashed on it from behind, going at a slightly higher speed. The result is thus two balls
moving in the same direction at identical speeds80.
A similar problem can occur if the red ball does everything before the white ball. In fact, the
collision will ONLY turn out fine if both balls read each other’s velocity before changing their own.
The problem exists because independent processes (the balls) must share states (in this case,
their velocities and the event of colliding). Getting information on a shared state and acting based
on it is a source of synchronization problems. In order to solve this and related problems,
concurrent systems offer synchronization methods, usually of the sorts presented in the list that
follows this paragraph. As can be seen from that list, the methods for solving the problem of
synchronization include methods used for solving the other mentioned problem: communication:
Lock-out methods: the access and manipulation of information about the shared state is
attributed to a single process, and others have to wait until the shared state becomes
free (typical examples from computer science are called semaphores81, condition
variables82 and monitors83).
Message-passing methods: rather than accessing a shared state, processes pass copies
of information among them, and are free to do whatever they desire with their copy of
the information84.
Remote invocation of methods: rather than accessing a shared state, processes provide
copies of information and request other processes to act on their behalf85.
Parallelize execution: if necessary, different parts of concurrent processes can be
forced to start coincidentally in time, and not to advance beyond a certain point until
all involved parts are complete86.
In section 3.4, I present a more complete description of several of these methods87, including
ToonTalk examples of their implementation and brief suggestions for educational use.
80
In some cases (such as ToonTalk programming), the behavior can be even stranger, because the balls can overlap a
bit by the time the collision is detected. If this overlap isn't undone, a new collision may be detected immediately after
the first, resulting in a reversal of movement!
81
(Dijkstra, 1965)
82
Id.
83
A method invented by Per Brinch Hansen in 1973, but its complete description (with several developments) was first
presented by Tony Hoare (1974).
84
A method introduced by Hansen (1969) and later expanded by Hoare (1978).
85
This technique is known as “remote procedure calls”, and was first introduced by Hansen (1978)
86
In computer-science terms, such techniques include parallel statements (Dijkstra, 1975), barriers (Tanenbaum, 2001,
pp. 123-124) and synchrons (Turbak, 1996).
3.2.2. What You Want vs. What To Do: constraint programming vs.
procedural programming
Regarding this second part of the major topic “Computer programming styles”, I found the
opening quote of the previous section to be particularly fortunate by having employed the word
“constraint.” I’ll present it here again, to spare the reader the trouble of browsing back to page 101.
« Programming languages not only furnish us with a means of
expression, but they also constrain our thinking in certain ways, by imposing
on us a particular model of computation. »
(Burns & Davies, 1993, p. 1)
In that section (3.2.1), I presented one way in which this could occur, by contrasting
sequential programming against concurrent programming. In this section, I present another
distinction, by contrasting programming with constraints, around intended goals, against
programming with orders, focusing on specific goals. The term “procedural”, used in the title of
this section, thus represents its semantic sense; it is not a synonym for “functional programming”
(presented in section 2.2.6) as it is sometimes used.
For a programming language, being sequential or concurrent, as presented in the last section,
and being procedural or constraint-oriented, as is being presented in this section, aren’t necessarily
advantages or hindrances: it all depends on the purpose for which the language is intended, on the
context of its use – and also on the thinking style of the user (programmer). Programming with
constraints provides the ability to express one's reasoning in a way that is quite different from
traditional programming, and that, in itself, is a powerful thing.
« A significant motivation for programming language research is to find
clean abstractions and conceptual frameworks that enable us to understand
and reason about complex computational phenomena in a simple way. »
(Saraswat, 1993, p. xxxiii)
The metaphor I elected to use for this section
is the common task of moving furniture or other
objects through a doorway (Figure 68).
Expressing such a task in terms of traditional
programming models implies that the programming
process is focused on how the task is performed –
what to do. Specifically, one would seek to
determine the starting position of the object, its size
and format, the distance to the doorway, the size of Figure 68 – Moving furniture involves goals and
the doorway, etc. Then one would act upon those constraints
data, to achieve the goal of transposing the door.
Here’s a typical approach to the resolution of the problem:
assemble data on object and door dimensions and positions;
determine need for re-orientation;
perform necessary re-orientation;
go through the doorway;
determine need for re-orientation before setting down the object;
set it down.
87
Sections 3.4.10 – “Parallel/Concurrent execution”, 3.4.11 – “Parallel/Concurrent statements”, 3.4.12 – “Message
passing / Communication channels”, and 3.4.18 – “Clients and servers”.
114 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
These operations, of course, imply smaller problems, such as how to turn it around, how to
pick it up, drop it, etc. The overall goal of taking the object through the door is kept in mind, but it
isn’t the focus of the programming task.
Rather, in constraint programming, one focus on which and what limitations define the task
– that what is wanted. The programming process is focused on specifying the details of the problem,
as finely as possible, and by that process to define how it should be solved. Here’s a constraint
approach to the resolution of the problem by defining it more precisely:
the object’s starting position is88 on the outside; The object must
the object’s ending position is on the inside; move.
the object’s path must be through the doorway; The object must fit
the object must not be disassembled; the doorway.
the object area facing the doorway must be smaller
than the area of the doorway.
the width of the object are must be less than the The object may
width of the doorway; have to be rotated.
the height of the object must be less than the
height of the doorway;
the object must be laid down on its base; The object may
the base must be leveled with the floor; have to be rotated.
the object must not be dropped;
…
the place where to set down must be clear.
I propose that the reader compares his/her own thinking styles while reading the previous two
sequences. As one’s reasoning progresses along the sequences, the mindframe towards the overall
problem (carrying the object inside) is likely to be quite different. Things that are explicit in one
model become implicit in another; things that are the major concern in a model become less
relevant in another. The reason I am not rendering concrete these differences is because they’re
most likely to differ from person to person; but I expect some sort of contrast to be deep enough to
be clearly felt by most people.
One of the most important distinctions between these two models is the handling of data. In
procedural programming (the former sequence) data is collected, stored and processed, flowing
through the program, which is composed of operations to be performed on the stored data. By
contrast, in constraint programming (the latter sequence) the program flow involves a continuous
refinement of constraints, eventually leading to a conclusion: the data to which the constraints apply
is almost ignored in the sentences. In them, data seems almost “internal” to each constraint.
One can imagine these sentences being written and read, gaining a better conception of the
overall problem, without actually getting hold of actual data values; in other words, as if it were not
necessary to have the actual data values for the program execution to proceed.
This last remark derives from the fact that constraint languages are logic programming
languages (Shapiro, 1989), which are geared towards processing and combining information in
logic relationships, rather than towards processing data values (processing data becomes a simple
implementation of the logic structure attained through those languages). The class of constraint
languages is thus more fully addressed as constraint logic programming languages89.
88
On this and the following line, my usage of the verb “is” means to impose a constraint on the mentioned positions; it
is not a mere declaration.
89
There have also been attempts to introduce constraints in traditional programming, under the general name of
Constraint Imperative Programming: a summary of this was included in the PhD thesis of Michael Travers (1996, pp.
52-53).
90
Another option would be to define NewTablePosition as a function, stating that when invocated, it would return the
sum of those same two values or functions. This, however, doesn’t change the overall issues mentioned in the text,
because the data values those functions deal with would still have to be calculated and manipulated.
91
If, as stated in footnote no. 90, NewTablePosition is a function, the same things happens: it is evaluated and the result
must be an actual value, such as “Yes” or “No”.
92
This process is known as instantiation of the logical variables.
93
ToonTalk, the programming language used in the field work supporting this thesis – and described in section 3.3.5 –
is one such language, albeit restricted in the kinds of constraints it supports.
116 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
The reader unacquainted with logic programming may question how computation can
advance, beyond a question such as the one presented, since it's highly likely that the next actions
depend on the answer. But often the logic reasoning of the program can be divided into two separate
lines of “reasoning”, so to speak, to analyze separately the consequences of a “yes” or a “no”; and
thus, the calculation can proceed, as long as the actions do not cause external consequences
(showing unintended images on the screen, erasing important files, setting off a nuclear bomb, etc.)
– and even in those cases, there is often the possibility of following through with the logic
reasoning, postponing actual actions that may result from such a reasoning.
Obviously, there are limitations to this line of action: in programs that are not supposed to
end, but rather to maintain a relationship with an external source (e.g., a human user), the number of
possible branches may be infinite94. And even on some programs with an expected termination, the
same may happen when performing a logical analysis instead of a numerical analysis, as illustrated
by the following citation95.
« A more conventional illustration is provided by the treatment of
arithmetic in logic programming languages, such as Prolog. (…) no one can
deny the necessity for operations to add and to multiply two variables, whose
value will be known only at runtime. This would mandate that the constraint-
solver also be able to solve systems of basic constraints of the form X+Y=Z
and X×Y=Z. This problem, however, is enormously complicated – and if the
variables X, Y and Z range over the integers, then it is undecidable, as a
result of the unsolvability of Hilbert’s Tenth Problem!96 »
(Saraswat, 1993, p. 26)
Summing it for the reader, this is the general point: the logic evaluation of a program cannot
compute in advance all possible resolutions paths to a problem (something hardly surprising, since
that would render it completely deterministic). But its combination with a view of programming as
a refinement of constraints allows for a much simplified and powerful specification of concurrent
behavior.
To conclude, I’d like to briefly present a little more technical background and consequences
of these ideas from constraint logic programming and concurrent logic programming, as combined
by Saraswat into the framework of concurrent constraint programming, already mentioned above.
When dealing with decision problems such as the one presented before, constraints help the
process of logical deduction, by allowing the program to focus on constraints themselves, not on the
actual data or its eventual values.
94
Such programs, as presented in the previous section, are dubbed “reactive” programs, while programs that are
conceived to end, eventually, after completing some processing, are dubbed “transformational.”
95
In logic programming without constraints, this situation can also occur in situations where the number of alternatives
is finite: the number of logic variants may be so huge as to render unviable the scrutiny of all possible answers to each
decision – a problem known as “combinatorial explosion”. This problem is tackled by control methods present in those
languages – which also pose limits on concurrency.
96
For a presentation of Hilbert’s problems aimed at laypeople, including his tenth problem, I recommend the article by
Portuguese physicist and mathematician Jorge Buescu (2003, pp. 73-86). English-language sources suggested by Jorge
Buescu in that article include the book The Hilbert Challenge, by J. Gray & D. Rowe (Oxford University Press, Oxford,
UK, 2000), and the Web page by David Joyce from Clark University, at
http://aleph0.clarku.edu/~djoyce/hilbert/toc.html.
97
I.e., the memory.
118 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
98
“A data-parallel extension of Common LISP for the Connection Machine” (Kinnersley, 1991, citing “The Essential
*LISP Manual”, TM Corp 1986).
99
An extensible language designed to develop compilers for the Ape100 parallel computers (Cabasino et al., 2001).
100
The textual language Python even acknowledges this in its syntax, by using indentation to specify grouping of
instructions, rather than using traditional pairs such as “begin end” (used in Pascal) or “{}” (used in C, C++, C# and
Java).
Start (…)
Increase the
count
YES
NO Is
test=TRUE ?
Assign to “test”
Is YES
the value of
count<limit?
GetNewItem()
NO
End (…)
103
In a more recent paper, they follow up on this line of reasoning, by stating “We propose that VPL research be partly
directed by methodical study of skilled users who are experts in the use of existing VPLs”, VPL meaning “visual
programming languages” (Whitley & Blackwell, 2001, p. 436).
104
The group of LabVIEW programmers in this study by Whitley & Blackwell had different levels of expertise
regarding textual programming languages, but the vast majority had a large experience: over 160 of those programmers
reported experience in programming categories “Medium projects”, “Big projects”, “Several years”, and “10 years+”,
for “General programming” (not “LabVIEW programming”), while only about 55 programmers indicated the categories
“Played around”, “Training course”, and “Small programs” (Whitley & Blackwell, 2001, p. 453).
105
“(…) it is more accurate to use the term Visual Programming for systems that allow the program to be created using
graphics, and Program Visualization for systems that use graphics only for illustrating programs after they have been
created” (Myers, 1989, p. 5).
106
“(…) products such as Visual Basic are not graphical languages because such products require that program logic
be typed in as text” (Whitley & Blackwell, 1997).
107
Indentation as used in Python (footnote 100) can be seen as a sequence of space or tabulation symbols, inserted in
the sequence of the text. Therefore, it doesn’t alter the one-dimensional nature of the programs.
122 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
This might at first sight invalidate usage of such kind of diagrams as flowcharts in pre-literate
settings. However, the mere presence of the text is not an absolute limitation, since flowcharts can
be used resorting to pictorial information rather than textual one. Figure 72, on p. 122, presents a
pictorial version of the previous flowchart, constructed by simply employing clipart pictures. One
can easily imagine such a flowchart being constructed in physical fashion (paper, crayons ...) in a
preschool activity room, with the children themselves taking part in the drawing of the pictures and
their gluing to the flowchart symbols.
A flowchart like this can be used in preschool settings as an activity in the mathematic logical
domain. The starting point is represented by an athlete preparing to race, the finishing point is
represented by a checkered flag, the positive and negative results are represented by color-coded
smileys, and the remaining activities and decisions are represented by actual pictures depicting
actions and events.
An activity could take place with the physical version of this flowchart, along with an actual
bucket for fish, toy fish, toy fishing rods, and toy pond.
“Start!”
“Are there 4 fishes in the bucket?”
“No? Set the bait and lay the rod!”
“Did any fish bite?”
“One did? Put it in the bucket!”
“Check to see if there are 4 fish in the bucket.”
… (Eventually, there will be 4 fish in the bucket, and the flow ends at the checkered
flag.)
This example is a way of turning a visual language based on text into a fully visual language.
I’m not presenting it as a proof of concept, but simply as a way to expose two problems and
limitations that occur in such a process: the pictures used are either metaphorical/hieroglyphic (i.e.
standing for a meaning or word, rather than for what they actually depict) or artistic (or
photographic) depictions of an actual activity or condition.
Metaphoric or hieroglyphic pictures, which in computer programs are usually called icons108,
should take in consideration the main concepts around the notion of metaphor, which will be
addressed in the next section (3.3.3, “Visual programming for children: concrete vs. abstract”, but
in a short note for the convenience of the reader I’d like to point out here that the interpretation of
metaphors and hieroglyphs is a convention, based on cultural norms and personal experience – and
can easily become as complex to read and use as a textual language (or even more complex).
However, the depictions of an activity or condition, while aiming to be as truthful as possible
to their intended meanings, can suffer from the same problem. For instance: the picture meaning to
represent a fisherman placing its catch in the bucket can be interpreted as taking a fish out of the
bucket instead109; or as scaling the fish just-captured; or even as eating it! But the major
technological consequence of basing a language on such depictions is that they cannot be
standardized, due to their open-ended nature: the number of depictable activities is virtually endless.
This renders unviable their interpretation by a computer.
108
The visual language Cantata calls them “glyphs” (Mosconi & Porta, 2000, p. 78).
109
The logic behind this can be, for instance, “I took one fish out, so I’ll return one fish to the pool.”
110
It is interesting to note that these advantages are at the technical level of implementation, while the mentioned
disadvantages are at the human level of usability.
111
For example, Ephraim Glinert’s languages PICT, presented in 1985, and Blox, presented in 1986 (Nickerson, 1994,
section 2.6.1). The earliest example, involving graphical specification of procedures, is from 1966 (Sutherland, 1966).
112
In a survey of Visual Programming Languages, Brad Myers analyses no less than 37 different visual languages
(Myers, 1989).
124 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
professional settings. This is partly due to dataflow programming being intrinsically related to a
graphic notation, since dataflow programs, being based on dataflow graphs113 can easily be
expressed graphically (vd. section 2.2.6), partly due to the advantage of having a graphical-inclined
notation that includes representations both of operations on data, and of the data itself.
In dataflow visual languages such as LabVIEW (Figure 74), data enters graphical items114,
representing program modules or procedures, where it is transformed; it then exits those items, in
this way flowing across the program.
Figure 74 – LabVIEW programming examples: generating an array of random integers and using dataflow to
determine execution order
From (respectively):
http://zone.ni.com/devzone/conceptd.nsf/2d17d611efb58b22862567a9006ffe76/60e39a753406ee7986256e5c000030c6/Overview/0.8
0A2?OpenElement&FieldElemFormat=gif
and
http://zone.ni.com/devzone/conceptd.nsf/2d17d611efb58b22862567a9006ffe76/f34045d2cc5357f486256d3400648c0f/Content2/5.112
6?OpenElement&FieldElemFormat=gif
113
“The ‘machine’ language of programs designed to be run on dataflow hardware architectures is the dataflow graph.
Most textual dataflow languages were translated into these graphs in order to be scheduled on the dataflow machine”
(Johnston et al., 2004, p. 17).
114
In LabVIEW, which was designed for creation of software interfaces for hardware devices (mainly in the field of
real-time data acquisition) these items are called “virtual instruments”.
115
Since data is entirely transmitted from a procedure to the next, any procedure can start to be executed “as soon as its
operands become available” (Johnston et al., 2004, p. 3), without the need to wait for its turn in a specific execution
sequence. This situation is similar to what happens in concurrent constraint programming languages: agents wait until
there is enough information to proceed, and then apply their actions concurrently to the constraints (vd. section 3.2.2).
116
“(…) traditional dataflow systems have program graphs with a topology that is fixed at compile-time. Even in so-
called dynamic graph systems, “dynamic” refers to the dynamic creation of a subgraph instance (for example, a new
loop iteration or procedure call). The subgraph structure is still fixed” (Grimshaw, 1993, p. 7).
117
Unfortunately, animation frames like these are a poor substitute for the actual motion. This and other videos of
Pictorial Janus programs can be found at the Web site (retrieved on October 15th, 2004)
http://www.cs.concordia.ca/~haarslev/pjmovies/.
126 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
The process is
repeated for the
remaining two
items...
Figure 75 – Pictorial Janus, execution example: appending the lists “a b c” and “d e f” to produce “a b c d e f”
From: http://kogs-www.informatik.uni-hamburg.de/~haarslev/pjmovies/append.qt (animated movie)
In spite of all advances and improvements in visual languages, from flowcharts to visual
programs with animation of their execution, one problem is common to all the languages referenced
here (which are a fair representation of the genre). And that problem is that the usage and
interpretation of these languages, irrespective of the reader’s stance on their advantages and
disadvantages, remain highly complex for the average (non-technical) computer user.
« [In most visual programming systems] (…) formal diagrams are used to
encode programs and many people find formal diagrams difficult to
understand and construct. Venn diagrams, for example, are much simpler
than visual programs and while most readers of a [technical computer]
journal (…) find them very easy, one forgets how hard it is for most children
to learn them. »
(Kahn, 1996b, p. 7)
Due to this conceptual complexity, it’s necessary to analyze programming languages in a
different manner, not just in visual vs. textual, as was performed in this section. In order to be easily
learned and used by children, languages must overcome this formal complexity at the level of their
usage. This is the subject of the next section, 3.3.3.
118
This has been questioned in recent years, and an example was already mentioned in this thesis, in section 2.4.5 (p.
80), when I presented the ideas of Sherry Turkle and Seymour Papert. They urged for a reevaluation of the concrete
mode of thinking (which they called “bricolage”), and pointed out examples of its use by adults in non-trivial situations
(Turkle & Papert, 1990).
128 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
become capable of using “real” tools (abstract tools)119. While the usage of toys and toying with
non-toys are common activities for children, they are far from being all that children do. A widely-
known situation that serves as a counter-example of that realization is that children are able to learn
how to play a “real” musical instrument while they are very young (2 or 3 years old), seemingly still
in the realm of concrete thinking, e.g. by using the Suzuki violin teaching method (Komlos,
1998)120. One may argue that a musical instrument is a real, physical object, and therefore concrete.
But by playing it, a child produces music – which is not physical: the sounds have a physical
impact, but its appreciation is at the cognitive and cultural level. This, too, could be dismissed by
saying that such a child is merely reproducing – aping – sounds that he/she heard, and therefore
acting on the concrete. This view of a child playing an instrument without a cognitive appreciation
of the music being played is for me hard to accept: it seems just one step short of branding the child
as unable to have emotions regarding the music being heard or played. But I am not presenting this
example as a proof or demonstration of my viewpoints. Rather, it is used to clarify to the reader my
point of apparent existence of inconsistencies on the view of strict separation between the concrete
and the abstract, which I expressed at the beginning of this paragraph as a “realization conflicting
with real-world experience”.
Indeed, both research and more recent cognitive theories provide support for a different view
on concrete thinking and its relationship with abstract thinking. It comes from three main areas: the
constructivist views on the processes of learning, the ecological systems theory dating from 1979,
by Urie Bronfenbrenner121 (both are presented in section 4.1.2), and particularly the work on
concrete mathematics done by Uriel Wilensky (1991 & 1993).
Under the ecological systems theory, the child is influenced by the entire environment where
he/she is embedded. “Environment”, here, means not just the physical and the social environment in
the child’s immediacy, but also events occurring in settings in which the person is not even present,
such as the ties between school and home, or the conditions of parental employment.
And the environment’s main influence upon a child is his/her interpretation of that
environment, rather than any “real” features of it. As a consequence, any attempt to understand a
child’s actions is superficial, if it is solely based on objective features of the environment: to
understand the child’s actions, there is the need to question the meaning of those features for the
child. This includes the impact of “real” objects and events on the child’s motivation, and also the
impact of “unreal” elements, such as those created by the child using his/her imagination, fantasies,
and conceptions (Spodek & Saracho, 1993, p. 78).
This theory implies that the notion of “concrete” goes beyond concepts such as being physical
or touchable: the child’s feelings and sensations towards the world, as well as interpretations of
events, imagined situations, etc., are very much “real” (concrete) for the child.
However, this ecological view is ignoring the cognitive processes at work in the child. The
discussion on the abstract and the concrete thus needs to connect it to the constructivist view of
cognition, particularly to the constructivist notions of accommodation and equilibration explained in
section 4.1.
Simply put, these notions explained by Piaget (1975) mean that when people experience novel
situations, they sometimes contradict one’s previous notions and understandings, rendering them
insufficient. This in turn unbalances one’s conceptions, and the way to balance them, reaching
cognitive equilibrium, is to accommodate the novel experience, by changing one’s own self,
constructing new notions.
119
Or use real tools in “toy” fashion.
120
A more radical point of view is that children learn about world and society in the real world and in the real society,
not in toy versions.
121
Now renamed as “bioecological system theory”.
122
Wilensky is referring to Willard Van Orman Quine’s 1960 work, “Word and Object” (MIT Press, Cambridge, MA,
USA).
130 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
One doesn’t have to picture an entity as different as an alien of a virus to realize how much
culture and world-views can impact the experience of concreteness. The following quote from a
literary work by William Camus123 provides a clear example of this.
« It wasn’t hard to recognize the chief's tepee, entirely white, plainly
adorned with grey feathers. I rasped the door three times and entered.
We, the Sioux, considered that the palefaces carried with them a smell of
dead people; on their part, the white men stated that the Sioux smelled like a
blend of badger and rancid fat. I thought that this was due to the fact of
white men and redskins not having similar senses of smell. However, having
lived for so long amongst the whites, the first thing to impress me upon
reaching the Wichita was the odor that filled the air, entering the nostrils
and impregnating my entire body. Above all, you mustn’t think that it
smelled bad; the white man, not being able to distinguish the various odors,
smells everything at once and claims it to be uncomfortable. But a Sioux
olfaction can separate each effluvium. That characteristic smell was
composed of bison fat, horse manure, charred wood, animal sweat, old
leather and remains of animals, bones, furs, innards, rotting under the sun.
Each of these aromas wasn’t unpleasant by itself, but together, they were
surprising for the nose of a paleface. »
(Camus, 1968, ch. 3, p. 92; originally written in French, translated into
English from the Portuguese translation)
Previously in this section, from the ecological systems theory, I stated that non-physical ideas
can indeed be concrete (or, under Wilensky’s continuum view, more concrete than abstract), since
their impact on the reasoning of the child depends on the child’s own interpretation of the physical
and non-physical environment. Wilensky proposes a similar view, by following from the notion of
relative personal views on the concrete. He defines concreteness not as “a property of an object but
rather a property of a person's relationship to an object” (Wilensky, 1991). And from this, arrives
to the notion of concreteness as being a property of both physical and non-physical concepts.
« It is because children share a common set of sensing apparatus (…)
and a common set of experiences such as touching, grasping, banging,
ingesting (…), that children come as close as they do to "concretizing" the
same objects in the world.
(…)
The more connections we make between an object and other objects, the
more concrete it becomes for us. The richer the set of representations of the
object, the more ways we have of interacting with it, the more concrete it is
for us. Concreteness, then, is that property which measures the degree of our
relatedness to the object, (the richness of our representations, interactions,
connections with the object), how close we are to it, or (…) the quality of
our relationship with the object. »
(id.)
But a most important realization by Wilensky is that this means that any concept can be
concrete or abstract to someone.
123
“William Camus was born in the Yukon territory, his mother French and his father Iroquois. He was raised ‘the
Indian way’ in Canada, where his father was a fur trader. He was a stock-car pilot in the USA (…), and later a
journalist and a defender of the Indian cause.” Translated from the French version (CIELJ, n.d.).
124
Piaget’s stages are presented in section 4.1.2, p. 258.
132 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
from scratch or adapting someone else’s metaphor125. Another way of putting it is that the links
between concepts are, themselves, the metaphor.
This may at first be seen as confusing if one only considers metaphors in their classical sense.
Traditionally, a metaphor was considered to be a mere stylistic technique in language, the usage of a
word outside its conventional meaning. For instance, the often-heard “the processor is the brain of
the computer” is a classical metaphor: since one considers brains to exist only within living
organisms, the usage of the word in that sentence intends to convey the idea that the processor
controls the computer like the brain controls the body.
But the modern view, known as contemporary theory of metaphor (Lakoff, 1992), sees
metaphor as a much more profound connection between elements than a mere elegant comparison.
Metaphor becomes a world-view, a mapping between different domains, to the point of sometimes
the person using it not even realizing that a metaphor is being used. In this sense, most human
thought is metaphorical.
« Metaphor is viewed more as a basic tool of cognition rather than a
special turn of language, and most concepts are generated by metaphors.
The exceptions are those concepts that are thought to be perceptual or
cognitive primitives, such as up or cat. Aside from these references to
concrete physical objects and experiences, metaphorical understanding is
the rule. »
(Travers, 1996, p. 31)
This is also the meaning I am using for the concept “metaphor”: a mapping between two
concepts, allowing one to be understood in terms of similarities with another. In this sense of
metaphor, simple sentences such as the above “the processor is the brain of the computer” are mere
results of the larger metaphor. This larger metaphor is known as a metaphoric model (Lakoff &
Johnson, 1980), or simply “metaphor”, and the isolated ideas that it creates, such as that sentence,
are considered to be mere metaphorical expressions (Lakoff, 1992).
Several examples of this perspective of metaphor as a world-view, or even a world-shaper, are
given by linguist George Lakoff and philosopher Mark Johnson, e.g. their example of the
metaphoric model “time is money”:
« TIME IS MONEY
You're wasting my time. This gadget will save you hours. I don't have the
time to give you. How do you spend your time these days? That flat tire cost
me an hour. (…) Put aside some time for ping pong. Is that worth your
while? (…) He's living on borrowed time. (…) Thank you for your time. »
(Lakoff & Johnson, 1980)
But there is another side to this view: metaphors acting in this manner can also be thought of
explicitly, looking for new ways to understand the connected concepts. By doing this, a person is in
fact acquiring new perspectives on both subjects126, and even though all such comparisons are
limited in correctness, they provide further grasping points for the thinker. And as I’ve explained
above, this can help the thinker render those concepts less abstract and more concrete.
125
A notion that helps to explain the absence of meaningful results in experiments comparing programming systems
usability in the presence and absence of metaphors (Blackwell & Green, 1999).
126
Tony Veale calls this ability the “creativity of metaphor” (Veale, 1995, pp. 9-11). An example of such use is
provided on the next page, for the field of computer science. Other, similar efforts have been done in many areas,
including education and educational practices (e.g., Vasconcelos, 1990).
127
Is in fact an acronym (WIMP) for “Windows, Icons, Menus, Pointing devices” or “Windows, Icons, Mouse, Pull-
down menus”. The pun is around the lines that “real users use a command-line, all other are wimps”.
134 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
In the same vein, metaphors are central to computing. As common examples, one can see the
computer activity as a spatial movement (from Travers, 1996: “the process is blocked”; “the
machine went into a run state”), and memory is commonly seen as space (ibid.: “garbage
collection128”, “partition129”, “allocation130”, “compacting131”). These are examples of metaphors
that become so prevalent that one no longer thinks of them as metaphors. They are often referred as
“dead metaphors”, but while this classification is accepted in the classical sense, it is disputed when
one considers Lakoff’s concept of metaphor as a mapping of conceptual domains.
« The MEMORY IS SPACE metaphor might be considered dead since it is
extremely conventionalized, but it is still alive in Lakoff’s sense — the
mapping between domains is still present and can be generative of new
constructs, such as the slangy term “bit bucket” (the mythical space where
lost bits go) (…) »
(Travers, 1996, p. 33)
« When the wine reviewer of The Times contrives the metaphor "a
muscular vintage", she relies upon the reader to see it as an extension of that
established metaphor whereby wines possess body, and in doing so he
breathes new life into the metaphor (we actually conjure an image of the
wine as a well-biceped body). »
(Veale, 1995, p. 16)
For this reason, some authors proposed the renaming of this concept as “transparent
metaphors” (Travers, 1996) or “dormant metaphors” (Veale, 1995)132.
I don’t mean to ignore criticism of the concept of metaphoric thinking, particularly from the
field of formal science (including computer science). The famous computer scientist Edsger
Dijkstra made clear his position in 1989:
« By means of metaphors and analogies, we try to link the new to the old,
the novel to the familiar. Under sufficiently slow and gradual change, it
works reasonably well; in the case of a sharp discontinuity, however, the
method breaks down. (…) the metaphors become more misleading than
illuminating. This is the situation that is characteristic of the “radical”
novelty. Coping with radical novelty requires an orthogonal method. One
must consider one’s own past, the experiences collected, and the habits
formed in it as an unfortunate accident of history, and one has to approach
the radical novelty with a blank mind, consciously refusing to try to link
history with what is already familiar, because the familiar is hopelessly
inadequate. »
(Dijkstra, 1989, p. 1398)
In my view, this negative view on metaphor is completely consistent with the contents of this
section. It refers to the intentional use of metaphors as tools for understanding of novel concepts.
But as I explained above, human thought and language is laden with dead/transparent metaphors,
which have acquired so deeply the meaning to which they became associated in a new field, to the
point of not even being seen as metaphors. Another contribution to realize the quixotic nature of
attempt to entirely avoid metaphor can also be extracted from my previous presentation (at the
128
The process of freeing allocated memory locations that are no longer referenced by any variable.
129
A logical division of memory.
130
Assignment of a memory block to a program.
131
Moving allocated memory blocks in order to make them contiguous, maximizing the amount of contiguous free
memory.
132
Of course, the usage of “dead”, “transparent” or “dormant” implies a metaphoric view of the concepts of metaphor
as a living organism that can die, sleep and awake (dead, dormant) or as a lens affecting our vision (transparent).
133
ToonTalk is an animated programming language; its syntax is presented in section 3.3.5, but one should be aware
that this is only a “comic strip” of an interactive animation controlled by the programmer in a videogame-like manner
(this approach to presenting ToonTalk code is also presented in section 3.3.5, on p. 198).
136 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
int pipedescriptor[2]; char text[10]; char msg[10];
pipe(pipedescriptor);
if ( fork() == 0 ) {
/* child process executes this */
close(pipedescriptor[1]);
read(pipedescriptor[0], text, 10); /* get from parent */
/*...do something...*/
}
else { /* parent process executes this */
memcpy(msg, “Hi there!”, 10);
close(pipedescriptor[0]);
write(pipedescriptor[1], msg, 10); /* send to child */
}
Start of procedure with “Hi there!” text. Pick up a nest. Drop it (egg hatches). A bird is born.
Pick up a truck. Using the magic wand… …make a clone. Put clone in truck.
Pick up an empty box. Put the nest in the box. Put nest in truck. The truck goes away.
Pick up the text. Give it to the bird. Bird takes it to its nest. The loyal bird returns!
Figure 77 – Sample program in traditional textual syntax and in child-oriented syntax134
134
ToonTalk syntax is presented in section 3.3.5. As with any translation, there are subtle differences. In this ToonTalk
code the child process will wait for the message and then will reproduce the parent’s behavior, spawning its own child
process and sending it the “Hi there!” message. Other ToonTalk alternatives for the spawning could be the use of a
library (in ToonTalk, a notebook) or passing the procedure as another entry parameter (simply by including it in the
original box alongside the “Hi there!” message). All these would unnecessarily complicate the equivalent C code.
135
A non-metaphorical version of such “jump” instructions would be named something like CPC (for “change program
counter”). This, of course, if we ignore that the name “program counter” is itself a metaphor for the digital circuit of a
register holding the address of the currently-executing instruction (another common name for such registers is
“instruction pointer” – even more clearly metaphorical).
136
I.e. the instructions composing the program.
137
Programming with physical items, as described latter in this section, also provides an environment where
collaboration can easily be employed, by having more than one person manipulating the objects used for programming.
But in general, this possibility didn’t impact the design of these systems.
138 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
Logo
(1966/67)
The Logo language was the first to be designed specifically for children use. Previously, other
languages such as BASIC and COBOL aimed to simplify the programming process for non-
technical users, or “novice” programmers; but such users were thought of as young adults, rather
than children – even if many children ended up programming in BASIC, for instance.
Logo history and general design goals were presented in section 2.4.5, but not the child-aimed
features of the language. A major problem in doing it for a language almost 40 years old, of which
many versions were created, is deciding which features to consider, besides those available since
the first version. I decided to focus on the most traditional aspects of the Logo programming
environment, namely the original language features, available in the first version of Logo, and the
“turtle graphics” subset which was included a few years later. There are three reasons for this
choice to include turtle graphics here, while ignoring newer Logo-related developments: firstly, it
was a command subset of tremendous popularity, to the point of sometimes people mistakenly
assuming Logo is only about turtle graphics; secondly, turtle graphics have greatly impacted
Seymour Papert’s educational ideas138; and thirdly, the turtle graphics command set and
programming model have inspired and were employed in many other programming languages for
children, which are mentioned later in this section. By including Logo graphics here, under the
Logo heading, their merits are assigned to the appropriate language.
As I mentioned in section 2.4.5, from the very start the key features of Logo were planned to
allow the programmer to focus more on the idea of the program, and less on its written
implementation. In this sense, its first contribution was the simplification of the written expression
of programs. To achieve this, many typical syntax elements were abolished, and the language
keywords and commands chosen carefully to resemble the current English language, sounding less
technical (an approach that had also been pursued previously, although perhaps not so radically, in
other designs of programming languages for novices).
A way to understand this simplification more clearly is to compare Logo with Lisp, the
language upon which the design of Logo was based, rather than comparing it to a completely
different language. Table 9 presents the same command in Lisp and in Logo. It results in the
presentation of the text “Hello World” on the screen139.
Lisp Logo
(princ "Hello World!") print [Hello World!]
Table 9 – “Hello world!” code in Lisp and in Logo
The differences in this example are: the parentheses used in the Lisp code disappeared in the
Logo example (although they could have been used, if so the user wished); the quotes became
square brackets; and “princ” became “print”. What’s the logic behind these changes? The
resulting command does seem more readable as an English-language expression, apart from the
change between quotes and square brackets, but why wasn’t Lisp just as readable in the first place?
138
E.g. in the idea of body-syntonicity (as mentioned in section 2.4.5 and explained in section 4.2.2).
139
Presenting “Hello World!” on the screen is the most typical example provided by programming language textbooks
and manuals to introduce a language’s syntax to a new user. Several Web sites, such as
http://www.cuillin.demon.co.uk/nazz/trivia/hw/hello_world.html, provide collections of “Hello World!” code in several
languages.
140
“As a programming language, LISP is characterized by the following ideas: computing with symbolic expressions
rather than numbers, representation of symbolic expressions and other information by list structure in the memory of a
computer, representation of information in external media mostly by multi-level lists and sometimes by S-expressions, a
small set of selector and constructor operations expressed as functions, composition of functions as a tool for forming
more complex functions, the use of conditional expressions for getting branching into function definitions, the recursive
use of conditional expressions as a sufficient tool for building computable functions, the use of λ-expressions for
naming functions, the representation of LISP programs as LISP data, the conditional expression interpretation of
Boolean connectives, the LISP function eval that serves both as a formal definition of the language and as an
interpreter, and garbage collection as a means of handling the erasure problem” (McCarthy, 1979, pp. 1-2).
141
This usage of “+” before its operands is called prefix notation, and the notation used in traditional algebra, “3+4”, is
called infix notation. Being aimed at children, Logo accepts not just Lisp’s prefix notation (using “sum” instead of “+”,
to ensure its readability in current English) and the traditional infix, “3+4”. This is another child-oriented simplification
of Lisp, but not a simplification regarding other languages, since the infix notation is the most common in programming
languages in general.
142
The aim being to provide formatted expressions on output, to feed a function called “read”, which is used for input
of expressions.
140 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
Another important example of simplification at this level is the method of defining a
procedure, by using the word “to”, which results in an English-language construction:
to sayHello
print [Hello!]
end
This allows the child to issue the just-defined procedure “sayHello” (immediately after, if so
desired), just by typing:
sayHello
Hello!
Completing the analysis of the example in Table 9, the usage of square brackets in it, instead
of quotes, seems to be counter-intuitive, since quotes are common sentence-delimiters in the written
English language. Logo uses square brackets because it views sentences as lists of words, and thus
requires sentences to be clearly expressed as lists – hence the square brackets, used as list
delimiters143. I am unaware of the actual motivation behind this use of brackets in the language
design, rather than using quotes, but I can point two advantages:
Since quotes are common in written English, there’s a high likelihood that a child will
need to issue a command to print a sentence such as «Marty said ‘Hello’». This poses
a problem, similar to the one I had while writing this paragraph: encapsulating quotes.
I resorted to using two different symbols, but in Logo this can be expressed directly,
as print [Marty said "Hello"]. Typically, programming languages use
special characters to overcame this limitation, which results in things like print
"Marty said \"Hello\". Obviously, Logo still faces this problem when
printing brackets; the advantage lies in brackets being less used in text than quotes.
Understanding that sentences can be viewed as lists of words is a powerful concept,
allowing a child to write programs that handle them as such. This means that imposing
from the start the view of a sentence as a list of words can be used to leverage more
advanced concepts.
This analysis of quotes allows me to bridge onto the topic of “simplification of syntax” not
being a clear requirement definition. I have no intention of questioning whether the option of using
brackets instead of quotes is advantageous or not, but rather of looking at it under my proposed
view of design of a language for children as providing a metaphoric model. In that sense, the
analysis of this option can be completely different depending on whether children are used to
reading or writing text employing quotes or not. In the likelihood that most children have
encountered quotes before, the option for brackets is a detachment from a previous context of using
text, and thus, questionable as a link to previous knowledge. But also commendable, for those
reasons I listed above, as a link to further knowledge. Other options could also be debated, e.g.:
« Logo is consistent and not overly error-prone, although some of the
syntax can cause confusion, for example the difference between "name and
:name (:name is used to access the value of name, while "name is used
to access the address). »
(McIver, 2001, p. 5-21)
Since the object of this thesis is not the specific analysis of Logo or textual programming, I do
not wish to probe these issues of textual-language syntax in further detail. A recent deep analysis at
143
Braces would have been another option, more closely linked with school math; speculating, there are two possible
explanation for using squares brackets instead: one is that braces {} are used in mathematics for unordered collections,
and lists are ordered; another is that many 1960s computer keyboards didn’t have braces.
144
E.g., in Logo, creating an array is achieved as:
make “mylist array 10
whereas in GRAIL, it is done as:
item mylist is array of 10 number
145
The error messages presented here were extracted from Berkeley Logo (distribution archives for several operating
systems are available for download at http://www.cs.berkeley.edu/~bh/logo.html).
146
The correctly-formed instruction could be, for instance, setitem 1 :mylist [6].
147
For instance, by using the instruction edit procedures.
148
This method of invoking procedures is also an advantage Logo got from Lisp. In some languages, a special
command had to be used to request the execution of a procedure; and in others, such a command did not exist and the
control flow had to jump around using goto commands, a technique that led to confusing and error-prone code, as
Edsger Dijkstra put forward in a classic paper (Dijkstra, 1968).
142 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
This means that there is no need to navigate through the entire code for the program: one can
simply focus on the specific problem at hand. In order to analyze procedure definitions, during
debugging, Logo provides commands such as po (meaning “Print Out”), which shows the code of a
specific procedure, pops (“Print Out ProcedureS”), which shows the code for all procedures, and
edit, which allows the programmer to edit the specific procedure he/she is worrying about, rather
than navigating the entire code (this command also allows the programmer to edit several
procedures at the same time, if so desired). In this fashion, if some procedure is not producing the
intended result, it can be edited, tried out, and tucked away nicely.
The final element of Logo I will address is also the most famous one: turtle graphics. This is a
subset of Logo commands for producing graphics, based on a physical metaphor: the graphics are
drawn by commanding a virtual pointer, instructing it to move, and sometimes drawing lines. This
pointer is known as “turtle” (hence the name “turtle graphics”), because it originated as a way to
command an actual physical, turtle-shaped, moving toy149.
Figure 78 – Children working at BBN with one of the first wireless turtle-robots (named “Irving”) in the early
1970s
Picture and caption text from: http://web.mit.edu/6.933/www/LogoFinalPaper.pdf, p. 17
« The first150 turtles were actual robots that rolled along the floor. They
got the name “turtle” because of the hard shells surrounding their delicate
electronic innards. A robot turtle has a pen in its belly, which it can push
down to the floor, or pull up inside itself. When the pen is down, the turtle
draws a trace of its motion along the floor. »
(Harvey, 1997, p. 180)
149
Created by Paul Wexelblat (according to a personal interview by Chakraborty et al., 1999, p. 17).
150
Brian Harvey is referring only to Logo turtles. The first “turtle” robots were actually built much earlier, between
1948 and 1949, by Grey Walter, but there is no connection between them and Logo (Holland, n.d.; Resnick &
Silverman, 1997).
151
“Generally, one turtle step is the smallest line your computer can draw. This is slightly oversimplified, though,
because that smallest distance may be different in different directions. But the size of a turtle step does not depend on
the direction; it’s always the same distance for any given computer” (Harvey, 1997, p. 180)
144 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
The importance of turtle graphics comes from providing graphical results for programs.
Rather than programming just with words and numbers, children can see graphical representations
of their programs, and reason in a graphical way. They can look at the last line in Figure 79, for
instance, and try to estimate the distance between the turtle and the smaller triangle; they can
associate that distance with its numerical representation; they can try to make the turtle move to the
smaller triangle, to be sure whether it is exactly at the same height (vertical position) or not, and
from there reason on the nature of equilateral triangles.
While creating graphical shapes, the children can get involved in deep reasoning, using
regular programming techniques such as loops, variables, recursion and conditions. Instead of being
limited to textual results, turtle graphics allowed Logo activities to be visual. This provides a strong
metaphorical link to one’s experiences, providing a mapping to visual notions of closeness, farness,
rotation, etc.
A problem with turtle graphics, however, is that their simplicity allows educators to look at
them just as an appealing way to introduce children to programming, as an end in itself. As I
mention in sections 2.4.5 and 4.2.2, there are two main purposes for introducing programming in
education: a plain one is to help children control computers, not necessarily as programmers but as
users that understand notions of sequence, concurrency, control and decision; a more ambitious one,
as people that explore their own thinking while reasoning over a problem in the process of teaching
the computer how to perform intended actions. The simplicity and power of turtle graphics has thus
been a boon, by allowing a stronger link between children and problems, but also a hindrance, by
diverting people’s attention from the larger goals (Chakraborty et al., 1999).
« (…) intellectual play is the best reason for learning about computer
programming in the first place. This is true whether you are a kid
programming for the fun of it or an adult looking for a career change. The
most successful computer programmers aren’t the ones who approach
programming as a task they have to carry out in order to get their
paychecks. They’re the ones for whom programming is a joyful game. Just
as a baseball diamond is a good medium in which you can exercise your
body, the computer is a good medium in which you can exercise your mind.
That’s the real virtue of the computer in education, not anything about job
training or about arithmetic drill. »
(Harvey, 1997, p. 4)
152
Squeak is based on the “release version” of Smalltalk, called Smalltalk-80.
153
Longer versions of Etoys that “string several ideas together to help the learner produce a deeper and more
concerted project” are called SimStories (Kay, n.d.). A linked concept is that of narratives that incorporate active
(programmed) media constructions, in order to both explain and exhibit ideas. These narratives are called “active
essays” (anon., n.d.-1).
154
If one so desires, the environment also allows direct editing and creation of textual Smalltalk code, thus allowing an
advanced programmer to use the full power of Smalltalk.
155
“The Disney Squeak team developed the infrastructure and ideas for Squeak-based learning environments. Alan Kay
originated many of the general concepts and project ideas, and these have been realized and implemented brilliantly by
Scott Wallace, John Maloney, Ted Kaehler, and Dan Ingalls. Kim Rose has organized experiments in classrooms and
sought the system improvements needed to make them feasible. BJ Conn and Kathleen Brewer have designed projects
specifically for children, and their work has helped the programmers to improve the system. Meanwhile, Mark Guzdial
at Georgia Tech has been using Squeak with adult learners.” (Steinmetz, 2001).
146 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
The Squeak Etoys method of expressing a program is
to allow children to work on objects drawn by them:
resizing, rotation, etc. While doing so, they can see
numerical and textual “properties” for the object. For
instance, Figure 81 presents a hand-drawn car surrounded by
its set of controls, common to all objects. One of those
controls is “heading”, and since the car in the picture has
been slightly rotated to the left, its value is now -2.
While the car is rotated, this value is updated in real-
time; and if the numerical value is changed directly, the car Figure 81 – Etoys object properties
also rotates in real-time, accordingly. For young children, From:
“the textual form of these properties doesn’t look as exciting http://www.squeakland.org/school/drive_a_car/i
mages/StandardViewer.gif
as the iconic car that can be directly manipulated (…). But,
the symbols can make the car do things!” (Squeakland, n.d.).
The educational rationale behind this is to build on the educational ideas developed in the
Logo culture and turn the computer programming environment into a place following the
educational ideas of Maria Montessori (presented in this thesis in section 4.1.1).
« Maria Montessori (…) saw how to let children exercise their wants and
still get them to learn what we think they need. Her great idea starts with the
observation that children are driven to learn their immediate environment
and culture through play (…). She realized that what children want is not
always the same as what they need — especially in 20th century Western
culture. (…) Her genius was to devise a special environment and artifacts
that look like toys to children — catering to their wants — but with beautiful
side effects that help them learn what we adults think they need. »
(Kay, n.d.)
The children can move the car directly, but the numerical properties allow them to connect
their actions to notions such as negative numbers (for turning counter-clockwise; positive number
turn clockwise), and other mathematical ideas.
In order to move beyond mere editing of properties,
the child can use some properties that define behaviors
(those with an exclamation point in Figure 81 and Figure
82). The commonly-used Squeak example of programming
the driving of a car renders this clear: by clicking the
exclamation point for the property “forward by 5”, the
car moves forward 5 points. Such behaviors can be dragged
together to the desktop, to create a script. In Figure 82, the
script reads:
Red Car script1 Figure 82 – Etoys script creation
From:
Red Car forward by 5 http://www.squeakland.org/school/drive_a_car/i
mages/drag_out_tiles.gif
Red Car turn by 5
156
Information organization in a disk drive is an important computer skill; adults and children should be able to
navigate efficiently in their computer’s file systems. However, being able to work without little knowledge and skills in
this area means that children can start programming and rendering computers useful without having to acquire file
navigation as a prerequisite.
157
Windows XP at 1152 by 864 pixels, of which 64 rows are used by the taskbar.
158
E.g., « My first impulse would not be to alt-left click an object to pull up a halo and then click the blue eyeball to pull
up one object's viewer at a time. Every time I explain this process, people just look at me or ask “And who came up with
THAT?” » (Basu, 2003).
159
Commonly-used Internet lingo acronym for “in other words”.
150 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
Stagecast Creator
This programming system was developed by
David Canfield Smith and Allen Cypher, mainly
between 1990 and 1997. Originally, at Apple Computer
Inc., it was called KidSim (Smith et. al., 1994), and then
renamed Cocoa (Smith et al., 1996). It is now a
commercial product of Stagecast Software, Inc., under
the name Stagecast Creator (Smith et al., 2001).
Smith & Cypher believe textual programming to Figure 86 – David Canfield Smith & Allen
be inappropriate for use by people without an interest in Cypher
the actual technical aspects of computer programming From:
http://www.cs.umd.edu/hcil/muiseum/canfield/davepic
itself, and thus Stagecast Creator was developed as a ture.jpg and
visual programming language, at least in its core http://www.acypher.com/images/ACypher.gif
programming method160.
« Our first insight was that language itself is the problem and that any
textual computer language represents an inherent barrier to user
understanding. Learning a new language is difficult for most people.
Consider the years of study required to learn a foreign language (…). A
programming language is an artificial language that deals with the arcane
world of algorithms and data structures. We concluded that no conventional
programming language would ever be widely accepted by end users. »
(Smith et. al., 2001, p. 9)
Following this reasoning, the emphasis of Stagecast Creator is on the simplification of
expressing the program. Smith & Cypher attempt to “abolish” syntax, at least in terms of its
conscientious perception by the users, by basing programming on visual rewrite rules, i.e.,
specifying graphical beginning and ending situations, rather than the actions that are to be
performed by the language itself. In this sense, there is a connection between Stagecast Creator and
the idea of constraint programming, with its pre- and post-conditions. Figure 87, on page 152,
presents an example of rule-definition in Stagecast Creator.
« It’s no good allowing users to create a program easily and then require
them to learn a difficult syntactic language to view and modify it (…). (…)
Creator does in fact have a syntax – the lists of tests and actions in a rule –
but people can create programs for a long time without even being aware of
this syntax. »
(Smith et al., 2001, p. 10)
160
Parts of Stagecast Creator, such as conditions and usage of variables, require some textual syntax, as is mentioned
further ahead in this section.
Stagecast Creator environment, after placing the iceman in the initial situation
The user selects the area for definition of the rule, by dragging161 its handles. The rule
definition becomes visible on a new window, on the right.
By dragging the iceman to the top of the ice block, the rule is defined. This can be
done in either the main window or the rule window. The definition becomes complete
after clicking on the button labeled “close” (with the green checkmark)
Figure 87 – Defining a rule in Stagecast Creator (climbing on top of an ice block)
Screenshots from the tutorial available at www.Stagecast.com
161
As the image shows, Stagecast Creator uses a grid structure for defining rules. This has the advantage of simplifying
the specification of starting conditions, since all elements must be located at well-defined positions. However, this also
means that when using this visual technique “all motion is stepwise and movement at any angle other than to one of the
squares surrounding the current position is impossible. Similarly changing the visible representation of a character
happens abruptly” (Sheehan, 2004).
152 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
The user must understand this graphical syntax in
two situations:
in order to change the ordering of the rules
(Stagecast applies the rules in sequence for
each element, not concurrently, so the
order of their execution may need to be re-
arranged, in order to attain the desired
effect);
in order to include conditions not
represented in the graphical environment
(for instance, a mouse-click, a key-click, or
a variable value).
As an example, Figure 88 presents a conditional
rule: the bat will move up one empty square, but only if
the user clicks on it with the mouse cursor. The symbol
to the right of “is clicked on” means “bottom square of Figure 88 – Conditional rule in
Stagecast Creator
the two squares of the rule”.
Textual syntax is also required when
variables have to be used. For instance, Figure
89 is part of a Stagecast tutorial and explains
how to add an action to a character to change
the value of a variable. In this case, the
magical power “zoom” is being assigned to
the variable “Magical Power”, when the
magician moves over a magical potion.
While all these features are relative to
the expression of the program, Stagecast
Creator also includes some features useful for
understanding the program’s execution. When
a program is not behaving as the programmer
intended, it can be paused, and the rules for Figure 89 – Updating variables in Stagecast Creator
each element inspected.
This inspection is performed at two levels: a global view
of the element’s rules (Figure 90), and a test analysis of an
individual rule (Figure 91). For instance, in the global list of
rules for the iceman (presented in Figure 90), the red “light”
near each rule report that it cannot be fired. (And a green light
would report a rule that can indeed be fired.)
By double-clicking on the specific rule that the
programmer intended to have executed, the Stagecast Creator
can test the rule and show the program which parts are valid or
invalid.
In Figure 91, the rule defined in Figure 87 is being tested
in a different situation: the iceman is facing a pile of two ice
blocks, instead of just one. Figure 90 – Analyzing which rules
apply or don’t apply in Stagecast
Creator
162
As pointed out in that section, the developers of Squeak Etoys see this difference of representations as an advantage,
a way to make a smooth transition not between programming and debugging activities but between graphical and
numerical representations.
163
During the IEEE 2001 Symposia on Human Centric Computing Languages and Environments (HCC'01), in Stresa,
Italy, I inquired Allen Cypher about this latter problem (I was wondering if one might program ultra-fast, invisible
“scout sprites” to locate objects), and he mentioned Stagecast was considering implementing a “radar” tool.
154 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
164
At the time, names for this idealization of Alan Kay included “KiddiKomp” and “Dynabook”.
165
This technique inspired, for instance, the programming environment LiveWorld, also mentioned in this section
(Travers, 1994b). There is also a similarity with the ToonTalk method of placing code behind pictures and then
organize it in different levels by placing those pictures behind others (vd. section 3.3.5, from p. 195 onward).
156 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
Playground (1989) & Liveworld (1994)
(Fenton & Beck, 1989; Travers, 1994a; Travers, 1994b)
Playground is a system in which
children create graphical objects and assign
behaviors to them. This assignment is done by
using a textual scripting language, designed to
be similar to the English language. According
to K&P, it is very easy to create and interact
with graphical elements in Playground, but
it’s much more difficult to interact with the
attributes of each object.
Liveworld is an evolution of the
concepts developed in Playground: it employs
a graphical interface for the rules and
attributes of each object, aimed at diminishing
the problem of accessing attributes and Figure 94 – Playground programming environment
managing rules. From: Fenton & Beck, 1989, p. 124)
166
Already mentioned in the section describing the Logo language, on page 139.
a deck of cards being handled by « Open Handy’s Thought Bubble. Use the New
character named Handy the Dog (Figure button to make a new rule. Type when anything
96, top left). The back of each card happens for the event. This way Handy will do the
displays a picture of the object to which it
action all the time when anything happens on the game
relates; the front contains data. board. We know we want Handy to figure out the
The programs are represented by CardWithLeast nectar of all flowers.
laying cards on the table in the We would like him to put the answer into the back
programming environment, and adding property of the leastFlower card. To do this, we
textual properties to them. will ask him to:
By using a natural-language textual set leastFlower’s back to
syntax, similar to GRAIL (mentioned in CardWithLeast nectar of all flowers
this section, on p. 157), the programmer Put that inside your new rule. The rule should
“tells” Handy the Dog about rules that look like this:
govern the objects represented by the
cards laid on the table. when anything happens
set leastFlower’s back to
CardWithLeast nectar of all
flowers
end when
Press Check, to make sure the new rule is
correct. If it is, close Handy’s Thought Bubble. »
(Pane, 2002, Appendix G, p. 11)
167
The Programmable Brick project led to the development of the LEGO company’s RCX Mindstorms brick
(http://www.lego.com/eng/education/mindstorms/home.asp?pagename=rcx&bhcp=1), and to a more recent MIT project
called Cricket (http://llk.media.mit.edu/projects/cricket/about/index.shtml).
168
“inicio” is “start”; “siempre” is “always”; “si entonces sino” is “if then else”.
169
http://www.ioe.ac.uk/playground
170
Several other people collaborated in management, design, and technical advice, including Secundino Correia,
Manuela Andrade, Peter Tomcsány, Ivan Kalas, and Andrej Blaho (Correia & Andrade, 2001).
171
I am referring to My Make Believe Castle. The “treasure isle” system is an identical one, only in the setting of an
island, rather than a castle.
172
At the NESTA Futurelab, Bristol, UK (www.nestafuturelab.org).
173
This was also a feature of the TORTIS slot machine (p. 171), 17 years earlier.
172 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
Logiblocs (1996)
(Logiblocs, n.d.)
These are building blocks with logical functions,
sensors (inputs), and actuators (outputs), which can be
connected to produce several constructions with varying
degrees of complexity. “From traffic lights to space
stations, from cars to computers, everything in today's
high-tech world is controlled in the same way as
Logiblocs. Inside each Logibloc is a printed circuit
board and every block is colour-coded to describe its
function. By plugging together Logiblocs in different
combinations you can create circuits and virtually write
your own simple program to build your own new Figure 130 – Logiblocs (“Spytech” kit)
inventions” (Logiblocs, n.d.).
From: http://www.logiblocs.com/img/products/all.gif
Logiblocs are sold as special-purpose kits, but the
blocks can be applied to a large number of projects
involving design skills and problem-solving skills.
AlgoCard (1997)
(Yamashita et al., 1997; Yamashita, n.d.)
AlgoCard is a system based on
AlgoBlock, which replaces blocks with
cards.
“AlgoBlock is a substantial
programming language, but because each
block consist[s] of electrical circuits, the
system lacks flexibility (…). AlgoCard
replaces blocks with cards. A computer
recognizes cards and interpret[s] them as
a program” (Yamashita, n.d.). Figure 131 – AlgoCard software environment
There are two elements to the From: http://jun.cyber.rcast.u-tokyo.ac.jp/RESEARCH/GRAD/WIN.GIF
AlgoCard system: a software environment
presents the position of the cards used to
express the program and the
corresponding program (Figure 131).
The cards themselves are tangible,
placed on a table with a grid, and
recognized by means of a computer-vision
system (Figure 132).
Those are Lego Duplo Primo™ blocks with electronics inside, and can be stacked just as any
ordinary Lego block. Figure 138 show a sample program: on the left, the touch sensor block is on
top of the light action block, which therefore produces light whenever the sensor is touched. On the
right, the movement action block has a seeing sensor block on top, which therefore moves whenever
the sensor detects enough light. By placing the first set of blocks (remote control) near the second
set (car), the car will move whenever the child put her/his hand in contact with the touch sensor. The
logic blocks could also have been used. For instance, if the “not” block was placed between the
seeing sensor and the movement block, the car would move whenever there was NOT enough light
reaching the seeing sensor.
Tangible Programming Bricks (2000)
(McNerney, 2000)
“Tangible Programming Bricks are
physical building blocks for constructing
simple programs” (McNerney, 2000, p. 2).
They were developed with the overall aim of
allowing people without programming
experience to control “everyday objects, from
toy cars to kitchen appliances” (id., ibid.).
Each brick has the electronics to behave
in a specific manner, and can receive
“parameter cards”. For instance, Figure 139
show bricks to control the behavior of an
oven, in a more detailed way than is normally
possible: defrost (the number of minutes is
not visible in the picture), then repeat 4 times: Figure 139 – Programmable Bricks program (the side-
cards contain parameters)
cook for forty minutes, and let it stand for 10
minutes. From: McNerney, 2000, p. 15
Eco-Pods (2005)
(Kikin-Gil, 2005)
Eco-Pods are a programming system aimed at
children aged between 4 and 6 years, which shares its
mains goals with System Blocks (p. 177); namely, to
“help children learn systems thinking” (Kikin-Gil, 2005,
p. 1), defined as “a holistic way of looking at the world
(…) as an assemblage of interrelated components
comprising a unified whole. The relationship of
elements in the system facilitates the flow of data,
matter or energy between them” (id., p. 4). The concepts
whose learning the system aims to facilitate include
“feedback loop, interconnectedness and change over
Figure 147 – Eco-Pods display interface
time” (id., p. 19).
From: Kikin-Gil, 2005, p. 42
In this system, children can indirectly influence
the growth of a flower (Figure 147), by controlling the
environment elements: wind, rain, light, heat. This
control is done by acting (blowing, shaking, spinning,
rubbing) upon tangible control elements, the Eco-Pods
(Figure 148).
According to the researcher involved in the design
and development of the Eco-Pods, “children understood
cause and effect, interconnectedness and change over Figure 148 – Eco-Pods (water, light, heat,
wind)
time” (id., p. 50).
From: Kikin-Gil, 2005, p. 42
174
In ToonTalk, one can drop some objects on top of others, and also re-order the resulting stack, achieving different
results. The programmer is therefore working with more complexity than just 2 plain dimensions, because the stacking
order affects visible results. But it is not a fully 3D environment, because one cannot really produce 3-D objects, just
stacks that remain two-dimensional stacks of 2-D objects (i.e., the stacks themselves have no height, either visibly or
interpreted from effects produced by sideway contact with other objects). This use of 2D objects whose design gives the
viewer the illusion of working in 3D is commonly referred to as “2.5D”.
175
Multi-User Dungeon. The name comes from the early use of the concept of text-based virtual worlds: a hosting
place, where several people could play fantasy adventure games together. The original fantasy adventure games usually
took place inside dungeons, hence the name.
176
Just like for game-editing software, this is a large genre. For a starting point reference, I suggest http://www.find-
site.com/index/Games/Video_Games/Simulation/Programming_Games.html.
177
This is the name of a user-written procedure for shooting. It is not a reference to the SHOT register, mentioned
previously.
In the level of Figure 158, for example, the blocking task must be assigned to lemmings
placed at specific spots in the platforms, so that the remaining lemmings only fall small heights.
This prevents them from splatting on the lower floor, so that they can reach the exit in enough
numbers. In the figure, the leftmost and rightmost lemmings have already been assigned the
blocking task.
178
Now part of Sony Entertainment.
184 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
The Incredible Machine (1993) / The Incredible Machine 2 (1994) /
The Incredible Machine 3 (1995) / Return of the Incredible Machine: Contraptions (2000) /
The Incredible Machine: Even More Contraptions (2001)
(Reyes, 2000)
These games were inspired by a
kind of comic gag common in several
animated features: one event causes
another, and another, and another, in a
hilarious sequence179. Another inspiration
source derived from the absurdly-
connected machines known as Rube
Goldberg inventions180.
In these games each level has a
specific goal, and provides several objects
that the user must place and combine, so Figure 159 – The Incredible Machine I & II cover art
that the resulting contraption produces the
From:
intended result. http://www.mobygames.com/images/covers/large/970790813-00.jpg
and
For instance, in Figure 160, the goal http://www.mobygames.com/images/covers/large/972067977-00.jpg
is for all three guns to fire. For this,
several objects have already been
positioned. The bowling ball, upon
rolling, will hit the punching glove
(containing a spring). This will tilt a
bucket tied to a rope. Upon falling, the
bucket will pull the rope, which in turn
will pull the trigger of the first gun. The
shot will blow the balloon, and the iron
weight tied to it will fall. The bucket that
was falling will also hit one end of the
seesaw, whose other end is tied to the
trigger of a second gun. In this figure, the
player is currently positioning the second
gun, and still has to come up with a Figure 160 – The Incredible Machine screenshot
solution for firing the third gun. From:
http://www.mobygames.com/images/shots/original/1082679853-00.png
179
Examples include Warner Brother’s Road Runner & Coyote cartoons, Hanna-Barbera's Tom & Jerry cartoons, and
more recently the 1988 movie “Who Framed Roger Rabbit”, which opens with a tribute to this kind of gag.
180
“While most machines work to make difficult tasks simple, his inventions made simple tasks amazingly complex.
Dozens of arms, wheels, gears, handles, cups, and rods were put in motion by balls, canary cages, pails, boots,
bathtubs, paddles, and live animals for simple tasks like squeezing an orange for juice or closing a window in case it
should start to rain before one gets home” (Rube Goldberg Inc., n.d.).
TO Defense
IFELSE (:_his_hand = 2)[disturb_hishand][
IFELSE (:_my-posture <= 2) [bend_forward][
IFELSE (:_my-posture =4) [bend_back][
IFELSE (:_my-posture= <=2) [move_forward][Offense]
]
]
]
END
TO Offense
IFELSE (:_his_hand = 2) [disturb_hishand][
IFELSE (:his_posture =4) [slap_down][
IFELSE (:_my-hand =2) [throw][
IFELSE (:distance= 1) [grasp_mawashi][push_foward]
]
]
]
END
Table 14 – Sample AlgoArena program (English-language version)
From: Suzuki & Kato, 2002, p. 286
181
For instance, browsing for game-design tools at http://www.the-underdogs.org/ provides no less than 214 different
titles, which don’t even include tools developed in Europe, such as Game Designer and HURG, presented in this
section. Tools for creating entirely new games, however, are only 10.
182
Released in the UK in 1983, under two different names: “Games Designer”, edited by Quicksilva, and “Games
Maker”, edited by St. Michael. The only difference is the loading screen, otherwise the software is the same (after
loading, “Games Maker” clearly displays the title “Games Designer”).
Figure 171 – Screenshot from a game created in HURG by Figure 172 – HURG: defining behavior on
Tony Samuels for the “Your Spectrum” magazine object collisions
From: http://www.users.globalnet.co.uk/~jg27paw4/yr17/yr17_24.htm From:
http://www.users.globalnet.co.uk/~jg27paw4/yr17/yr17_
24d.gif
ARK: Alternate Reality Kit (1986)
(Smith, 1986)
The Alternate Reality Kit does not fit
exactly within this category (game-creation
systems), since its aim is to create interactive
simulations, not just games (a goal it shares
with Stagecast Creator, presented in p. 151). I
have opted to include it here nonetheless, since
this is more of a distinction in aim, rather than
in actual programming features, which are
similar to other products in this genre.
“ARK is built upon a physical-world
metaphor: all objects have an image, a
position, a velocity, and can experience forces.
Users manipulate objects with a mouse-
operated "hand" which enables them to carry Figure 173 – Alternate Reality Kit environment
and throw objects, to press buttons, and to From: Smith, 1986. p. 62
operate sliders” (Smith, 1986, p. 61).
ARK included several innovative ideas.
One was conceiving the metaphor of a virtual
world, with a hand to grasp objects, and
dragging command buttons to assign behaviors
to pictures – these are techniques also used in
ToonTalk (section 3.3.5, p. 195). Another was
the idea of dragging parameters to buttons,
which is similar to what is now used in Squeak
Etoys (p. 146).
183
Multimedia Fusion is aimed at adolescents and adults, rather than children.
192 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
Game Maker (1999)
(Overmars, 2004)
Game Maker is a modern game editor, developed by Mark Overmars. Like HURG or Klik &
Play, it can be used to create entirely new games. Users can define sprites, objects, rooms, events
and actions, employing features common in modern windowed environments, such as menus, tree
structures for organization, tabbed dialogs, and drag-and-drop elements.
« You can import and create images, sprites (animated images) and
sounds and use them. You easily define the objects in your game and indicate
their behavior. And you can define appealing rooms with scrolling
backgrounds in which the game take place. »
(Overmars, 2004, p. 6).
A particular feature of Game Maker is that it includes its own textual programming language,
GML, similar to the professional programming language C. This feature is not child-oriented, but
advanced users can have full control of the game-making interface: scripts in GML can be assigned
to game elements, to finely define behaviors and events.
Game Maker has an interesting track record in terms of educational use, including technology
summer camps and elementary schools, but also high schools and universities. The official site
includes a page with teaching materials, an introduction for children aged 11-13, and other reference
material, at http://www.gamemaker.nl/teachers.html.
Figure 179 – Point & Click DK environment: object status, frames, image resource, action script
Being a novel concept, it helps to state what animated programming isn’t: it is not the
programming of animated characters or plays by means of static code; it is not the animation of the
execution of static code; it is not the usage of animated icons or objects in place of traditional static
icons.
Animated programming is the usage of animation to express the code itself. In order to help
picture this concept, one can think of a programmer saying “watch what I do” and of a system that
records and interprets the visual (animated) actions of the programmer. This is just a simplification,
for complete expression of code must also include methods for other programming constructs, such
as specifying conditions and generalizing the actions of the programmer.
« The fundamental idea behind ToonTalk is that source code is animated.
(ToonTalk is so named because one is "talking" in (car)toons.) This does not
mean that we take a visual programming language and replace some static
icons by animated icons. It means that animation is the means of
communicating to both humans and computers the entire meaning of a
program. »
(Kahn, 1995, p. 5)
In this regard, one can think of cases of “animated programming” in the physical world: for
instance, when a shooting a movie or rehearsing a play. Sometimes a director explains his/her
intentions to an actor by performing actual body movements, gestures, facial expressions, etc. In
this sense, there is “animated programming” of the actor’s performance. By considering the
physical world, a few of the systems described in section 3.3.4, under the category “Programming
with physical objects” (p. 128), can also be considered instances of animated programming, at least
partially. Specifically, the main feature of programming the Curlybot (p. 174) is reproducing
physical motion; and programming in Topobo (p. 178) is entirely done by moving the
programmable pieces185.
184
“It seems that no one has ever tried to do this. (And when we figured out how to, we applied for a patent of the
invention.)” (Kahn, 1995, p. 7).
185
In these cases, the “execution” of the program by the actor or robot is also an animation – an interpretation of the
animation provided by the director/programmer. A generic animated programming system needs to go beyond mere
cases of “animation to program animation”.
186
In Sweden, Jakob Tholander and Ylva Fernaeus have conducted programming activities with children, without a
computer, in a setting similar to this “movie director” situation (Fernaeus & Tholander, 2003). Each children would be
assigned (or define) a small program by a combination of body motion, spoken explanation and written notes. Just like
in the “movie director” example, part of this programming is animated, but not its entirety.
196 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
Given the novelty of the field itself, there is no available research on usage of animated
programming, by controlled comparison with static programming, to support or disprove these
expectations, but informal anecdotal evidence, favorable to them, is mounting up (e.g., Playground
Project, 2001). However, research regarding the impact of animation on users’ understanding of
visual information, albeit limited, provides positive indications:
“If a task requires a subject to know something about objects’ spatial
position, and the viewpoint is changed, then animating that change in
viewpoint appears to help users. (...) This has direct implications for many
applications that present linear data – including word processors,
spreadsheets, and Web browsers.”
(Bederson & Boltman187, 1998)
Before proceeding with the description of specific features of ToonTalk, I need to address two
problems with the implementation and description of animated programs. The creation of
animation by the user/programmer and providing a static description of the programs (for
instances such as their presentation on printed matter).
The creation of animation is a basic problem for any animated programming language: since
the source code itself is animated, the user must be able to produce the required animations. But
producing animations is often a complicated task in itself188. The solution provided by ToonTalk is
to make the programming environment resemble a video game, where the user controls and
manipulate game elements while programming.
“(...) constructing animation is generally difficult and time-consuming.
Good animation authoring tools help but it is still much more difficult to
animate an action than to describe it symbolically. Luckily, there is one sort
of computer animation that is trivial for a user to produce – video game
animation. Even small children have no troubles producing a range of
sophisticated animations when playing games like Mario Brothers. While the
range is, of course, very limited relative to a general animation authoring
tool, video game style animation is fine for the purposes of communicating
programs to computers.”
(Kahn, 1995, p. 5)
187
This paper also contains a nice summary of studies on how animation affects user performance.
188
To the point that there are programming languages specifically targeting the creation of animations, such as SAM
(Geiger et al., 1998) or Alice (Conway, 1997).
Figure 182 – Comic strip: ToonTalk program for making a puppy turn
around
From: Kindborg, 2003, p. 107
Ensuing with the description of ToonTalk and animated programming, it is necessary to say
that ToonTalk is not just a programming language, but also a programming environment where that
language is used to create programs. For this reason, I’ll employ the analysis categories already
used in section 3.3.4 for other programming languages and environments: expressing a program,
understanding the execution of the program, and child-orientation of the programming environment.
198 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
In ToonTalk, the most striking feature associated with the latter category is the emphasis on
providing a global metaphor for conducting programming activities. As much as possible, all the
programming activities take place in a video-game world resembling a city. The user (programmer)
controls a “doll” or “figurine”, seen as his/her programming “persona” or “avatar” (Figure 184).
Controlling that programmer doll, in video-game fashion, the user can enter and leave houses,
where computations are taking place, observe and debug ongoing computations, and create new
computations using objects representing tools and primitives, stored inside a legged, trailing,
toolbox. Since the city can grow large, a helicopter is provided, to allow a bird’s-eye view and
simplify navigation in the city (the toolbox and the helicopter are visible in Figure 184).
189
The term “process” is used here just for the sake of simplicity in this short description. “Agent”, “actor” or “object"
could also have been used.
Figure 185 – ToonTalk programming environment: programmer’s hand and toolbox contents
By “tools”, I am referring to elements whose only purpose is to allow the programmer to
manipulate the environment and the visual elements used in programming: producing copies,
zooming in and out, deleting (vacuuming), erasing (creating a generic version of an element),
saving to disk, etc. They are extensions to the programmer’s persona. All other ToonTalk elements
are primitives. In this taxonomy, the programmer’s hand and the programmer’s persona aren’t
classified at all (neither as tools nor as primitives); they are meant to be seen as extensions to the
human programmer’s own body and mind. One should have in mind that since tools are extensions
to the persona, a different “programmer” might not need them to achieve the same purpose: for
instance, if the programmer persona was a winged dragon, rather than a human, there would be no
need for an helicopter to fly around, nor for a vacuum cleaner to get rid of things (albeit charring
things down to the ground might not be a good idea should one need them later)190. In this sense,
the elements which I classify as ToonTalk tools are the ones presented in Table 15.
All elements in ToonTalk are “cartoons”, even the tools. In line with the language and
environment metaphor, they possess animations. Table 15, which details the tools, presents
examples of such animations.
190
An alternative computer science perspective could be to disregard the existence of tools altogether, since all their
purposes are potentically replaceable by a programmer persona. As I describe further ahead in this section, the syntax of
ToonTalk is not dependent on the tools themselves but on the static primitives (which can be seen as values) and actions
upon them, which I call "animated primitives” (and can also be seen as operations). Conceivably, any animated
primitive can be replaced by a completely different one, as long as its effect and applicability remain identical, and the
language would still be ToonTalk, even if the overall appearance changed a lot: " The ToonTalk world resembles a
twentieth century city. There are helicopters, trucks, houses, streets, bike pumps, toolboxes, hand-held vacuums, boxes,
and robots. Wildlife is limited to birds and their nests. This is just one of many consistent themes that could underlie a
programming system like ToonTalk. A space theme with shuttle craft, teleporters and the like would work as well. So
would a medieval magical theme or an Alice in Wonderland theme" (Kahn, 1995).
200 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
ENVIRONMENT TOOLS
Visual (when not used) Visual (in use) Modes of operation191 Location
Dusty the Vacuum
S – Suck up element Inside Tooly the
Toolbox.
R – Reverse (spit out)
Pops out when the
E – Erase surface programmer kneels.
Helicopter
Landed on city streets.
Flying Can be summoned with
the “F1” or “H” keys.
Maggie the Magic Wand
C – Copy element
Inside Tooly the
S – Copy itself Toolbox.
Pops out when the
O – Copy original programmer kneels.
picture of an element
Marty the Martian
Shows up whenever
Providing help with the programmer is
text balloons inside a house.
N/A
Providing help with Can be sent away or
audible speech summoned with the F1
key.
Pumpy the Bike Pump
B – Make big
L – Make little
W – Make wide Inside Tooly the
Toolbox.
N – Make narrow
T – Make tall Pops out when the
S – Make short programmer kneels.
G – Make “good”
size192
Tooly the Toolbox
Trails behind the
Following the programmer when
programmer he/she is walking or
standing up.
Open on the floor or When the programmer
in hand kneels, Tooly opens
up.
Table 15 – ToonTalk tools and their purpose
191
The modes represented by letter buttons are presented as they appear in the US English version, but are found
localized in other language versions of ToonTalk.
192
In ToonTalk, this means each object’s default size.
193
Most of these primitives are not visually “static”, they possess animations. The term “static” is used because those
animations serve no specific programming purpose, and are employed solely for aesthetic or metaphoric reasons.
194
In the ToonTalk software environment, a message can be one of the square-shaped static primitives or a scale, but a
broader view of just the ToonTalk language, not its current environment, could envision it as being any static primitive.
195
This is the current status of the ToonTalk language and environment, which does not possess an actual specification
document. Envisioning such a specification, one could consider all static primitives as containers, and the current
ToonTalk software simply as a language implementation were only some of those containers are usable as such.
196
First-In, First-Out.
202 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
Organization of elements in
Notebook
collections197 of templates.
Representation of a sequence of
Robot
operations (i.e., a procedure).
197
The term “collection”, used here, aims to convey a distinction between notebooks and arrays (which are represented
by cubby boxes). While ToonTalk collections are ordered (i.e., notebooks have page numbers), just like arrays, they are
distinguishable from ToonTalk arrays in several aspects. Firstly, they are indexed: in a notebook, a program can directly
access an element, using a value that only becomes defined at runtime (either by page number or textual content of odd-
numbered pages); cubby box arrays must be manipulated or iterated. Secondly, notebooks do not have a defined size:
they hold a finite set of elements, but the only way to specify a number of “empty” cells/pages is to have a non-empty
cell after them in numerical page order. Thirdly, notebooks are not divisible: there is no primitive to split the contents of
one notebook over two notebooks, whereas with cubby boxes one can readily do that operation.
Repositioning of static
primitives
– OR –
removal from a
Grabbing and
container or array
dropping
– OR –
instantiation of a static
primitive from a
template.
Combination of static
primitives.
The actual operation
depends on the nature of
Dropping on
the primitives being
combined.
Not all combinations are
valid.
Elimination of a static
Vacuuming
primitive.
Generalization of a
static primitive.
Erasing
Not applicable to all
static primitives.
Recovery of a static
primitive that was
recently vacuumed
– OR –
Spitting
recovery of a defined
state from a recently
generalized static
primitive.
Creation of a duplicate
Magic wand
with a defined state,
copy of
from a generalized
original
primitive.
Number pad
on The letter index is increased.
text pad
198
ToonTalk arithmetic supports arbitrarily large numbers, exact fractions, and irrational (approximate) numbers. It
provides some interesting solutions for displaying numbers with tens of thousands of digits, or even with an infinite
number of digits (Kahn, 2004). For instance, the rational number 120/19, above, is displayed with an ever-shrinking
sequence of digits. If the programmer enlarges the size of the number pad, more digits become visible.
199
I.e., a generalized text pad.
Image, number
The dropped-on image or pad
pad or text pad
becomes an independent part of
on
the bottom image.
image
Image The bottom image acquires the
on visual looks of the dropped-on
erased image image.
Static primitive
Placement of the dropped-on
on
primitive inside the cubby box.
cubby box
Cubby box
on side of Concatenation of the two arrays.
cubby box
Text pad
Text converted into an array with a
on
single-letter pad in each hole.
erased cubby box
Number pad The erased box becomes an array
on with as many empty boxes as the
erased cubby box dropped-on number.
Notebook The notebook templates are
on instantiated. Each element is placed
erased cubby box in sequence in the resulting array.
The erased box becomes an array
Robot team with as many holes as there were
on team members.
erased cubby box The robot team is split, and each
member is placed into a hole.
Static primitive203
Placement of the dropped-on
on
primitive inside the nest.
empty nest
200
In the current implementation of ToonTalk, only rectangle-shaped static primitives and scales can be used (see
footnote 194, on page 202).
201
I.e., the animated primitive “drop on” results in another animated “drop on” primitive.
202
If there is more than one nest associated with a given bird, then the static primitive is duplicated (copied), and each
nest receives a copy. A different perspective on this could be that the static primitive is turned into a template upon
being dropped on a bird, and from that template several instances are created, one for each nest.
203
As mentioned in footnotes 194 (page 202) and 200 (page 206), in the current implementation of ToonTalk only
rectangular static primitives and scales can be used.
206 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
Static primitive,
Placement of the dropped-on
carried by bird
primitive inside the nest, below204
on
existing contents.
non-empty nest
The two nests are joined. Birds
Nest
associated with either nest
on
become associated with the
empty nest
resulting nest.
Static primitive
Placement of the static primitive
on
inside the container.
flipped container
Change of setting to the robot’s
thought bubble; until exit from this
Array setting, all actions (animated
on primitives) are recorded as that
untaught robot robot’s sequence of operations. The
status of the dropped-on array is
recorded as that robot’s constrains.
The robot’s constraints are
compared to the dropped-on box.
Array
If they match, the robot executes its
on
sequence of operations repeatedly,
taught robot
until the constraints cease to be
valid.
Array
on Assignment of new constraints to
thought balloon of the robot’s sequence of operations.
taught robot
Retraining. The setting changes to
the robot’s thought bubble, where
Array on taught the robot replays its sequence of
robot whose operations, either until the end or
thought balloon until the programmer interrupts it,
has been by moving the mouse. Any
vacuumed subsequent actions are recorded
following the replayed ones.
(Unreplayed actions are discarded.)
Robot team. From the viewpoint of
all other primitives, a team is a
Robot single robot.
on Within the team, if a dropped-on
robot array fails to meet the constraints of
a team member, the array is passed
on to the next team member in line.
204
The picture in the “visual result” column was edited for the benefit of printed clarity. In ToonTalk, the presence of
items “behind” the first is not visible until the first one is removed.
Static primitive
The static primitive becomes a
on
template, stored in that page of
empty page of a
the notebook.
notebook
Number pad
The notebook opens on the page
on
matching the dropped-on number.
base of notebook
205
If the robot constraints are not generalized, then it will only act on an identical array, which renders the programming
little more than macro recording (in the presented example, the robot will swap “11” with “22”, but not “22” with “11”,
nor any other combination of numbers). The generalization of constraints is how “any program can be created by
working with examples” (Kahn, 2001b).
206
In this row, the rightmost cell shows two sample matching teams. Firstly, a team that is identical to the constraint.
Secondly, a team where several changes occurred, but that still matches the constraint: a new robot was added to the
team, but since it is located behind the first two, it is not considered for matching purposes; and the constraint of the
second robot was changed, but the robot itself is the same.
Figure 193 – First execution method: dropping the working box on a robot and watching it work.
The second method means that the moment the truck departs, the computation is running, but
not under the eye of the programmer. This is an adequate situation in several cases. For instance, if
one already debugged the program reasonably well and simply wants it to execute and terminate
autonomously; or if one wants it to run continuously and simply observe the computation results
indirectly, as messages being delivered to a container or some other remote effect (changes to
images in view for example).
The third method is similar to the second, in that the robots will be executing at full speed,
and the programmer can only observe indirect effects. Its difference lies in practical issues. For
instance, if one wants to inspect all robots manipulating an image’s properties, it is easier to find
Figure 195 – Dispatching one robot, with a small figurine width, and six seconds later.
Should the programmer find this behavior odd, he/she may want to inspect the impact of the
width-changing robot. But waiting for its animation to unroll for each received number may be
tedious. Using the bird and nest can be helpful. The robot can stay behind the image, working on its
width, and the programmer can hand new numbers to the bird directly, watching the resulting effect
on the picture width, rather than having to wait for the animation of the robot (Figure 196).
207
As mentioned before, the name of the bird and the label on the nest take no part in this whatsoever: the connection of
the bird with the nest is an intrinsic (and immutable) property of both.
208
This pair of robots produces the following results: on the left, at each iteration the number will increase by one, so
the number will be 0, 1, 2, 3, 4, ...; on the right, the number dropped on the nest is added to the value already in the hole
labeled “sum”, which will be “0, 1, 3, 6, 10, …”, i.e. the result of 0+1+2+3+4+…
Figure 196 – Sending one number to the robot on the back of the figurine, using the bird.
The manipulation of controls for a picture, as mentioned here, is perhaps easier to understand
if detailed a bit further. The “controls” themselves are regular primitives (text pads, number pads,
boxes, images) that present special behaviors. This is how ToonTalk links itself to the state of the
programming system. Terminology-wise, these primitives with special behaviors are only called
“controls” when they provide access to the state of an internal ToonTalk container element (a
picture, for instance); they are called “sensors” instead, if they provide access to the state of the
computer system or the overall ToonTalk programming environment (mouse position, pressed keys,
looks of the current ToonTalk house209, etc.).
The sensors can be found in the “Sensors” notebook, within ToonTalk’s main notebook. The
controls, being specific to a container, can be found in the back of each container, which can be
accessed in several ways, while the container is being held: pressing “F” for “flip”210; holding down
a shift key and left-clicking the mouse; and, if the user activates the appropriate program
customization option, right-clicking the mouse. Figure 198 present the resulting animation, with a
picture container being flipped to reveal its contents (in this case, it’s empty) and the notebook of
controls flying out of it.
Figure 197 – Flipping a container to access its contents and notebook of controls.
Repeating the flip operation returns the container to its original state, and the notebook of
controls returns to its back.
Table 20 presents an assortment of sample controls and sensors, selected for the purpose of
presenting the varieties of this kind of elements. It should be noted that sensors and controls
commonly present some animated cue, in order to render them distinct from regular, static-looking
objects. Pads have a “light marquee” outline, and picture controls flash regularly, for example.
209
There is a possible inconsistency in this distinction in that some sensors, such as the looks of the current house, are in
fact local to a ToonTalk element.
210
Localized versions of ToonTalk employ different keys. For instance, the European Portuguese version uses “V”
since the word is “Virar”.
214 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
SAMPLE PICTURE CONTROLS
Readable /
Image and name Description Possible values
Writable
Distance from the left side of the containing
image or viewport211, measured from the
center. Writing to it (dropping a number pad Rational
R+W
on top or editing with the keyboard) changes numbers.
the horizontal position of the picture.
211
When a picture is on the floor, rather than on top of another, ToonTalk coordinates are relative to the area visible to
the programmer, from 0 (leftmost side) to 1000 (rightmost side), and 0 (bottommost side) to 1000 (topmost side).
Images placed outside of the currently visible area have coordinates that are either negative or greater than 1000.
212
The “collision” and “no collision” pictures are animated icons, displaying a ball hitting or missing a wall,
respectively.
213
If the format of the original picture file does not support transparency, ToonTalk uses black as the “transparent
color” for this sensor.
Front of picture
Shows which
subpictures are part of
Array of
this picture. Dusty can
containers:
be used to access these R
pictures, number
subpictures and
pads, text pads.
manipulate their
contents or controls.
SAMPLE TOONTALK SENSORS
Readable/
Image and name Description Possible values
Writable
A text pad
indicating the
Indicates the key that was most recently
R letter.
pressed on the computer system’s keyboard.
Any integer
The value of this sensor is constantly
R number between
changing, in pseudo-random manner.
0 and 999.
214
If the persona is standing up, this affects the entire persona; if the programmer's persona is flying in the helicopter,
this affects the entire helicopter.
3.4.1. Computability
Computer programming concept Preschool education connection
Not all conceivable functions can be At times, the computer may seem to be a
implemented with a computer. Some are “magical” object. Obviously, it is not such a
mathematic impossibilities215, others can only thing, but a technological object. Children can
complete in a time longer than the life of the learn about inherent limitations in computation,
universe (Mitchell, 2003, ch. 2), or require more realizing that the computer is just a machine,
storage space than the number of particles in the with real-world limitations.
universe216.
Activity guidelines
By involving children in the design and planning of activities that employ the computer,
opportunities are likely to arise for addressing the matter of what a computer can, and cannot
achieve. But this is a tricky matter, particularly for preschool teachers or any educator without a
strong computer science background. There is the serious risk of confusion between what a given
computer cannot do, for lack of resources, and no computer at all can do. In the physical-world
field, preschool teachers risk electing to state that computers cannot do something like, for instance,
turn on and off the lights – while, in fact, they can, with adequate interfacing materials. Even things
like deciding if a person is “pretty” or not are not safe to address: they include a large degree of
subjectivity, but also a large degree of measurable real-world phenomena, such as facial
proportions, symmetry, etc.
One option for educators to avoid this problem is to focus computer limitations entirely on the
field of human cognition: a computer can’t answer questions such as “am I a good person?”, “do I
mean well?” etc.
As an example, the following events took place in December 2004, while one of my college
students, from studies in Early Childhood Education, set out to program an activity where children
would have to match generic geometrical shapes to those composing a picture. For instance, in
Figure 198 the arms are rectangles, so green rectangles from the left should be dropped on top of
each arm. Halfway through, she was troubled that children might want to drop a circle on the clown
body, but by accident drop it on the head instead, and since both shapes are circles, a match would
occur. She had partially worked around the situation by using circles of different colors, but still,
there were times when that solution wouldn’t suffice (identical shapes for the left and right hands or
arms, for instance). As things stood, dropping a shape on an unintended place might cause positive
feedback, something she didn’t intend to happen.
215
Like the well-known example known as the “halting theorem”: creating a function to determine whether any given
program will terminate or not (Mitchell, 2003, pp. 14-15).
216
It can be argued that this limitation (storage space) is not independent of the previous one (execution time), because
in order to use a storage location, a computer system must also access it. However, in common computer systems,
storage space must be allocated before being accessed, and the complexity of the execution of an allocation operation is
often independent of the actual amount of storage being allocated. Therefore, one can imagine a situation where the
execution would take place in a viable amount of time, but the storage requirements are a physical impossibility.
217
The following dialogue is presented from my personal recall. It was not recorded or accurately transcribed in any
way, and as such only reflects the content of the dialogue, not the actual exchange of words that took place.
220 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
Figure 200 – The robot is picking «the fourth element», not «the “2”» nor «the last».
218
Taking a box out of ToonTalk’s toolbox (a.k.a. Tooly) creates an array. Connecting boxes is ToonTalk’s syntax for
creating larger arrays or joining arrays. A box inside another represents an array within a cell.
222 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
219
In my ToonTalk ontology, a template is an infinite stack from which one can pick up newly-created objects. Infinite
stacks are commonly found in notebooks and in Tooly the Toolbox, but the programmer can also create them using a
keyboard shortcut.
220
ToonTalk provides three methods for copying: using Maggie the Magic Wand to copy; dropping the object to be
copied on a bird linked to several nests; and clipboard copy using keyboard shortcuts.
221
In more general terms, one could however imagine a version of ToonTalk were the matching of a robot’s thought
bubble becomes visible: for instance, a robot could go to each hole in turn and use scales or some other method to
explicitly compare the contents of the box with its thought bubble. However, such approaches cannot ultimately render
everything visible as unequivocal events for a human to interpret. The broader concept is that the entire meaning
perceived in communication involving human beings cannot be determined solely by the elements of syntax that
compose that communication; the meaning of an expression employed in human communication depends on
interpretation – semantics – and context – pragmatics (for a summary of these concepts, vd. Brown, 2001).
222
This example was built around a “pair matching” game designed by two of my college students.
Figure 201 – In this city, children can tell which houses are “theirs”.
223
This occurred in a programming session at the early stages of the field work; it violates the preferred programming
style developed subsequently.
224
ToonTalk users at several computers can communicate by sharing birds, and this can be used to produce objects that
change according to remote operations. However, this method offers some amount of complexity and is not as general
has having access to a truly multi-user programming environment, such as MOOSE Crossing (p. 172) or Pet Park (p.
182).
230 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
Figure 206 – Teaching a robot to create several houses, each with a different Euro coin.
225
The concept of “statement” was presented in section 3.4.4.
Figure 208 – Different execution speeds: the bottom robot finished first, this time.
3.4.15. Recursion
Computer programming concept Preschool education connection
Recursion can be understood as a The use of recursion is associated with the
definition that is, at least partly, defined in terms ability to recognize, use, and define patterns and
of itself: “In general (…) the routine for a models: “(…) contemporary thought views
recursive function uses itself as a subroutine” learning as a person's ability to construct new
(McCarthy, 1960, p. 193). A common example knowledge based upon what they already know
of recursion is the definition of the mathematical or believe to be true (…); in short, the ability to
factorial function (n!) as: perform model-based reasoning based upon
n! = {if n=0, result = 1; else, result = n × (n-1)! } reflection (actually 'recursion'), and
metacognition” (Reilly, 2002, my emphasis).
Recursion can also be employed in speech,
The use of recursion in preschool and
as in “to clean a house, starting from the main
kindergarten is initiated with the description and
door, you clean the rooms you can reach
application of simple patterns: “In the lower
through the inner doors, and finally the entry
hall itself; to clean those other rooms, you do grades, students can describe patterns like 2, 4,
the same: clean yet other rooms you can reach 6, 8, ... by focusing on how a term is obtained
through room doors, before cleaning each room from the previous number—in this example, by
itself”. Expressions such as “and so on”, or adding 2. This is the beginning of recursive
“over and over again” are commonly employed thinking” (NCTM, 2000, ch. 3, p. 38).
in such uses of recursion. But for these age groups, it is also
In fact, recursion has been tied to the important to employ recursion in non-numerical
ability of the limited-element set of human ways. A well-known example is this imaginary
languages to generate an infinite number of program, Logo-like (Muller, 1998, p. 341):
sentences, by being essential to grammar: TO GET.THROUGH.LIFE
GET.THROUGH.TODAY
« It seems clear that we must regard
GET.THROUGH.LIFE
linguistic competence as (…) a system
END
constituted by rules that interact to determine
Disregarding the use of text, an analysis of
the form and intrinsic meaning of a potentially
actions using recursion, such as this, is at a
infinite number of sentences. (…) Such a system
complexity level usable at the preschool level.
– a generative grammar – (…) defines a
language (…) as “a recursively generated In ToonTalk, a robot can receive a copy of
system, where the laws of generation are fixed itself in its box (or get a copy of itself from the
and invariant, but the scope and the specific main notebook, or use ToonTalk’s magic wand
manner in which they are applied remain to copy itself). A recursive operation is done by
entirely unspecified.” » sending one or more such copies in a truck (a
recursive spawning, in this case).
(Chomsky, 1968, my emphasis)
Activity guidelines
During my field activities, recursion was not a key topic, and therefore I cannot provide
elaborate field-based examples, just the following simple field-based proposals. In these cases,
recursion was employed, albeit not pursued, to create new houses. When teaching a robot how to
build houses, it must put another robot in a truck (Figure 204 and Figure 206). Recursion is
employed if that robot is a copy of the current robot. This means that the new robot is also a house-
builder. The resulting program behavior depends on what the actual robots do, besides building
houses. For instance:
if the robots only build houses at each turn, this method is faster at “filling up” the
city, because at each turn there are more robots building houses at the same time;
if each robot builds a house and blows up a bomb, the result will be a “moving house”.
226
Here, Tony Hoare is referring to a generic concurrent-programming system. But he does acknowledge that
arbitrariness is not absolutely crucial to the use of alternatives: “An implementation should take advantage of its
freedom of selection to ensure efficient execution and good response” (Hoare, 1978, p. 422). ToonTalk’s option is to
prioritize all alternatives (order of robots in a team).
227
By erasing the letter pad in its thought bubble (“any letter”) or vacuuming it (“anything”).
228
If the generalization was done by vacuuming the letter pad from the robot’s thought bubble, the robot will in fact
attempt to put any object on the roof, although only letters, numbers, and pictures work.
236 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
Activity guidelines
A crucial aspect of such activities is how to identify the client making a request, and the
server to whom the request is being made. In preschool settings, this can be made with text
(capitalized names), but the most versatile solutions would be the use of pictures and/or sounds. For
instance, Figure 212 displays several “requests”, in the form of ToonTalk boxes. In the rightmost
hole of each, a picture identifies the “requester”, represented by his/her “hat” (nurse, nurse, baker,
and postman). These could also be sounds for the child to play, achieving the same effect.
Another aspect is how to identify the request. Again, the use of pictures and sounds provides
more flexibility, rather than depending solely on text or numbers (yet, these can also be used). For
instance, in the same figure, the top request comes from the nurse, and it consists of a parcel (first
hole) and a postage stamp (second hole). The text in the third hole simply restates it in written form.
Numbers could be used to represent how many
boxes and stamps are being requested, so that the stamp
picture could stand for as many stamps as desired.
A child can execute “server” actions, responding to
requests, or program a robot to respond, or to produce the
answer. The answers can be delivered to the requesters
manually, but the requests can also include a reply bird,
as shown in Figure 211 (there can be an extra hole in the
request box, for this reply bird, but it can also be behind
one of the pictures). Using such “reply birds”, server
robots or children can answer requests from clients not
Figure 212 – Sorting requests
known beforehand.
229
A description of the Socratic Method can be found in Windelband, 1919.
230
E.g., the Spartan culture acknowledged development stages and considered years from birth to 7 as those prior to
formal education (Lascarides & Hinitz, 2000, p. 5); and Hippocrates “divided man’s life into seven stages” (id., p. 8),
the first of which was “infant (birth to seven years)” (id., ibid.).
233
Including Oberlin’s innovative Knitting School.
234
Pestalozzi (1746-1827) developed an educational method and ideas that anticipated much of modern pedagogy, such
as the fundamental value of knowledge based on experience, experimentation, and direct contact with objects; the need
to ensure that each child finds meaningfulness what is learned; and the use of self-expression as a way to achieve a
deeper intuition of the world. But although he gave great importance to the education of young children, he believed
that such education should most adequately be done at home, in the family, rather than in extrafamilial institutions
(Abbagnano & Visalberghi, 1959, pp. 589-603).
235
Alcott was an American educator who attracted controversy towards his teaching after publishing a book called
“Conversations with Children on the Gospels”, with chapters such as “Conjugal Relations” and “Gestation”. The book
“attracted unfavorable attention from Calvinist clergymen and some journalists. (...) The public did not forget the
controversy (...)” (Crouch, 1991).
244 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
however, several private initiatives were created after the British model of Owen and his followers,
and were called salle d’asile. These flourished and were gradually taken over by the state. In 1848,
a French Law recognized them already as “establishments for public instruction”, and called them
écoles maternelles, although this name would only become commonplace in 1881 (Gomes, 1977,
pp. 15-16). Today, France’s preschools are still known as “maternal schools” (Ambassade de
France au Brésil, 2002).
The second major historical root of modern preschools appeared
roughly 20 years after the opening of Owen’s Infant School in New
Lanark. In 1837, the German educationalist Friedrich Wilhelm
August Fröbel created in the city of Blankenburg (Thuringia,
Germany) an educational institution for young children, his
Kleinkinderpflegeanstalt (“institute for infant care”), a name that, at
the time, was commonly used in Germany for such institutions. But
given that his views on the education of young children were quite
different, three years later he renamed it as Kindergarten (“children
garden”), a name that attempted to summarize those ideas: as plants in
a garden, in harmony with nature and under the care of experienced
gardeners, so should children be raised (Gomes, 1977, p. 17). His
methods and views had a strong and widespread influence in the Figure 215 – Friedrich Fröbel
Western world. 1782-1852
From: http://www.froebelverein-
« We grant space and time to young plants and animals keilhau.de/assets/images/db_images/
db_froebel24.jpg
because we know that, in accordance with the laws that
live in them, they will develop properly and grow well; young animals and
plants are given rest, and arbitrary interference with their growth is
avoided, because it is known that the opposite practice would disturb their
pure unfolding and sound development »
(Fröbel, 1826)
Fröbel had studied the pedagogy of Pestalozzi. Like Robert Owen, he visited Pestalozzi’s own
school in Switzerland but his contact with Pestalozzi was much longer than a mere visit (1805 and
1808-1810). During his early career, between 1816 and 1835, Fröbel founded and run several
schools and an orphanage, before his interests turned to the education of early childhood, influenced
by the philosophical ideas of Jan Ámos Komenský236 (id., ibid.).
Underlying the pedagogy of Fröbel is the conviction of a profound “unity of reality”: a
profound convergence between physical reality, the human self, and divinity (Abbagnano &
Visalberghi, 1959, vol. III, pp. 609-610). But the modern-day relevance of Fröbel lies in the
methods he devised and sought use in connection with this conviction, rather than in his
philosophical ideas themselves. For Fröbel did not just use the teachings of Pestalozzi, but had
several crucial pedagogic intuitions, which together with his philosophical thinking provided the
base for his then-revolutionary methods.
236
Czech philosopher (1572-1670) better known by the Latin name of Comenius, whose didactic works put forward the
notion of a “pansophic” system of education: “universal by its very nature (…) intended for all men, irrespective of
social or economic position, religion, race or nationality. It must be extended to all peoples, however ’underdeveloped’,
as we say today, they may be (Piaget, 1957, p. 10). This included the notion of education regardless of age. Comenius
recognized four different stages in education (infancy – from birth to age 6, childhood, adolescence, and youth), but
“grasps the fact that the same forms of knowledge are necessary at each of the different levels, because they correspond
to permanent needs; and that the difference between these levels lies mainly in the way in which the forms of knowledge
are re-outlined or restated (id., p. 4). Even young children should thus learn in all knowledge areas. Details of his ideas
in this regard were presented in his 1633 work, Informatorium Školy Mateřski, “The School of Infancy” (Komenský,
1633).
237
Jacobo Rodríguez Pereira (1715-1780), was a Spanish expert in the oral education of the deaf, working in Paris, who
recognized the crucial role of embracing sensory input within the learning process (Plann, 1997, pp. 73-77; Röhrs,
1994).
238
Jean Itard (1775-1838), was a French doctor that specialized on diseases of the ear, as Chief Physician at the
National Institution for Deaf-Mutes in Paris (Plucker, 2003). He is better known for his educational work with “the
child known as ‘The Wild Boy of Aveyron’ (...) and he is recognized today as one of the founding fathers of special
education” (id., ibid.). This boy was a child seemingly aged eleven or twelve, found naked and living alone in the
woods of southern France, modernly believed to have been mentally retarded or autistic; Itard thought otherwise and
developed an educational strategy to educate him, relying heavily on sensory-training and stimulation (id., ibid.). His
efforts had limited success, but he was “the first physician to declare that an enriched environment could compensate
for developmental delays caused by heredity or previous deprivation” (id., ibid.).
239
Edouard Séguin (1812-1880) was a student of Jean Itard (vd. footnote 238, above). He “claimed that he could
change idiots by educating them and, more fundamentally, that idiots could benefit from the effort (…). Once idiots
showed that they could learn, they became worth understanding, and they became worth changing” (Noll & Trent Jr.,
2004, p. 2). His approach used muscular exercises to induce a change in behavior, a method he described as
physiological education (id., ibid.).
240
Social development is partly in the scope of this thesis due to concerns of contextual integration presented in section
6.2 and chapter 1 regarding teacher intervention.
250 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
Gesell built on Hall’s ideas by conducting research in a more
systematic manner, with careful and duly study of children. His
research resulted in the creation of the Gesell Development
Schedules, a set of stages grouping physical, language, personal and
social developments and traits, aimed at children between four weeks
and six years of age. Under the basic philosophy of Stanley Hall and
Gesell, the role of education is to support or avoid obstructing
children’s natural development process, and children should be
assessed to evaluate their level of readiness. The teacher should avoid
presenting a child with a specific theme before the child is ready to Figure 220 – Arnold L. Gesell
approach it (Spodek & Saracho, 1993, pp. 67-68). “There is an inner 1880-1961
timetable which determines the child’s rate of development. Trying to From: http://www.freudianslip.co.uk
/images/arnold-gesell-portrait.jpg
teach activities ahead of that timetable will at best result in only
minor, temporary growth” (Gesell Institute, 2004).
The maturational theory was highly influential during the first decades of the 20th century, but
eventually gave way to constructivist approaches to education in most educational institutions. Its
dismissal of attempts to better a child’s development was criticized for causing self-fulfilling
prophecies, since it may cause parents or teachers to give up on a child by considering his/her future
to be predetermined by genetics and therefore being little point in intervening (Meisels, 1988).
Current early childhood education programs assume that while some children do indeed achieve the
learning expectations without requiring specific intervention, other children require the specific
support and intervention of educators: many children have access routinely to formal and informal
experiences that provide success in learning, but others may not have access to such experiences or
suffer from developmental deficiencies or delays limiting their abilities to relate to them (Spodek &
Saracho, 1993, p. 68).The contributions of the maturational theory that are still relevant in common
modern-day practice are its emphasis on an educational process centered on the needs of the child,
rather than on the needs of teaching, and the concept of progressive child development –
progressive not just in its amount, but also in its nature and qualities.
Another early theory was behaviorism, whose basic tenets have
already been mentioned in section 2.4.3. It mirrors the aforementioned
maturational theory, in that it sees the environment as the main source
of influence on human development, disregarding internal influences.
The ideas of behaviorism developed from classical psychological
research on conditioning, namely classical conditioning principles
derived from the well-known Pavlov’s experiments241.
From those principles, American theorists John Watson (Figure
221, on the right) and Edward Thorndike (Figure 37, p. 66) coined the
term behaviorism and made the first efforts to apply the principles of
conditioning to human learning. Figure 221 – John B. Watson
1878-1958
They focused on controlling the environment to influence the From: http://www.psychologie.uni
-heidelberg.de/ae/allg/lehre/wct/e/
learning and development of each individual, and researched various E11/Bilder_1-1/Watson.jpg
241
“The work that made Pavlov a household name in psychology actually began as a study in digestion. He was looking
at the digestive process in dogs, especially the interaction between salivation and the action of the stomach. He realized
they were closely linked by reflexes in the autonomic nervous system. Without salivation, the stomach didn't get the
message to start digesting. Pavlov wanted to see if external stimuli could affect this process, so he rang a metronome at
the same time he gave the experimental dogs food. After a while, the dogs – which before only salivated when they saw
and ate their food – would begin to salivate when the metronome sounded, even if no food were present. In 1903
Pavlov published his results calling this a ‘conditioned reflex,’ different from an innate reflex, such as yanking a hand
back from a flame, in that it had to be learned. Pavlov called this learning process (...) ‘conditioning.’ He also found
that the conditioned reflex will be repressed if the stimulus proves ‘wrong’ too often. If the metronome sounds
repeatedly and no food appears, eventually the dog stops salivating at the sound” (PBS, 1998).
Unipolarity
Trust
I vs.
vs.
Infancy Premature Self-
Mistrust
differentiation
II Autonomy Bipolarity
Early vs. vs.
Childhood Shame, Doubt Autism
Play
Identification
Initiative
III vs.
vs.
Play Age (Oedipal)
Guilt
Fantasy
Identities
Work
Industry Identification
IV vs.
vs.
School Age Inferiority Identity
Foreclosure
Leadership Ideological
Time Self-certainty Role Anticipation of Identity Sexual Identity
Polarization Polarization
V Perspective vs. Experimentation Achievement vs. vs.
vs. vs.
Adolescence vs. Identity vs. vs. Identity Bisexual
Authority Diffusion of
Time Diffusion Consciousness Negative Identity Work Paralysis Diffusion Diffusion
Diffusion Ideals
Solidarity Intimacy
VI vs. vs.
Young Adult Social Isolation Isolation
Generativity
VII vs.
Adulthood Self-
absorption
Integrity
VIII vs.
Mature Age Disgust,
Despair
This criticism notwithstanding, Piaget's stages of Table 23 are still relevant if seen as
providing a global overview of the evolution of specific thinking abilities, rather than a strict
evolutionary map. Piaget himself may have seen them as more flexible than some of the above
criticism assumes (Papert, 1999b). Also, they’re useful as a background for understanding finer
Piagetian concepts.
In section 6.1, as a result of the field work supporting this thesis, I present several hurdles that
preschool children face when trying to program computers. Those hurdles are presented in light of
existing research on human difficulties in computer programming. However, a different avenue of
research can be envisaged: trying to establish associations243 between Piaget’s limitations, presented
in Table 24, and my hurdles of section 6.1.
Among the above limitations, one is relevant to the overall panorama of this thesis, and that is
the aspect of egocentrism, as I will now explain. As is mentioned in Table 24, one should note that
in Piagetian terminology, this does not refer to the psychological condition of obsession with
oneself, but to the lack of ability to engage in what he calls intellectual co-operation, which
requires one to recognize the existence of different viewpoints and ways of thinking:
« (...) the only valid meaning of egocentrism: the lack of decentering, of
the ability to shift mental perspective, in social relationships as well as in
242
A particular variety of Piagetian cognitive tasks, where one feature (such as length or volume) is kept while other
features change, and children’s perceptions of the transformation are analyzed.
243
Some of these associations may seem almost obvious, but specific research is needed to establish associations that go
beyond speculation. For instance, my second hurdle is “Children may expect human-like interpretation of their
intentions and autonomy in its execution by the computer.” This may seem like an instance of animistic thinking,
but it seems feasible to suggest that egocentrism is also playing a non-negligible role. The actual roles of such
limitations can only be elucidated by conducting further research.
247
Part of Bruner’s thought on knowledge representations was his proposed model of systems of representation: active
representation, by means of acts and manipulations; iconic representation, by means of images used in referral to
specific information; and symbolic representations, by using language or other symbols to represent information and
meaning (Spodek & Saracho, 1993, p. 77).
248
The issue of applying theoretical principles in educational practice is presented in section 4.1.3, and is also discussed
in the scope of the educational use of computer programming in sections 2.4.5 and 4.2.2.
249
A concept one also finds in Seymour Papert’s educational ideas, when he calls for personally meaningful, e.g., "ego-
syntonic" learning projects (vd. sections 2.4.5 and 4.2.2).
264 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
250
Some highlights and a summary of Papert’s educational thought were already presented in section 2.4.5.
Lastly, three other concerns are quite similar between the three approaches of these educators.
These are the preoccupation with the usage of democratic principles in education, which these
thinkers linked to the importance of developing the learners’ motivation, by basing education on
each individual’s interests.
« Individuals, Dewey argued, achieved self-realization by utilizing their
peculiar talents to contribute to the well-being of their community, and
hence the critical task of education in a democratic society was to help
children develop the character, the habits and virtues, that would enable
them to achieve self-realization. (...) Dewey argued that in order for a school
to foster social spirit and develop democratic character in children, it had to
be organized as a co-operative community. In order to educate for
democracy the school had to become ‘an institution in which the child is, for
the time, to live — to be a member of a community life in which he feels that
he participates, and to which he contributes’ (Dewey, 1895, p. 224). »
(Westbrook, 1993, p. 5)
As the above quote indicates, Dewey saw the self-realization of children as achievable by
allowing them to participate in the development of the educational process. This must be seen in the
light of traditional schooling, where children would be ordered to open a book on a given page and
all children were to read the same text. But Dewey also meant it in a more profound way than
simply providing individual attention to each student, as can be seen by his “co-operative
community” concept, mentioned at the end of the above citation. This can be mistaken for an
entirely children-centric perspective, but that is not entirely so; Dewey believed that the teacher had
an essential role in promoting and developing this participation:
« I believe that the child should be stimulated and controlled in his work
through the life of the community. I believe that under existing conditions far
too much of the stimulus and control proceeds from the teacher, because of
251
“EUR” represents Netherlands, Great Britain, Denmark, Sweden, Belgium, Switzerland, and Norway.
268 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
neglect of the idea of the school as a form of social life. I believe that the
teacher's place and work in the school is to be interpreted from this same
basis. The teacher is not in the school to impose certain ideas or to form
certain habits in the child, but is there as a member of the community to
select the influences which shall affect the child and to assist him in
properly responding to these influences. I believe that the discipline of the
school should proceed from the life of the school as a whole and not
directly from the teacher. I believe that the teacher's business is simply to
determine on the basis of larger experience and riper wisdom, how the
discipline of life shall come to the child. »
(Dewey, 1897)
One should notice that, even though in the above text Dewey employs words such as “simply”
to address the role of the teacher, this role as described by him is nonetheless nothing short of
essential. But his description of change in teacher's roles from a quasi-military starting position may
be misleading, potentially allowing an interpretation of his thought as one of lack of self-discipline
and permissiveness. But discipline is a constant care of Dewey; it’s simply that it is a discipline of a
democratic nature, where all must contribute and every contribution is valued.
Kilpatrick followed much in Dewey’s stead, believing that by adopting democratic principles,
a community – even the school community – “encourages its members to become participants in
civic discussions that require concerted, collaborative actions in the name of social justice and
structural change. (...) children are people who are, and ought to be, actively engaged in attempts
to understand and become more skilful in the world in which they live” (Beyer, 1997, p. 11). The
reasoning behind his project method requires each project to be agreed upon between teacher and
student: the crucial point is that “there be some dominating purpose—which of course may not be
observable—in which students wholeheartedly participate” (id., p. 8). This way, according to
Kilpatrick, there is an unification between student's interests and their actions, in the course of
project development: having an inner “want” or desire leads to the creation of an “aim” or “goal”,
which people effort themselves to achieve. There should therefore be an educational effort to create
interest, leading to effort, leading again to interest, a “life process” Kilpatrick calls the “true unit of
study”, “the organism-in-active-interaction-with-the-environment” (Kilpatrick, 1951, p. 14).
Freinet’s educational ideas were not specifically addressing the teaching of democracy, but in
effect lead to the same principles: “The lack of genuine communication effectively condemns
working-class pupils to intellectual banishment from a universe of language that is totally alien to
them. This results in under-achievement and dropping out, and in particular accounts for the anti-
democratic manner in which schools operate. Here too Freinet was a pioneer, to the extent that his
ideas on language teaching called for genuine communication, i.e. for personal expression and a
sympathetic ear” (Legrand, 1993, p. 11). This attention to children was also present in Freinet’s
attention to the personal drives and motivations as essential to learning:
« (...) for him the essence of his techniques is ‘experimental trial and
error’. Schools, of course, are there for learning, but the learning process is
something that cannot be imposed from outside (...). The essential input must
come from the learner himself or herself. The urge to know is aroused by the
obstacles encountered, by gaps in the evidence, by failure to understand and
by searching for what will make understanding possible. To be effective, this
search must be spontaneous, actuated by the internal need of the sector, and
there will inevitably be mistakes along the way. It is by feeling their way, by
trying first one approach then another, that the child and the adult achieve
real learning »
(Legrand, 1993, pp. 9-10)
252
Freinet’s pedagogic approach is usually categorized as part of the French “New Education” tradition (Gal, 1966, p.
37), along with Maria Montessori, who was mentioned in p. 247. This citation was translated from the Portuguese
version.
270 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
High/Scope
This model is strongly based on the child development principles of
Jean Piaget (vd. p. 257). It evolved from a 1962 preschool project by
American psychologist David Weikart (experienced in the education of
children with special educational needs), at the Ypsilanti school district, in
Michigan, USA (Formosinho, 1998, p. 56). This preschool project, known
as the Ypsilanti Perry Pre-School Project (id., ibid.), eventually led to the
development of what became known as the High/Scope curriculum, in 1970
(id., p. 59; Epstein, 2003; High/Scope Educational Research Foundation,
2005). From these origins, the High/Scope model evolved into its current
form.
From its theoretical background in Piaget theory, the High/Scope
Figure 234 – David P.
model applies it in practice through the activity-based learning style, in the Weikart
Dewey and Kilpatrick tradition (vd. p. 266). Specifically, it focuses on 1931 - 2003
providing each child with “key experiences” for his/her cognitive From:
development, as is described below. http://lifeinlegacy.com/2003/
1220/WeikartDavid.jpg
Space and materials
The entire educational environment (e.g., the physical organization of the preschool room)
must be “carefully chosen and arranged to promote active learning” (Epstein, 2003). The children
should have access to several different spaces and materials, and be able to find, use, and return
them independently (id., ibid.). This is achieved by having distinct activity areas within a room, to
allow diversity of curricular approaches, for instance: home area, constructions area, library area,
etc. These do not follow a strict model, but are instead supposed to be organized several times in the
course of the day-to-day educational events. For instance, a trip to the local post office may result in
children wanting to create a post office area (Formosinho, 1998, pp. 68-69).
A specific feature of this model is a set of 58 “key experiences”. These are “social,
intellectual, and physical experiences (...) organized into ten categories that comprise social
development (initiative and social relations), visual and performing arts (creative representation,
movement, and music), reading (language and literacy), and math and science (number,
classification, seriation253, space, and time)” (Epstein, 2003). These experiences are a constant
reference for the High/Scope teachers in setting up the environment and planning, and are also the
basis of a Child Observation Record, which is the main assessment tool of the model (Formosinho,
1998, p. 60; Epstein, 2003).
Time management
The daily structure of the High/Scope model is based on a “plan-do-review” sequence
(Epstein, 2003). The activities themselves are not pre-structured (dependent on the contributions of
adults), but they are also not totally random or totally improvised (dependent on children’s bursts of
energy). The High/Scope model aims to combine both situations, through the plan-do-review
sequence. So, the adult must in his/her activity plan beforehand, right from the organization of the
educational environment itself, from the anticipation of likely events and the thinking through of
how time must be managed, proceeding from this planning to its execution with the children and to
its review. The time management aim of the High/Scope model is that children are aware of an
underlying structure that provides confidence by being known and predictable. It is to be flexible
when needed, but not random, so that a child knows what to expect (Formosinho, 1998, pp. 70-72).
253
“Seriation” is the ability to arrange things in a logical progression. For instance, putting the smaller objects in front
of the larger ones, creating a row with the objects in order from the oldest to the newst, etc.
Reggio Emilia
This model takes its name after the city
of Reggio Emilia, in Northern Italy (Figure
235), where it developed. Its origins,
documented by journalist and teacher Loris
Malaguzzi, lie in the joint creation by several
citizens254 of a young children school, six days
after the end in Europe of the Second World
War, in the Spring of 1945, in the small
village of Villa Cella, near the city of Reggio
Emilia (Malaguzzi, 1998). Several similar
schools were created, and for several years the
various teachers strove to make the citizen’s
efforts worthwhile. Eventually, in 1963, these
Figure 235 – Reggio Emilia location and
previous efforts led to the creation of Loris Malaguzzi (1920-1994)
municipality-supported schools. Photo from: Spaggiari & Rinaldi, 2000, p. 212
254
“I found women intent upon salvaging and washing pieces of brick. The people had gotten together and had decided
that the money to begin the construction would come from the sale of an abandoned war tank, a few trucks, and some
horses left behind by the retreating Germans. ‘The rest will come,’ they said to me. ‘I am a teacher,’ I said. ‘Good,’
they said, ‘If that is true, come work with us.’ It all seemed unbelievable: the idea, the school, the inventory consisting
of a tank, a few trucks, and horses. They explained everything to me: ‘We will build the school on our own, working at
night and on Sundays. The land has been donated by a farmer; the bricks and beams will be salvaged from bombed
houses; the sand will come from the river; the work will be volunteered by all of us.’ ‘And the money to run the school?’
A moment of embarrassment and then they said, ‘We will find it.’ Women, men, young people - all farmers and workers,
all special people who had survived a hundred war horrors – they were all dead serious. Within 8 months, the school
and our friendship had set down roots” (Malaguzzi, 1998).
typically involve many children in a common project, often requiring enough space for the
development of large structures, e.g., an enormous dinosaur (id., p. 109).
Children use traditional educational materials, as one would expect, but the contact with
various forms of personal artistic expression is central to the model’s activities. Art is not the focus
of the schools, one must realize. It is extensively used in order to empower children with many
different forms of expression – expressive languages – allowing them to work upon a theme or
255
I.e., “elementary”, “primary”, “basic”, the actual nomenclature varying accross national educational systems.
256
“Information and Communication Technology”, which includes computers, but also several other types of
equipment, such as digital cameras, cellphones, etc.
257
Recently, the researchers involved in a project to establish the educational impact of teacher training on preschoolers'
learning mentioned how that project provided “hitherto unavailable data and inferences about preschoolers' cognitive,
social and technological capabilities within a technology-enhanced environment” (Swaminathan et al., 2005).
258
This survey study encompasses settings in Bulgaria, Portugal, Spain, Sweden, and the UK.
259
France, Germany, Italy, Portugal, Spain and UK.
260
“IT i skolan”, a Swedish national action program for ICT use in Schools, which ran from 1999 to 2002 (ITiS, 2003).
280 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
reviews (Clements, 1999a; Haugland, 2000; Clements & Sarama, 2002, 2003; Plowman & Stephen,
2003; Paz, 2004; Bostad, 2004; Plowman & Stephen, 2005). A central research-based concept in all
these sources is that “simply providing ICT equipment to schools or teachers will not necessarily
make a difference; what makes the difference is the way in which this equipment and other
resources are used” (Bostad, 2004, p. 4). That is, technology should be “integrated into the regular
learning environment and used as one of many options to support children’s learning” (NAEYC,
1996, p. 2).
Table 25 summarizes the evolution and development of the field and provides a framework
for situating the various educational practices on the use of computers (and ICT in general).
Scaffolding of
Physical and technical
Role of children and adults children’s
arrangements
learning
Only one computer is
available for children to use,
at the teacher’s discretion.
Children seldom use the computer, Teachers stop
Only a few software programs
nor do teachers encourage its use. engaging themselves
A low level of are available, the software is
Teachers often take a controlling once children are
quality unconnected with the current
(“isolation”) and instructing role, partly to self-sufficient and
classroom themes and topics.
ensure that all children have equal have learned basic
The child operating the
opportunities to use the computer. ICT skills.
computer has his or her back
to the other children and is
not involved in their activities.
Sitting together in front of a
computer, children help each other,
negotiate turn-taking, collaborate,
and tutor each other. Children
The computer is relocated communicate, discuss strategies,
The computer is still
into a more central position solve problems, and have fun
not an integrated
among other classroom together while they use games and
part of other
activities. educational programs.
activities in the
Computers and other ICT Children develop different strategies
preschool. Its uses
A good level of equipment (such as digital while learning to handle the
can be described as
quality cameras) are available for computer and/or different programs.
(“integration”) learning by doing
children to use. They ask friends, experiment, guess,
various activities on
A range of software programs move the mouse aimlessly, use help
the computer,
is available, including functions, and explore by themselves
compared to
pedagogical programs, or with friends.
learning through the
creativity/multimedia Teachers encourage children to
computer.
programs, and games. send email, use the Internet for
information, and write or illustrate,
or lay down soundtracks and
narration for their own stories on
the computer.
Children use computers and Children explore new topics, are Teachers interact
ICT equipment throughout the creative in their search for with and guide the
day as a multifunctional tool information, ask questions, and children. They
that is integrated with other express their reflections and feeling. create possibilities
A high level of
activities and themes. Practitioners and children use in which ICT can be
quality
(“immersion”) Children learn through the computers to document children’s used to support
computer and from each other activities, make labels and signs as children in
while using a variety of needed, and send messages. developing new
programs or creating their Parents can access information experiences and to
own. while in the setting. expand their world.
Table 25 - Levels of quality of ICT use in an early childhood education setting
From: Bostad, 2004, p. 41
261
The use of computers in this fashion, with teachers, has been frequently associated with the notion of “communities
of practice” of Jean Lave and Etienne Wenger (vd. section 4.1.2, p. 256).
282 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
262
Vd. footnote 53, on p. 92. Piaget’s educational thought is presented in section 4.1.2, p. 257.
263
Papert, 1980, p. 23.
264
The Logo language is described at length in section 3.3.4, pp. 139-146.
267
Formed from the greek root mathe (µαθη), “to learn” (Papert, 1980). One way to see it is to consider that mathetics
is to learning what pedagogy is to teaching.
268
“If one eschews pipeline models of transmitting knowledge in talking among ourselves as well as in theorizing about
classrooms, then one must expect that I will not be able to tell you my idea of constructionism. Doing so is bound to
trivialize it. Instead, I must confine myself to engage you in experiences (including verbal ones) liable to encourage
your own personal construction of something in some sense like it. Only in this way will there be something rich enough
in your mind to be worth talking about” (Papert & Harel, 1991).
270
ToonTalk’s limited editing option of using time-travelling only addresses these problems partially, since children can
re-route the course of actions of a robot, but not actually edit it; however, as I mention in section 4.2.2, ToonTalk does
have editing possibilities in terms of the distributed nature of its programs and the mechanism of behaviors (vd. p. 374).
271
In a more general sense, before the child masters the immediate-response programming system.
272
This research was conducted in 1986, as reported by Clements et al., 1993.
277
A book was published in Russian, on the use of PervoLogo in teaching (Soprunov, 1996), but I have no information
regarding its contents.
278
“Logo Word Worlds are computer-based learning environments, or microworlds, for inductive learning of language.
Children create and manipulate computer animated objects on the display screen by using words of a natural language.
(…) The main goal of the Purdue-Headstart-Apple Project was to explore the impact of computer experience with logo
based Word Worlds on pre-readers” (Hopper, 2001).
279
The Reggio Emilia pedagogic model is presented in section 4.1.3, pp. 273-276.
280
“(…) in my case, at the preschool level (children from age 4) until the first grade (6-7 years) they work with a Logo
util called Facilito (designed by the Educational Computing Center of IBM in Venezuela)” (Estevez, 1998, translated
from the Spanish original).
281
The involvement of older children in the design and development process of technological projects was being
approached in the same year at the academic level (Druin, 1999a, 1999b).
282
During my field work with ToonTalk programming, which I discuss in chapters 1 and 1 of this thesis, I have
witnessed children “forgetting” they were teaching a robot and started playing with it; this observation by Montemayor
and his colleagues may offer another perspective on this issue.
283
Vd. section 4.1.3, particularly the parts on the High/Scope model, for a description of activity centers.
310 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
2004). The studies were centered on social interactions, rather than on actual programming
developments and issues. The article tells how much time children spent constructing, role-playing,
etc. and whether they were doing it alone, with a peer, an adult, or a combination of peers and
adults. The researchers were satisfied with the level of involvement of children with programming
in the kindergarten, where specific sessions were conducted, but not with the level of involvement
achieved in the preschool, since only 5 of the 13 children there got involved (id.).
At the level of robotics programming, in 2004 more LEGO Mindstorms user stories surfaced,
such as an account of a four-year-old having learned how to program a LEGO robot (Rice, 2004).
In Australia, a trial project regarding the use of the Valiant Roamer robot in preschool and
primary school settings was initiated, planned to proceed until 2006, “to establish a developmental
scope and sequence across sectors, common language and underlying skill and concept
development required” (Marsham, 2004).
More information was also published about the Topobo system, which had been created in the
previous year, as mentioned above. Based on the research conducted in 2003, some activities and
ideas were outlined, inspired by Froebel’s kindergarten gifts284 (Raffle, 2004, pp. 74-83).
Researchers have also conducted classroom studies with 25 kindergartners, aged between 5 and 6
years (Raffle et al., 2004), but only for three hours, having focused their research on older children.
However, they did report that all the children involved in the research associated the Topobo
models with “with their ‘familiar knowledge’ about animals and machines” (id.); but their
kindergarten-related information is limited to this: “Kindergartners generally programmed only one
(…) [model]. Some kindergartners puzzled over cause and effect with the programming and
playback, while others understood the interface and playfully experimented with creations and
storytelling” (id.).
Still in 2004, some user
studies for System Blocks (vd. p.
177) were presented, including 5
preschool students (Zuckerman,
2004, pp. 86-91), with ages between
3 ½ to 4 ½ years old (id., p. 86). The
researcher conducted only one
session with each child, lasting
between 15 to 30 minutes. The
sessions were based around
mapping real-world cases such as
water flow (Figure 244) or eating Figure 244 – System Blocks arrangement for a water flow example
From: Zuckerman et al., 2005
cookies onto a system with an input,
an accumulator and an output, probing the child's understanding of system dynamics often. “Out of
the five children, three could analogize the moving lights to water, and two could not. (…) The
three children that could analogize moved on to the cookies example. (…) The 4-year-olds
successfully simulated the model while describing with joy how they bake the cookies and other kids
eat the cookies” (Zuckerman et al., 2005).
So now, in 2005, what information can be extracted from all this history of computer
programming with preschool-aged children, overall?
Not much.
There has been a large evolution of the variety of tools and systems at the disposal of
educators, but research on educational practice at the preschool level has not seen similar progress.
284
The description of these gifts can be found in section 4.1.1.
285
In section 4.2.2, p. 284, I addressed the way in which the lack of programming experience may render difficult the
perception of its significance and features.
286
Here, I’m addressing the typical, narrowly-interpreted way to understand “problem-solving”. But “problem-solving”
can also be understood in a broader, albeit less common, sense: the development of personal approaches and strategies
to deal with the unknown and overcome difficulties. I have no qualm whatsoever with the concept of “problem-solving”
under this perspective.
314 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
of “new ways of thinking and learning” (Papert, 1980, p. xiv) – instead of new ways of solving
problems.
By classifying programming as a “problem-solving” activity, one is disregarding the
requirement imposed by programming to develop strategies to think, to develop strategies to
interpret. Indeed, when “problem-solving” one is considering strategies to approach and solve a
problem, but not to approach the unknown.
In the research supporting this thesis, my concern has been the encompassing of programming
by children, the way to empower them with it, rather than giving them a driver’s license for it. As
was put in 1960 by the pionners of the educational use of computers, at a time when such use would
necessarily involve programming (vd. p. 87), “to use computers better and more wisely by virtue of
understanding them first as general tools to be used in reasoning through solutions of problems per
se rather than as devices to solve particular problems” (Alan Perlis, acc. to Katz, 1960, p. 522).
In view of this concern, I didn’t want my ToonTalk-based research to be just another piece of
limited-scope information on “successfulness of programming by children”, as those provided by
studies devoted to programming systems other than Logo, as I mentioned on p. 312. I wanted to
provide more in-depth data, gathered from larger numbers of children and settings, over longer time
periods than just a few brief sessions with limited numbers of children. And to avoid restricting the
applicability of the field information to children with some command of general reading or writing,
I avoided activities based on any kind of reading or writing beyond the children’s own first names.
Further, in view of the integration of computer use in the context of preschool rooms, I worked with
children aged 3, 4 and 5 years old, rather than just those aged 5 or older, to attain a broader view of
the issues involving computer use in preschool education settings. And finally, also in the scope of
attaining this broader view, I combined research efforts over different settings: in and out of
preschool rooms; working with several children at a time, with just a pair of children at a time, and
with only one children at a time; directly conducting activities with children myself, but also just
providing guidance to educators, to gain insights on the applicability of my research and ideas by
others. My efforts under these directions are described in chapter 1.
In terms of data-gathering and results focus, most research done on preschoolers, since Radia
Perlman’s early efforts took place, was technocentric, mainly concerned with immediate impacts of
the existence of programming than with the actual processes that should guide its use; I wanted my
research to pick up on Perlman’s focus on the processes of using programming, and evolve from
this starting point, by combining the directions pointed by the few later studies that focused on the
educational processes and settings besides programming itself (which I have summarized on p.
313). For this reason, my research contributions are presented in four different parts: section 3.4
contains examples of usage of programming techniques to develop other learning objectives;
section 6.1 provides a structured view on the hurdles faced by preschoolers in the mental process of
programming; section 6.2 provides some insights on issues facing the educational use of
programming by preschool teachers; and chapter 1 provides a framework to help preschool teachers
integrate or embed programming activities and systems in everyday educational settings.
288
This became quite evident in my experience during the research sessions. In those sessions, children often managed
to employ, using ToonTalk, concepts and intentions which they often cannot communicate to the adult researcher or
educator. It also often the case that one realizes that the children are mentally dealing with concepts which they cannot
easily tackle due to insufficient coordination of their gestures, in terms of interface control. Similar experiences have
also been reported by other researchers, e.g., “[Children’s] suggestions indicate that they do not master the language
necessary to only communicate verbally with the interviewer regarding issues of programming. However, through the
concrete properties of the programming environment (“in there”) they may refer to program elements through pointing
and short references without knowing a specific terminology” (Tholander, 2002).
289
Fortunately, as is mentioned in section 5.2.1, the children responded more than favorably to ToonTalk’s
environment.
320 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
enough similarities with the interface distinctions between ToonTalk and Stagecast Creator, for me
to deem this research relevant regarding a selection between the two. It thus can be seen as a late
endorsement of my decision in 2000 (it was only published two years later):
« (...) the children had more difficulties when programming with Squeak
than with TT290. (...) It seemed that pictures and animations were easier to
understand than tiles with text. (...) Perhaps TT and Squeak are designed for
partly different users? »
(Eljaala, 2002, p. 79)
Finally, ToonTalk and Stagecast Creator aren’t completely language independent. For
instance, ToonTalk employs a talking “Martian” as a help system; also, some behaviors of its
controls are language-dependent (the button that makes the bike pump enlarge or shrink objects, for
instance, has command letters on it). And several elements on the Stagecast Creator environment
are also language-dependent. Having these language-dependent elements in English would be yet
another hurdle for Portuguese-speaking children. This also tipped the scales towards ToonTalk,
whose European Portuguese version was launched in May 2000.
290
ToonTalk.
291
Erasing or vacuuming contents of robot’s thought bubble (vd. section 3.3.5, particularly Figure 189, p. 209).
324 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
option to try out specifically these two distinct approaches was an attempt to build my own style –
build up my personal understanding – by reconciling in my personal practice the two major
recommendations from the existing research literature. The first can be summed up as: “if (...) high-
interest software is used, teachers need to offer plenty of instruction, monitoring and guidance for
children” (Early Connections, n.d.); as for the second, it is rather that “The teacher is no longer the
holder and disseminator of knowledge, but rather a questioner, guide and risk-taker willing to
explore, experiment, and incorporate technology into their learning environment” (id., ibid.).
In the course of the following years, I eventually came to adopt an approach of intervention
that was mainly under the coached style (vd. section 5.3), and these initial trials enabled me to do so
with greater confidence and insight, blending both styles according to each particular context and
each child.
The detailed reports I wrote after each of the sessions of Table 28 are presented (translated
into English) in Annex IV, on p. 475.
The children, their pairing, and the preschool rooms computer environment
To ensure the children’s privacy, I will refer to them by their first name initials (Table 30).
PRESCHOOL CHILDREN AGES
SPP Z (boy) and O (boy) 5 and 4
AR M1 (boy) and R (boy) 4 and 5
AA J (boy), M2 (girl) and S (girl) 4, 4 and 5
Table 30 – Children identification and ages
The selection of children was another variable that was influenced by the short time available
to conduct research before the end of the school year. Specifically, I asked the preschool teachers to
select children that had previous experience with computers (freehand drawing, using CD-ROMs,
etc.), so that I could focus as much as possible on programming issues, rather than other initiation
problems. Regarding children’s prior achievements, for these initial sessions I made no particular
specifications, which was perhaps an error: in general, the preschool teachers selected children that
they saw as intellectually above average. The only exception was the incidental inclusion of S, in
the AA preschool. This was fortunate, for the way she overcame her original shyness to devote time
to ToonTalk when she got a chance was an event that contributed a great deal to my confidence and
reassured me that I was on the right track (the circumstances of all this are detailed in Annex IV, on
p. 475).
The computer environments in the preschool rooms of SPP and AA were fairly similar, as
detailed in Table 31. The AR preschool was the only one with a separate computer room, isolated
from the main preschool activities room.
Preschool Computer environment
Windows 98 computer on a table, by the windows, amidst the preschool room.
SPP Usually turned off, but children could use it on call, by requesting permission from
the teacher (Figure 245, right-side photograph).
About four computers with Windows 98 were located in a separate room, adjoining
the gym, which in turn was connected to both the preschool room and the elementary
AR
school (under the same building). Children were not allowed in the computer room
without supervision.
Windows 98 computer on a table, by the windows, amidst the preschool room.
Usually turned off, but children could use it on call, by requesting permission from
AA the teacher. The table was too high for comfortable use with the preschool chairs,
meaning that children would use it while standing up, a situation since corrected
(Figure 245, left-side photograph).
Table 31 – Preschool rooms computer environments
292
This is not fundamentally necessary to accomplish the exchange of pictures, it is rather a practical necessity: with a
large tree, one can't see where it is being dropped, and sometimes it ends on the flower picture or in the wrong hole.
328 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
5.2.4. Preliminary data and information
Figure 249 – the A4 sheet for the robot’s thoughts (with scotch tape) and the A5 sheets for the blue baskets
The robot’s generic behavior was demonstrated to the children again, who were completely
puzzled over it. I then had them initiate the “robot” theatre play. The children used the markers to
draw a flower on the blank A5 sheets, while I drew a tree (Figure 249, right-side image). One child
would play the robot, holding the A4 sheet with the thought bubble over his head; the other would
fill the plastic baskets with the A5 sheets with the pictures and hand them to the “robot”. This way,
the child playing the robot would have to check his “thoughts” content before proceeding, which I
hoped would help clarify the robot’s behavior.
Only one issue was detected: the child presenting the baskets would have a different
perspective of left/right than the robot-playing child! I overcome this problem by acting as “in-
between” trader, turning the baskets around; this would ensure that both children had the same
left/right perspective.
All worked smoothly: they would check the thought-bubble sheet, and the robot would only
exchange the pictures when they matched. However, when I pulled off the taped pictures from the
thought-bubble sheet, leaving only the drawing of an empty box, a curious behavior ensued: the
robot-player started to exchange the images continuously, without looking at the thought bubble to
check their applicability!
While this would indeed be the actual behavior of a ToonTalk robot under those
circumstances, the child’s lack of understanding of what was going on, just previously, makes me
doubt that he was interpreting the contents of the thought bubble as rules for the robot. In my view,
he was just mimicking the apparent robot behavior. Clearly then the concept of “entry parameters”
or conditions, while clear for concrete examples, was completely disregarded for the abstract case
of generalization: The children were not interpreting the behavior of the robot as the result of
rules, but only in terms of its observed behavior.
293
As described in Annex I.
5.3.5. Setting 4
Six preschool computer-activities teachers, involved in the ICEI294 project, received ToonTalk
training, before setting to use it on one preschool room per week each. All children on these rooms
took part. In the first session, the teachers let the children get acquainted with the environment.
Then three different approaches were suggested to the teachers295: -
1. “Straight into programming”. Or “programming as the basic activity”. At the second
or third session the latest, robot-programming activities would be suggested, and other
manipulation activities (enlarging, vacuuming, etc.) would only be practiced as
necessary.
2. “Automated behaviors”. Or “programming as an extension based on automated
behaviors”. Children would explore environments based on cause-effect elements, like
joining a truck, a box and a robot to build a house; playing with automated sensors;
giving objects to carrier pigeons that carry them to their nests; combining properties
and see the resulting behavior of objects.
3. “Acquaintance first”. Or “programming as a development of generic activities”.
Children would gain basic control over the programming environment, enlarging and
shrinking objects, copying them, customizing the looks of the environment, and using
it as a place for conducting usual kindergarten activities: pattern matching, knowledge
of professions, of animals, of cookery, etc. Programming would only be introduced
afterwards, integrated in the environment.
294
ICEI, “Informática em Contextos de Educação de Infância” (Computers in Early Childhood Education Contexts) was
a subproject of a larger Digital Cities & Regions project, “Trás-os-Montes Digital.” Several computer-activities teachers
would spend each day of the week at a different preschool room, conducting computer activities with all the children in
that room. They would return once a week to each preschool room, for the duration of the school year, and also provide
computer training for the preschool teachers, in some evening training sessions (Cruz et al., in press).
295
Mostly, results from these approaches were inconclusive, because approaches 1 and 2 proved more demanding than
expected in terms of teacher preparation, training, and time required by the teachers for activity design and set-up.
5.3.7. Setting 6
After a one-semester course on computer use in preschool, which included the development
of a ToonTalk activity for preschoolers, two second-year students from the baccalaureate in Early
Childhood Education at the University of Trás-os-Montes e Alto Douro, Portugal, embraced my
suggestion to try out their planned activity in the following semester. It would be part of one of their
traineeships, which was rendered possible because their allocated traineeship preschool for the
semester had already been developing, since the start of the school year, a larger project (Teixeira et
al., in press), under which several activities were already being conducted, matching their planned
activity (“professions”). This was the preschool room at Parada de Cunhos, where there is a
computer which is usually turned on and accessible to children throughout the day. Having been
their teacher in the previous semester, I had provided thorough advice, support and guidance during
the development of their activity plan. Before they initiated the actual sessions with children, I
provided them with some extra pointers, but let them conduct the sessions on their own, with no
further contact. I did provide very occasional phone counselling on technical ToonTalk issues, but I
have provided no extra support or guidance on educational issues or on how to conduct the sessions.
The students, named Irina Brandão and Liliana Miguéis296, divided the children into two groups.
With the larger group, their aim was simply to explore ToonTalk generically; but with a smaller
group of 4 children they intended to try out their planned activity. They proposed it to the children
(as mentioned above, under a more encompassing project).
Overall, it was a huge success. The larger group enjoyed ToonTalk but didn’t develop any
particular novel situations. But the smaller group demonstrated that there is a large potential in a
focused, context-integrated approach. The children started exploring the possibilities opened up by
the world they had developed. The various professions exchanged items, using ToonTalk birds:
cakes, flowers, pine trees for planting, etc.; children would come accross situations where a parcel
was wrongly delivered, and would interpret the situation and decide on how to correct it. They set
up and used 12 communication channels (birds), used them, and explored in a rich setting how
different professions would require products and services from one another.
The final report from these activities, complete297 with pictures, is provided in Annex IX.
296
Another student, Mónica Pereira, also took part in the planning, but did not participate in these sessions.
297
The report included a CD-R with pictures, ToonTalk cities, and crash dump files, which is not provided in this thesis.
298
Difficulty in decomposing larger problems into subtasks.
299
Misunderstanding of the implications, temporal or otherwise, of concurrently-executing subtasks.
300
Confusion regarding the properties of specific objects and the relations between different objects.
342 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
Although beyond the scope of the current research, it would be interesting for psychological
and sociological studies to be conducted in order to determine factors influencing both this strong
engagement by children, and this common skepticism by preschool education professionals.
But it must also be said that, throughout the sessions, it would not be uncommon for a child to
lose motivation or became disappointed, when specific circumstances or events would cause
him/her to lose the notion of what could be done, or of what was happening. This is the first hurdle I
chose to present, but rather than just consider it and other hurdles in isolation, it must be kept in
mind that the hurdles can occur in sequence or coincidence, and thus are not just hurdles, but causal
factors that mutually influence each other.
I chose to name these problems as “hurdles,” because I see them as obstacles to one’s
personal progression and development, rather than a payload one has to carry while programming.
And I believe that the now-common habit of labeling difficulties as “challenges” or “opportunities”
would be justly applicable to them.
In hindsight, a major distinction between the interaction factors mentioned previously in this
section and the presented hurdles is that the hurdles often lie at the level of general personal
development, and are not simply technical programming issues or issues of learning difficulty.
Perhaps such a condition should have been expected, given that preschool children are still in the
first stages of their personal development. Thus, planning towards paths to help children overcome
these difficulties can and should involve broader approaches to the development of children’s
cognition, social interaction, and self-attitude. In terms of programming activities, in the next
section I have provided the context in which these general hurdles may appear.
With all these general ideas taken into considerations, as much as possible, I have formulated
the hurdles in a language-independent way, so as to allow them to be more readily mapped and
converted by researchers willing to conduct similar research with other programming environments,
or wishing to explore programming from other perspectives. Such research avenues have already
contributed and may further contribute to better establish the general underlying hurdles behind
programming by preschool children.
1. Children can easily get weary from unforeseen system behavior or difficulties.
2. Children may expect human-like interpretation of their intentions and autonomy
in its execution by the computer.
3. It can happen that during programming (seen as “teaching”, “showing”, or
“explaining”) children combine actual events and actions with fantasies.
4. The concept of sequencing activities can be confusing.
5. Children find it hard to consider the possibility of being wrong and not knowing
it.
Children can easily get weary from unforeseen system behavior or difficulties
Spohrer & Soloway (1986) classification: construct-based & plan-composition
Cognitive: motivation
Jenkins (2002) classification:
Interaction: interest & pace
The immediate consequence of this is that children lose interest or dismiss potentially
interesting paths of exploration. They may return to strategies and activities they feel comfortable
with, until they no longer satisfy them, at which time they may give up on programming entirely.
Such circumstances can be originated by multiple causes, from the complex to the trivial. For
instance, when a ToonTalk picture is unintentionally dropped on another, they are bammed together
and the child is momentarily abducted from her intended path of action. She may be able to vacuum
the dropped-on picture and resume. Or she may not. Or find the situation awkward and abandon it.
Should the child come across system bugs and errors, they may also contribute to this, as may
disruptive actions by other children.
One must be aware that these difficulties are often located mainly at the physical level (i.e.,
fine motricity control), not at the cognitive level. It was not uncommon for children seemingly
unable to execute complex procedures in ToonTalk to be able to “coach” or even “teach” other
children, more skilled on the use of the mouse, to perform beyond what themselves had managed to
accomplish.
Another, more subtle version of this problem occurs when a child find himself/herself in an
uncomfortable cognitive situation. For instance, it’s fairly easy for something to distract children
from general goals. For instance, when a child interrupts a programming activity to perform other
required tasks elsewhere, such as drawing in Windows Paint, that same child may end up forgetting
what was the purpose of the drawing after returning to ToonTalk; or he/she may remember the
purpose of the drawing, but not the current state of affairs in the context of the activity being
developed.
It was fairly normal for children, in such circumstances, to change course and objectives
entirely. The most likely outcome is that further detours from their plans occur, and eventually the
children will find themselves amongst a mess of unfinished ideas and elements.
Teachers and educators must therefore pay particular attention to the setting and development
of goals by/for children. But one must be aware that it can happen for a child to abandon a goal
simply because he/she came across a new focus of interest, not because he/she lost track of previous
ideas and/or status. This, in itself, is not an occurrence of this hurdle.
An approach that helps in this regard is the contextual integration of programming activities
within the general context of activities taking place in the preschool room (Morgado et al., 2005),
which provides mutually-reinforcing contextual support (vd. sections 6.2 and 7.1).
301
In this particular example, it could indeed be changed by editing the notebooks; but the conscious use of that
technique assumes an ability to employ a plan-composition skill more complex than the one being addressed.
346 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
Children expect subprograms to run without being set up
In other words, children often create a small subprogram, but expect the computer or the
subprogram itself to “know” when to run and on which items.
To put it in ToonTalk terms, children expect robots to start working the moment they are
taught, by using the same box that was used to teach them. Children would forget or find
unacceptable that they had to give the robots a starting box.
However, an important factor to consider is that this may be a consequence of programming
based on small sets of actions, which have an immediate and “obvious” application. During the
research sessions, children wouldn’t make this kind of assumption for robots intended to be used in
a specific situation, such as, “when it reaches the new house”, or “when the picture is turned
around”.
Therefore, I believe a useful approach to tackle this problem is to introduce in the planning
phase, before the actual programming actions, elements that cannot be included in the program
itself, such as a schedule, a location, or an external event. Or, in more formal terms: to plan and
develop a context that imposes such conditions on the execution of an activity.
It can happen that during programming children combine actual events and
actions with fantasies
Spohrer & Soloway (1986) classification: construct-based
Cognitive: learning styles
Jenkins (2002) classification:
Interaction: educational novelty
While this situation may seem to be easy to detect, that is not necessarily so. A child may
create a program that seemingly does nothing, or that appears to be composed of random commands
or actions, and such situations provide a clue to the occurrence of this hurdle. However, it can be
masked in minute details and expectations, undetectable unless one probes the child's understanding
and intentions.
For instance, in ToonTalk a child may teach a robot how to pick a box, then drop it, pick up a
picture, move around, put the picture back, put something else in the box, put objects on the ground
and combine some pictures, numbers and text with Bammer. And then, if that child is asked to
describe the robot’s actions, the description can be revealed as an imagined story or a mixture of the
actual actions and fantastic interpretations of them; or even include imagined, invisible events that
are supposed to be occurring between actions. In the particular case of ToonTalk, since
programming is an interactive activity between the child and a robot-persona, this may be seen as
being analogous to doll-playing or figurine-playing with the robots and other programming
elements, instead of programming.
Regarding the detection of more subtle occurrences of this hurdle, it may be wise to inquire
from time to time, asking children to describe the behavior or purpose of a specific subprogram.
As for dealing with it, the research sessions provide little help, for they had not been planned
in a way as to facilitate the detection of this. And the mere absence of this hurdle cannot serve as an
indication that it was avoided: it might as well have passed unnoticed. However, there were specific
circumstances in which children did describe the actual events taking place, and those may be seen
as indications of potential paths for tackling this; and at least one case where a child maintained her
interpretations in the fictional realm, which can provide an indication of what may not work. Also,
one must recall that programs are constructions with an actual existence, and thus must pass what
Seymour Papert called the “test of reality” (Papert, 1999, p. xii): they’re only complete and
successful if they work; “if they don’t work they are a challenge to understand why and to
overcome the obstacles. They can be shown, shared and discussed with other people” (id., ibid.).
Among the specific circumstances that occurred in the research settings, particularly valuable
were situations in which a child would describe the behavior of another child’s robot, as long as it
was simple enough to allow this analysis, and would flatly said that it wasn’t doing the necessary
actions. Asking other children to provide advice was also helpful. Finally, also valuable was the
lack of success of the attempt to make a child realize the situation by asking her to describe the
robot’s actions to the other children, using a comic-strip version of the robot: the child stuck with a
fictional interpretation of the depicted actions, and although the other children soon ignored her
strange story, she nevertheless attempted to tell them the “story of her robot”, never recognizing
that there was no actual story to tell from what was there.
Children find it hard to consider the possibility of being wrong and not knowing it
Spohrer & Soloway (1986) classification: plan-composition
Cognitive: learning styles
Jenkins (2002) classification:
Interaction: educational novelty
It is common knowledge among programmers that hardly any program can be found to be free
of errors. A fundamental skill in the process of programming is precisely the ability to review a
program’s execution, structure and overall operation, and correct any errors that are detected – the
process commonly referred to as “debugging.”
« Debugging is a central part of computer programming. Programs
seldom work when first coded. Many superficial syntactic errors are easy to
find (...). But a substantial number of bugs require concentrated problem
solving. Though various debugging strategies and tricks are often taught in
programming classes, much of the skill of debugging is learned through the
experience of writing programs and getting them to run. »
(Gugerty & Olson, 1986)
Most studies of how children – even preschool children – and novices in general learn
debugging assume that the correction of errors is a natural necessity, and that the main problem is
the acquisition of better overall understanding of the operation of programs:
« (...) young children debugging their Electronic Block stacks were
limited by a lack of understanding about the nature of interactions between
blocks. Older children successfully debugged code stacks, as their obviously
deeper understanding of the blocks allowed them to alter structures to
produce the behaviours they desired. »
(Wyeth & Purchase, 2002)
« (...) the primary reason for the experts’ superiority was the ease with
which they understood what the program does and is supposed to do. (...)
Novices (...) did not have sufficient programming knowledge to focus in on
good hypotheses. »
(Gugerty & Olson, 1986)
However, in the course of the research sessions with preschoolers, I became convinced that
there is a more fundamental issue to address, regarding young children. And that is the very notion
that it is possible to explain something in the wrong way, but without knowing that it is wrong.
During the sessions, while programming ToonTalk robots, most children assumed that a robot
learned exactly what they meant to teach him. They would not consider either the possibility of
having made a mistake or that their actions may very well have unintended consequences. This was
gathered from the fact that often children would not welcome suggestions for “testing” or “trying
out” their robots. I sometimes urged them to test the robots nonetheless, before actually using them
in the intended situation. But in general, children would do so without much enthusiasm, and the
mere suggestion of “testing” usually left children puzzled about the purpose of such testing.
I have not been able to overcome this problem: when robots had an immediate application,
“testing” would occur naturally, since testing and execution would be identical. I can only point out
to research literature on older novice programmers, which recommends that learners of
programming “enhance their debugging skills by completing carefully planned debugging
activities” (Chmiel & Loui, 2004). I therefore propose taking advantage of any opportunities where
preschoolers programs can behave unexpectedly, and help them confront this situation.
302
Annex I provides an overview of these sessions, and Annex I contains all the reports provided by the computer-
activities teachers. Another contribution to my personal construction of these concepts was my experience as lecturer of
the course “Informática no Ensino” (“Computers in Education”), part of the curriculum for the bacallaureate in Early
Childhood Education at the University of Trás-os-Montes and Alto Douro (since 2001).
303
As sessions took place, I would sometimes during the weekly meetings leverage teachers’ accounts as context to
broaden their understanding, including some theoretical background.
304
These were based on children's achievements during the first and second research settings. For example, decorating
houses, building houses, organizing objects on the floor, composing pictures, playing hide-and-seek and exchanging
gifts with birds, and programming robots to perform these various activities, as well as others such as swapping the
contents of boxes or passing a ball around using birds.
352 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
and further actions debated) with an interval of a few days between it and the previous
and coming sessions.
And these short descriptions don’t cover the entire spectrum of support provided. Specific
documents were laid down for guidance, setting forth the data recording style and elements,
explaining the approach styles mentioned in section 5.3.5, emphasizing the importance of
maintaining a given approach, providing examples of activities for each approach style, explaining
the issues put forth in section 6.1, establishing terminology, and providing some ready-made logical
explanations for children’s anticipated questions. (Example: “Why must we stop teaching the robot
by pressing ESC?” – “Because it’s flying, while in the Robot School in the Clouds. If we don’t tell
it to come down, by pressing ESC, all the stuff will fall and on the ground and get broken.”) These
documents are presented in Annex II, on p. 445.
Yet, as I already mentioned in this section, encouraging results were scarce. And this
constituted the most important outcome of the fourth research setting: the awareness that it was not
that the general conditions had not been met (although indeed with plenty of room for
improvement), or that the general approach to teachers had been laid on wrong educational
principles. Rather, as mentioned at the opening of this section, the problem laid on wrong starting
assumptions on the particular nature and features of computer-programming activities with
preschool children and preschool teachers.
Quickly I found out that computer teachers involved in programming were facing some of the
hurdles I had previously found with children. For instance, the very first time they taught a robot –
they did it with an empty box! In other cases, they would be happy to see the children “teaching the
robot”, without caring about what was being taught to the robot, or with what purpose. (In both
cases, instances of the second hurdle mentioned in section 6.1.)
Therefore, a specific strategy was proposed for presenting robot programming (Morgado et
al., 2003a), following the general sequence of activities that compose the classical definition of
programming (Blackwell, 2002): defining requirements; perform a specification; “design the
technical features”; perform the coding; and “anticipate and account for departures from the
intended behaviour (debugging)” (id., ibid.):
Step Challenge question Intended consequence
st
1 What do you want to do? Setting a purpose. (defining requirements).
Define needed objects and assemble them in a box.
2nd What do you need?
(perform a specification).
Execution of actions upon the objects.
3rd How do you do it?
(design the technical features).
Can you teach a robot Demonstrate to robot a specific set of actions.
4th
that? (perform the coding).
(a) Did it learn properly? Emphasize the need to test programmed actions.
If the robot wasn’t properly programmed, or if it
5th Debugging.
(b) What went wrong? doesn’t connect to other objects as expected, discuss
the reasons and possible solutions.
Table 34 – Strategy devised for teaching robot programming
The teachers found this set of question helped them see programming in a clearer way, but by
the time I developed it, they didn’t manage to try and evaluate its impact and usefulness with
children.
Another problem the teachers faced was that they found ToonTalk and programming to be so
different from what they were used to do, that their activities would end up closed within ToonTalk
and its environment, disconnected from everyday preschool activities, to the point of sometimes
there being no sense of purpose for the activities, beyond ToonTalk itself. In one case, for instance,
a teacher was conducting activities with birds and nests, having been told that she could focus,
305
Besides the brief descriptions in sections 5.3.7 and 5.3.8, further information is provided in Annex I (final report on
the activities conducted in setting 6) and in Annex I (full logs detailing the activities conducted in setting 7).
354 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
306
This quote is part of the overview of these sessions, provided in Annex VII, and the full reports are provided in
Annex VIII.
307
They may also be phtographs of real animals, taken or selected by children; or photographs of physical clay pieces or
other products of child play; or even, scanned pictures of cartoon animals, as long as the children are involved in their
selection and production.
Figure 251 – Fruit cards and toy fruits, usable in preschool activities
From: http://www.hifivelearning.com/images/fruitVegCart.jpg and http://www.toy-choice.co.uk/graphics/refAgentaFruitinTray2.jpg
The idea being presented here is: in the context of an activity that was planned to take
place off the computer, the computer may be integrated, by turning it as a source of pieces to
be used off the computer.
Other examples of uses in this
fashion include using the computer as a
tool for recording the status of an
activity, as is shown in Figure 252
(using it in the same way as a paper
table posted on the wall, children can
check those records to determine their
current status later on), and using the
computer to communicate by e-mail
with another organization (and then
wait for an answer to arrive).
Figure 253 – City with houses for three professionals (plus a "pictures" house)
Figure 253 and the other figures in this section are from an activity developed308 in the
ToonTalk programming environment, based on the concept of interchanging services among
professionals (this was part of research setting 6, described in section 5.3.7). The example presented
in this section is based on this activity, but extends it in various ways, and this extended version is
presented in full description in Annex XII. It is intended for use in a preschool room where the
overall theme/project “professions” is already being developed. The mailwoman needs bread from
the baker, who needs shots from the nurse, who needs letters and bread...
Children can develop many activities under the
context of that general theme/project, and in that process
assemble several pictures associated with professions. For
this example, I’ll consider the professions of mailwoman,
baker and nurse. The pictures can be uniforms and items
such as stamps, pastry, bread, etc.
Some of the assembled pictures (originating in Web
sites, books, children’s drawings, etc.) can then taken into
the ToonTalk environment, available for the children to use,
along with other pictures brought in by the teacher (Figure
254). Each group of children, having been acquainted with a
specific professional’s “tools of the trade”, can use the Figure 254 – Postwoman's items and
pictures to decorate a house for that professional (this was uniform
also done in the Mondrões preschool, during research
setting 4, vd. section 5.3.5).
So far, nothing renders this activity different from the previous examples. But this decoration
is just the activity preparation; the actual activity kernel takes place afterwards.
In the course of the preschool day, in another (off-computer) activity, the need may arise (or
be created by the teacher) for a specific product – say, a cake from a baker. The child that needs that
cake can go to the computer, enter the ToonTalk environment and enter the baker’s house. There,
that child can leave a request for a cake. This can take several forms: the number “1”, the text
“cake” and the name of the requesting child; or a picture of a cake and the photograph of the
308
The sample activity described in this section was inspired in a much simpler version of it, developed between
November 2003 and February 2004 by three second-year college students under the supervision of Leonel Morgado
(Irina Brandão, Liliana Miguéis and Mónica Pereira, course “Computers in Teaching”, Early Childhood Education
baccalaureate, University of Trás-os-Montes and Alto Douro, Portugal), and further developed and assayed with four
children during a traineeship, as described in section 5.3.7.
364 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
requesting child; or the picture of a cake and an object representing the profession role-played by
the requesting child!
For instance, in Figure 255 several requests have
been found at a house: top to bottom, there is a request for
a parcel and a stamp from the nurse (identified by the
nurse’s cap); a request for a cookie, also from the nurse; a
textual request for band-aid from the baker; and a request
for a medicine shot from the postwoman. Clearly, some of
these requests must be in the wrong house, since no
professional can deal with them all (unless some child
was role-playing a services contractor!).
These seemingly “wrong” requests pose a nice
learning opportunity. Supposing this is the nurse’s house,
Figure 255 – Set of requests in a house
the two bottom requests can be satisfied, but the others
shouldn’t be here, but rather taken to the appropriate houses (postwoman’s and baker’s). This can
be used to start a preschool-wide debate on the organization of requests within a house. Should
one’s own requests be kept alongside requests from other people? Should one keep a “record” (i.e.,
a copy) of the sent requests, and if so, should that copy by stored alongside external requests?
But what if this was another professional’s house (a truck driver’s house, for instance)? This
child could call the child that placed an inadequate request there, and together decide how to solve
the problem. However, the teacher could also take part, by prompting the child to decide how a
wrong request should be handled. Should it be ignored? Should it be returned to the sender? Should
the sender (the real child, a preschool colleague) be called so that he/she could learn about the
mistake? Should the request be helpfully forwarded to the proper professional? And if so, should a
note about the mistake be sent to the child who made it?
Getting back to the original request in this example, there was the need for a cake. A child
would compose such a request, and place it in the baker’s house. Other requests would also have
been made during the school day. Sometime during the school day, the child playing the baker will
go to the ToonTalk environment and find that there is a request for a cake. That cake can be
delivered to the house of the child requesting it, who later will find it has been delivered.
Having been fulfilled the request for a cake, the teacher can be notified, and this can lead to
another off-computer activity. For instance, a toy cake, a cake card, cake token or something to that
effect can be handed to the child, for continuing with the activity that originated the request for that
cake.
But there may not be the necessity for a physical cake token at all! The consequence of
delivering the cake in the ToonTalk environment may be that a check mark is painted in a
classroom “today’s To Do list”; or that beans of toy money needs to be exchanged to “pay” the
baker for that “virtual” cake!
The overall idea is: a computer environment can be used not a starting point or ending
point of a specific activity, but simply as yet another educational play setting in a preschool
activity room, completely integrated in the context of other, off-computer activities taking
place there. Actions off the computer can require a computer action to be complete, and a computer
result can lead to off-computer consequences.
309
This example was inspired on a ToonTalk activity developed under my counseling, between October 2004 and
January 2005, by two second-year students from the course “Computers in Teaching”, Early Childhood Education
baccalaureate, at the University of Trás-os-Montes and Alto Douro, Portugal (Maria Fernanda Figueiredo M. Silva and
Susana Maria Alves Faria).
310
In Figure 256, the students adopted a different approach: to have a central “bazaar” usable by all children. However,
if children don’t have their own place to customize or use as a base for activities, the development of activities is
seriously limited, because each child lacks adequate control over the events of at least some part of the virtual city.
366 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
than having the child-court-caretaker to be there whenever another child wants to “play tennis”, that
child-caretaker can be suggested (or come up with the idea) of making a ToonTalk program (or
several) to do the necessary comparisons311!
This setting places children in a situation where there is a nice motivation for the development
of the interactive, animated cartoon-stories of ToonTalk programs. The programs can be as simple
as asking, using a pre-recorded sound, “Did you bring your racket?” The child wanting to play
tennis presents his/her racket and if the comparison succeeds, then a pre-recorded sound can state
“you can play.”
After playing tennis, the child can proceed with whatever was required by the activity that
originated the tennis session (for instance, recording on paper that one tennis session was performed
during a specific weekday).
Another way to conduct these activities is for the robot-caretakers to provide an “entry ticket”
or some other token when a child presents the suitable equipment, and such tokens can then be
presented to the preschool teacher or child acting as referee, or even printed, and used to access
some other off-computer activity.
The overall idea is that within an integrated activity there are often opportunities for
including programming embedded in a larger context. Not just for a purpose, but for a
purpose within a context. Programming in such conditions becomes a tool for automation of the
environment – an empowering concept.
311
Currently, ToonTalk provides no primitive operation to check for the presence of an item within a list without
iterating it. This prevents a generic “matching” robot from being programmed by virtually any preschoolers. However,
the problem is simplified by instating the rule that the robot’s thought bubble is not to be ignored, i.e., children should
present the sports equipment in the exact same order it is asked. This is far from being a perfect solution, but is it a
usable solution nonetheless.
Figure 258 – “Bird’s mass”, by J (boy, age 5), AA Figure 259 – “Painting”, by J (girl, age 3), SPP
preschool, 2001 preschool, 2001
Figure 260 – “Flower garden”, by DU (boy, age 4), Figure 261 – Personal composition on the wall, by J
SPP preschool, 2001 (girl, age 4), SPP preschool, 2001
In a tangible programming system such as the Valiant Roamer (p. 172), this can involve
extremely personal customizations, involving physical items and actions. For instance, in research
setting 4 (described in section 5.3.5) the computer-activities teacher at the Mondrões preschool let
children customize ToonTalk, creating a “city of professions.” This was a larger school-wide
project, under which conducted many activities, some of them with a Roamer robot. Before those
activities were initiated, however, children participated in the construction of cardboard houses, one
for each professional, and they customized “turtle shell” for the Roamer robot, for the robot to
“role-play” each profession (Figure 263).
Figure 263 – Roamer robot in disguise: flower seller, firewoman and chef
From312: João-Monteiro et al., 2003
312
These photographs, made public by João-Monteiro et al. (2003) as generic customization examples, were actually
devised by the computer-activities teacher, RC, at the Mondrões preschool, as described in this sections’ text, and
customized by the children there, under the project “city of professions”.
313
After performing this activity, some children, following a suggestion from the computer-activities teacher, taught a
robot how to perform the matching for this particular case (not for any general case).
370 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
Another activity on the theme of sorting and organization is grouping. This can be achived
visually, simply by bringing order to a disorganized set of elements. For instance, in Figure 266, on
the left picture there are many scattered objects. Using the hand of ToonTalk’s interface314, children
can bring order to this, separating the pictures into thematic groups. On the right-side picture of the
same figure, for example, the objects were aggregated into “animals”, “fruits”, and “farm tools.”
This example is from the sample315 activity presented in Annex XI.
314
The background picture of a tree is covering the entire ToonTalk viewport.
315
This example was inspired on a ToonTalk activity developed under my counseling, between October 2003 and
January 2004, by three second-year students from the course “Computers in Teaching”, Early Childhood Education
baccalaureate, at the University of Trás-os-Montes and Alto Douro, Portugal (Elisabete Gonçalves, Ercília Carocha, and
Sónia Carvalho).
316
ToonTalk notebooks can be used for list manipulation activities, by placing an element on each page.
Figure 268 – Moving a Stagecast Creator character using the mouse, instead of programming rules
In many programming systems and environments, however, this approach does not stand out
clearly. On some cases, such as some implementations of Logo (p. 139), the manipulation of data is
done by issuing system commands or some other method of program specification, in which case
one is employing the usage typology no. 4 (vd. section 7.3.4). On other cases, such as Squeak Etoys
(p. 146) and some tangible-programming systems such as Electronic Blocks (p. 175), the
manipulation of data implies changes in other environment elements, in which case one is
employing the usage typology no. 3 (vd. section 7.3.3).
But often tangible programming systems allow for this style of “data manipulation” in a sense
similar to the Stagecast Creator example, above. When the elements of a tangible-programming
system are themselves programmable, as in the case of the Valiant Roamer (p. 172), the children
can reproduce the intended movements and actions of those elements, in fact “rehearsing” the
intended results of programming. But this rehearsal can be done even before children are aware of
the available commands, or only aware of their limitations (e.g., “the Roamer cannot jump”), and
this is why I have chosen to consider such activities as part of this typology.
Figure 269 – Bird cloning itself to deliver an ‘A’ into several nests.
There are many ways to use this bird behavior. For example:
to create, rapidly317, a large number of copies of several objects;
to conduct activities involving the distribution of objects by several different
locations318.
Other readily employable activities in ToonTalk are house-building (by combining a truck, a
robot, and a box) and house demolition (by using a bomb inside a house), both of which (as
reported in the various research sessions) were a widespread success among children (vd. section
5.3). Yet another ToonTalk activity in this fashion is comparing numbers with scales (to interpret
the resulting tilting of the scales).
One particular kind of ToonTalk activities also falls under this typology, albeit not being
usable with most children in preschool settings, due to its current reliance on text and numbers319:
flipping an image (vd. Figure 197, p. 214), taking out some of its controls, such as “Width”, and
observe how the change in the control’s values reflect changes in the image, and vice-versa. A
317
Without programming a robot to copy nests, the child will have to create the copies of the nest by hand using the
magic wand, but this only needs to be done once. Say a child copies a nest four times, getting five nests in all. From
then on, whenever she needs 5 copies of any object, she just has to hand that object to the bird associated with those
nests, to get 5 identical objects.
318
A sample activity using this concept was summarized in section 7.2.4, and is fully described in Annex I.
319
It might be possible to place graphical behaviors on the back of a picture to act as controls, but a nicer approach
would be if ToonTalk allowed the creation of libraries of pictures whose control notebooks had been edited to replace
numerical and textual controls by graphical versions.
Figure 270 – ToonTalk behavior on the back of a picture, with two description alongside
From: Noss et al., 2002
As mentioned in section 3.3.5 (on p. 214), ToonTalk images are containers, which can be
flipped around to place or remove contents from their back sides. These contents can also be
subprograms, performing all sorts of activities and reacting to events affecting the images, which
become “images with behaviors” that can be combined by simply dropping them on the back of
each other. For instance, in Figure 271 the white square acquires vertical movement automatically,
because a “I start moving up” behavior was dropped on its back. And it will bounce off the two
smaller violet rectangles, because of the other behavior dropped on its back, “I bounce off things
when I hit them moving up and down.”
Figure 271 – The white square on the left picture, and two combined behaviors on its backside
From: Noss et al., 2002
In other programming systems, the approach presented in this typology is used by providing
the children with programming elements that interact with other programming elements, responding
to them or making them react.
Figure 272 – Stagecast Creator tutorial: the child must copy monkeys so they get the bananas out of the way
Another Stagecast Creator example is provided in Figure 273: the cat runs and the dog chases
it. However, there is a rule (presented in the middle) that when the dog passes nearby a bush, it
hides behind the bush. Children may try out the behavior of the dog, cat, and bush, and try out
several combinations and settings, perhaps even coming up with a storyline, or “planting” more
bushes to help the cat escape.
Figure 273 – Dog chasing a cat, rule telling the dog to hide behind a bush, and the result
320
In the Stagecast Creator tutorial, at a certain point Bungee’s path is blocked by a gigantic beehive, which when
clicked upon lifts off and lets the bees out (Bungee then runs underneath it).
Figure 274 – Remote control car with Electronic Blocks (identical to Figure 138)
From: Wyeth & Wyeth, 2001
Figure 275 – Robots typed the children’s names many times (on the floor).
Even adults find it difficult to reason under these parameters. This much is a recurrent theme
in programming literature (vd. chapter 1), but I also had the opportunity to construct my personal
first-hand knowledge and notions in several contexts, as described in section 6.2. One specific
support item, developed as a conceptual support for both adults and children, was an inquiry-based
strategy of facing the programming process (Morgado et al., 2003a), presented in section 6.2 (Table
34, p. 353).
This typology maps onto virtually any other programming system, since it represents the
typical entry point found on presentations of the syntax of most programming systems. Notable
exceptions are Stagecast Creator and Squeak Etoys, whose tutorials propose simpler entry points, as
321
This took place in a session during the second research setting, summarized in Annex I and detailed in Annex I.
322
In the Stagecast Creator Tutorial, this is the second activity; in the list of Squeak Etoys tutorials at the Squeakland
site (anon., n.d.-2), these activities are part of the third tutorial.
378 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
8. Final remarks
9. References
Annex I
—
A robot that writes “MARIA”
Figure 281 – Original situation (empty box) and starting the process (giving the box to the robot)
Figure 282 – After the first (left) and second (right) iterations
Figure 283 – During the third iteration, “MARIA” is bammed on the previous contents; result of the third
iteration (center); and after 12 iterations (right)
Figure 284 – After many iterations (no need to wait, just stroll outside the house for two seconds while the robot
works at full speed), taking the name outside, making it tall, and flying over it: the name extends over the sea!
Annex II
—
E-mail exchanges
I don't remember the ages of the children, unless I specified it in the paper
that you have (I haven't looked at the paper recently, so I don't remember
what's in it).
Radia
----------
Hi,
Thanks for this personal account! These are the kind of remarks and
observations that are true gold for what I'm doing, because they provide actual
insights on how things were happening at the time, and how it went. I can find
several parallels between what happened to you and several of my initial
programming sessions in ToonTalk.
1. Did you also worked with children aged 3, or only with 4- and 5-
year olds?
2. Can I include your mail(s) in my thesis, as an Appendix?
3. If not, can I forward them to my advisor, Ken Kahn?
Inté,
Leonel
----------
I'm so glad you're interested! Unfortunately, that work was a long time
ago, and I was more into building the system rather than rigorously studying how
well students learned with it. And although the design was nice, I also built
the hardware, and I am not good at that, so it was very expensive and fragile.
Today I'm sure someone could rebuild the whole thing a lot better, and then have
more studies with students.
My recollection, from the relatively small trials we did on the equipment, was
that 3-5 year olds understood the basic button box (the direct commands) with no
problem. They were relatively uninterested in the numbers (it wasn't that
exciting to be able to say "5 forward" instead of hitting "forward" 5 times).
And they were pretty baffled by the programming buttons.
They did manage to use them to fill the screen with the icons for the commands,
but they were ignoring the turtle when they did that. They'd hit "start
remembering", then hit lots of commands, in particular the light and horn
because those icons were really pretty, and then hit "forget it" and then start
again, all the time ignoring the turtle. And when people tried to get them to
understand the concept of a program, the teacher would say "ignore the
screen...teach the turtle to draw a square...hit start remembering...now have it
draw a square".
They could do this, but when they hit "do it", they were confused if the turtle
turned the wrong way (because that's how they'd hit the commands when they
taught the turtle to draw a square). THey thought the picture the turtle drew
was the program, rather than the sequence of commands.
So that's why I did the slot machine, because physically picking up a "command"
and putting it into the "procedure" seemed like they'd have to understand it.
The slot machine was quite successful with older kids if I remember correctly (7
and up), but didn't interest the 3-5 year olds too much. But there was also not
very much use of the slot machine, because it was so fragile it was often
broken...if it was jiggled the cards wouldn't line up and the machine would read
the wrong commands. And shortly after building the slot machine, I wound up
leaving grad school, and nobody else really picked up on the research.
So maybe you will start where I left off! Good luck, and feel free to keep in
touch.
Radia
Olá,
http://www.ioe.ac.uk/playground/RESEARCH/reports/finalreport/index..htm
--
Tiago Correia
http://www.cnotinfor.pt
Hi Leonel,
I am that Paul, and tried to find some old document that described the FASTR
system, but it's a long time ago and I could find nothing.
Radia Perlman was also inventing systems, one involving rearrangeable cards.
These days, we'd probably use cards with bar-codes on them, but she used
some other technology. Those didn't try capturing the programs in any
child-readable form.
If there's more I can help with, please let me know. Good luck with your
research. I'd be very curious to know more about what you are looking at,
and what you're finding.
--Paul
Hi Leonel,
Your post was passed along to me by Fiedelia Kuang. I have used Stagecast
Creator with my boy when he was 4 and 5 (he's now six). He was able to make
characters move around the screen using the keyboard, he was able to work
through the tutorials (with occasional help), but his favorite part I think was
editing the images. He was a big KidPix user at the same time (and earlier).
Most of the time, we'd work/play together on Stagecast.
Who are you doing it for? I'm interested in seeing the results of your research.
I used to create educational applications in Macromedia Director (years ago). I
have also written on how to program in Lingo and taught how to program in Java.
I've had an interest in how people (young and old) learn to program, perhaps
because I learned as an adult.
Regards,
John R. Nyquist
Hello Leonel,
There was work done last year at Columbia College's (Chicago) Early Childhood
Education dept. directed by Carol Ann Stowe and Val Scarlatta -- I've copied
them here. They designed an Etoy interface appropriate for this age child.
They will present this work at SqueakFest at Columbia just next week -- I don't
know where you are located, but you should try to come!
Anyways...I hope Carol Ann and Val will respond to you directly.
regards,
Kim
Leonel
The most exciting work took place at the University of Chicago Laboratory School
in my daughter Elspeth Stowe-Grant's classroom. She and Val worked together so
that her 4 year old class could use Squeak in their study of Matisse. We have
hours of video that I am going to analyze for patterns, but Val made some very
interesting modifications of Squeak to make it 4 year old friendly. She isolated
and enlarged the tiles needed for the project at hand.
We are working on our presentation for Sqeakfest and a book documenting the
process. We have been working in two other classrooms too - a kindergarten and a
first grade (the next 2 levels here in the States). We will send things along
when they are ready.
Carol Ann
Hi Leonel --
I'm not sure that the PARC internal reports are easy to find -- that was 33
years ago ...
However, I think the best thing is to press on and do a new set of experiments
with fresh thoughts.
Also, check out the kindergartens in Reggio Emilia, Italy. They have done some
very neat things with 3,4,5 year olds, and with LOGO, etc. I will be visiting
there in Sept to see the latest stuff.
Cheers,
Alan
Annex III
—
Reports detailing the sessions of May-June 2000
323
I wanted that later either they or their teacher could easily enter the saved play situation. I feared that by having a
long username this might not work out properly.
324
Rosa, my wife, was the person that performed computer sessions weekly on the preschool. She also used a physical
robot regularly – a Valiant Roamer (vd. p. 172).
325
“Father”, in Portuguese.
460 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
Then, together with O, we placed the flower and the tree in the right position. He handed the box to the robot,
which again managed to swap its contents.
We were crossing the 12 o’clock morning closing time, so I ended up the session. Z knew that we would
continue on Thursday. I let them know that for the next session we were going to teach the robot to swap the images not
caring about their position.
I asked them if they had enjoyed it – well, at least they hadn’t even hinted at being fed up – and they both said
yes while nodding.
Date Tuesday, May 23rd 2000
Participants Z (boy, 5 years) and O (boy, 4 years).
Starting time 11h37
End time 11h58
I arrived as everybody was finishing a small morning snack – today it had started a little bit later than usual.
O immediately said “Now?” showing surprise.
I waited until they were finished, but turned on the computer while I was waiting (but left the monitor off).
Windows’ starting tune drew all attentions. From his table position, O started looking at the computer. Since the image
didn’t show up, he started to grow impatient, even though he was still eating, and started saying “Well?".
Both Z and O were eager to start, and the moment he did, Z immediately moved the mouse to the ToonTalk icon.
This time, I merely held the mouse in place, after he had moved it, so that it wouldn’t budge while he double-clicked.
We talked about the last session, and I was able to confirm that they both remembered what we had addressed.
O landed the chopper; Z went into the house and made Marty go away.
Since we hadn’t saved the robot, we had to program (“make”) it again. I let them do it on their own, from start to
finish, providing only spoken assistance from time to time. Z performed the programming movements, but O was
encouraging him to do them faster ("Come on, pick up the tree!").
The only action I did perform was picking up the book with images from within the larger one.
Full list of actions performed:
Pick up and drop a robot.
Pick up and drop a box.
Pick up another box and drop it over the border of the first one.
Seek a tree in the images book.
Take it from the book.
Set the pump on the "P" for "pequeno" (“small”) and shrink the tree.
(O turned the pump on.)
Place the tree in a hole, in the double box.
O went seeking a flower in the book, took it out and placed it in the box.
The box was handed to the robot.
I called to their attention the fact that the robot wasn’t thinking about anything.
Inside the robot’s thoughts, Z performed the image-swapping.
I pressed Esc, explaining that it allowed us to leave the robot’s thoughts.
We tested the robot.
We talked about how annoying it would be if we had to do this all over again next week; and how it would be
convenient to save the robot in a book.
Throughout this conversation, O said: "Next week, Santa Claus will be coming326", and this sparked a discussion,
because Z picked up on this by saying "Santa Claus doesn’t exist", which was something O didn’t agree with.
They asked for my opinion, which I evaded by replying “Well, as far as I’m concerned, it sure would be nice for
him to exist.” I focused their attention by saying "Well, we are drifting away. The computer is what we’re dealing with,
here."
Then, following my instructions, Z looked for an empty page on the book, and we placed the robot there.
326
In May? Could this have been due to their ideas about “snow” in the robot’s thought cloud?
327
I had read the instructions on how only images and pads, all square-shaped things, would work with birds, and had
checked that bombs and trucks and the like wouldn’t work, but I hadn’t extensively tried out every single available
item.
464 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
Date Monday, June 12th, 2000
Participants Z (boy, 5 years)
Starting time 11h50
End time 12h00
I started by setting up the computer that meanwhile had been taken to the University computer centre for repairs
– it still refused to boot, so I opened it up and sorted the problem out – a disk cable that was way too stretched was the
problem, so I changed its position a bit, so that no random disk or CD-ROM problems would arise. The only tools
available for this job were a screwdriver that was way too large and some pliers. All this meant that I ended up with
little time for the actual session.
O was not present, anyway; so I opted to simply let Z play around a little in ToonTalk, in order for him not to get
much more practice than O.
Z is now almost autonomous: his only difficulty is performing the double-click to activate the program. From
then on, he clicks the play button, chooses one of the figurine buttons and navigates quite well within ToonTalk.
Since we had been saving ToonTalk’s state from session to session, the moment we entered a house we found
the Swappy robot working, swapping on and on.
I asked Z to stop it by holding it. Then, using the vacuum, we cleaned up the house.
We worked solely this behavior: essaying the placement of a nest in a box and giving the box to the robot.
Z picked up a box, but chose to copy it with the wand, instead of picking up another one. After building a two-
hole box, I told him "we can also use the wand on the robot’s thoughts", and showed him what I meant, by copying a
tree and a flower.
Then, we placed the tree on a hole and the nest on another, and handed the box to the robot.
At first, Z thought that the robot was rejecting it, because the left arm was raised. But I called his attention to the
fact that it hadn’t dropped the box.
I said: "It’s waiting to find out what will the bird take to the nest. Try giving it a flower."
"Is the flower a drawing?" – asked Z (he remembered the rule I had instituted in a previous session, saying that
we can only give square things and drawings to the birds – well, I can’t be sure he remembered it all, but at least he did
remember the “drawings” bit).
Since I said it was, he gave the flower to the bird and we watched as the robot performed the swapping. I
concluded the session, explaining that for the next one, we would set robots exchanging things among them, using birds
for assistance.
Date Thursday, June 15th, 2000
Participants Z (boy, 5 years)
Starting time 11h35
End time 12h00
O, again, wasn’t attending the preschool. Therefore, I moved on with Z, on the theme of combining the use of
robots and birds. We started by going over the working of the Swappy robot, after we had placed a nest in one of the
holes.
In order to get the result I wanted, we had to start from scratch, and therefore I asked Z to clean up the working
area, which he did with the vacuum.
I then proposed that Z should make a robot that would receive a flower in a box and a bird in another, and give
the flower to the bird!
He did as instructed, with a trick he had devised before: he picked up and dropped a box; but instead of repeating
the procedure, he used the wand to create a copy.
Programming the robot was easy; it was a simple matter of picking the flower and giving it to the bird.
The robot was tested, without further complication.
I then suggested that we picked up another nest – which Z did. Then, I instructed him to place the nest where the
flower was: “What if we now gave the flower to the bird from the new nest, what will happen?” Says Z: “It will take the
flower to his nest.” “And then, Z?” – I asked. He replied: “The robot will give the flower to this bird, which will take it
to that nest.”
We tried it, and it worked just as Z had described it.
Araucária preschool
Date Monday, May 30th 2000
Participants M (boy, 4 years).
Starting time 11h00
End time 11h17
The preschool educator, Edite, told me that only M was available for the session, because the other kids that
should be present hadn’t come (they had participated on a tour the previous day, which arrived quite late – they
probably were sleeping a few more hours today, she said).
I had already turned the computer on and installed ToonTalk.
I asked M if he knew who I was – he said no, shyly.
He was very shy throughout the entire session, particularly regarding conversation, but never hesitated when it
came to use the mouse.
“But you do know Rosa, the computer teacher,” I asked. He said he did, so I explained (to make him feel more
comfortable): “I’m Leonel, Rosa’s boyfriend.” I carried on: “I’m here to show you a game, in order to see whether you
like to play with it or not.”
I also explained that two other boys, R and L, were supposed to be at this session. He told me that they would
only arrive in the afternoon.
I told him that was all right, because we would all be present next week. But for today, it would be just us.
I showed him the ToonTalk icon. “Do you know how to start a program?” I asked. “No,” he said. “OK then.
Take the mouse pointer over the program icon” – this he did. “Now you’ve got to press the button twice.” He was too
slow for the action to be interpreted as a double-click. “You got to do it faster,” I said. The second time round, he
managed to do it.
Upon the ToonTalk starting window, I said: “This is where we’re going to play. I’ll press a button, to let it know
we want to play.”
I explained to him that we could choose the style of figure we wanted to play with: long hair, with a hat or bald.
He pointed to the “Com chapéu” (with a hat) button.
I asked him if he knew what “this” was, as I pointed to the helicopter on the screen. He correctly identified it as
being a chopper. I then asked “what about that, down below?” – “Those are houses,” he replied.
I encouraged him to move the mouse, and he showed no difficulty controlling the chopper. After explaining what
the buttons were for (go up or down), he also controlled the chopper easily using these movements.
Since he was quite at ease, I told him to land near the houses. First time around, the perspective fooled him, and
he almost landed a street down too far away, but following my indications he went up again and finally landed on the
right street.
He moved the figurine and Tooly, without any difficulty, and following a suggestion of mine, entered the first
house.
I then explained him that the Martian was there to help us when play alone. But that since now I was there, the
Martian wasn’t required, and I was going to send him away.
After I pressed the F1 button, he moved the mouse at will, quite at ease: he even picked up the word “Imagens”
(images) from the notebook. I therefore told him to pick up a box, without any further delay. My intention was to make
him build a two-hole box, but before I could say anything he picked up a letter block.
Well, since he was holding a letter, I told him to drop it in the box. I must say that it was not necessary to tell
him that the mouse buttons were used to get objects – he immediately assumed it (notice that he had originally taken the
initiative of picking up the word “imagens”). I merely told him that the mouse buttons were also used to drop things.
After placing the letter in the box, he was idling, not knowing what to do. Then I told him to pick up a box,
which we did together, my hand over his. And then we picked another box. Always keeping my hand over his, I
explained that I was going to join both boxes, by dropping one on top of the other. The mouse with the hammer came
along – since the boxes were next to the top of the screen, there was enough time for him to observe the mouse.
I noticed that the initial enthusiasm was being replaced by some frustration, because he had no idea of what to
do. I then explained that what we could do on this game was playing by training robots, teaching them.
328
In 2000: Araucária, As Árvores, São Pedro Parque.
329
In the current version of ToonTalk, pressing the space bar only makes the vacuum cleaner work once. But at the
time, it would stay on until the user pressed the space bar again to turn it off (or dropped it).
330
This would have worked in the current ToonTalk version. At the time, robot’s couldn’t be programmed to enlarge or
shrink objects, something I wasn’t aware of.
470 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
As Árvores preschool
Date Friday, June 9th 2000
Participants J (boy, 4 years), M (girl, 4 years), S (girl, 5 years).
Starting time 15h20
End time 15h50
The preschool educator, Gina (with whom I had spoken previously regarding the sessions), was not present when
I arrived at the preschool room. I set up the computer, and called J and M, in order to introduce myself and explain that
we were going to play with a new game, and that I intended to see whether they liked the game or not. They told me
they already knew about that, and they also told me that “our parents were told about it, and they told us we were going
to do something on the computer, both of us and also S”. Well, since Gina in fact had mentioned in passing the
possibility of including other children in this activity, besides J and M, I assumed this information to be correct and
therefore called S and we started the session. Later on, I found out that what the children had told me was not correct.
Due to limited space near the computer, and to the height of the table, chairs were not practical. So, I used the
solution employed in the computer literacy sessions that take place weekly on this preschool: to do everything standing,
without chairs. In order to avoid being at a much higher level than the children, I sat on a table, by the computer.
The mouse on this computer only has two buttons, which cover a mouse area much larger than the one occupied
by the buttons on the mice of the other preschools331. Therefore, children have an easier time pressing them.
This even turned out to be a bit counterproductive: upon seeing ToonTalk, the children (except S) wanted to use
the mouse, to the point of placing their hands on it simultaneously, which resulted on almost random mouse clicks.
Initially, we drafted who would choose the figurine style, using three distinct color pens: each child picked up
one, I scrambled them and dropped them on the ground; the furthest to the left was deemed the winning one.
The chopper was identified as such by M and J, but not by S. All of them, one at a time, had the chance to move
it, and make it go up as well as down. The perspective used raised some difficulties on selection of landing place: they
were always landing on the street above the houses, being tricked by the perspective.
After several consecutive "kneelings" of the figurine on the street, which I always cancelled with the Esc key, we
managed to enter a house. At this moment, they were starting to exchange control more often – Maria was ruling, most
of the time. They were all quite excited, and (or so it seemed to me) without enough focus for any explanation about the
method of robot programming. Therefore, I decided that indeed the best thing would be for us to simply explore the
overall functioning of the software.
So, I started by getting the ball from the images notebook, and showed them how to use the pump to make it big.
In order to simplify operation, the keyboard was shoved to a side and laid vertically, so that the letters would not draw
attention, but the Esc key and the space bar would still be easily accessible.
They immediately started using the pump to make a robot big, very big (until the screen could only present its
legs), and also a very big pair of scales.
Afterwards, I taught them how to use the vacuum to clean up everything.
Without giving me a moment to breathe, they picked up a nest, and I took the opportunity to explain to them how
birds worked. We tried giving all sorts of objects to the bird and watched as it took them to its nest. We created another
bird and this allowed the children to confirm that each bird carries objects to its own nest. A bird was then taken to
another house, in order to make clear that distance from the nest is no obstacle to a bird’s operation. From this point on,
the children started creating bird after bird... We already had 7 or 8 on the screen!
The children were very entertained, but half an hour had elapsed already, so I decided to end the session. They
all told me they had enjoyed it a lot, and I scheduled another session, on the following week, and said that on that
session they would learn how to teach robots.
331
São Pedro Parque and Araucária.
332
This environment bug has since been corrected.
333
I knew I could repair this by copying and pasting an images notebook from another user, but that would ruin the flow
of the activity.
472 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
Date Monday, June 19th 2000
Participants J (boy, 4 years), M (girl, 4 years), S (girl, 5 years).
Starting time 10h30
End time 10h50
This session didn’t actually took place as intended, because all the kids were practicing for the several plays and
games that would take place during the end-of-year party to be held on that afternoon.
We did initiate the session, but there were already cakes and refreshments available, and all the kids were too
excited to actually be able to focus on ToonTalk.
But I still managed to take these notes:
• I imported a bunny picture, because M wanted to play with a rabbit picture on ToonTalk. After importing the
picture, by dropping the filename on the appropriate sensor, I taught them how to use the wand, but this ended up
copying the sensor, not its contents. Given the situation, I had no opportunity to find out how to overcome this334, and
so I decided to let them go rehearse the plays and eat cake with all the other children.
• S, even though I already had dismissed them, decided to stay, in order to play with ToonTalk a bit. She mainly
picked up nests to create birds, and moved several toolbox objects around, using the pump to enlarge and reduce them –
I concluded the session after letting her play around in this manner a bit.
334
Only later did I learn that one needs to vacuum and spit the contents of the sensor, not copy them.
Annex IV
—
Details of sessions conducted between February-June 2001
The children
During these sessions, the children were divided into 5 different groups. In each group, all the
children took part in computer activities simultaneously, in pairs.
GROUP 1
A pair of three-year olds. The sessions took place at a specific university room (setting 2, below).
One of the parents would take the children to that room, but wouldn’t be present during the
sessions. From the fourth session onwards, the preschool decided to replace 3-year old R with 4-
year old P, as detailed further ahead in this annex.
These children were selected by the preschool teacher at the SPP preschool.
C (girl, 3 years); R (girl, 3 years); P (girl, 4 years)
GROUP 2
Six children aged mostly 5 (there was a 4-year old, and a girl who had just turned 6).
A specific room was set up for the sessions, in the University (setting 1, below).
Children were brought in by their parents, who weren’t be present during the sessions.
The children were paired, although the pairings were changed informally, depending on the
activities taking place.
These children came from the AA preschool. Those marked with an * were those involved in
ToonTalk sessions, the previous year.
J* (boy, 5 years); M* (girl, 5 years); S* (girl, 6 years);
L (girl, 4 years); G (boy, 5 years); R (boy, 5 years)
GROUP 3
Six children of mixed age (4-year olds and 5-year olds). These sessions also took place in setting 1,
under conditions identical to group 2, above.
The children came from the SPP preschool. None of the children involved in the sessions the
previous year was able to attend.
A (girl, 5 years); B (boy, 4 years); D (boy, 4 years);
J (girl, 5 years); M (girl, 4 years); R (boy, 4 years).
GROUP 4
Six children of mixed age (4-year olds and 5-year olds). These sessions also took place in setting 1,
under conditions identical to groups 2 and 3, above.
The children came from the SPP preschool. None of the children involved in the sessions the
previous year were able to attend.
A (boy, 5 years); AA (girl, 4 years); DA (boy, 4 years);
DU (boy, 5 years); H (boy, 5 years); J (girl, 4 years);
GROUP 5
A single three-year old. Some of the sessions took place at a specific university room (setting 3,
below), while other took place in setting 1, usually before the sessions with the older children.
The child’s mother would take her to that room, and the child would be sitting on her mother’s lap
while using the computer.
This child came from SPP preschool.
J (girl, 3 years).
The environment
There were three basic settings, described below.
Setting 1:
A main room was prepared for the large groups (in the list above, groups 2, 3, and 4). This
had a direct access from the parking lot, a few tables and chairs, and three 15” CRT monitors. The
computers used were a combination of laptops and desktops, but the laptops were equipped with
regular mice. Instead of using the laptop screens, these computers were connected to the CRT
monitors, for better visualization from wide angles.
Setting 2:
This was a meeting room in the engineering building, at the university. It was used by group
1, from the list above. There was no direct access from the parking lot, but a parent would bring the
children to the entrance of the building, from where the researcher would lead the children to this
room. A laptop computer was used, equipped with a regular mouse.
Setting 3:
ToonTalk was installed on a desktop computer, at a University office also used for assessment
of computer-support required by citizens with special needs. This was used in some of the sessions
with the child in group 5, for the convenience of her mother, a teaching assistant whose office was
located in the same building. There was direct access from the parking lot, although this was not
relevant to the case, for the child would often already be inside the building, at her mother’s office.
Group 1
Session 1 (February 12th, 2001):
Only C attended. Initially, she practiced the manipulation of ToonTalk elements, including
the tools and images from the notebook. She wanted to make a house with a garden, which was
achieved using three built-in ToonTalk images: a house façade, a colored rectangle and a flower
(figure on the right).
Session 2 (February 19th, 2001):
Both C and R attended. They expressed their desire to work with “trees, fruits, and girls”, took out these pictures
from the notebook, and proceeded by combining and moving images around. Then I suggested that pictures might be
organized in boxes, and from this they practiced putting things inside boxes and taking them out, and joining boxes.
The two children frequently need my support to handle the
mouse. Usually I need to help them place their hands on the mouse
properly, so that they can move it and click at the same time.
Following my instructions, Rita executed the robot-programming
procedure for exchanging a tree and a flower. Then she did the same for
another robot, to exchange a girl and a ball (C helped her completing
this one).
The robots were tested and afterwards I placed them side by side
near the boxes, which I intentionally mismatched (figure on the
right335). Both girls were able to correctly identify to which robot each
box belonged.
Session 3 (March 5th, 2001):
Only C attended. Due to computer problems (constant crashes for lack of disk space), I ended up only
performing freehand drawing on MSPaint with C, so that she should practice mouse skills.
Session 4 (March 26th, 2001):
The preschool teacher decided to replace R, and the 4-year old P was sent instead. The girls arrived late;
therefore, this session was only 30 minutes long, instead of the usual 40 to 50 minutes.
335
In this and subsequent figures, occurrences of the children’s names have been grayed out with a diagonal pattern
( ).
478 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
I suggested for C to show P how to use the bike pump. C
identified it, but no longer remembered how it was used. However,
she now managed to use the mouse and ToonTalk without major
difficulties, selecting and picking up what she intended. After C
played around with the bike pump and the ToonTalk objects for a
while, P practiced using the pump to enlarge and shrink nests.
They practiced the use of the magic wand for copying.
C referred to the smaller birds as “baby birds”.
The session ended after both girls tried giving the letter A to a
bird, and seeing it multiply to deliver it to all the copies of its nest
(figure on the right).
Session 5 (April 2nd, 2001):
Both C and P attended. I tried to leverage their use of boxes, birds, and magic wand, by proposing the
programming of a robot that would “make birds”. I demonstrated this: the robot would take a bird, copy it, and give the
copy to the original bird, so it would be taken to the nest. The children were not able to understand this at all.
Session 6 (June 4th, 2001):
Both C and P attended. Since there was a two-month gap between sessions, I asked them if they remembered
which game we were playing. They said they didn’t remember. However, upon launching ToonTalk, C said she did
remember it after all.
C practiced the control of the helicopter, with some difficulty: the top-down perspective fooled her and she often
landed away from the houses, but P was able to keep prompting her to correct the movement, and was able to point the
direction of the houses, even thought neither could see them at low altitude.
I explained how to “send away” or “call back” the Martian using the F1 key. Oddly, C didn’t immediately
associate the behavior with the keyboard key, and tried to push the paper keyboard overlay where the Martin was
drawn, just above the F1 key.
They could not understand the text-to-speech engine at regular volume, but they did understand the speech at
high volume, and ensued by repeating/responding to the Martian’s speech: “Good morning/Good morning”, “See
you/See you”. C liked this and spent a few minutes sending the Martian away and calling him back, but P was soon fed
up and asked her to stop.
They both vehemently wanted to make nests, so we proceeded along that line of action. P also wanted to build
houses with a truck – something which I hadn’t shown any of them before, so this idea must have been passed down
from the other children at the preschool, 12 of which did that kind of activity, in other groups.
They proceeded by playing around with the bird’s behavior, giving them objects and figuring out where they
were being taken, what kinds of objects birds carry, etc. After building houses using trucks, I proposed a game and we
took a bird’s nest to a different house, to try and see if the bird would be able to find its nest, still. After confirming
delivery (which they found “great”), I ended the session.
Group 2
NOTE: Three children in this group had prior ToonTalk experience, albeit very limited (3 sessions), in the
previous year.
Session 1 (February 14th, 2001):
For this session, I had the assistance of Rosa Cristóvão.
The children picked up and dropped a large number of ToonTalk objects and controlled the figurine, without
major difficulties. Among the lesser ones: confusion about the different functions of the mouse buttons, while
controlling the helicopter, and needlessly pressing of the mouse buttons while moving the figurine, causing many
unwanted “kneelings”.
For helping J, M, and S remember their prior ToonTalk experience, I suggested that they might want to teach the
robots how to play. J & R gave an empty box to a robot, and my suggestion was for the robot to create trucks (i.e., place
a truck in the empty box). I then suggested that they taught another robot how to vacuum trucks, which J did without
any problems.
Then J wanted to teach another robot – but he couldn’t decide on what to teach it. So I suggested that they
postponed the teaching of the third robot and put the first two to play, instead.
336
At the time, ToonTalk required that children would press the space bar once to start a tool and once more to stop it.
For these young children, this made it too hard to control the process.
Group 3
Session 1 (February 14th, 2001):
All children performed, with only slight differences, the same initial
sequence: land, select a house, go in, kneel, scatter objects on the floor, and
vacuum them. They also did a few freehand drawings (on the right is presented A’s
drawing, she called it “a spider’s web”).
B & D were thrilled about traveling around with the helicopter and
controlling the figurine. The change in perspective when kneeling and getting up
was also enjoyed by them, and they spent a fair amount of time doing these things.
Together, A & M taught a robot how to vacuum bombs, which I generalized afterwards. I suggested that they
might now teach a few more robots any way they liked, but when I came back to see the result, they had only scattered
birds and numbers, and a few boxes (and boxes inside of boxes). But at that moment A taught a robot how to vacuum
the contents of a box that, inside, had another box with a nest.
I’ve shown R & J how to program a robot to vacuum a bomb. Then I challenged them to teach a robot how to
vacuum trucks. R managed to progress and do it eventually, as J watched. But in the end, R couldn’t find out how to
make the robot work, but J did: she pointed R to the right box.
For the remainder of the session, I let them all explore the environment at will.
Session 2 (February 21st, 2001):
J did not attend.
Initially, all children did freehand drawings in these sessions (on the
right is presented R’s drawing). Upon starting to use ToonTalk, they all
demonstrated the ability to notice the wiggling cue provided by the system to
show which object is the "target" of operation.
R programmed a robot that would take two birds with a scale between them, and then would replace the right-
side bird with a truck. D started making houses, lots and lots of houses, manually, and then taught a robot how to build
houses.
The figures below present R’s robot and the result of both D’s work and his robot’s work.
337
The notebook name doesn’t match the programmers’ because they had used the last user’s login.
488 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
Group 4
Session 1 (February 15th, 2001):
The usual initiation activities were used: landing the helicopter, entering a house, taking objects from the
toolbox, vacuuming them.
Right from the start, two children wanted to make freehand drawings. But
they agreed about playing in ToonTalk first, and drawing freehand later (one of
the resulting drawings is shown on the right). But given this situation, I suggested
that all children could now decorate the ToonTalk house they were in. Since this
was the first session, I placed the room sensor on the floor, as well has the images
notebook. Thus they could place elements on the sensor and then get up to check
the overall result on the actual wall.
Afterwards, while A, DU, H, and J did some freehand drawings, AA and
DA started playing with ToonTalk’s helicopter, flying around and exploring on foot with the figurine. When they
entered a house, I suggested to AA that she could teach a robot how to paint the wall. I told her to give the robot a
picture of her own (two overlaid house images), and then, inside the robot's thought bubble I fetched the room sensor
for her. She placed the image on it, and then we left the thought bubble. She and DA then tested this robot with different
images.
Session 2 (March 1st, 2001):
Due to other, unexpected pressing professional matters, this session lasted only 15 minutes. These were used to
let the children practice the ToonTalk environment overall, manipulating the objects and tools as much as possible.
Session 3 (March 8th, 2001):
Fernando Lemos assisted me during this session.
I suggested, as a general theme for the session, for all children to make things
bigger or smaller, thus practicing the use of the pump. I also intended to suggest
tucking the resulting objects in a box.
Led by Fernando Lemos, H and DA played proficiently, creating differently-
sized bombs. Afterwards, they used boxes, and decided that it was funny to be able
to have a very large box, and set out to build one with 13-holes, with many different
objects (see the figure on the right).
DU and AA were trying to monopolize their computers; this was somewhat
of a complication. They managed to use the pump effectively, although still needing a bit more practice. J also
demonstrated having enough control, but lacking willingness, which is understandable.
A was repeatedly taking out object from the toolbox and putting them back in,
and seemingly enjoying himself doing it.
As the session neared its end, AA wanted to draw a garden, but there wasn’t
enough time to do it in Windows Paint, so I suggested that she planted a garden of
flowers in ToonTalk and used this suggestion to allow her to practice the change in
color and size of a rectangle, and change the color of flowers. The resulting garden is
shown here on the right.
Session 4 (March 29th, 2001):
There are programs and screen shots of this session, but no descriptive
document. The children must have chatted in the preschool with the children from
group 3, who by this time had already benefited from 5 full sessions, because they are
exhibiting a very advanced control of ToonTalk elements and even programming
concepts.
A & DU used the magic wand to create many trucks and boxes. So, following my suggestion and instructions,
DU made a robot that would place a truck inside an empty box and A made another that would vacuum a truck from a
box with one. I then suggested that they could join these two robots in a team of their own (see the figure on the right,
above). However, this team wouldn’t work because of the way ToonTalk interprets constraints: the empty-box
constraint means “anything or nothing”, rather than “empty box”. Therefore, when the box already has a truck inside,
the team leader tries to put another truck in it, rather than hand it over to the next robot in line338.
338
Even if the team order was inverted, it still wouldn't work, because ToonTalk would make the robot holding the
empty box wait until something is put in it, rather than pass it over to the next robot in the line.
On their part, J and AA each programmed a robot to write their name. Since their robots had no starting
constraints (i.e., they were taught starting with an empty box), the names would be repeated over and over again,
quickly extending along the room floor, something they found quite amusing (as shown in the figure, below).
Group 5
Session 1 (March 29th, 2001):
This session was devoted to providing J with enough latitude for exploring the environment: landing the
helicopter, walking with the figurine, entering a house, grabbing objects and dropping them, and the combination of
letters and numbers with Bammer the mouse.
Session 2 (April 5th, 2001):
J still remembered how to use the helicopter, and make it rise and descend. During this session, I noticed that she
has developed a technique for using a regular-sized mouse: she holds it by the bottom (the end nearer to her), until the
cursor is positioned. Then, she releases the mouse, lifts her hand and goes up towards the buttons, to click them. So,
throughout the session I would hold the mouse while she did this, to make sure her clicks would occur exactly where
she positioned the mouse, and not elsewhere.
Following my indications, J grabbed the main notebook and took out the images notebook. I showed her how to
use the notebook, and she browsed until she found an image she liked (the roof of the pink house), laid the notebook on
the floor, took out the image and laid it on the floor also. From then on, she started combining other pictures with this
one, in any way that she desired. While doing this, she also practiced the use of the resizing pump. An interesting point
is that while looking for it, she called it “hose”, and indeed I usually recommend that children use the pump by
“pointing the hose to the picture.”
When her composition was complete, she got the picture frame from the notebook, resized the frame and her
composition suitably, and set it all together. It was “her painting.” It
should be noted that one of her father’s hobbies is painting. So, I took
out the room sensor from the sensors notebooks and laid it on the floor,
for her to hang her painting on the wall. After resizing the framed
picture adequately, she got the figure up to check out how it looked on
the wall (see the figure on the right).
Another interesting aspect is that before the end of the session
she still exited the house with the figurine and strolled around the
ToonTalk city a bit. While doing this, she referred to the house where
she had been as “my house”, and said about the other houses: “those are
not my house”, which shows that she was perfectly capable of knowing
where she was, in the ToonTalk world.
Annex V
—
Details of sessions conducted in Nov/2001-Feb/2002
The children
During these sessions, the children were divided into 3 different groups. In each session, only
one group was present.
GROUP 1
The girl J, aged four, who was the 3-year old in group 5 of the previous year (vd. Annex V). This
group had a single session, in setting 2 (see below). Afterwards, J started having session in her
preschool room, along with a colleague, and so became part of Group 2, below.
J (girl, 4 years)
GROUP 2
A pair of four-year olds. The sessions took place in their preschool room (setting 1, below). The
other children in that preschool would be conducting their own activities at the same time, in that
room.
One of these, J, was the 3-year old in group 5 of the previous year (vd. Annex V). The other child
was selected by the preschool teacher at the SPP preschool.
J (girl, 4 years); C (boy, 4 years)
The environment
All but the first of the sessions took place in setting 1, described below.
Setting 1:
Within the preschool room, at the SPP preschool, a Windows 98 computer was available,
nearby a window. There was no physical separation between the computer space and the other
activity areas of that room. The computer had a 15” CRT monitor and regular-sized mouse and
keyboard. It was usually turned off, but children could request permission from the educator to turn
it on and use it at any moment.
Setting 2:
Identical to setting 3 in Annex V.
Group 1
Session 1 (November 7th, 2001):
Duration: 30 minutes.
J didn’t remember some things very well, since our last session in June. According to her mother, she used
ToonTalk at home since then, but only 3 times. She didn’t remember how to make the helicopter go up and down, but
had no problem once I reminded her of the mouse buttons. She didn’t even get confused with the top-down perspective.
She easily strolled into a house, but pressed Esc to kneel, so I had to remind her that the mouse buttons did that.
I decided that it was better to ask her what she remembered about ToonTalk. She replied that she didn’t
remember how the trucks were used to build houses. So I explained the process to her again, this time using the version
of the robot's box being its luggage. She then made a new house, and went out. Seeing the other houses, she asked if
any of them was the new house. I said, “no, these are the original houses. How many houses were there, initially?” She
answered: “three.” So I said we should go looking for the new one. This we did, walking to the right, and confirming
that the robot was inside the new house.
I asked if she wanted to decorate the wall, like last year. She wanted to, but couldn’t remember how. So we went
over that process again, and she placed a bird picture and a ball on the wall. She got up to check the result, satisfied.
Group 2
Session 1 (November 13th, 2001):
No written record was kept for this session, but my recollection and the stored files allow me to present the main
points.
J & C built a new house. J already knew how to do it, and C, although he had never used ToonTalk before, could
describe the procedure in detail. According to the preschool teacher, the children from this preschool who took part in
the session, the previous year, had described their activities several times, and this was how C learned about the process.
So C was the one using the mouse, to practice.
Then, I wanted to develop a long-term activity, and discussed this with them, in terms of what should we do in
ToonTalk during the year. They said they’d like to make soup, likely because that was a topic being addressed in the
preschool, that week.
So we started by making a list of all the soup ingredients, and created a box with a hole for each. Then both J and
C drew one of those in Windows Paint, and I imported their drawings into ToonTalk, for storage in the box of
ingredients. (See the figure, below: from the left, it says Carrot, Onion, Potato, Water, Leek, and Olive Oil).
In ToonTalk, we went over the procedure for making soup: for starters, the carrot had to be placed on the water,
so they first did that, to see the result, and then a robot was taught to do the same thing. I must say I need to consider
how to employ robots for a large number of pictures, since in the common situation any change in order will render the
robots useless. A different strategy must be devised.
Overall, it was interesting to see that the children could be kept focused on a specific project, with ToonTalk
sessions separated by one week.
Session 3 (November 27th, 2001):
No written record was kept for this session.
Annex VI
—
Documents used as guidance for the group of preschool
computer-activity teachers (translated into English)
Basic structure
The following are the basic assumptions of the entire action.
The activites are to be performed involving all children in each preschool room.
Each activity is performed with pairings of children of the same age (two 3-year-olds,
two 4-year-olds, or two 5-year-olds); exceptionally, there may be groups of 3 children
or a child may be alone.
In each session (understood as an activity undertook by a pair of children) will yield a
detailed report of its development, containing:
o predefined objectives;
o session start time;
o session end time;
o session development and outcomes, regarding learning;
o created programs, created objects, and other elements that were actually produced
(including illustrative screenshots);
o general comments.
The activities are programmed and developed under a global strategic orientation,
regarding the approach to programming concepts, as is described further ahead.
Computer programming is the main learning theme; other themes should be
coordinated around this, complementing it.
Approach strategies
Three different strategies were selected, to approach computer-programming as a learning
theme:
1. Programming as the basic activity
2. Programming as an extension based on automated behaviors
3. Programming as a development of generic activities
Children-adapted terminology
Original ToonTalk terminology Adapted terminology
Toolbox Toy box
Tools (Dusty, Pumpy, Magic Wand) Tools
To program To teach
Image Drawing
[X] (room, roof, etc.) sensor make-believe [X], magical [X]
339
This was the actual behavior of ToonTalk at the time this document was written. Now, ToonTalk turns the tools off
automatically (vd. section 3.3.5).
Children-adapted explanation
Abstraction by erasing the robot’s thoughts
This concept was found to be employable, by adopting an approch of usefulness for the child.
Specifically, by programming several different robots that do the same things, only with different
thought bubbles (exchanges tree with flower; exchanges truck with bomb; exchanges boy with
helicopter, etc.), these can be labeled as “picky”, and the child can be shown that if we erase the
drawings from the thoughts, they no longer care about the differences.
Fuller and more diverse approaches have not been developed yet: perception that one doesn’t
have to erase everything, just what needs to be generalized; difference between erasing the box
contents and the box itself; etc.
Why does the truck build a house with a robot and a box?
So far, the adopted explanation has been:
“This is a construction-site truck; it will only build a house if it has a robot to live in it. And
the robot only allows the truck to leave when it has its lugagge – the box.”
Comments:
Jane Doe John Doe Starting time: 10h00 End time: 10h23
Predefined objectives:
Comments:
Jane Doe John Doe Starting time: 10h00 End time: 10h23
Predefined objectives:
Comments:
Annex VII
—
Summaries and highlights from the sessions conducted by
computer-activity teachers in preschools
Mateus preschool
Computer-activities teacher profile
Name initials FL
Age 21
Education Bachelor in Early Childhood Education
Professional He had been a computer-activities teacher at 5 preschools, in the two previous years.
experience That had been his first full-time job, and was also his current job.
Computing skills His degree included a course on basic computing.
Had been a regular computer user for several years.
Received regular training and guidance on computer use in preschool contexts, within
the ICEI project.
ToonTalk training Attended two training sessions on the use of the environment tools and basic
programming.
The children
19 children: 8 girls, 11 boys; 2 three-year olds, 11 four-year olds, 6 five-year olds.
Group Child 1 (Age, Gender) Child 2 (Age, Gender)
1 PL 4 Girl LF 4 Boy
2 PR 4 Boy JPM 4 Boy
3 AR 4 Girl RJ 4 Boy
4 L 4 Boy MT 4 Girl
5 AA 5 Girl AC 4 Girl
6 MA 5 Boy M 4 Boy
7 IX 4 Girl LE 5 Boy
8 FG 5 Boy
9 AF 5 Boy T 5 Girl
10 R 3 Girl JPF 3 Boy
Sessions table
Group Session Date Start End Time Group Session Date Start End Time
1 1 28-Out-2002 10:45 11:10 0:25 4 1 28-Out-2002 10:20 10:40 0:20
1 2 11-Nov-2002 9:40 10:06 0:26 4 2 4-Nov-2002 10:05 10:26 0:21
1 3 18-Nov-2002 10:15 10:37 0:22 4 3 11-Nov-2002 10:40 10:55 0:15
1 4 25-Nov-2002 9:35 10:01 0:26 4 4 18-Nov-2002 10:40 11:10 0:30
2 1 28-Out-2002 10:30 10:55 0:25 4 5 2-Dez-2002
2 2 4-Nov-2002 11:24 11:49 0:25 4 6 9-Dez-2002
2 3 11-Nov-2002 4 7 16-Dez-2002
2 4 18-Nov-2002 9:40 10:02 0:22 5 1 28-Out-2002 9:40 10:13 0:33
2 5 25-Nov-2002 10:10 10:30 0:20 5 2 4-Nov-2002 10:30 10:53 0:23
2 6 9-Dez-2002 5 3 11-Nov-2002 9:45 10:28 0:43
2 7 16-Dez-2002 5 4 18-Nov-2002 10:40 11:00 0:20
3 1 28-Out-2002 11:10 11:30 0:20 5 5 25-Nov-2002 14:10 14:36 0:26
3 2 4-Nov-2002 9:40 10:05 0:25 5 6a* 2-Dez-2002 9:40 10:00 0:20
3 3 11-Nov-2002 10:10 10:35 0:25 5 6b* 2-Dex-2002
3 4 18-Nov-2002 10:06 10:35 0:29 5 7a* 9-Dez-2002
3 5 25-Nov-2002 9:35 10:05 0:30 5 7b* 9-Dez-2002
3 6 2-Dez-2002 10:07 10:31 0:24 5 8a* 16-Dez-2002
3 7 9-Dez-2002 5 8b* 16-Dez-2002
3 8 16-Dez-2002 (*The children were paired by the teacher, due to absentees.)
Highlights – Group 1
“(...) LF had some difficulty grabbing objects and vacuuming. This was due to the fact
that he had not assimilated the “rule” that in order to grab any object or vacuum, he must
first see whether the desired object is moving, as I transmitted to him and exemplified.”
(FL, session 1, my emphasis)
“(...) PL only taught the robot how to take objects from the toolbox. I can remember
neither how one exits the thought, nor how to make the test to check if the robot learned
something.”
(FL, session 4, my emphasis)
Highlights – Group 3
« AR had barely sat down and started playing right away, making more and more
houses, without help. (...) After she had built several houses, I suggested that she swapped
objects inside the boxes, a task she performed without difficulties. Then I explained to her
that the robot could do the same thing, and that all she had to do was teach it. (...) RJ
wanted nothing but building houses and blowing them up; I couldn’t drive him to perform
the same tasks as AR. »
(FL, session 3, my emphasis)
« Both children said they didn’t want to work in ToonTalk, at the start of the activity.
»
(FL, session 6, his emphasis)
« RJ didn’t want to do the proposed activity. Although I have tried to drive him towards
my plan, I couldn’t manage to persuade him away from his will to blow up houses in order
to see the construction workers rebuilding them afterwards. »
(FL, session 7)
Highlights – Group 5
« (...) I asked her if she still remembered the way to teach a robot how to work and why
not teach it to build houses. She took my challenge and gave the robot a box with a truck (I
asked her the reason for being a truck and not something else, to check if she was already
reasoning that we need a truck to build houses; however, it was a random choice, which
means that she had no such intention). »
(FL, session 6a, my emphasis)
« (...) Then he exited the thought and tested the robot. (This entire task was performed
by L following the indications of AC.)
AC was merely working on the street, placing several objects on the ground, and simply
carrying them from one place to another. This surprised me a lot, because she had been
constantly helping out L. »
(FL, session 6b, my emphasis)
Highlights – Group 6
« (...) MA had the same problems of the previous session, although a bit less
pronounced. M surprised me in a positive way; it was just a matter of reminding how to
perform the various tasks, for him to start working on his own, not caring for anyone else. »
(FL, session 2)
Highlights – Group 7
« FG didn’t want to perform the task on the room floor, and so found it a bit harder to
do it in the robot’s thought. However, with some help from me, of verbal nature, he
managed to unswap what LE had done. (...) Had the activity been performed first by this
child, I certainly would have had many more difficulties in fulfilling it, that’s why I put
him to do it after LE. »
(FL, session 6, my emphasis)
Highlights – Group 8
« The easiness demonstrated by JPF when performing the tasks is in fact something that
surprised me, given that this child presents some difficulties in executing drawings on Paint
and in playing computer games. »
(FL, session 2, my emphasis)
« In another house, JPF entered the robot’s thoughts, picked up a bomb and made it
blow up. He tested the robot and enjoyed seeing it blow up the house. JPF had no major
difficulties programming the robot, very few times I had to intervene to warn him of this
matter or the other. »
(FL, session 4)
Highlights – Group 9
« In the case of AF, I was already expecting his performance to fall short (he is a child
with special educational needs, even though he’s not declared as such). »
(FL, session 2)
Highlights – Group 10
« She experienced some difficulties, namely while taking objects out of the toolbox,
because to take out an object, she would take another instead. I didn't want to move on too
much with R, since she’s hardly ever present, and when she is she doesn’t want to come to
the computers. »
(FL, session 6, my emphasis)
Mondrões preschool
Computer-activities teacher profile
Name initials RC
Age 25
Education Professional training as Animator in Computing for Children.
Second-year undergraduate student of Early Childhood Education.
Professional Had previously worked two years as teacher/animator at a private computer-activities
experience school for children, and also as a computer training teacher for adults. Afterwards,
she had been working for three years as a computer-activities teacher at 5 preschools.
Computing skills Power user (able to conduct computer training sessions).
Able to customize and employ several programs in non-standard, programmatic ways
(e.g., game development using MS PowerPoint).
Provided training and guidance on computer use in preschool contexts, for the ICEI
project.
ToonTalk training Attended two training sessions on the use of the environment tools and basic
programming and had previous superficial contact with it.
The children
11 children: 4 girls, 7 boys; 1 three-year old, 4 four-year olds, 6 five-year olds.
Group Child 1 (Age, Gender) Child 2 (Age, Gender)
1 L 5 Boy R 4 Girl
2 RA 5 Boy S 3 Girl
3 D 4 Boy M 4 Boy
4 T 5 Boy RF 4 Boy
5 SI 5 Girl SM 5 Boy
6 P 5 Girl
Sessions table
Group Session Date Start End Time Group Session Date Start End Time
1 1 9-Out-2002 1 4 1 9-Out-2002 4
1 2 16-Out-2002 9:00 9:50 1 4 2 16-Out-2002 11:10 11:25 4
1 3 23-Out-2002 1 4 3 23-Out-2002 4
1 4 30-Out-2005 9:15 9:45 1 4 4 30-Out-2005 10:50 11:20 4
2 1 9-Out-2002 2 5 1 9-Out-2002 5
2 2 16-Out-2002 10:30 10:45 2 5 2 16-Out-2002 9:55 10:15 5
2 3 23-Out-2002 2 5 3 23-Out-2002 5
2 4 30-Out-2005 9:45 10:15 2 5 4 30-Out-2005 11:20 11:45 5
3 1 9-Out-2002 3 6 1 9-Out-2002 6
3 2 16-Out-2002 10:45 11:05 3 6 2 16-Out-2002 11:25 11:45 6
3 3 23-Out-2002 3 6 3 23-Out-2002 6
3 4 30-Out-2005 10:15 10:45 3
Highlights – Group 1
« What can be asserted is that at this moment (3rd session) R can manipulate the mouse.
When I asked her if she still remembered how houses were built, R quickly explained it to
me and then did it. Whenever she built a house, she would get the figurine up, left the house,
and took off in the helicopter to see it. »
(RC, session 3)
« R took off in the helicopter and showed the houses to L... (I was surprised by this
attitude of R.) L then wanted to do the same thing. »
(RC, session 4)
Highlights – Group 2
« R built houses with my assistance (he has some trouble using the mouse). Then he told
me he didn’t want [to play] anymore. »
(RC, session 3)
« R is now perfectly capable of building houses and has been teaching S, who had no
idea of how to do it (he helped her, placing his hand on top of hers). (...) R still has some
trouble to fully control the mouse, but he’s managing it. »
(RC, session 4)
Highlights – Group 3
« D and M managed to build houses, and wanted to count them. After they did, I showed
them how they could build a city. Both D and M managed to teach the robot, and went out
into the street and up with the helicopter to see the development. They were very surprised
with what they had done. I did notice that M was more surprised than did D. »
(RC, session 4)
Highlights – Group 5
«I tried suggestion that they developed a city, but none of them took the least notice,
what they wanted was to build houses and count them in frenzy.
SM:”Do you want me to take a bomb out?”
SI: “Yes. Tuck it up, it can blow up!!!”
And in this manner they proceeded with building houses and counting them. »
(RC, session 3)
«They were both perplexed with how fast the construction workers built houses. They
have shown difficulty in understanding the robot’s thought:
SM – I’m a bit mixed up!?
SI – I am, too.
At this moment I explained them that when we want to do something, we must think
about what we want to do, and so the robot also had to think... Since robots don’t think by
themselves, one has to go into their thoughts to teach them. I think they were convinced. »
(RC, Session 4)
Highlights – Group 6
« She told me that [in the previous session] we had been building houses, and when I
asked her what birds did, she told me she didn’t know. Therefore, I decided to modify the
session’s goals, to do house-building. And I told her that we would be building houses. To
my amazement, this was P’s construction sequence: 1) took out a truck and a robot, placed
the robot on the truck; 2) took out a nest and started giving things to the bird....
RC – P, how does one build a house?
P – With a truck, a robot, and a box.
RC – And why did you take out a nest?
P – I felt like giving things to the bird for it to carry to the nest. »
(RC, Session 4)
The children
14 children: 5 girls, 9 boys; 5 three-year olds, 6 four-year olds, 3 five-year olds.
Group Child 1 (Age, Gender) Child 2 (Age, Gender)
1 B 3 Boy
2 D 4 Boy
3 R 4 Boy G 4 Boy
4 M 4 Boy DI 3 Boy
5 F 4 Boy
6 MA 5 Boy
7 MR 3 Girl C 3 Girl
8 A 5 Boy
9 AN 3 Girl
10 CR 4 Girl
11 CA 5 Girl
Sessions table
Group Session Date Start End Time Group Session Date Start End Time
1 1 25-Out-2002 9:45 9:55 1 8 2 4-Nov-2002 10:14 11:05 8
2 1 25-Out-2002 9:57 10:14 2 8 3 15-Nov-2002 8
2 2 29-Nov-2005 15:51 15:54 2 8 4 22-Nov-2002 10:00 10:25 8
3 1 25-Out-2002 10:16 10:31 3 8 5 29-Nov-2005 11:34 11:55 8
3 2 4-Nov-2002 11:46 12:05 3 9 1 25-Out-2002 15:10 15:16 9
4 1 25-Out-2002 10:33 10:55 4 10 1 25-Out-2002 11:14 11:40 10
5 1 25-Out-2002 10:57 11:05 5 10 2 4-Nov-2002 10:10 10:42 10
6 1 29-Nov-2005 14:15 14:55 6 10 3 15-Nov-2002 10
7 1 25-Out-2002 11:47 12:05 7 10 4 22-Nov-2002 10:31 11:12 10
7 2 4-Nov-2002 14:37 15:07 7 11 1 4-Nov-2002 15:08 15:25 11
7 4 22-Nov-2002 11:18 11:41 7 11 2 22-Nov-2002 14:17 14:31 11
8 1 25-Out-2002 14:20 15:05 8 11 3 29-Nov-2005 14:56 15:49 11
Highlights – Group 2
« He didn’t want to play anymore; instead he wanted to see what the mouse was made
of. »
(CF, Session 1)
Highlights – Group 3
« [R] kept on taking out many objects from the box and wanted to build many. I got
muddled with all the objects scattered around and wasn’t too successufl in building houses.
I helped him with my hand. He didn’t want to play any more. »
(CF, Session 2)
Highlights – Group 7
« MR and C are not capable of using the mouse, i.e., they are constantly moving it in a
disoriented way. »
(CF, Session 2)
Highlights – Group 8
« I taught him how to build houses, and he wanted to try out. He was also successful and
wanted to be the rest of the time building houses and checking the final result. »
(CF, Session 1)
« When he took out the robot, I suggested teaching it how to swap objects and showed
him how to do it. I repeated it several times and asked him to do it on his own. But he didn’t
want to. »
(CF, Session 2)
« Without any guidance, he entered a house, kneeled and took out the notebook of
drawings. He asked me how it was browsed. I explained him and showed him how to do it.
He enjoyed seeing the drawings and took the one showing the toolbox. He wanted to take
out many identical pictures and overlay them. I asked if he still remembered how to teach a
robot about swapping objects. He said, “oh, I don’t want to do that. I’d rather make
houses.” I then asked if he would prefer teaching the robot how to build houses. I preferred
making a drawing. »
(CF, Session 5)
Highlights – Group 10
« CR landed well, and wanted to enter a house but kept moving the mouse for too long
and lost track of the site. Since she couldn’t find the houses, she wanted to get back into the
chopper. But she had also lost track of it. We had to exit Toon[Talk] without saving and re-
enter. She landed, entered a house and wanted to blow it up. Then she built a new one, all
this without my help. »
(CF, Session 2)
« She asked if the girl had no friends. I taught her how to browse the notebook and take
out the drawing of a friend. She did it on her own. »
(CF, Session 2)
« Outside its thought, the robot repeated everything, including the “errors” and CR
said: “This robot does confusing things!” »
(CF, Session 4)
Highlights – Group 11
« I let her at will to do whatever she wanted to with the mouse, and the result was that
she tried to grab the objects by taking her other hand to the monitor. »
(CF, Session 1)
« CA no longer remembered the purpose of the mouse buttons. She found out by clicking
randomly. However, she was no longer able to land the chopper. In an act of irritation, she
moved the mouse vary fast and the chopper landed. »
(CF, Session 3)
« On foot, she saw that there were toys still not tucked in the toolbox and she wanted to
tuck them in, even while standing up. I explained that one needs to bend down to get the toys
and she tried out with one toy in the activities room [(outside the computer)]. She tried
several times to kneel [in ToonTalk], but was always doing it away from the floor location
of the toys. I helped her. »
(CF, Session 3)
The children
21 children: 13 girls, 8 boys; 6 three-year olds, 8 four-year olds, 7 five-year olds.
Group Child 1 (Age, Gender) Child 2 (Age, Gender)
1 A 3 Girl D 3 Boy
2 M 3 Girl R 3 Girl
3 MN 3 Girl J 3 Boy
4 IN 4 Girl C 4 Girl
5 L 4 Boy MA 4 Girl
6 U 5 Girl CA 5 Girl
7 CR 4 Boy JG 4 Girl
8 IM 5 Girl S 5 Boy
9 AM 5 Girl V 5 Boy
10 AX 4 Boy G 4 Boy
11 AL 5 Girl
Sessions table
Group Session Date Start End Time Group Session Date Start End Time
1 1 10-Out-2002 9:08 9:28 0:20 3 5 7-Nov-2002 9:50 10:18 0:28
1 2 15-Out-2002 9:56 10:19 0:23 3 6 5-Dez-2002 11:05 11:34 0:29
1 3 24-Out-2002 14:10 14:29 0:19 3 7 4-Fev-2003 11:00 11:26 0:26
1 4 29-Out-2002 10:11 10:41 0:30 3 8 18-Fev-2003 10:25 10:43 0:18
1 5 5-Nov-2002 9:15 9:45 0:30 3 9 11-Mar-2003 15:30 15:54 0:24
1 6 5-Dez-2002 14:37 14:57 0:20 3 10 27-Mar-2003 10:28 11:00 0:32
1 7 23-Jan-2003 9:20 9:40 0:20 3 11 20-Mai-2003 14:55 15:20 0:25
1 8 4-Fev-2003 10:25 10:45 0:20 3 12 3-Jun-2003 11:00 11:30 0:30
1 9 13-Fev-2003 10:45 11:10 0:25 4 1 10-Out-2002 10:05 10:22 0:17
1 10 11-Mar-2003 15:05 15:28 0:23 4 2 15-Out-2002 10:22 10:50 0:28
1 11 27-Mar-2003 10:15 10:26 0:11 4 3 24-Out-2002 10:00 10:24 0:24
1 12 22-Mai-2003 10:18 10:37 0:19 4 4 31-Out-2002 9:45 10:15 0:30
1 13 5-Jun-2003 9:20 9:50 0:30 4 5 7-Nov-2002 9:15 9:46 0:31
2 1 10-Out-2002 0:30 0:46 0:16 4 6 5-Dez-2002 10:12 10:38 0:26
2 2 15-Out-2002 9:20 9:53 0:33 4 7 23-Jan-2003 9:45 10:00 0:15
2 3 24-Out-2002 11:35 11:58 0:23 4 8 4-Fev-2003 14:03 14:20 0:17
2 4 31-Out-2002 9:10 9:36 0:26 4 9 13-Fev-2003 9:45 10:06 0:21
2 5 7-Nov-2002 9:20 10:40 1:20 4 10 18-Mar-2003 10:47 11:05 0:18
2 6 5-Dez-2002 10:40 11:02 0:22 4 11 27-Mar-2003 9:40 10:14 0:34
2 7 23-Jan-2003 11:00 11:20 0:20 4 12 22-Mai-2003 9:14 9:44 0:30
2 8 4-Fev-2003 9:15 9:40 0:25 4 13 3-Jun-2003 14:05 14:35 0:30
2 9 13-Fev-2003 9:10 9:44 0:34 5 1 10-Out-2002 10:25 10:45 0:20
2 10 18-Mar-2003 10:20 10:45 0:25 5 2 17-Out-2002 11:15 11:40 0:25
2 11 27-Mar-2003 11:15 11:36 0:21 5 3 24-Out-2002 11:00 11:35 0:35
2 12 20-Mai-2003 14:15 14:40 0:25 5 4 29-Out-2002 15:30 16:00 0:30
2 13 5-Jun-2003 11:10 11:46 0:36 5 5 5-Nov-2002 10:48 11:15 0:27
3 1a 10-Out-2002 9:48 10:03 0:15 5 6 5-Dez-2002 15:32 15:56 0:24
3 1b 10-Out-2002 15:06 15:30 0:24 5 7 4-Fev-2003 15:07 15:30 0:23
3 2 17-Out-2002 14:15 14:46 0:31 5 8 18-Fev-2003 10:45 11:07 0:22
3 3 24-Out-2002 14:35 15:00 0:25 5 9 18-Mar-2003 15:10 15:40 0:30
3 4 31-Out-2002 10:27 10:50 0:23 5 10 1-Abr-2003 14:32 14:46 0:14
Highlights – Group 1
« If I don’t say anything, D stays “stunned” looking at the ToonTalk environment and
playing with the mouse. Today he played with the mouse by making moise as if it was a toy
car. »
(PF, Session 6)
« D didn’t know how to explain the swap or what it was. I opted for the comparison box.
D identified the identical images, but couldn’t understand the swap. He managed to make
the swap, but only to place identical images below the matching ones.
Highlights – Group 2
« As for the figurine, she tried commanding it by speaking to it: “go to the airplane,
shucks!” »
(PF, Session 1)
« They’re both more calm while working, and stopped clicking aimlessly. They realized
that they need to turn the vacuum cleaner off in order for it to stop making noise. »
(PF, Session 6)
« M – Drop the box, hand. It’s taking it for ever to drop the box, PF!
(she’s not realizing that she’s the one controlling the hand).
R – The tree has eyes.
M – To see well.
R – I don’t like trees with eyes. »
(PF, Session 11)
« R sought in the notebook. She constructed meaningful settings to decorate the wall.
One of them was a boy, a plane, and an explosion. She said: “the boy is going to see it
blowing up”. »
(PF, Session 13)
Highlights – Group 3
« While playing with the helicopter, he asked: “Is it crazy?” I answered: “no, you’re the
one moving it, aren’t you?”
J: Yes. »
(PF, Session 4)
« I explained them that in order to have identical boxes we had to place the images in
the same order. J explained: “yeah... bird/bird, mouse/mouse, yellow flower/yellow flower,
pink flower/pink flower,tree/tree...” »
(PF, Session 9)
« MN is at will picking and dropping objects in ToonTalk. This was a victory! »
(PF, Session 10)
« When leaving the robot’s thought, J asks: “Shall I give it this box?” – As he points to
the starting box.
PF – Why does it stop?
J – Because he’s finished doing this.
J says that he taught “Hugo” how to swap the places of things. J tried giving a box with
several holes to the robot. Then he realized that he only had taught it with two holes, and
therefore it wouldn’t work out this way. »
(PF, Session 10)
Highlights – Group 4
« They don’t leave the robot’s thoughts. They say:“I think it learned!”. They don’t check
to see if the robot learned what they taught it. »
(PF, Session 8)
« I asked why was it that the robot stopped after doing what they had taught it. C’s
answer was: “The box is empty.” »
(PF, Session 8)
« I didn’t move on with robot programming, because in terms of reasoning I don’t think
IN and C are ready; perhaps within a couple of sessions. »
(PF, Session 9 – cf. the two previous highlights)
Highlights – Group 5
« L, after blowing up each house, would lift off to check that there one less house [in the
city]. »
(PF, Session 1)
« MA required assistance to find the sensor notebook. Then, she managed to find the
wall and decorate it, which gave her great joy, upon seeing on the wall the Santa Claus she
had drawn. MA always lifts the figurine to check out what she did. »
(PF, Session 6)
« I asked MA what swapping is. She said: “it’s putting one here and another there” –
she pointed as she explained.
PF – What is the robot thinking?
MA: It’s thinking that it’s going to do the game again.
I explained that it only does the game if we give it an identical box.
PF – Why did it stop?
MA: Because it’s thinking about another box.
Then MA tried swapping the objects and tested the robot again. »
(PF, Session 10)
« L noticed that the wall is identical to the one in the notebook. The abstraction is still
not being achieved. Only when I tell them can they understand that they need to use a
“make-believe” wall. (Session 11)
L finds everything complicated. He won’t check whether the name is on the roof, he says
that “it’s on the small one, therefore it is.” (Session 12) »
(PF, Sessions 11 & 12; the contradictions in the teacher’s reasoning have been
underlined)
Highlights – Group 7
« CR made a robot to build houses. Then he made 3 more. They already know how to get
up and sit down without any difficulty.
CR: “I’m going to make many houses.”
JG used the magic wand: “ah! Got it! More trucks!”
They used the bomb/grenade. I told them: “Are we going to blow up all the houses?”
Them: “Yes, because some build themselves afterwards!”
They took drawings out of the notebook and stored them in boxes. When picking the
spaceship, J said: “We must make this smaller!” And she fetched the air pump. J did a “box
of stuff” and saved it in her notebook. »
(PF, Session 1)
« PF – “If we join the boxes...”
CR – “I know, I know!... The mouse comes and joins them!” »
(PF, Session 3)
Highlights – Group 8
« Predetermined objectives:
to develop concentration – w/ IM;
to develop his relationship with co-workers – w/ S. »
(PF, Session 2)
« IM said she had to be at the computer: “I must work very much, in order to learn.” IM
likes to work, and to experiment, and tries to make things on her own. I had to her to “let
me” assist her, because she was saying “I can’t do it”, but was avoiding help. »
(PF, Session 4)
Highlights – Group 9
« She made 2 twin birds, which she named “the bird brothers”, and then I helped her
save a box with them in her notebook. »
(PF, Session 1)
« As soon as V entered the ToonTalk house, he said, “I’m going to blow up the house.”
However, he forgot that in order to blow up the house he had to hold the bomb in the
figurine’s hand.
PF – “What can we do to find out whose is each house?”
V – “We can give money to the man and stay there!”
I explained that also in drawings the name allows us to know who made them. »
(PF, Session 4)
« Today, AM was very distracted, she only focused when I told her that we could make
gifts (with the boxes) for her to offer. »
(PF, Session 6, when Christmas was nearing)
« PF – Why did it stop?
Instead of answering, V filled up the box again, matching the stuff the robot had in its
head. »
(PF, Session 9)
« PF – Why did it stop, AM?
AM – I don’t know. »
(PF, Session 10)
Highlights – Group 10
« The city that AX has since the school year 2001/2002 is filled with many houses. On
his own, he went to the robot’s memory.
PF – “What are you doing, AX?”
AX – “I’m teaching the robot how to make houses. Look at this...” »
(PF, Session 1a)
« Back into ToonTalk, he [G] made a builder robot (he already knew how to). (...) As for
the vacuum cleaner and the wand, he still experiences some difficulties in understanding
that he must hold them in the hand in order to use them. »
(PF, Session 1b)
« PF – What uses can the boxes have?
AX – “To put things in.”
Eu – “Then, if this is our travelling case, what will you put inside?”
AX – “I’ll take with me a robot, a truck, a bomb, a number, a truck, and scales. There:
it’s done.”
He entered the robot’s thoughts: “I’m going to teach the robot how to explode the
box...”
PF – What are you teaching to it, anyway?
AX: How to make houses.
(...)
AX: the birdies carry the things to the nest, so their little children can eat.
I explained to AX that if he gives an empty box to the robot, what he may teach him it’ll
do always in sequence.
AX: it’ll keep on doing it, is it? »
(PF, Session 2)
« In the robot’s thoughts, AX doesn’t realize that he’s now controlling the robot, and
continues to act as himself340. (...) AX forgets to exit from the robot’s thoughts. (...) PF: And
if the box gets empty, what happens?; AX: “It won’t have anything to work with.” »
(PF, Session 9)
« AX taught G how to make a swap and how to teach the robot. AX told G to give the
box to the robot’s hands, to see if it learned. G still forgets to give the box to the robot to
teach it. Inside the robot’s thoughts, G remembered to use the magic wand, but he doesn’t
leave the thoughts. »
(PF, Session 10)
340
I.e., as if he was still controlling the programmer figurine.
536 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
Session overview – Group 11
This girl started taking part in the ToonTalk session two weeks after the other children. She demonstrated ease in
doing the basic actions, and even some complex actions such as building houses and putting pictures on the roof (see
the first highlight, below).
In programming, she was showed consideration for the necessary items, and demonstrated ease in programming
(see the second highlight, below). She was also very keen on noticing that the robot was using the vacuum cleaner,
when she hadn’t taught it to do that, and on the reddening of a mismatched image (see the third highlight, below).
Highlights – Group 11
« She likes to build houses and exits, so that, in the helicopter, can see the houses she
built: “Look at the houses I sent to be made,” she said while pointing.
Without any instructions from me, she wanted to put her name on the roof. She only
asked how to change pages in the notebook. »
(PF, Session 2)
« To teach the robot how to make houses, AL thought she just needed a box and a truck,
because she already had a robot (the one being taught). She mentioned having to exit the
robot’s thoughts. She doesn’t use the original box, but learned to copy the box, so that the
robot doesn’t stop. AL –“We have to teach things, and to avoid stopping, we must teach it to
make tricks with the magic wand.” »
(PF, Session 5)
« AL: Why does the tree turn red?
PF – Because it has already used the tree341.
(...)
AL taught the robot again and remembered to give it the box to see if it had learned. She
says that she didn’t teach it to vacuum, but it does vacuum342. »
(PF, Session 6)
341
This remark by the teacher is actually quite confusing, or even plain wrong. The tree had turned red because the
swap had been made and in the tree’s position there was now a different image.
342
She’s probably right. ToonTalk robots automatically vacuum any objects left on the floor at the end of a cycle.
The children
22 children: 14 girls, 8 boys; 0 three-year olds, 12 four-year olds, 10 five-year olds.
Group Child 1 (Age, Gender) Child 2 (Age, Gender)
1 IT 5 Girl ACS 4 Girl
2 F 5 Boy M 5 Boy
3 IF 4 Girl MG 4 Girl
4 AT 4 Girl CP 4 Girl
5 FM 4 Boy D 4 Boy
6 FS 5 Boy C 5 Girl
7 FL 4 Boy DI 4 Boy
8 B 5 Girl CA 5 Girl
9 BB 5 Girl L 5 Boy
10 J 5 Girl MA 4 Girl
11 A 4 Girl AC 4 Girl
Sessions table
Group Session Date Start End Time Group Session Date Start End Time
1 1 28-Out-2002 14:30 14:50 0:20 7 1 29-Out-2002 10:10 10:30 0:20
1 2 5-Nov-2002 9:40 10:00 0:20 7 2a 4-Nov-2002 14:41 15:00 0:19
2 1 28-Out-2002 14:50 15:10 0:20 7 2b 4-Nov-2002 15:20 15:40 0:20
2 2 5-Nov-2002 10:00 10:20 0:20 8 1 29-Out-2002 10:30 10:50 0:20
3 1 28-Out-2002 15:15 15:40 0:25 8 2 5-Nov-2002 9:20 9:40 0:20
3 2a 4-Nov-2002 14:41 15:00 0:19 9 1 29-Out-2002 10:55 11:20 0:25
3 2b 4-Nov-2002 15:00 15:20 0:20 9 2a 4-Nov-2002 15:40 16:00 0:20
4 1 28-Out-2002 15:40 16:00 0:20 9 2b 5-Nov-2002 10:40 11:00 0:20
5 1 29-Out-2002 9:30 9:50 0:20 10 1 29-Out-2002 11:20 11:40 0:20
5 2a 4-Nov-2002 14:15 14:40 0:25 10 2a 4-Nov-2002 15:00 15:20 0:20
5 2b 5-Nov-2002 10:40 11:00 0:20 10 2b 5-Nov-2002 9:40 10:00 0:20
6 1 29-Out-2002 9:50 10:10 0:20 11 1 29-Out-2002 11:40 12:00 0:20
6 2a 4-Nov-2002 15:20 15:40 0:20 11 2a 4-Nov-2002 14:15 14:40 0:25
6 2b 4-Nov-2002 15:40 16:00 0:20 11 2b 5-Nov-2002 11:20 11:45 0:25
The children
12 children: 6 girls, 6 boys; 4 three-year olds, 4 four-year olds, 4 five-year olds.
Group Child 1 (Age, Gender) Child 2 (Age, Gender)
1 JO 4 Boy F 3 Boy
2 A 4 Girl L 4 Boy
3 JG 3 Boy C 3 Girl
4 P 5 Boy FI 5 Girl
5 JA 5 Girl CA 5 Girl
6 E 4 Boy S 3 Girl
Sessions table
Group Session Date Start End Time Group Session Date Start End Time
1 1 17-Out-2002 14:15 15:45 1:30 4 1 21-Out-2002 9:45 10:15 0:30
2 1 10-Out-2002 10:00 10:30 0:30 4 2 10-Fev-2003 15:00 15:30 0:30
2 2 17-Out-2002 14:15 15:45 1:30 5 1 21-Out-2002 11:15 11:45 0:30
2 3 28-Nov-2002 14:45 15:30 0:45 5 2 13-Jan-2003 11:30 12:00 0:30
2 4 13-Jan-2003 10:45 11:15 0:30 6 1 21-Out-2002 11:45 12:00 0:15
2 5 10-Fev-2003 14:15 14:45 0:30 6 2 28-Nov-2002 11:00 11:45 0:45
3 1 18-Out-2002 10:00 10:45 0:45 6 3 13-Jan-2003 14:30 15:00 0:30
3 2 21-Out-2002 10:20 11:10 0:50 6 4 10-Fev-2003 10:30 11:15 0:45
3 3 28-Nov-2002 9:45 10:00 0:15 7 1 28-Nov-2002 10:05 11:00 0:55
3 4 28-Nov-2002 15:30 15:45 0:15
3 5 13-Jan-2003 10:00 10:30 0:30
Annex VIII
—
Full reports from the sessions conducted by computer-activity
teachers in preschools
Mateus preschool
Group 1
Session 1
Início: 10h 45m Fim: 11h10m
PL (age 4) /LF (age 4)
Objectivos Prévios: Introdução ao TOON TALK (breve apresentação do ambiente do Toon Talk).
Desenrolar e Resultados Gerais:
Esta primeira actividade consistiu emas criança, de forma livre explorarem o ambiente do Toon Talk. Pilotarem
o Helicóptero, faze-lo aterrar junto às casas, entrarem com o boneco na casa e explorarem as diferentes ferramentas que
se encontramao seu dispor. O LF conseguiu “pilotar” o Heli até pousar junto às casas, conseguiu também, embora com
alguma dificuldade entrar na casa. Já dentro desta e, com a caixa de ferramentas ao seu dispor, o LF teve algumas
dificuldades em agarrar objectos e a aspirar. Esta dificuldade deveu-se ao facto de ele não ter assimilado a “regra” de
que para se agarrar algum objecto ou aspirar, tem de primeiro ver se o objecto pretendido está a mexer, como lhe foi por
mim transmitido e exemplificado.
A PL sentiu algumas dificuldades em fazer descer o heli, pois confundiu por diversas vezes as teclas
(descer/subir), teve ainda dificuldades em o colocar junto às casa e em concretizar a aterragem propriamente dita, pois
como o heli se apresentava ao mesmo nível das casas, ela pensava que este já se encontrava em terra.
Após ter efectuado a aterragem, ela saiu com o boneco e tentou chegar à casa. Esta foi mais uma tarefa de difícil
concretização, uma vez que, por diversas vezes, ela fez, sem ser sua intenção, sentar o boneco.
Quando entrou, tive de a ajudar para que ela conseguisse agarrar os objectos e experimentar trabalhar com
alguns deles.
Lista de elementos de registo (ficheiros) associados:
Observações:
O LF identificou de imediato o heli e disse que as casas eram o aeroporto.
Session 2
Início: 09h 40m Fim: 10h06m
PL (age 4) /LF (age 4)
Objectivos Prévios: Trocar caixas/objectos no seu interior/programar o Robô
Desenrolar e Resultados Gerais:
Esta terceira sessão consistiu na realização de trocas de objectos nas caixas, e se possível, na programação do
robô para efectuar essas mesmas trocas.
Assim, e passando à caracterização do desempenho das duas crianças que compõem este grupo, tenho a referir
que a PL sentiu muitas dificuldades durante o desenrolar desta actividade. Para ela fazer o percurso desde a saída do
helicóptero até à casa com o boneco foi de facto bastante complicado, pois foram várias as vezes em que fez o boneco
sentar sem o querer. Já dentro da casa, mais propriamente no chão desta, a Patrícia não conseguiu, de forma satisfatória,
realizar as tarefas mais simples tais como: agarrar, aspirar, trocar objectos, dado que aquando da realização de qualquer
uma destas tarefas, ela nunca conseguiu obter o que pretendia.
Em Relação ao desempenho do LF, posso dizer que foi idêntico ao da Patrícia. As dificuldades sentidas foram
exactamente as mesmas, não havendo por isso nada a acrescentar.
Resta-me apenas referir que não avancei para a troca de caixas e por sua vez, para a programação do robô, pelo
simples facto de não considerar conveniente introduzir novas tarefas, sem que estas estejam presentes nas crianças.
Lista de elementos de registo (ficheiros) associados:
Observações:
Observações:
As dificuldades sentidas por estas crianças, não se prendem tanto com a programação do robô propriamente dita,
mas sim com a realização de tarefas como o aspirar, o agarrar, o copiar o objecto certo.
Session 4
Início: 09h 35m Fim: 10h 01m
PL (age 4) /LF (age 4)
Objectivos Prévios: Avaliar o desempenho da criança
Desenrolar e Resultados Gerais:
A PL sentiu dificuldades em fazer pousar o heli e em se deslocar para a casa sem fazer sentar o boneco no chão
da rua. Sentiu ainda dificuldades em agarrar objectos, bem como em dar a caixa ao robô para entrar no seu pensamento.
Já dentro do pensamento, a PL ensinou somente o robô a retirar objectos da mala de ferramentas. Não se lembro como
se fazia para sair do pensamento, nem como fazer o teste para verificar se o robô aprendeu algo. Assim, todo o
desenrolar da actividade foi feito com um constante auxílio dado por mim.
O LF retirou alguns objectos da mala de ferramentas (camião, caixas, letras, números e um ninho) e, limitou-se a
deslocá-los de um lado para o outro. Não fez portanto, programação do robô, o que não quer dizer que não o saiba fazer,
mas, e por sua própria vontade, não avançou para a programação.
Lista de elementos de registo (ficheiros) associados:
Observações:
O LF perguntou porque razão jogamos sempre o mesmo jogo.
Group 2
Session 1
Início: 10h 30m Fim: 10h55m
PR (age 4) / JPM (age 4)
Objectivos Prévios: Introdução ao TOON TALK (breve apresentação do ambiente do Toon Talk).
Observações:
Ambas as crianças identificaram o heli como sendo um avião.
O JPM teve distraído após ter realizado a sua tarefa.
A mesma criança não gostou do jogo.
Session 2
Change in group composition due to absentees. This session matches Session 2 in group 7.
Início: 11h 24m Fim: 11h 49m
PR (age 4) / LE (age 5)
Objectivos Prévios:
Identificar e trabalhar com algumas ferramentas do TOONTALK.
Desenrolar e Resultados Gerais:
O LE não teve dificuldade alguma em realizar esta actividade. Não necessitou de nenhum tipo de ajuda, eu só lhe
dei algumas dicas para ele fazer este ou aquele tipo de tarefa, como o aspirar objectos do interior das caixas, copiar
objectos, rebentar com as casas, etc.
O PR, sentiu mais dificuldades, nomeadamente no agarrar, aspirar e copiar, pois esqueceu-se frequentemente de
que o objecto com que quer trabalhar tem de estarem movimento.
As dificuldades sentidas por esta criança prendem-se com o facto de esta não conseguir permanecer muito tempo
concentrada no que está a realizar.
Lista de elementos de registo (ficheiros) associados:
Observações:
Session 3
Início: Fim:
PR (age 4) / JPM (age 4)
Objectivos Prévios:
Trocar caixas/objectos no seu interior/programar o Robô
Desenrolar e Resultados Gerais:
Neste grupo faltou um elemento, o PR, por essa razão faço apenas referência ao JPM.
O JPM conseguiu fazer a troca de objectos dentro das caixas com bastante facilidade, ele retirou duas caixas da
mala de ferramentas, tirou um camião e uma bomba da mesma e colocou esses objectos em cada um dos
compartimentos da caixa, e digo caixa porque embora ele tivesse tirado duas ele juntou a segunda à primeira, o que
origina, como sabemos, uma só caixa com dois compartimentos. Depois trocou de um lado para o outro o camião e a
bomba, sem grandes dificuldades. De seguida, e após ele ter realizado esta tarefa por diversas vezes, sugeri que o JPM
Observações:
O JPM perguntou ao início, qual a razão pela qual se joga sempre o mesmo jogo.
Session 4
Início: 09h 40m Fim: 10h 2m
PR (age 4) / JPM (age 4)
Objectivos Prévios:
Trocar caixas/objectos no seu interior/programar o Robô
Desenrolar e Resultados Gerais:
O PR após ter navegado com o helicóptero, ele pousou-o e dirigiu-se para casa. Dentro da casa ele, com a minha
indicação, começou por tirar duas caixas da mala de ferramentas, um camião e uma bomba. Colocou esses mesmos
objectos nas caixas e esteve a trocá-los de posição. Depois, pegou nessa mesma caixa e deu-a ao robô, tendo assim
entrado no pensamento deste. Aí ele ensinou o robô a trocar os objectos de sítio e a volta-los a colocar na posição
correcta. Em seguida retirou uma balança da mala de ferramentas para saber quando é que o robô termina a sua tarefa.
(a colocação da balança foi feita por minha indicação). Terminado o ensinamento, o PR saiu do pensamento do robô e
foi verificar se o robô estava ou não a trabalhar como ele o ensinara. No fim resolveu que tinha de rebentar com as casas
e foi o que ele fez, com bastante contentamento.
O JPM teve grandes dificuldades em navegar e pousar o helicóptero, principalmente em pousar junto às casas.
Tive de colocar a minha mão sobre a dele, para que este conseguisse pousar junto às casas. Já dentro da casa, o JPM
quis somente rebentar com as casas. Ele rebentou com uma, saiu da casa entrou no heli e foi ver o resultado, rebentou
com a outra e fez o mesmo, quando só faltava uma casa para rebentar decidiu que não queria mais jogar.
Lista de elementos de registo (ficheiros) associados:
Observações:
O JPM perguntou ao início da sessão anterior o porquê de estarmos sempre com o mesmo jogo. Este
aborrecimento poderá estar a influenciar o seu desempenho e o seu interesse nas sessões do Toon Talk.
Session 5
Início: 10h10m Fim: 10h30m
PR (age 4) / JPM (age 4)
Objectivos Prévios:
Trocar caixas/objectos no seu interior/programar o Robô
Desenrolar e Resultados Gerais:
Nesta sessão de toon talk, o PR e o JPM quiseram trabalhar em conjunto no toon talk. Durante toda a sessão
estas duas crianças estiveram a trabalhar em sintonia ajudando-se mutuamente. Teria sido bom que ambas tivessem
optado por ensinar o robô a trabalhar, no entanto não o fizeram, pois optaram por fazer cópias de camiões, balanças e
caixas, bem como em aspirar os mesmos. Quando se cansaram de fazer cópias e de aspirar, resolveram rebentar com as
casas, o que lhes deu um grande gozo.
Apesar de não terem avançado muito, penso que esta sessão correu bem, pelo facto de ter possibilitado um
desempenho totalmente feito em conjunto por estas duas crianças, durante o qual eu pude observar a perfeita sintonia
existente entre estas duas crianças.
Lista de elementos de registo (ficheiros) associados:
Observações:
Observações:
O JPM faltou.
Session 7
Início: 00 h00m Fim: 00h00m
PR (age 4) / JPM (age 4)
Objectivos Prévios:
Fazer corresponder a imagem da folha com a localização dos bonecos (carro, peão).
Desenrolar e Resultados Gerais:
O PR esteve a ensinar ao JPM o que aprendeu na sessão anterior. Não teve grandes dificuldades em demonstrar
como se fazia. O JPM não entendeu muito bem todas aquelas trocas que o PR realizou, mas com a minha explicação ele
conseguiu realizar a actividade sem grandes dificuldades. No entanto, e como o PR quis explicar ao JPM como se fazia,
eu não lhes expliquei como copiar as imagens para o ToonTalk, tendo optado por o fazer antes do PR começar a sua
explicação.
Lista de elementos de registo (ficheiros) associados:
Observações:
Group 3
Session 1
Início: 11h10m Fim: 11h30m
AR (age 4) / RJ (age 4)
Objectivos Prévios:
Introdução ao TOON TALK (breve apresentação do ambiente do Toon Talk).
Desenrolar e Resultados Gerais:
A AR sentiu bastantes dificuldades em realizar todas as tarefas do jogo, desde o pilotar até ao agarrar dos
objectos. Esta criança, por diversas vezes trocou os comandos de pilotagem do heli, o que lhe dificultou a sua
aterragem, não conseguiu passear com o boneco, pois estava constantemente a sentá-lo sem querer. Após conseguir
entrar na casa escolhida (a que estava à sua frente), ela brincou com o aspirador, com a bomba, tirou objectos da caixa
de ferramentas, mas sempre com bastantes dificuldades, tendo tido, durante toda a sessão, uma grande ajuda minha.
No que diz respeito ao RJ, as anotações por mim tomadas são as mesmas que tirei para a criança anterior. As
dificuldades sentidas por este menino, foram as mesmas sentidas pela AR.
Lista de elementos de registo (ficheiros) associados:
Observações:
Observações:
O RJ esteve sempre interessado no desenrolar do “trabalho” da AR, tendo ajudado esta aquando da construção
de casas. A AR queria construir casas mas, esqueceu-se que tinha de colocar uma caixa no camião. O RJ, desde logo,
alertou a sua colega para esta falha, e explicou a solução.
Session 3
Início: 10h10m Fim: 10h35m
AR (age 4) / RJ (age 4)
Objectivos Prévios:
Trocar caixas/objectos no seu interior/programar o Robô
Desenrolar e Resultados Gerais:
A AR mal se sentou começou logo a jogar, fazer casas e mais casas sem ajuda. Ela começou a colocar nos
camiões caixas e robôs e eu perguntei se ela sabia o que estava a fazer, tendo ela respondido que estava a construir
casas. Após ter construído varias casas, sugeri que ela trocasse objectos dentro das caixas, tarefa que ela realizou sem
grande dificuldade. Em seguida expliquei-lhe que o robô também podia fazer o mesmo e que para isso bastava ensina-
lo. Então ela perguntou como se fazia e eu expliquei. Após esta minha explicação, a AR deitou “mãos ao trabalho” e
programou o robô sem que para isso eu tivesse que a estar constantemente a ajudar.
O RJ só quis fazer casas e rebentar com as mesmas, não consegui levá-lo a realizar as tarefas que a AR realizou.
No entanto, e de acordo com o desempenho do RJ no tipo de tarefa que realizou, penso que não irá ter grandes
dificuldades em programar o robô.
Lista de elementos de registo (ficheiros) associados:
Observações:
Session 4
Início: 10h06m Fim: 10h35m
AR (age 4)/ RJ (age 4)
Objectivos Prévios:
Trocar caixas/objectos no seu interior/programar o Robô
Desenrolar e Resultados Gerais:
A AR tentou, assim que aterrou o helicóptero, programar o robô por três vezes consecutivas. Eu esperei para ver
se ela dava conta do porquê de não conseguir realizar tal tarefa, no entanto tive de intervir para lhe explicar que não se
consegue programar o robô no chão da rua. Assim, ela entrou na casa com alguma dificuldade, pois não conseguia
acertar com a porta, e de imediato retirou um robô da caixa de ferramentas, duas caixas vazias que encheu uma com o
nº1 e a outra com a letra A, juntou as duas e o rato fez a colagem das mesmas. Depois ela deu ao robô as respectivas
caixas, ou melhor a caixa com dois compartimentos e programou o robô a aspirar o conteúdo da caixa. Saiu e veio testar
o robô. Após verificar o seu funcionamento, ela programou outro robô a aspirar de uma caixa um camião. Esta segunda
programação foi inteiramente feita por ela sem o meu auxílio.
Observações:
A AR quando teve de dar a caixa ao robô para entrar no seu pensamento, ela utilizou a caixa inicial, ao contrário
das outras crianças, que vão sempre buscar uma nova caixa à mala de ferramentas.
Session 5
Início: 09h35m Fim: 10h05m
AR (age 4) / RJ (age 4)
Objectivos Prévios:
Trocar caixas/objectos no seu interior/programar o Robô
Desenrolar e Resultados Gerais:
A AR ensinou o robô a copiar caixas com o nº 1 e a aspirar as mesmas. Para entrar no pensamento, a AR deu ao
robô uma caixa com a letra A. Em seguida entrou no pensamento e retirou uma caixa vazia e um caixa de nº da mala de
ferramentas, colocou a última dentro da primeira e agarrou na varinha mágica e fez 3 cópias. Em seguida pegou no
aspirador e aspirou-as. Ao aspirar, a AR esqueceu-se de parar o aspirador, no entanto conseguiu aspirar só o pretendido,
pois não existia mais nada, no seu caminho, que pudesse ser aspirado acidentalmente.
Após ter testado o robô, dando-lhe uma caixa igual à que o robô tinha no seu pensamento, caixa essa que voltou
a retirar da mala de ferramentas, a AR construiu casas, retirando um camião, uma caixa e um robô da mala de
ferramentas.
O RJ, esteve a ensinar um robô a construir casas, e outro a destruir uma casa. Para isso, ele deu ao robô uma
caixa com uma balança e já dentro do pensamento, retirou um camião, uma caixa e um robô da mala de ferramentas e
programou um robô a construir casas. Veio testar esse mesmo robô, teste esse que não conseguiu realizar à primeira
porque deu uma caixa com um robô e não a caixa que estava no pensamento do robô. No entanto, após eu ter explicado
e lembrado, ele conseguiu fazer o teste.
No segundo robô, o RJ deu uma caixa com um camião, entrou no pensamento e retirou uma bomba da mala de
ferramentas e rebentou com o pensamento. Realizou o teste sem cometer o erro anterior.
Lista de elementos de registo (ficheiros) associados:
Observações:
Session 6
Início: 10h07m Fim: 10h31m
AR (age 4) / RJ (age 4)
Objectivos Prévios:
Avaliar o desempenho da criança.
Desenrolar e Resultados Gerais:
A AR começou por construir várias casas, depois retirou duas caixas da mala de ferramentas e colou-as. No
buraco do lado esquerdo colocou a letra A e no buraco do lado direito o nº 1. Agarrou essa mesma caixa e deu-a ao
robô. Entrou no pensamento, retirou um ninho da mala de ferramentas, pousou-o, retirou mais alguns objectos e, desses
objectos deu alguns ao pássaro. Depois quis sair do pensamento, mas não se recordava como fazer. Esperei um pouco
para ver se ela se lembrava, mas conseguiu sair com o auxílio do RJ que se aprontou a ajudar a sua colega. Quando veio
testar o robô, também não se conseguiu lembra como se fazia. Para conseguir realizar essa tarefa eu tive de lhe explicar
os procedimentos que devia tomar. No entanto, esperei que ela se conseguisse lembrar e/ou que o RJ a apoiasse. Para
acabar rebentou com algumas casas.
O RJ começou por construir casas, em seguida retirou uma caixa e o nº 1 da mala de ferramentas, colocou o
último dentro da primeira e agarrou a caixa e colocou-a nas mãos do robô (teve dificuldade em agarrar na caixa por
completo, isto é, ao tentar agarrar a caixa ele agarrou o nº.). Já no pensamento, ensinou o robô a retirar alguns objectos
Observações:
Ambas as crianças disseram que não queriam trabalhar no Toon Talk, aquando do início da actividade.
Session 7
Início: Fim:
AR (age 4) / RJ (age 4)
Objectivos Prévios:
Fazer corresponder a imagem da folha com a localização dos bonecos (carro, peão).
Desenrolar e Resultados Gerais:
O RJ não quis fazer a actividade proposta. Embora eu tivesse tentado encaminha-lo para o que tinha planeado,
não consegui persuadi-lo da sua vontade de rebentar com as casas para depois ver os trabalhadores a reconstrui-las.
Lista de elementos de registo (ficheiros) associados:
Observações:
A AR faltou
Session 8
Início: Fim:
AR (age 4) / RJ (age 4)
Objectivos Prévios:
Fazer corresponder a imagem da folha com a localização dos bonecos (carro, peão).
Desenrolar e Resultados Gerais:
O RJ conseguiu realizar a troca no chão da casa, mas não conseguiu ensinar o robô, embora eu tenha
exemplificado várias vezes. Ele entrou no pensamento do robô com a caixa mas depois ele fez a troca e muitas mais
coisa, como o copiar, o aspirar, enfim fez de tudo sem se aperceber de que tudo o que fazia o robô também iria fazer. O
resultado, como é evidente foi uma tremenda “salgalhada” sem princípio nem meio nem fim.
Lista de elementos de registo (ficheiros) associados:
Observações:
A AR faltou.
Group 4
Session 1
Início: 10h20m Fim: 10h40m
L (age 4) / MT (age 4)
Objectivos Prévios:
Introdução ao TOON TALK (breve apresentação do ambiente do Toon Talk).
Desenrolar e Resultados Gerais:
Neste grupo de duas crianças, a que se destacou mais, pela positiva, foi a MT, pois ela conseguiu, desde logo,
realizar com alguma destreza, o percurso com o heli e também todas as outras tarefas que se lhe apresentaram pela
frente, como foi o caso de entrar em casa, fazer sentar o boneco, tirar objectos da caixa de ferramentas, e trabalhar com
alguns dos instrumentos tais como, o aspirador e a varinha mágica.
Observações:
Session 2
Início: 10h05m Fim: 10h26m
L (age 4) / MT (age 4)
Objectivos Prévios:
Identificar e trabalhar com algumas ferramentas do TOONTALK.
Desenrolar e Resultados Gerais:
A MT conseguiu lembrar-se do que aprendeu na 1ª sessão, o que originou a que neste dia, ela tenha trabalhado
facilmente com as ferramentas do TOON TALK (aspirador, varinha mágica e bomba de encher). Esta criança fez descer
o heli, entrou em casa, e fez sentar o boneco sem praticamente ter pedido ajuda. Para trabalhar com as diversas
ferramentas a MT precisou de alguma ajuda, nomeadamente para encher alguns objectos tirados da caixa de
ferramentas, uma vez que, esta tarefa não tinha ainda sido explorada pela criança. Em tudo o resto, a MT esteve sempre
com alguma à vontade e compenetrada no que fazia.
O L teve muitas dificuldades em realizar esta sessão. Não se lembrou do que tinha aprendido, e mesmo com a
minha ajuda para o fazer recordar, ele não conseguiu trabalhar com as diferentes funcionalidades do jogo. Continua a
trocar o botão que leva o heli no sentido descendente com o que o leva no sentido ascendente, dificultando assim a sua
pilotagem. Para tirar um objecto da caixa de ferramentas, recolhe dois ou três diferentes dos escolhidos e só depois, com
bastante insistência minha para que estivesse com atenção ao movimento do objecto, é que ele conseguiu tirar o
escolhido. No que respeita a aspirar e a fazer copias as dificuldades prenderam-se com o mesmo facto, ou seja, a criança
não dá atenção ao movimento do objecto escolhido.
Lista de elementos de registo (ficheiros) associados:
Observações:
A MT ajudou o L durante o tempo em que este esteve a realizar a actividade, contudo esta sessão foi
interrompida pelo facto de a MT se ter fartado de estar na sala e ter dito que queria vir embora. O L perante a atitude da
Teresa foi de “arrasto” com ela.
Session 3
Início: 10h40m Fim: 10h55m
L (age 4) / MT (age 4)
Objectivos Prévios:
Trocar caixas/objectos no seu interior/programar o Robô
Desenrolar e Resultados Gerais:
A terceira sessão realizada por este grupo, não se desenrolou como estava à espera pois, a MT só quis encher e
esvaziar objectos com a bomba de encher, no entanto conseguiu realizar esta tarefa com bastante facilidade.
O L esteve constantemente a construir e a destruir casas, e embora estivesse a faze-lo com muita satisfação, ele
não conseguiu permanecer muito tempo no computador.
Lista de elementos de registo (ficheiros) associados:
Observações:
A MT quando tentou encher os objectos pela primeira vez, utilizou a bomba de destruição, mas após eu ter
explicado qual a diferença entre uma e outra, ela não trocou mais as bombas .
Observações:
Session 5
Início: 00h00m Fim: 00h0m
L (age 4) / AC (age 4) – this matches session 6b of group 5.
Objectivos Prévios:
Avaliar o desempenho da criança.
Desenrolar e Resultados Gerais:
O L começou por retirar objectos ao acaso da mala de ferramentas e a desloca-los de um lado para o outro.
Depois, com a indicação da AC, ele deu uma caixa ao robô e entrou no pensamento. Aí ensinou o robô a retirar uma
caixa da mala de ferramentas, um camião, que colocou dentro da caixa e um ninho. Depois saiu do pensamento e testou
o robô. (toda a tarefa foi realizada pelo L com a indicação da AC).
A AC esteve somente a trabalhar no chão (da rua), retirando para o mesmo diversos objectos, tendo-se limitado a
transportá-los de um lado para o outro. Este facto supeendeu-me bastante, pois ela esteve constantemente a ajudar o L.
Lista de elementos de registo (ficheiros) associados:
Observações:
Session 6
Início: 00h00m Fim: 00h0m
L (age 4) / AC (age 4) – this matches session 7b of group 5.
Objectivos Prévios:
Fazer corresponder a imagem da folha com a localização dos bonecos (carro, peão).
Desenrolar e Resultados Gerais:
O L fez a troca dos sinais no chão da casa e posteriormente ensinou o robô a realizar a mesma tarefa. No chão da
casa ele retirou os dois sinais da caixa e colocou-os no chão. Depois pegou no que estava no lado esquerdo e colocou-o
no lado direito e o que estava no lado direito colocou-o no lado esquerdo, tendo depois desfeito essa troca para dar a
caixa ao robô. Dentro do pensamento do robô ele realizou a tarefa com uma pequena diferença. Retirou-o o sinal do
lado esquerdo e colocou-o no chão e depois pegou no do lado direito e colocou-o logo no lado esquerdo da caixa. Em
seguida pegou no outro sinal e colocou-o no respectivo lugar. Entretanto ele ia desfazer o que havia feito, pois foi o que
fez no chão da casa. Então tive de lhe explicar porque razão ele tinha desfeito a troca no chão da casa. Ele compreendeu
a razão, e o objectivo da actividade.
Observações:
Session 7
Início: 00h00m Fim: 00h0m
L (age 4) / AC (age 4) – this matches session 8b of group 5.
Objectivos Prévios:
Fazer corresponder a imagem da folha com a localização dos bonecos (carro, peão).
Desenrolar e Resultados Gerais:
O L realizou a tarefa de imediato no pensamento do robô sem grandes dificuldades. No entanto, ao contrário de
algumas crianças, este não conseguiu copiar sozinho os sinais e o camião.
A AC fez a actividade com o meu auxílio. Ela fez as trocas no chão da casa, ensinou o robô a destrocar o que o L
tinha trocado, mas sempre com a minha ajuda, pois não se lembrava sequer de como se fazia para entrar no pensamento
do robô.
Lista de elementos de registo (ficheiros) associados:
Observações:
Group 5
Session 1
Início: 09h40m Fim: 10h13m
AA (age 5) / AC (age 4)
Objectivos Prévios:
Introdução ao TOON TALK (breve apresentação do ambiente do Toon Talk).
Desenrolar e Resultados Gerais:
Ambas as crianças conseguiram identificar o heli, mas não identificaram as casas como tal, quando vistas de
cima.
A AA teve dificuldades em se aperceber se o heli tinha ou não pousado, pois para ela este já estaria no chão
desde o momento em que se encontra ao mesmo nível das casas e, embora eu tenha feito referência e alertado para o
facto de o heli só se encontrar pousado quando não se encontrasse com as pás em movimento e com o motor silenciado,
ela continuou a ter dificuldades em se aperceber se de facto o heli se encontrava ou não parado. Por esta razão eu insisti
na navegação para que a AA se apercebesse de tal facto.
No que diz respeito ao agarrar de objectos, a AA não teve grandes dificuldades em entender que para realizar tal
tarefa, necessitava de ver o objecto pretendido a abanar. No entanto, e como gostou de retirar objectos da caixa e de os
colocar no chão, a certa altura eram tantos em tão pouco espaço, que a levou a sentir bastantes dificuldades para os
agarrar, como é evidente.
Em relação ao outro membro do grupo, a AC, posso referir que esta sentiu muitas dificuldades em todo o tipo de
tarefa que fez, na navegação, no deslocamento do boneco, no agarrar, no aspirar.... Penso no entanto que as dificuldades
se devem só à não compreensão das “regras” do jogo, mas também ao seu menor desenvolvimento, ao nível da
motricidade fina, pois tem bastantes dificuldades em trabalhar com o rato.
Lista de elementos de registo (ficheiros) associados:
Observações:
Observações:
Session 3
Início: 09h45m Fim: 10h28m
AA (age 5) / AC (age 4)
Objectivos Prévios:
Trocar caixas/objectos no seu interior/programar o Robô
Desenrolar e Resultados Gerais:
A AA começou por tirar alguns objectos da mala de ferramentas, letras, números e caixas.
Ela colocou uma caixa com o nº 2 e tentou colocar uma letra nessa mesma caixa. Não deu resultado. Eu
expliquei o porquê de não dar para fazer isso e ela em seguida tirou uma caixa vazia e colocou a letra A e depois
colocou mais duas vezes a mesma letra. Em seguida copiou, com a varinha mágica essa caixa e aspirou tudo. Em
seguida, expliquei como se poderia fazer para ensinar o robô a trabalhar sozinho. Ela gostou da ideia, e após a minha
explicação ela começou logo a trabalhar. Então deu uma caixa vazia ao robô, entrou no pensamento e ensinou o robô a
tirar uma caixa da mala de ferramentas, retirar um camião e coloca-lo lá dentro, depois tirou outra caixa e colocou
dentro desta uma balança e trocou os conteúdos das caixas. Saiu do pensamento e veio ver o robô a trabalhar. Quando
deu a caixa vazia ao robô este começou a trabalhar, no entanto apareceu uma mensagem emitida pelo marciano de que o
robô havia perdido o rasto a muita coisa e que ele não esperava trabalhar com tanta coisa. No entanto, e apesar do erro,
a AA conseguiu ver o robô a trabalhar.
A AC começou também por retirar objectos da mala de ferramentas e a coloca-los dentro de caixas, depois
aspirou tudo o que havia retirado e colocado no chão da casa e pegou numa caixa vazia e deu-a ao robô. Entrou no
pensamento deste e programou-o não para fazer trocas, porque ela não o quis, mas sim para o ensinar a aspirar. Então
ensinou o robô a aspirar uma letra, um nº e um camião. Saiu do pensamento e veio ver o robô a trabalhar.
Por fim a AA decidiu aspirar a casa toda e sair.
Lista de elementos de registo (ficheiros) associados:
Observações:
Session 4
Início: 10h 40m Fim: 11h00m
AA (age 5) / AC (age 4)
Objectivos Prévios: Trocar caixas/objectos no seu interior/programar o Robô
Observações:
A AC faltou.
Session 5
Início: 14h 10m Fim: 14h36m
MA (age 5) / AA (age 5) – this matches session 5 in group 6.
Objectivos Prévios:
Trocar caixas/objectos no seu interior/programar o Robô
Desenrolar e Resultados Gerais:
O MA a primeira coisa que fez foi rebentar com a casa (já não se lembrava como se fazia). Posteriormente
entrou noutra casa e foi ensinar o robô. Ele já não sabia qual era o robô. Eu disse-lhe qual era o robô e ele deu uma
caixa vazia e entrou no pensamento. No pensamento, o MA confundiu a mão que o robô mexe com a mão que lhe
permite agarrar os objectos. Após ter entendido qual a mão que agarra (através da minha explicação), tirou duas caixas
vazias da mala de ferramentas e colocou em cada uma delas dois camiões, tendo de seguida trocado os respectivos
lugares. Saiu do pensamento do robô, verificou se o robô trabalhava ou não, e em seguida rebentou com a casa.
O MA realizou esta actividade praticamente sem o meu auxílio.
A AA deu ao robô uma caixa com a letra A e já no pensamento ela agarrou na letra e escreveu o seu nome (com
a minha ajuda). Depois retirou três caixas da mala de ferramentas e colocou o seu nome, noutra colocou o nº um e na
última a letra A. Posteriormente trocou o nome com o nº e veio verificar o resultado. No fim rebentou com a casa.
Lista de elementos de registo (ficheiros) associados:
Observações:
Session 6a
Início: 09h40m Fim: 10h00m
MA (age 5) / AA (age 5)
Objectivos Prévios:
Avaliar o desempenho da criança.
Desenrolar e Resultados Gerais:
A AA mal entrou na casa quis rebentar com a mesma. Como já vem sendo hábito este tipo de acção, eu
perguntei-lhe se ela ainda se lembrava como se ensina o robô a trabalhar e porque não ensina-lo a construir casas. Ela
aceitou o meu desafio e deu ao robô uma caixa com um camião (eu perguntei o porquê de ser um camião e não outra
coisa qualquer para verificar se ela já estava a pensar que para se construir casas precisamos de um camião, no entanto
foi uma escolha ao acaso ou seja não tinha essa intenção). Já dentro do pensamento, ela retirou um camião, uma caixa
(que colocou prontamente no camião) e um robô que colocou dentro da caixa transportada pelo camião. Verificou se o
robô construiu alguma casa, facto de que se apercebeu de imediato, pois estavam na mesma 3 casas, quando só
deveriam existir duas pois tinha já rebentado com uma. Para finalizar, e como não podia deixar de ser, a AA rebentou
com todas as casas que existiam.
O MA seguiu exactamente os mesmos passos da AA, rebentou com uma casa, foi programar o robô para
construir casa, a única diferença foi ter dado ao robô uma caixa com uma letra para entrar no seu pensamento. No
Observações:
Session 6b
Início: 00h00m Fim: 00h0m
L (age 4) / AC (age 4) – this matches session 5 of group 4.
Session 7a
Início: 00h00m Fim: 0h00m – this matches session 7 of group 6.
MA (age 5) / AA (age 5)
Objectivos Prévios:
Fazer corresponder a imagem da folha com a localização dos bonecos (carro, peão).
Desenrolar e Resultados Gerais:
Ambas as crianças realizaram a tarefa “manualmente”, numa primeira fase, e depois ensinaram o robô a fazer a
mesma correspondência.
A primeira criança a trabalhar foi o MA. Este teve de ensinar o robô a trocar o objecto do compartimento da
direita para o compartimento da esquerda, de modo a colocar o sinal dos peões mais perto do boneco que está na folha.
Conseguiu, embora com alguma dificuldade, pois não se recordava como ensinar o robô.
A AA não conseguiu realizar a tarefa de forma autónoma. Fui eu quem praticamente fez a actividade, pois
embora ela tivesse estado atenta, não conseguiu lembrar-se da maior parte das acções para que pudesse realizar a dita
tarefa.
Lista de elementos de registo (ficheiros) associados:
Observações:
Session 7b
Início: 00h00m Fim: 00h0m
L (age 4) / AC (age 4) – this matches session 6 of group 4.
Session 8a
Início: 00h00m Fim: 0h00m – this matches session 8 of group 6.
MA (age 5) / AA (age 5)
Objectivos Prévios:
Fazer corresponder a imagem da folha com a localização dos bonecos (carro, peão).
Desenrolar e Resultados Gerais:
Ambas as crianças conseguiram realizar a tarefa, embora com alguma dificuldade, nomeadamente a AA. No
entanto esta teve uma prestação bastante mais positiva do que na sessão anterior. A actividade foi idêntica a anterior,
mas desta vez, foram as crianças a copiar os bonecos (sinais; camião) para o ToonTalk.
A ordem da realização da actividade foi a mesma da sessão anterior, para que assim, a AA, que teve muitas
dificuldades da última vez, observasse com atenção para que a sua prestação melhorasse.
Lista de elementos de registo (ficheiros) associados:
Observações:
Session 8b
Início: 00h00m Fim: 00h0m
L (age 4) / AC (age 4) – this matches session 7 of group 4.
Observações:
Session 2
Início: 10h55m Fim: 11h22m
MA (age 5) / M (age 4)
Objectivos Prévios:
Identificar e trabalhar com algumas ferramentas do TOONTALK.
Desenrolar e Resultados Gerais:
O MA sentiu dificuldades em agarrar objectos, não conseguiu interiorizar que para tal feito, tem de ter o objecto
escolhido a mexer, teve também alguns problemas ao aspirar, foram várias as tentativas para aspirar, no entanto ele
fazia-o sempre com o aspirador no chão, mesmo após eu ter explicado como se tem de proceder. Para além destas
dificuldades, o MA teve os mesmos problemas da sessão anterior, embora de forma mais aligeirada.
O M surpreendeu-me pela positiva. Foi só lembrar como se faziam as diversas tarefas, para que ele começasse a
trabalhar sozinho sem ligar a ninguém. Conseguiu aspirar objectos retirados da caixa de ferramentas, fazer cópias, e
explodir com as casas, o que para ele foi deveras divertido.
Lista de elementos de registo (ficheiros) associados:
Observações:
Session 3
Início: 10h30m Fim: 10h57m
MA (age 5) / M (age 4)
Objectivos Prévios:
Trocar caixas/objectos no seu interior/programar o Robô
Observações:
Foi muito estranho para mim o desempenho do M, não por ele se ter esquecido de como realizar esta ou aquela
tarefa, mas sim a dificuldade sentida após o ter lembrado de como se fazia. Espero porém que seja fruto de um mau dia,
pois na sessão anterior o M surpreendeu-me pela positiva.
Session 4
Início: 11h15m Fim: 11h35m
MA (age 5) / M (age 4)
Objectivos Prévios:
Trocar caixas/objectos no seu interior/programar o Robô
Desenrolar e Resultados Gerais:
O MA, retirou uma caixa da mala de ferramentas, uma letra e colocou esta última na caixa. Pegou na caixa e
deu-a ao robô para entrar no pensamento. Já lá dentro, ele ensinou o robô a aspirar objectos do interior das caixas. Para
tal, retirou um camião e uma caixa, introduziu o primeiro dentro desta e aspirou-o. Veio ver o robô a trabalhar, mas
esqueceu-se de dar uma caixa idêntica à do pensamento do robô. Eu alertei o Miguel para este facto e ele conseguiu ver
o trabalho do robô.
Depois, ensinou o robô a aspirar uma bomba da caixa. Tanto na primeira como na segunda programação, tive de
auxiliar a criança, pois ele sentiu algumas dificuldades, nomeadamente, no agarrar nos objectos, entrar no pensamento e
agarrar objectos com o robô. No entanto, essa minha ajuda foi menor na segunda programação.
O M, e embora eu lhe tenha explicado e exemplificado como se programa o robô, não se mostrou interessado em
realizar tal tarefa. Fez somente algumas cópias de objectos e rebentou com muitas casas.
Fiz uma programação do robô com ele, após este ter estado a brincar livremente no jogo, para ver se o conseguia
levar a interessar-se mas não consegui, pois logo que acabamos de programar ele quis ir embora.
Lista de elementos de registo (ficheiros) associados:
Observações:
Session 5
Início: 14h 10m Fim: 14h36m
MA (age 5) / AA (age 5) – this matches session 5 of group 5.
Session 6
Session 7
Início: 00h00m Fim: 0h00m – this matches session 7a of group 5.
MA (age 5) / AA (age 5)
Session 8
Início: 00h00m Fim: 0h00m – this matches session 8a of group 5.
MA (age 5) / AA (age 5)
Observações:
Session 2
Change in group composition due to absentees. This session matches Session 2 in group 2.
Início: 11h 24m Fim: 11h 49m
PR (age 4)/LE (age 5)
Objectivos Prévios:
Identificar e trabalhar com algumas ferramentas do TOONTALK.
Desenrolar e Resultados Gerais:
O LE não teve dificuldade alguma em realizar esta actividade. Não necessitou de nenhum tipo de ajuda, eu só lhe
dei algumas dicas para ele fazer este ou aquele tipo de tarefa, como o aspirar objectos do interior das caixas, copiar
objectos, rebentar com as casas, etc.
O PR, sentiu mais dificuldades, nomeadamente no agarrar, aspirar e copiar, pois esqueceu-se frequentemente de
que o objecto com que quer trabalhar tem de estarem movimento.
As dificuldades sentidas por esta criança prendem-se com o facto de esta não conseguir permanecer muito tempo
concentrada no que está a realizar.
Lista de elementos de registo (ficheiros) associados:
Observações:
Session 3
No records.
Session 4
No records.
Session 5
Início: 15h11m Fim: 15h39m
IX (age 4) / LE (age 5)
Objectivos Prévios: Trocar caixas/objectos no seu interior/programar o Robô
Observações:
A IX faltou.
Session 6
Início: 15h11m Fim: 15h39m
FG (age 5) / LE (age 5) – this matches session session 7 of group 8.
Objectivos Prévios:
Fazer corresponder a imagem da folha com a localização dos bonecos (carro, peão).
Desenrolar e Resultados Gerais:
O LE realizou a tarefa sem grandes dificuldades. Ele fez as trocas no chão da casa, e depois deu as caixas (na
posição inicial) ao robô, entrou no seu pensamento e ensinou-o a realizar a troca de forma a que o sinal do lado
esquerdo fosse colocado no lado direito de forma a que este fica-se mais perto da imagem colocada na folha. O
objectivo da actividade foi bem compreendido por esta criança.
O FG não quis realizar a tarefa no chão da casa, tendo por isso tido mais dificuldade em a realizar logo no
pensamento do robô. No entanto com alguma ajuda minha, ajuda essa verbal, ele conseguiu destrocar o que o LE havia
feito. O objectivo da actividade foi também por ele percebido. Se a actividade tivesse sido realizada primeiramente por
esta criança, certamente teria tido muitas mais dificuldades em a concretizar, por essa razão o coloquei a fazer após o
LE.
Lista de elementos de registo (ficheiros) associados:
Observações:
Session 7
Início: Fim:
FG (age 5) / LE (age 5) – this matches session 8 of group 8.
Objectivos Prévios:
Fazer corresponder a imagem da folha com a localização dos bonecos (carro, peão).
Desenrolar e Resultados Gerais:
O LE foi novamente ao primeiro a “trabalhar”. Nesta sessão expliquei como se fazia para se copiar os bonecos
para o ToonTalk. Embora não conseguisse fazê-lo de imediato, o LE à terceira tentativa copiou os desenhos e foi ele
que fez o cenário para a actividade. Após estar tudo no lugar ele fez a troca dos objectos no chão da casa e
posteriormente deu as caixas na posição inicial (porque eu o alertei para tal facto) e ensinou o robô. A actividade foi
realizada com sucesso, apesar de o facto de ter de copiar os desenhos o ter confundido um pouco no início.
O FG teve mais dificuldade em concretizar a actividade, facto esse que está certamente relacionado com a falta
de atenção durante a prestação do LE e também a falta de vontade de a realizar, pois a sua vontade era rebentar com as
casas.
Lista de elementos de registo (ficheiros) associados:
Observações:
Observações:
Session 2
Início: 11h45m Fim: 12h15m
FG (age 5) / JPF (age 3) – this matches session 2 of group 10.
Objectivos Prévios:
Identificar e trabalhar com algumas ferramentas do TOON TALK.
Desenrolar e Resultados Gerais:
Nesta sessão o JPF conseguiu, após eu o ter lembrado, realizar as tarefas com bastante facilidade. Ele recolheu,
aspirou e copiou objectos com bastante à vontade, o único problema foi a quantidade de objectos que ele tirou para o
chão da casa que a transformou num “campo de batalha”. No fim ele quis explodir as casas, tarefa que lhe deu um
enorme gozo e que repetiu vezes sem conta.
O FG teve mais dificuldades. Ele não se conseguia lembrar de nada do que tinha feito na sessão anterior, e após
eu o ter relembrado, continuou a sentir dificuldades em realizar algumas das tarefas, nomeadamente o recolher objectos,
aspirar e o copiar.
Lista de elementos de registo (ficheiros) associados:
Observações:
A facilidade demonstrada pelo JPF na realização das tarefas é de facto algo que me surpreendeu, dado que esta
criança tem algumas dificuldades em realizar desenhos no Paint e jogos no computador.
Session 3
Início: 11h30m Fim: 12h07m
FG (5 anos) / JPF (3 anos) – this matches session 3 of group 10.
Objectivos Prévios: Trocar caixas/objectos no seu interior/programar o Robô
Desenrolar e Resultados Gerais:
O FG entrou na casa e tirou alguns objectos que em seguida aspirou. Posteriormente, voltou a tirar alguns
objectos da mala de ferramentas e fez cópias com a varinha mágica. Após ele ter realizado algumas tarefas que já tinha
realizado na sessão anterior, eu disse-lhe que poderíamos ensinar o robot a trabalhar sozinho. Ele mostrou-se
interessado e então expliquei e exemplifiquei como se faz para que ele tentasse programar o robot.
Observações:
Session 4
Início: 09h40m Fim: 10h12m
FG (age 5) / JPF (age 3) – this matches session 4 of group 10.
Objectivos Prévios:
Trocar caixas/objectos no seu interior/programar o Robô
Desenrolar e Resultados Gerais:
O FG sentiu grandes dificuldades na realização da tarefa. Não conseguiu entrar na casa à primeira vez, confundiu
a tecla F1 com a tecla Esc quando quis fazer desaparecer o marciano e não se lembrou de como se faz para sentar o
boneco.
Quando entrou na casa, foi logo buscar uma bomba e rebentou com a mesma. Na outra casa, ele já foi para a
programação do robô. Retirou uma caixa e uma letra da mala de ferramentas e colocou a letra no interior da caixa. Em
seguida aspirou a letra. Após ter treinado cá fora ele deu uma caixa com a letra A ao robô e programou o robô a aspirar
de uma caixa a letra A. Teve muitas dificuldades em programar o robô, e como tal estive constantemente a apoiá-lo.
Depois programou outro robô a aspirar um camião, mas teve na mesma grandes dificuldades. Essas dificuldades
também se fizeram sentir aquando da parte de testagem do robô, pois das duas vezes ele cometeu o mesmo engano, não
tendo dado uma caixa idêntica à que o robô tinha no pensamento.
O JPF entrou no pensamento do robô e ensinou-o a aspirar de uma caixa um nº, em seguida testou o robô tendo
depois rebentado com a casa.
Já noutra casa o JPF entrou no pensamento do robô e pegou numa bomba e fê-la rebentar. Testou o robô e gostou
de o ver a rebentar com a casa.
O JPF não teve grandes dificuldades em programar o robô, poucas foram as vezes que tive de intervir Para o
alertar para este ou aquele aspecto.
Lista de elementos de registo (ficheiros) associados:
Observações:
Session 5
Início: 10h05m Fim: 10h25m
FG (5 anos)
Objectivos Prévios: Avaliar o desempenho da criança.
Observações:
Session 6
Início: 15h11m Fim: 15h39m
FG (age 5) / LE (age 5) – this matches session session 6 of group 7.
Session 7
Início: Fim:
FG (age 5) / LE (age 5) – this matches session 7 of group 7.
Group 9
Session 1
Início: 14h40m Fim: 15h06m
AF (age 5) / T (age 5)
Objectivos Prévios:
Introdução ao TOON TALK (breve apresentação do ambiente do Toon Talk)/ Trocar caixas/objectos no seu
interior/programar o Robô.
Desenrolar e Resultados Gerais:
A T entrou na casa e retirou alguns objectos e fez cópias dos mesmos. Em seguida aspirou o chão da casa e deu
ao robô uma caixa com uma balança. (Teve algumas dificuldades em agarrar objectos e em trabalhar com a varinha
mágica e com o aspirador, nomeadamente para os fazer funcionar, pois esquecia-se que os tem de ter na mão para eles
trabalharem). No pensamento ela ensinou o robô a fazer cópias de camiões, retirou um camião, agarrou na varinha
mágica e fez 3 cópias seguidas. Em seguida testou o robô e rebentou com a casa.
O AF, ao contrário do que esperava, conseguiu pilotar e fazer aterrar o helí, entrou na casa e começou a retirar
objectos da mala de ferramentas e a colocá-los no chão da casa. Tudo isto foi feito sem eu lhe ter ensinado nada nem
sequer lhe disse como se fazia. Penso que o facto do ToonTalk estar instalado no PC da sala de actividades foi um
factor preponderante para que esta criança tenha conseguido, na primeira sessão a que está presente, obter tão bom
resultado.
Lista de elementos de registo (ficheiros) associados:
Observações:
A actividade desenvolvida com o AF teve como objectivo inicial, “introduzir a criança” no ambiente do toon
talk, no entanto esta criança demonstrou ter já um conhecimento deste programa, facto pelo qual eu permiti que esta
avançasse até onde avançou sem restrições da minha parte, uma vez que quando me preparava para começar a explicar
o ambiente de trabalho, já ela estava a pilotar o helí, tendo eu optado por ver até onde ela chegava.
Session 2
Início: 00h00m Fim: 00h00m
AF (age 5) / T (age 5)
Objectivos Prévios:
Fazer corresponder a imagem da folha com a localização dos bonecos (carro, peão).
Observações:
Session 3
Início: 00h00m Fim: 00h00m
AF (age 5) / T (age 5)
Objectivos Prévios:
Fazer corresponder a imagem da folha com a localização dos bonecos (carro, peão).
Desenrolar e Resultados Gerais:
O AF, com bastante dificuldade, realizou a actividade programada. Primeiro fez a troca dos objectos
“manualmente”, e aí correu tudo bem, depois ensinou o robô a trocar da mesma forma esses objectos de acordo com a
imagem que estava na folha (note-se que a actividade proposta para esta criança foi a actividade proposta para a sessão
anterior a qual ele não conseguiu realizar), aqui tive de lhe explicar mais uma vez o objectivo da troca dos sinais e
ajudá-lo a realizar essa mesma troca. Penso que ele não percebeu o objectivo da actividade, embora tivesse dito que
sim.
A T realizou a mesma actividade, mas conseguiu, praticamente sem a minha ajuda, chegar ao fim da actividade.
O mais importante para mim foi o facto da T ter entendido o porquê de destrocar a localização das imagens, durante a
actividade.
Lista de elementos de registo (ficheiros) associados:
Observações:
Group 10
Session 1
Início: 11h00m Fim: 11h18m
FG (age 5) / JPF (age 3) – this matches session 1 of group 8.
Session 2
Início: 11h45m Fim: 12h15m
FG (age 5) / JPF (age 3) – this matches session 2 of group 8.
Session 3
Início: 11h30m Fim: 12h07m
FG (age 5) / JPF (age 3) – this matches session 3 of group 8.
Session 4
Início: 09h40m Fim: 10h12m
FG (age 5) / JPF (age 3) – this matches session 4 of group 8.
Observações:
A R nunca esteve presente nas sessões anteriores do Toon Talk. As restantes sessões do JPF estão no anterior
grupo ao qual pertencia.
Session 6
Início: 11h25m Fim: 11h55m
R (age 3) / JPF (age 3)
Objectivos Prévios:
Observações:
Mondrões preschool
First session, all groups:
Esta sessão serviu para apresentar o TT às crianças, assim como alguns conceitos base da sua funcionalidade:
1. Formar grupos de pares (A formação destes grupos tiveram como critério a sua idade e os anos de
projecto (ICEI), existe 1 par que já é o 3º ano que trabalha com o computador);
2. Começámos por escrever os nomes de cada par, depois escolhemos qual a aparência do boneco
do jogo; já no jogo perguntei (o que é aquilo ali em baixo?) ao início fixaram os olhos e não
deram resposta, mas assim que (com a minha ajuda) começámos a descer as sugestões variaram
entre casas (para a maioria) no entanto houve uma criança que achava que a casa do meio era
uma pá, no entanto o seu colega disse logo que não, “aquilo são casas”; houve também outra que
rapidamente disse que estava num helicóptero e que aquilo era fogo. Quando lhes perguntei como
se chamava o transporte, todos disseram que era um helicóptero.
3. Quando aterrámos saímos do helicóptero, e eu sugeri que tentassem sozinhos, prontamente o
fizeram, no entanto os que estão pela 1ª vez no jardim não conseguiram fazer sem a minha ajuda.
4. Voltaram a aterrar e entrámos na casa, depois tentaram tirar coisas da caixa (os que estão pela 1ª
vez não conseguiram fazer sozinhos);
5. Expliquei como se levantavam e depois como tinham tanta coisa no chão falei que teríamos de
limpar. Nesse momento começámos a trabalhar com o aspirador.
6. Saímos da casa e fomos para o helicóptero e depois terminámos.
Todas as crianças experimentaram individualmente.
Group 5
Session 2
GRUPO: (5) SI + SM
TEMPO: 9h55 às 10h15
Nº DE SESSÃO: 2ª
OBJECTIVO: Conseguir fazer o que está proposto nos objectivos gerais;
Construir casas
ACTIVIDADE: No ecrã apontaram para o ícone do TT: e o SM clicou e entrou. Os dois estão autónomos
conseguiram realizar os objectivos gerais. Construíram casas o procedimento utilizado foi igual ao utilizado com o T. A
SI percebeu logo que o camião com o robô e uma caixa construia casas “O Robo fez a casa!!!” (SI)
Session 3
GRUPO: (5) SI + SM
TEMPO:
Nº DE SESSÃO: 3ª sessão
OBJECTIVO:
Descer o helicóptero;
Sair e entrar na casa;
Abaixar;
Tirar objectos da caixa;
Construir casas.
Ensinar o Robô a fazê-las;
Guardar no caderno, com o nome.
ACTIVIDADE:
Os dois recordavam-se de tudo o que tínhamos feito na última sessão (construir casas) e começaram a fazê-lo ora
um ora o outro (quando não estavam com o rato davam sugestões ao que estava a fazer).
Toda a sessão foi passada em: tira camião, mete robô, mete caixa, levanta, saí da casa sobe no helicóptero e
conta as casas.
Tentei sugerir em construir uma cidade, mas nenhum me ligou, queriam era construir casas e conta-las
freneticamente.
SM: ”Queres que tire uma bomba?”
SI: “Sim.”
SI: “arruma a bomba que pode explodir!!!”
Continuaram a construir casas e a contá-las.
Group 6
Session 2
GRUPO: (6) P
TEMPO: 11h25 às 11h45
Nº DE SESSÃO: 2ª
OBJECTIVO: Conseguir fazer o que está proposto nos objectivos gerais;
Construir casas
ACTIVIDADE:
Muito autónoma, realizou tudo o que estava proposto nos objectivos gerais. Tirou várias coisas da caixa, no
entanto aos pássaros deu objectos para eles levarem para o ninho.
Construiu 3 casas, mas teve alguma dificuldade em perceber que as construía, apesar de numa das caixas ter
colocado um objecto à sua escolha (minha sugestão)
343
The teacher.
Observações:
Group 4
Data: 2002/10/25 Início: 10h 33m
Término: 10h 55m
Nome: M / DI
Objectivos:
ajoelhar-se/levantar-se;
levantar/pousar helicóptero;
notar que ao apontar o objecto treme;
agarrar/largar objectos;
Desenrolar e resultados gerais:
O M pousou rápido e ajoelhou-se sem intenção de o fazer.
Ajudei a agarrar alguns objectos, mas não quis experimentar mais.
O DI quis entrar no helicóptero, levantar e pousar de novo. Entrou dentro da casa, já sabe que clicando ajoelha-
se. Ajudei a agarrar objectos e ensinei a construir casas. Quis repetir mas já não se lembrava do quais objectos eram
necessários. Voltei a repetir mas sozinho não conseguiu fazer.
Ensinei também a rebentar as casas. Quis fazer sozinho mas também não conseguiu.
Lista de elementos de registo (ficheiros) associados:
Observações:
O DI experimentou construir casas e rebentá-las, contudo, não foi um objectivo proposto mas que se
proporcionou.
Observações:
O F tem muita dificuldade em controlar o rato e como está constantemente a clicar, não consegue agarrar o que
deseja.
Group 6
Data: 2002/11/29 Início: 14h 15m
Término: 14h 55m
Nome: MA Idade: 5 anos
Objectivos:
descer/levantar helicóptero;
ajoelhar-se/levantar-se;
notar que ao apontar o objecto treme;
agarrar/largar objectos.
Desenrolar e resultados gerais:
O MA identificou só o heli.
Clicando sem ajuda, descobriu como pousava e levantava.
Pousou sem ajuda e num acto de clicar com o rato, ajoelhou-se. Identificou a mão e começou a tirar objectos da
caixa das ferramentas. Sem ajuda, descobriu que ao apontar o objecto treme e é aquele que a mão agarra. Tirou os
objectos todos e experimentou várias vezes o agarrar/largar os objectos.
Sugeri que voltasse a arrumar os objectos para “arrumar a casa”. Como não conseguia arrumar as letras, porque
já tinha várias juntas ensinei a aspirar. Quis experimentar. Perguntou o que fazia a bomba de dar ar. Mostrei e também
experimentou. Perguntou o que fazia a varinha mágica. Mostrei e experimentou muitas vezes, copiando muitas bombas
de dar ar.
Perguntei se era capaz de tirar caixas azuis e arrumar alguns objectos dentro.
Como tirou muitas caixas, acabou por perder a localização de algumas delas. Pôs-se a pé para as procurar melhor
e tudo isto sem ajuda. Quis mexer muito tempo com o rato e acabou por perder de vez a sua localização. Ajudei a
encontrá-las. Ajoelhou-se e colocou os objectos tirados, dentro de casa caixa.
Perguntei se conseguia entrar no heli. Fê-lo bem.
Perguntou o que havia dentro das casas. Sugeri que visse ele próprio.
Pousou, entrou e apercebeu-se de que a cor do chão era diferente. Pediu para que a menina subisse ao andar de
cima. Expliquei que a casa ainda não tinha escadas mas que mais tarde iríamos fazer umas.
Tive que pedir para dar o lugar ao colega.
Lista de elementos de registo (ficheiros) associados:
Observações: Foi a 1ª vez que o MA jogou no Toon.
Observações:
Group 2
Session 1
Data: 2002/10/25 Início: 9h 57m
Término: 10h 14m
Nome: D
Objectivos:
descer/levantar helicóptero;
ajoelhar-se/levantar-se;
notar que ao apontar o objecto treme;
agarrar/largar objectos.
Desenrolar e resultados gerais:
Ajudei o D a pousar o helicóptero. Como está sempre a clicar, ajoelhou-se logo. Ajudei a levantar-se.
Moveu muito rápido o rato e perdeu a caixa dos brinquedos. Soube levantar-se e ajudei a procurá-la.
Não quis jogar mais porque preferiu ver como é feito o rato.
Lista de elementos de registo (ficheiros) associados:
Observações:
Session 2
Data: 2002/11/29 Início: 15h 51m
Término: 15h 54m
Nome: D Idade: 4 anos
Objectivos:
notar que ao apontar o objecto treme;
agarrar/largar objectos.
Desenrolar e resultados gerais:
Pousou.
Pedi para tirar objectos da caixa das ferramentas.
Observações:
O D ainda não se apercebe muito bem que ao apontar o objecto treme. É capaz de agarrar melhor os objectos que
são maiores (letra, número, caixa azul, camião).
Group 3
Session 1
Data: 2002/10/25 Início: 10h 16m
Término: 10h 31m
Nome: R / G
Objectivos:
ajoelhar-se/levantar-se;
notar que ao apontar o objecto treme;
agarrar/largar objectos;
aumentar/diminuir objectos;
copiar objectos.
Desenrolar e resultados gerais:
O R pousou perto das casas. Saiu do helicóptero e entrou dentro das casas. Sabe ajoelhar-se sozinho e consegue
levantar-se sem ajuda. Mostrei como se aumenta/diminui objectos, mas não quis experimentar. Ensinei a copiar
objectos e experimentou uma vez e preferiu andar de helicóptero, para cima e para baixo.
O G pousou, entrou numa casa e sem se aperceber ajoelhou-se e tirou alguns objectos da caixa. Conseguiu
agarrar alguns objectos, mas não se apercebeu que ao apontar o objecto pisca. Não quis jogar mais.
Lista de elementos de registo (ficheiros) associados:
Observações:
Pedi ao R para dar o lugar ao colega. O G não quis jogar mais.
Session 2
Data: 2002/11/04 Início: 11h 46m
Término: 12h 05m
Nome: R / G
Objectivos:
notar que ao apontar o objecto treme;
agarrar/largar objectos;
Desenrolar e resultados gerais:
O R pediu para construir casas porque tinha visto o A (grupo 8) a construir.
Ensinei mas teve dificuldades em agarrar os objectos pretendidos. Ainda não se apercebe do piscar do objecto
apontado e acaba por agarrar objectos não desejados. Foi tirando muitos objectos da caixa e quis construir muitas casas.
Atrapalhou-se com a quantidade de objectos e não foi muito bem sucedido da construção. Ajudei com a minha mão.
Não quis jogar mais. O G pediu para entrar no heli mas já não sabia como levantar o menino. Relembrei a tecla.
Também não era capaz de manusear o rato para entrar no heli. Ajudei a entrar no heli e sem querer voltou a pousar. Sem
querer entrou em casa e voltou a sair. Não quis jogar mais.
Lista de elementos de registo (ficheiros) associados:
Observações:
Observações:
Perdeu por várias vezes o local do heli e das casas.
Session 2
Data: 2002/11/04 Início: 14h 37m
Término: 15h 07m
Nome: MR / C
Objectivos:
notar que ao apontar o objecto treme;
agarrar/largar objectos.
Desenrolar e resultados gerais:
A C não sabe pousar. Ajudei e num clicar constante ajoelhou-se. Pediu para levantar uma vez que já não se
lembrava. Como está sempre a mexer com o rato, perdeu o local do heli. Ajudei a encontrar porque pediu para entrar no
heli. Ajudei e sem se aperceber do que fazia pousou perto das casas. Voltou a perder o local por estar sempre a mexer
com o rato. Desapontada não quis jogar mais.
Tive que sair do Toon porque não conseguimos encontrar o heli.
A MR pousou, ajoelhou-se, voltou a levantar-se e quis entrar novamente no heli mas tal como a colega já não o
encontrava. Ajudei. Preferiu estar sempre a pousar, sair do heli, e voltar a entrar. Sugeri ajoelhar e tirar alguns objectos,
mas não fui bem sucedida.
Lista de elementos de registo (ficheiros) associados:
A MR e a C não são capazes de manusear o rato, isto é, estão constantemente a mexer com ele de maneira
desorientada.
Observações:
Observações:
Group 8
Session 1
Data: 2002/10/25 Início: 14h 20m
Término: 15h 5m
Nome: A
Objectivos:
ajoelhar-se/levantar-se;
notar que ao apontar o objecto treme;
agarrar/largar objectos;
tirar caixas da caixa dos brinquedos;
construir casas;
aspirar/cuspir objectos;
copiar objectos.
Desenrolar e resultados gerais:
O A já pousa sem ajuda e perto das casas. Ajoelha-se sem ajuda e já tira objectos da caixa. Ensinei a
aspirar/cuspir objectos. Experimentou sozinho e foi bem sucedido.
Ensinei a construir casas e quis experimentar. Também foi bem sucedido e quis ficar o resto de tempo a construir
casas e a verificar o resultado final (entrar no heli. E ver as casas construídas).
Lista de elementos de registo (ficheiros) associados:
Observações:
O A tem ainda alguma dificuldade em se aperceber de que o objecto pisca ao apontar. Não ensinei a copiar
objectos por vontade da criança, que preferiu construir casas.
Observações:
Session 3
This session is mentioned in the record of session 4, but no record of it was kept.
Session 4
Data: 2002/11/22 Início: 10h
Término: 10h 25m
Nome: A Idade: 5 anos
Objectivos:
ensinar o robô a trocar objectos.
Desenrolar e resultados gerais:
O A pousou o heli perto das casas.
Perguntei se ainda se lembrava do que tinha feito na semana passada. Como já não se lembrava relembrei que
ensinámos o robô a trocar objectos. Perguntei se ainda se lembrava como se fazia e respondeu que sim. Pedi então para
me mostrar e disse-lhe que me ía ensinar como se fazia. Embaraçou-se dizendo que já não se lembrava. Sugeri que lhe
repetisse os procedimentos. A sugestão não foi bem recebida e preferiu construir casas. Construiu uma casa e depois de
a construir, começou por iniciativa própria a tirar duas caixas. Perguntei o que ia fazer e respondeu que ía ensinar o robô
na troca dos objectos. Contudo, não avançou mais porque não se lembrava. Ajudei com a minha mão e fizemos. Quando
saímos do pensamento do robô, não o quis testar e quis ver a casa que tinha construído.
Voltou a descer e quis explodir as casas. Insisti para que visse o que andava a fazer no robô dentro de casa.
Entrou nas casas uma de cada vez e explodiu-as. Quis entrar no heli para ver que já não havia casas. Depois de entrar no
heli e levantar disse desolado: oh fizeram-nas outra vez… Resolveu pousar e entrar numa casa. Ajoelhou-se e folheou o
caderno dos desenhos. Tirou o heli a voar e quis colocar ao lado o heli a pousar mas colocou-o tão perto que este quase
desapareceu ao ser martelado pelo rato. Expliquei que não poderia por tão perto porque pode haver um acidente. Não
quis jogar mais.
Lista de elementos de registo (ficheiros) associados:
Observações:
Observações:
Group 10
Session 1
Data: 2002/10/25 Início: 11h 14m
Término: 11h 40m
Nome: CR
Objectivos:
notar que ao apontar o objecto treme;
aumentar/diminuir objectos;
construir casas;
rebentar casas;
copiar objectos.
Desenrolar e resultados gerais:
A CR pousou perto das casas. Entrou, ajoelhou-se. Já agarra bem os objectos mas tem alguma dificuldade em
aperceber-se que piscam ao apontar.
Ensinei a copiar e experimentou sozinha com sucesso. Ensinei a rebentá-las e experimentou uma vez. Preferiu
construir muitas casas.
Ensinei a folhear o caderno e procurar objectos para colocar dentro das caixas. Preferiu continuar a construir
casas. Sempre que construía algumas casas, levantava no heli, para ver o resultado final.
Lista de elementos de registo (ficheiros) associados:
Observações:
Manuseia bem o rato.
A CR já sabe construir casas sem ajuda e agarra bem nos objectos.
Session 3
This session is mentioned in the record of session 4, but no record of it was kept.
Session 4
Data: 2002/11/22 Início: 10h 31m
Término: 11h 12m
Nome: Carina Idade: 4 anos
Objectivos:
ensinar o robô a trocar objectos.
Desenrolar e resultados gerais:
A Carina pousou perto das casas e perguntei se ainda se lembrava o que tinha feito na semana passada. Disse que
sim e quis fazer sozinha mas já não se lembrava. Relembrei e começou por fazer sozinha, fora do pensamento do robô,
indo buscar desenhos ao caderno (árvore e heli). Já no pensamento do robô, foi buscar desenhos diferentes (pessoa tonta
e flor). Deixei fazer para no fim lhe explicar o sucedido. Expliquei que o temos que colocar os mesmos objectos para
que o robô os reconheça, senão não sabe o que fazer.
Já não sabia como se saía do pensamento do robô. Relembrei.
Fora do pensamento, o robô repetiu tudo, inclusive “erros” e disse a Carina: “Este robô faz coisas confusas!”
Não quis repetir, por causa da confusão e esta foi a sua justificação. Preferiu folhear o caderno dos desenhos e
tirar alguns desenhos, colocando-os em caixas. Teve um pouco de dificuldade em colocar os desenhos cada um na sua
caixa, devido à proximidade destas. Assim, alguns dos desenhos ficavam sobrepostos e ficavam “cortados”.
Pediu para sair.
Lista de elementos de registo (ficheiros) associados:
Observações:
Observações:
A CA tem muitas dificuldades em se concentrar e está sempre distraída. Não consegue manusear o rato, isto é,
clicar e arrastar ao mesmo tempo e não consegue mexê-lo devagar. Na maior parte das vezes ajuda com a outra mão
para o segurar o que acaba por não resultar muito bem. Tento ajudar mas é preciso fazer muita pressão na sua mão para
mexer o rato devagar.
Falta muitas vezes.
Session 2
Data: 2002/11/22 Início: 14h 17m
Término: 14h 31m
Nome: CA Idade: 5 anos
Objectivos:
pousar o heli perto das casas;
notar que ao apontar o objecto treme;
agarrar/largar objectos;
Desenrolar e resultados gerais:
Para a CA esta foi a segunda sessão do Toon.
Como é uma criança com muitos problemas de concentração as dificuldades ainda se agravam mais.
Ajudei a pousar o heli e pedi para clicar à vontade com o botão que desejasse para ver o resultado. Distrai-se
facilmente acabando por não escutar o que lhe é dito.
Ajudei a pousar e pediu como se entrava novamente para o heli.
Mostrei como se fazia, mas sozinha já não foi capaz.
Ajudei com a minha mão. Quis entrar em casa mas como tem muitas dificuldades em manusear o rato não foi
capaz sozinha, isto é, sem ajuda manual.
Lista de elementos de registo (ficheiros) associados:
Observações:
A CA esteve ainda mais distraída porque as crianças de Gravelos lhes fizeram uma visita.
Observações:
A CA ainda tem algumas dificuldades em aperceber-se que os objectos ao apontar tremem.
Distrai-se facilmente e falta muitas vezes.
Session 2
Nome1 A (3 anos)
Nome2 D (3 anos)
Hora inicial 9h56 Hora final 10h19
Objectivos prévios
Rever ambiente do ToonTalk. Aperfeiçoar a motricidade fina. Explorar e conhecer os comandos do Paint.
Desenrolar e resultados gerais:
A A já consegue dirigir os movimentos e sentar-se.
A A quis experimentar muitas cores do Paint.
O D consegue sentar e levantar o boneco sem dificuldades. Sentou e levantou o boneco diversas vezes, dentro e fora
da casa.
Lista de elementos de registo (ficheiros) associados:
Desenhos do Paint.
Observações
Exploraram as cores.
Às 10h13 o Daniel perdeu a concentração.
Session 3
Nome1 A (3 anos)
Nome2 D (3 anos)
Hora inicial 14h10 Hora final 14h29
Objectivos prévios
Ambientar-se ao ToonTalk. Desenvolver motricidade fina. Trabalhar as cores.
Noções: “vazia vs. cheia”; “dentro vs. fora”.
Desenrolar e resultados gerais:
A A está a desenvolver rapidamente a capacidade de movimentação com o rato. Conseguiu perceber que agora é a
mão dela que controla a mão do ToonTalk.
Confunde o Esc (levantar) e o clic de sentar.
Gosta de mexer muito com o rato a ver o helicóptero mexer-se.
Lista de elementos de registo (ficheiros) associados:
Caixa de coisas no caderno do ToonTalk. Desenho do Paint.
Observações
A A tem especial interesse por letras. Pede sempre para escrever o nome. O mesmo se passa em outras actividades, por
exemplo a desenhar manualmente faz muitas aproximações a letras.
Session 5
Nome1 A–3
Nome2 D–3
Hora inicial 9:15 Hora final 9:45
Objectivos prévios
Trabalhar o controlo “liga/desliga” com o “space”.
Tirar coisas da caixa para aspirar.
Desenrolar e resultados gerais:
A A não identifica as casas. O D apontou-lhe as casas. A A já controla os movimentos do rato. A A não quer a ajuda
do D para trabalhar com o ToonTalk.
O D continua a querer ver o boneco a levantar-se continuamente. A A disse que queria pôr uma flor no telhado, “como
a AL... e uma bola”. A A já consegue tirar coisas da caixa e pousar no chão sem ajuda, mas não consegue trabalhar o
rato e o “space” juntos. Carrega no rato, tentando “ligar/desligar”.
O D não consegue controlar o movimento da mão.
Nota: parece-me que o “som” poderá ajudá-los muito a trabalhar.
Lista de elementos de registo (ficheiros) associados:
Observações
A A presta muita atenção ao trabalho desenvolvido também com os colegas.
Por vezes a A pega no rato e levanta-o, querendo ver isso no ecrã.
O D fica fascinado a trabalhar, embora precise constantemente de ajuda.
Session 6
Nome1 A–3
Nome2 D–3
Hora inicial 14h37 Hora final 14h57
Objectivos prévios
Usar desenho do Paint para decorar a casa ToonTalk. Usar caixas com coisas dentro como se fossem prendas para
oferecer.
Desenrolar e resultados gerais:
A voar a A ainda não vão sozinha ter a uma casa. O D explicou-lhe onde estão as casas.
A A pega bem nos objectos mas não encontra o caderno dos sensores nem percebe que é nele que tem que procurar a
“parede faz-de-conta”.
O D também ainda não tem autonomia para usar cadernos.
Lista de elementos de registo (ficheiros) associados:
Desenhos do Paint e cidade ToonTalk.
Observações
Se eu não disser nada, o D fica “espantado” a olhar para o ambiente ToonTalk e brinca com o rato. Hoje brincou com
o rato a fazer ruído como se fosse um carrinho de brincar.
Group 2
Session 1
Nome1 M (3 anos)
Nome2 R (3 anos)
Hora inicial 9h30 Hora final 9h46
Objectivos prévios
Apresentação do “rato”.
Promover a comunicação, sobretudo para a Rita que é bastante inibida.
Desenrolar e resultados gerais:
A R desatou a rir ao ver o boneco de apresentação e ao ouvir o som inicial “Tóim!!”.
Não identificaram o helicóptero. Só depois de lhe dizer que voava é que disseram que era um avião. Também não
identificaram as casas. A R gostou de andar a voar com o “avião”. Quanto ao boneco, tentou dar-lhe ordens falando
com ele: “vai prò avião, fogo!”. As duas repetiram ordens.
Lista de elementos de registo (ficheiros) associados:
Observações
São duas boas comunicadoras quando juntas. A R é mais inibida no dia-a-dia do jardim.
Após 15 minutos começaram a ficar distraídas.
Session 2
Nome1 M (3 anos)
Nome2 R (3 anos)
Hora inicial 9h20 Hora final 9h53
Objectivos prévios
Relembrar os comandos do ToonTalk. Explorar o ambiente do ToonTalk e os comandos do Paint.
Desenrolar e resultados gerais:
A R já conseguiu baixar o avião e gosta de brincar com o rato, movimentando o avião e o boneco.
Depois de entrar em casa a intenção é fazer “Pause” (aprender a interromper o jogo). Conseguiram perceber que foram
fazer um desenho para guardar no caderno do ToonTalk.
Quiseram desenhar as suas caras.
Lista de elementos de registo (ficheiros) associados:
Desenhos do Paint.
Observações
Depois de fazerem o desenho, levantaram o boneco, após voltarem ao ToonTalk. Voltei a explicar, tal como na 1ª
sessão, que o boneco, acabada a brincadeira, volta para o helicóptero e vai embora.
Session 4
Nome1 R–3
Nome2 M–3
Hora inicial 9:10 Hora final 9:36
Objectivos prévios
Identificação de cores e formas. Desenvolver a motricidade fina.
Desenrolar e resultados gerais:
A R e a M ainda têm muitas dificuldades em levar o rato para onde quer.
M: Depois vamos fazer desenho! Sim?
A M e a R perceberam bem o jogo e identificaram bem a sequência. Contudo, ainda não têm qualquer autonomia no
ambiente ToonTalk; isto é, precisam de ajuda para pegar e largar objectos e para fazer movimentos com a mão e com
o helicóptero.
Lista de elementos de registo (ficheiros) associados:
Caixa com objectos, no caderno ToonTalk.
Observações
Preparei o ambiente com uma caixa com quatro objectos diferentes que guardamos no caderno. No chão estavam
dispersos objectos iguais. Quis que construíssem uma caixa para colocar na mesma ordem os objectos dispersos.
A R e a M dispersam-se facilmente.
Session 5
Nome1 R–3
Nome2 M–3
Hora inicial 9:20 Hora final 10:40
Objectivos prévios
Trabalhar o controlo do rato. Iniciar a exploração do aspirador.
Desenrolar e resultados gerais:
A R explica à M como mexer o avião e pergunta “onde estão as casas?” e responde apontando: “estão ali” (apontou os
telhados).
A M já consegue tirar coisas da caixa de ferramentas mas não os coloca fora da caixa.
M: “a mão nã via o que está ali!”
(Mostrando que tem necessidade de ver o boneco.)
Lista de elementos de registo (ficheiros) associados:
Observações
A R e a M ainda estão a explorar o controlo do rato.
Não explorámos o aspirador, pois a R e a M ainda não têm qualquer controlo com o rato. Pediram para fazer um
desenho, fomos ao Paint, desenhar – não conseguem desenhar, ou mesmo fazer riscos, sem ajuda.
Session 7
NOME: R
IDADE: 3 anos
DATA:23-01-03
HORA DE INÍCIO: 11h00
HORA DE TERMINUS: 11h20
OBJECTIVOS PRÉVIOS: foi actividade livre para aferir conhecimentos do toontalk
DESENROLAR E RESULTADOS GERAIS: a R precisa de ajda para executar tarefas no Toontalk. Consegue
tirar objectos da caixa de ferramentas. Perguntou: “Não vamos pôr nome?”. Sendo assim, optamos por colocar a foto
numa caixa azul, para podermos escrever o nome em baixo e também para ser mais fácil para a R, pois não teve de
procurar a moldura do caderno.
Session 8
GRUPO: R e M
IDADE: 3 anos
DATA:04-02-03
HORA DE INÍCIO: 9h15m
HORA DE TERMINUS: 9h40m
OBJECTIVOS PRÉVIOS: fazer uma caixa com duas coisas diferentes para poder trocar
DESENROLAR E RESULTADOS GERAIS: a R conseguiu aterrar e entrar na casa sozinha.
A R fez uma caixa com um camião e um Robot. Conseguiu perceber como fazer e o que é a troca. Precisou de
ajuda para perceber que os objectos tremem antes de podermos segurar neles.
A M também conseguiu perceber a troca mas pediu ajuda para trocar os objectos pois ainda tem dificuldade em
manipular o rato.
OBSERVAÇÕES: a capacidade de concentração e destreza da M e da R tem evoluído positivamente.
Session 9
GRUPO: R e M
IDADE: 3 anos
DATA: 13- 02- 03
HORA DE INÍCIO: 9h10m
HORA DE TERMINUS: 9h44m
OBJECTIVOS PRÉVIOS: fazer duas caixas para fazer a “troca”
DESENROLAR E RESULTADOS GERAIS: a M precisou que lhe indicasse como se sentar e como caminhar
sem se sentar. Já consegue ir buscar as caixas mas pergunta se deve clicar e onde, para fazer as coisas.
Group 3
Session 1a
Nome1 MN (3 anos)
Nome2
Hora inicial 9h48 Hora final 10h03
Objectivos prévios
Desenvolver/promover a comunicação. Apresentação do ambiente do ToonTalk.
Desenrolar e resultados gerais:
A MN estava muito calada. Brinquei com ela dizendo-lhe que “o gato lhe tinha comido a língua”. Ela mostrou a
pontinha da língua para provar que sabe falar.
Não consegui perceber se identificou o helicóptero pois, após alguma insistência continuou a não responder.
Lista de elementos de registo (ficheiros) associados:
-
Observações
Mesmo noutros espaços da sala de jardim a MN está sempre muito quieta e calada.
Session 2
Nome1 MN (3 anos)
Nome2 J (3 anos)
Hora inicial 14h15 Hora final 14h46
Objectivos prévios
Desenvolver a capacidade de comunicação com a MN. Trabalhar/explorar ferramentas do Paint (como um auxiliar do
ToonTalk).
Desenrolar e resultados gerais:
A MN identificou o avião. Já se lembrava do “sentar e levantar” pelo que o faz várias vezes, rindo-se. Como é muito
pequena tem dificuldades em agarrar o rato. No Paint fez alguns riscos. Gosta de clicar de forma contínua como que
gostando do "clic" que ouve.
Começou a falar muito. Riu-se, disse coisas que foi descobrindo: “olha o passarinho” (e apontava). Ao imprimir os
desenhos do Paint riu-se, revelando que o computador é uma experiência nova para ela.
O J usou a varinha mágica para fazer muitos passarinhos. Esteve também a trabalhar “liga/desliga” com o aspirador.
Interiorizou a ideia de desligar o aspirador após aspirar um determinado objecto.
Lista de elementos de registo (ficheiros) associados:
Desenhos do Paint.
Observações
Session 3
Nome1 J (3 anos)
Nome2 MN (3 anos)
Hora inicial 14h35 Hora final 15h00
Objectivos prévios
Desenvolver motricidade fina.
Trabalhar a comunicação com a MN.
Desenrolar e resultados gerais:
A MN começou a repetir palavras das frases que eu dizia ao João.
Ao ver a impressora a funcionar a MN começou a chamar-me e a dizer excitada: “olha, olha, olha mais...”
Ao iniciar o ToonTalk começou: “olha, olha!” Quando disse ao João para largar o camião no chão ele largou o rato. A
MN ao dar conta do movimento com o rato: “olha, fixe!!”
Lista de elementos de registo (ficheiros) associados:
Garagem de camiões no caderno do ToonTalk.
Observações
Expliquei que também nós temos que levar as coisas a onde as queremos arrumar. Exemplifiquei com uma caneta.
A MN fez riscos no Paint. Achou graça aos riscos e disse que já não sabia o que levou (ingredientes) a tarte de maçã.
A MN carrega no rato muitas vezes, sem perceber para quê.
Session 4
Nome1 J–3
Nome2 MN – 3
Hora inicial 10:27 Hora final 10:50
Objectivos prévios
Trabalhar a igualdade e identificação dentro do ambiente do ToonTalk.
Desenvolver a motricidade fina, em especial com a MN.
Desenrolar e resultados gerais:
A MN fica entusiasmada ao ver o desenho a sair na impressora: “A minha, a minha! Olha! ...Tira!! É minha.”
O J perguntou: “A árvore fala?”. A árvore era uma das imagens guardadas em caixa.
A MN consegue mexer o boneco a andar e ir para o helicóptero. O J gosta de explorar o espaço ToonTalk. Perguntou
se o boneco entra sozinho no helicóptero. Expliquei que era ele que o fazia entrar.
Ao brincar com o helicóptero perguntou: “Ele está doido?” Respondi: “não és tu que o mexes, não és?”
J: Sim.
Lista de elementos de registo (ficheiros) associados:
Desenho de uma abóbora – Paint. Caixas de objectos – no caderno do ToonTalk.
Observações
O J começou por desenhar uma abóbora no Pain.
A MN ainda não consegue segurar bem o rato.
O J diz “Vou brincar!” quando movimenta o boneco em círculos pela casa (interior).
J: “Quero fazer magia!” Deposi de me ver usar a varinha mágica.
Session 5
Nome1 J–3
Nome2 MN – 3
Hora inicial 9:50 Hora final 10:18
Objectivos prévios
Trabalhar o controlo do aspirador e perceber a importância de manter o espaço limpo.
MN – Trabalhar o controlo com o rato.
Desenrolar e resultados gerais:
No jardim, o J: “opss! Sentei-me!... Onde levanto?” O J conseguiu perceber o “liga/desliga” do aspirador, mas tem
tendência a usar apenas a mão direita para trabalhar. Consegue, sem referência, aspirar objecto por objecto, desligando
ao fim de cada objecto. A MN gosta de ver o “avião” rodar e clica com muita frequência. A MN quis brincar no
jardim. Embora não controle o rato, a MN conseguiu perceber que tem que ligar e desligar o aspirador.
Observações
A MN continua a ter muitas dificuldades em segurar o rato e em clicar apenas para a execução de actividades
específicas.
O J mal se sentou disse: “Eu quero o do helicóptero!”
Quando largou o aspirador sem querer a MN disse: olha, fugiu!
Session 6
Nome1 J–3
Nome2 MN – 3
Hora inicial 11h05 Hora final 11h34
Objectivos prévios
Trabalhar a varinha mágica e o aspirador para fazer mais imagens de Natal e para as aspirar. Guardar imagens no
caderno.
Desenrolar e resultados gerais:
O J consegue usar bem a varinha mágica e o aspirador, sabe que tem que ligar e desligar.
A MN clica sem saber bem para quê. Ainda não controla os movimentos com o rato de acordo com os objectivos.
Acha muita graça ao passarinho que sai do ninho.
A MN conseguiu perceber que tem que ligar e desligar o aspitrador, mas precisa de ajuda a coordenar os movimentos.
Lista de elementos de registo (ficheiros) associados:
Cidade ToonTalk e dsenho do Paint sobre o Natal
Observações
A MN e o J trabalham bem juntos. O João já tem alguma autonomia no ToonTalk, que a MN não tem.
Session 7
GRUPO: J e MN
IDADE: 3 anos
DATA:4-02-03
HORA DE INÍCIO: 11h00m
HORA DE TERMINUS: 11h26m
OBJECTIVOS PRÉVIOS: fazer caixa das trocas. Perceber a troca e conseguir fazer a troca.
DESENROLAR E RESULTADOS GERAIS: o J construiu a caixa das trocas sem ajuda e fez facilmente a troca.
Avançamos para programação do robot a fazer troca. O J facilmente aprendeu a programar o robot, fazendo-o, depois,
sem ajuda. Não se apercebeu que fica uma caixa igual à do pensamento e fez outra.
A MN percebeu a troca e conseguiu fazê- la sozinha.
OBSERVAÇÕES: a MN já consegue perceber e manipular os movimentos com o rato.
Session 8
GRUPO: J e MN
IDADE: 3 anos
DATA: 18- 02- 03
HORA DE INÍCIO: 10h25m
HORA DE TERMINUS: 10h43m
OBJECTIVOS PRÉVIOS: trocar imagens
DESENROLAR E RESULTADOS GERAIS: a MN já consegue fazer uma caixa dupla e colocar lá as imagens.
A MN não conseguiu fazer a troca logo de início. Por vezes coloca imagens em cima de outras pois não tem,
ainda, a noção do tempo certo para largar as imagens onde quer.
A nível de destreza a MN já não precisa de ajuda. Já percebe como segurar as coisas.
Depois de algumas explicações, a MN acabou por conseguir fazer a troca.
OBSERVAÇÕES: o J faltou.
Group 4
Session 1
Nome1 IN (4 anos)
Nome2 C (4 anos)
Hora inicial 10h05 Hora final 10h22
Objectivos prévios
Identificar ambiente do ToonTalk.
Apresentação da caixa de ferramentas.
Desenrolar e resultados gerais:
A IN: “É um avião”. A C identificou as casas.
Tiveram facilidade em sentar e levantar.
Depois de lhes apresentar a caixa de ferramentas a IN quis tirar coisas da caixa e pousar no chão.
A C também quis tirar coisas da caixa.
A IN, por minha sugestão, usou o aspirador para limpar o chão.
Lista de elementos de registo (ficheiros) associados:
-
Observações
A IN tornou-se uma criança muito comunicativa, isto é, comparativamente ao ano lectivo 2001/2002 em que a IN
raramente se exprimia verbalmente.
Session 3
Nome1 IN (4 anos)
Nome2 C (4 anos)
Hora inicial 10h00 Hora final 10h24
Objectivos prévios
Desenvolver motricidade fina no Paint. Noções de "vazias" vs. "cheias".
ToonTalk – noções de “dentro” e “fora”. Manipular a mão no ambiente ToonTalk.
Desenrolar e resultados gerais:
A IN já não se lembrava de como levantar e aterrar. Andou um pouco perdida. Aterrou diversas vezes fora do espaço
das casas. Precisou de ajuda para ir até às casas. Já consegue (IN) tirar e juntar caixas com destreza.
A C trabalha bem com a IN. A C ainda tem dificuldade em tirar coisas da caixa de ferramentas.
Lista de elementos de registo (ficheiros) associados:
Desenhos do Paint de registo da “tarte de maçã”.
IN – Mexer ingredientes
C – Leite para juntar
Observações
A IN chamou a atenção da C para não se distrair: “C olha pràqui.” A C distraiu-se algumas vezes, prestando atenção
ao que a educadora estava a dizer.
Session 4
Nome1 IN – 4
Nome2 C–4
Hora inicial 9:45 Hora final 10:15
Objectivos prévios
Aprender a fazer o robô construtor de casas e testar a construção de casas.
Trabalhar com a bomba de ar.
Desenrolar e resultados gerais:
A C começou por fazer uma caixa igual à que lhe preparei com objectos. A C já domina bem os movimentos no
ambiente ToonTalk.
Disse que o robô tem que levar a mala de viagem para ir para a nova casa. A C e a IN aprenderam a fazer casas novas
e a ver se, de facto, existiam mais casas na cidade ToonTalk.
C: “O camião é para pôr as malas.”
A IN ainda carrega/clica muitas vezes.
Lista de elementos de registo (ficheiros) associados:
Caixa de objectos no caderno ToonTalk. Casas na cidade.
Observações
A C e a IN cada vez que se chama a atenção ou surgem temas de maior ênfase que a educadora refere, perdem a
concentração.
Fizeram também o desenho de uma abóbora no Paint, a pedido da educadora, até porque estão a trabalhar abóboras no
“dia das bruxas”.
Session 5
Nome1 IN – 4
Nome2 C–4
Hora inicial 9:15 Hora final 9:46
Objectivos prévios
Trabalhar o controlo do aspirador, com o objectivo de estabelecermos um paralelismo entre a arrumação da sala de
jardim e da sala/quarto do ToonTalk.
Desenrolar e resultados gerais:
A IN ainda tem alguma dificuldade em conseguir entrar em casa. Senta-se algumas vezes sem a intenção de o fazer.
A IN andou a aspirar o quarto mas custou um pouco a perceber que tinha de se sentar perto do “lixo” para o aspirar.
Não desliga o aspirador sem a lembrar.
A C também tem tendência a manter o aspirador ligado.
Lista de elementos de registo (ficheiros) associados:
Observações
Ao fim de 25 minutos a C comelou a ficar irrequieta na cadeira.
Session 6
Nome1 I – 4 anos
Nome2 C – 4 anos
Hora inicial 10h12 Hora final 10h38
Objectivos prévios
Trabalhar imagens de Natal para usar a bomba de ar e guardar imagens no caderno.
Desenrolar e resultados gerais:
A C é muito distraída. Não consegue usar o caderno de sensores sem ajuda. Ao trabalhar a bomba de ar não se lembra
de desligar a bomba.
A IN não consegue mudar as funções da bomba de ar.
A IN já não se recorda de como levantar o boneco.
A IN experimentou dar uma caixa a um passarinho e deu conta que ele “voou”, mas não referiu que ele levou a caixa
para o ninho.
Lista de elementos de registo (ficheiros) associados:
Cidade ToonTalk e desenhos (do Paint) de Natal.
Observações
A C pediu para se levantar antes da Iolanda terminar a actividade no ToonTalk.
Session 12
NOMES: I e C
IDADE: 4 anos
DATA: 22- 05-03
HORA DE INÍCIO: 9h14m
HORA DE TERMINUS: 9h44m
OBJECTIVOS PRÉVIOS: já referidos
DESENROLAR E RESULTADOS GERAIS: a C precisou rever alguns comandos: levantar, sentar, bomba de
ar.
Também já não se recordava como escrever o nome. Para colocar o nome na entrada de casa já conseguiu
apontar que tinha de usar o caderno.
Não ia verificar se o nome estava mesmo na entrada.
A IN esteve a recordar como fazer casas o que já estava meio esquecido!
A IN não conseguiu explicar como pôr o nome na entrada de casa. Depois de pôr o nome não foi verificar. A C
vai explicando.
Group 5
Session 1
Nome1 L (4 anos)
Nome2 MA (4 anos)
Hora inicial 10h25 Hora final 10h45
Objectivos prévios
Explorar o ambiente do ToonTalk.
Noção de “tirar objectos para fora da caixa de ferramentas”.
Desenrolar e resultados gerais:
A MA disse “É um avião”. Identificaram as casas.
A MA gostou especialmente dos ninhos, por causa dos passarinhos: “Oh PF, já tirei muitos!”, disse com um sorriso
após já ter tirado muitos ninhos da caixa de ferramentas. Depois usou o aspirador, por sugestão minha.
Ao descobrirem a bomba/granada quiseram rebentar mais casas. Ao repararem que rebentando todas elas eram
reconstruídas, quiseram rebentar mais casas.
Lista de elementos de registo (ficheiros) associados:
-
Observações
O L após rebentar cada casa levantava voo para verificar que havia menos uma casa.
Session 2
Nome1 L (4 anos)
Nome2 MA (4 anos)
Hora inicial 11h15 Hora final 11h40
Objectivos prévios
Explorar ferramentas do ToonTalk e do Paint.
Desenrolar e resultados gerais:
A MA vai perguntando onde tem de carregar mas já controla bem os movimentos com o rato e reconhece os objectos
da caixa de ferramentas do ToonTalk.
No Paint já consegue traçar linhas, com precisão, com o pincel.
Desenhou uma casa, uma flor e uma árvore. Pediu a minha ajuda para desenhar a árvore, o resto de desenho executou
sozinha.
Lista de elementos de registo (ficheiros) associados:
Desenho do Paint.
Observações
O L faltou.
Session 4
Nome1 MA – 4
Nome2 L–4
Hora inicial 15:30 Hora final 16.00
Objectivos prévios
Explorar as ferramentas do Paint com o L. Trabalhar o tema “As abóboras do dia das Bruxas”.
Trabalhei a bomba de ar do ToonTalk.
Desenrolar e resultados gerais:
No Paint o L já consegue dominar melhor o traço. Desenhou uma abóbora perguntando: “Está a ficar bem?” Eu – sim,
muito gira.
O L já sabe utilizar bem o rato para levantar e aterrar no ToonTalk. Consegue aterrar e entrar nas casas. Com a bomba
de ar ainda têm dificuldade em apontar a bomba e ligar e desligar, ao mesmo tempo.
A MA trabalhou com uma flor. O L também. Ambos têm dificuldades em usar as duas mãos ao mesmo tempo.
Lista de elementos de registo (ficheiros) associados:
Observações
Antes de começar o L disse: vamos para o jogo do avião!
Session 5
Nome1 MA – 4
Nome2 L–4
Hora inicial 10:48 Hora final 11:15
Objectivos prévios
Trabalhar o controlo com a barra de espaços. Aspirar para manter o espaço limpo.
Desenrolar e resultados gerais:
A MA gosta de experimentar o helicóptero mas não aterra perto das casas a não ser que lhe digam para o fazer.
A ver o passarinho sair do ovo ambos se riem. Depois quiseram ver muitos pássaros a sair do ovo.
Depois de tirarem coisas da caixa levantaram o boneco. Eu – “como está o chão?” MA – “Está desarrumado.” L –
“Está sujo.”
O L tem tendência a carregar muitas vezes no rato.
Lista de elementos de registo (ficheiros) associados:
Observações
O L perguntou: “Porque não vais buscar a coisinha cresce e abaixa, cresce e abaixa”, referindo-se à bomba de ar.
A MA chegou a cabeça ao ecrã e disse: “Ai, não se ouve nada.”
Para ir para outra casa, o L foi “a pé”, acabou por se perder.
Session 7
GRUPO: MA e L
IDADE: 4 anos
DATA: 4-02-03
HORA DE INÍCIO: 15h07m
HORA DE TERMINUS: 15h30m
OBJECTIVOS PRÉVIOS: colocar o nome no telhado
DESENROLAR E RESULTADOS GERAIS: a MA precisa de indicações, não se lembrando como levanta o
boneco. O L ajudou.
Na 2ª tentativa a MA voltou a precisar de ajuda. Para a MA as letras para o nome estão no teclado directamente,
sem se lembrar de ir buscar as letras da caixa do toontalk.
OBSERVAÇÕES: a MA faz perguntas do género: “ carrego aqui?”. Ou diz: “não sei...”, muitas vezes por
preguiça e alguma insegurança.
Session 8
GRUPO: MA e L
IDADE: 4 anos
DATA: 18- 02- 03
HORA DE INÍCIO: 10h45m
HORA DE TERMINUS: 11h07m
OBJECTIVOS PRÉVIOS: colocar desenho na parede e ensinar o robot a fazer o mesmo.
DESENROLAR E RESULTADOS GERAIS: depois de repetir à MA como se coloca o desenho na parede, a
MA não confirma se o desenho, de facto, está na parede grande.
Para levantar o boneco foi o L que a ajudou.
O L teve dificuldade em encontrar a parede para colocar o desenho, apesar de ter o caderno simplificado. Mas
sabia colocar o desenho. Antes de entrar em casa disse: “ vou espreitar à janela! Está aí alguém?”. Fez de conta que
espreitava.
OBSERVAÇÕES: a MA faz o sorriso de quem só faz quando lhe dão a certeza de estar a fazer bem.
Não ensinaram o robot pois ainda há muitas dúvidas relativamente a fazê-lo por eles próprios.
Session 10
NOMES: MA e L
IDADE: 4 anos
DATA: 1-04-03
HORA DE INÍCIO: 14h32m
HORA DE TERMINUS: 14h46m
OBJECTIVOS PRÉVIOS: já referidos
DESENROLAR E RESULTADOS GERAIS: perguntei à MA o que é a troca. Disse: é pôr aqui um e ali outro. -
explicou apontando.
Eu – O que é que o robô está a pensar?
Resp.: A pensar que vai fazer outra vez o jogo.
Expliquei que ele só faz o jogo se lhe dermos uma caixa igual.
Eu - Porque parou?
Resp.: porque está a pensar noutra caixa.
Depois a MA experimentou trocar os objectos e voltou a testar o robô.
OBSERVAÇÕES: o L faltou
Session 11
NOMES: MA e L
IDADE: 4 anos
DATA: 22- 05-03
HORA DE INÍCIO: 9h46m
HORA DE TERMINUS: 10h06m
OBJECTIVOS PRÉVIOS: já referidos
DESENROLAR E RESULTADOS GERAIS: o L sugeriu pegar no desenho e carregar no Space.
O L deu conta que a parede é igual à do caderno. A abstracção ainda não é feita. Só com indicação eles
conseguem perceber que têm de usar uma parede “faz de conta”. A MA sabe que para pôr o desenho numa parede
precisa de uma parede mas mesmo com o caderno simplificado não a identificou. Depois esperei sem dizer nada, ela fez
sozinha. Diz que vê que o desenho fica na parede porque está na pequena. Para pôr o nome a MA disse que precisava
das letras. Não verifica se o nome fica na entrada da casa.
608 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
Session 12
NOMES: MA e L
IDADE: 4 anos
DATA: 05- 06-03
HORA DE INÍCIO: 10h30m
HORA DE TERMINUS: 11h00m
OBJECTIVOS PRÉVIOS: colocar nome no telhado. Perceber o que é preciso para colocar o nome no telhado,
colocando as coisas numa caixa.
DESENROLAR E RESULTADOS GERAIS: Para o L é tudo complicado. Não vai verificar se o nome está no
telhado pois diz que “está no pequeno, por isso está”.
Depois desarrumou montes de coisas e começou a experimentar pegar em tudo. Tive de lhe dizer para aspirar as
coisas e trabalhar com calma. Não sabe escrever o nome.
A MA já da indicações ao L de como fazer as coisas bem. Para escrever o nome só precisou que lhe apagasse o –
A – para escrever.
Ao fazer a caixa com o que é preciso para pôr o nome no telhado largou o nome com o telhado ainda dentro da
caixa.
Esquece como levantar o boneco e não verifica se o nome fica mesmo no telhado.
OBSERVAÇÕES: o L estava excitado porque tinham chegado à sala pintainhos que o S trouxe.
Group 6
Session 1
Nome1 U (5 anos)
Nome2 CA (5 anos)
Hora inicial 11h40 Hora final 12h04
Objectivos prévios
Identificar ambiente do ToonTalk.
Usar ferramentas. Noção de “dentro” vs. “fora", associada à ideia de “arrumar”.
Desenrolar e resultados gerais:
Não tiveram dificuldades em aprender a sentar e levantar.
Tiraram coisas da caixa de ferramentas e guardaram em caixas (que juntaram). Depois experimentaram tirar e tornar a
meter.
Brincaram com o robô construtor, usando também a varinha mágica para construir casas mais rapidamente. Depois,
por sugestão minha, limparam o chão com o aspirador.
Lista de elementos de registo (ficheiros) associados:
-
Observações
A CA já sabia usar o robô "construtor" pois o ToonTalk está instalado no computador da sala e as crianças costumam
explorá-lo livremente, sem acompanhamento.
Session 2
Nome1 CA (5 anos)
Nome2 U (5 anos)
Hora inicial 11h00 Hora final 11h36
Objectivos prévios
Ver até que ponto a U e a CA estão autónomas no Paint. Explorar ambiente do ToonTalk.
Desenrolar e resultados gerais:
A U e a CA conseguiram descer com o helicóptero e manejar o boneco sem quaisquer dificuldades.
A U quis desenhar uma casa, uma árvore e uma menina.
Desenharam sem qualquer ajuda.
A CA não sabia como levantar o boneco.
Lista de elementos de registo (ficheiros) associados:
Desenhos no Pain.
Observações
Session 4
Nome1 U -5
Nome2 CA – 5
Hora inicial 9:25 Hora final 10:08
Objectivos prévios
Prepararem o jogo para os meninos mais novos utilizar a bomba de ar.
Usar varinha mágica para fazer cópias.
Desenrolar e resultados gerais:
A U e a CA estão muito distraídas. Começaram a prestar mais atenção ao relembrarem os desenhos feitos no Paint.
CA – “Eram 4 maçãs.” No ToonTalk, a U para aterrar esteve cheia de “cuidados” para aterrar nas casas. A CA
explicava: “para subir é no outro botão”. A CA perguntou se usava Esca para ajoelhar.
Lista de elementos de registo (ficheiros) associados:
Desenhos do Paint de 24-10-2002. Jogo no caderno ToonTalk.
Observações
Fases definidas da realização da tarte, pela U e CA:
1 – Ingredientes – ‘O que precisamos... a farinha... e mais”
2 – Juntar farinha, açúcar, ovos e canela.
3 – “Mexemos tudo.”
4 – “Untamos a forma com manteiga.”
5 – “Deitamos a mistura da bacia na forma.”
6 – “Pusémos a maçá, aos bocadinhos.”
7 – Foi ao forno.
8 – “Ficou pronta para comer.”
Session 5
Nome1 U–5
Nome2 CA – 5
Hora inicial 9:50 Hora final 10:15
Objectivos prévios
Trabalhar o controlo “liga/desliga”. A importância de mantermos os espaços arrumados e organizados. Aspirar e
bomba de ar.
Desenrolar e resultados gerais:
Quiseram escrever o nome.
A CA controla bem o “levantar/sentar”. Como de costume, interroga-me sobre a boa execução de tarefas. Optei por
lhe propor que descubra, ela mostrou já sabe, por exemplo “como se senta” (que foi uma das questões que levantou. A
CA controla bem o “ligar/desligar” com o space.
Com a bomba de ar conseguiu perceber que o G é igual a “grande” e o P = a “pequeno”. Com a bomba de ar ainda
confundem a localização da tecla para “ligar/desligar”.
Lista de elementos de registo (ficheiros) associados:
Observações
A CA descobriu que deve aspirar para que não fique “lixo” no chão.
A U ainda confunde um pouco o botão esquerdo do rato com o “space”.
A CA explicou à U onde se carrega para o helicóptero levantar.
Session 7
GRUPO: U e CA
IDADE: 5 anos
DATA:4-02-03
HORA DE INÍCIO: 11h30m
HORA DE TERMINUS: 11h45m
OBJECTIVOS PRÉVIOS: colocar o nome no telhado e ensinar o robot a fazer o mesmo
DESENROLAR E RESULTADOS GERAIS: a U e a CA conseguiram colocar os seus nomes em telhados
facilmente. A U ainda confunde alguns comandos do toontalk, como por exemplo, “ como se sentar”.
A CA e a U funcionam mesmo como uma equipa, ajudando- se mutuamente.
Ainda não entenderam bem como se ensina o robot. Não tiveram a iniciativa de testar o que lhe ensinaram.
OBSERVAÇÕES: a U e a CA ficaram agitadas quando se aperceberam que estavam a ser observadas por um
grupo de pessoas que veio ver o nosso trabalho.
Session 8
GRUPO: U e CA
IDADE: 5 anos
DATA: 18- 02- 03
HORA DE INÍCIO: 9h20m
HORA DE TERMINUS: 9h48m
OBJECTIVOS PRÉVIOS: colocar desenho na moldura e ensinar o robot a fazer o mesmo.
DESENROLAR E RESULTADOS GERAIS: a U precisa de indicações da CA. Para colocar o desenho mais
pequeno, a CA diz logo: “vai buscar a bomba”.
A U já não sabe como colocar desenhos na parede.
A CA já se movimenta sem ser necessário dar-lhe indicações. Encontrou a moldura e colocou o desenho.
Para ensinar o robot, a CA sabia ir ao pensamento “temos de ir ao pensamento do robot.” Aprendeu a ensiná- lo
mas não verifica se ele aprendeu.
OBSERVAÇÕES: a CA disse que a mão que aparece no toontalk parece a mão de um macaco.
A U não ensinou o robot.
Session 10
NOMES: C e U
IDADE: 5 anos
DATA: 1- 04-03
HORA DE INÍCIO: 11h38m
HORA DE TERMINUS: 11h58m
OBJECTIVOS PRÉVIOS: já referidos
DESENROLAR E RESULTADOS GERAIS: perguntei o que era a troca. Responderam: é chegar ali e trocar a
árvore e a flor.
A U lembrava- se de usar a varinha mágica no pensamento. Perguntei porque estava a usar a varinha mágica. A
CA respondeu que era para o robô fazer sempre igual.
A CA ao testar o robô não usa a caixa inicial.
Perguntei porque é que o robô que ensinaram não parava. A U respondeu que lhe tinha ensinado truques de
magia.
Por já estarmos na Primavera estivemos ainda a decorar a entrada da casa com flores, o que as estimulou.
OBSERVAÇÕES:
Group 7
Session 1
Nome1 CR (4 anos)
Nome2 JG (4 anos)
Hora inicial 10h58 Hora final 11h19
Objectivos prévios
Aferir a destreza adquirida no ano 2001/2002 em termos de motricidade fina e de capacidade de explorar um jogo.
Desenrolar e resultados gerais:
Identificaram o helicóptero e as casas.
O CR fez um robô para construção de casas. Depois fez mais 3.
Já sabem levantar/sentar sem dificuldades. CR: “Vou fazer muitas casas.”
A JG usou a varinha mágica: “ah! Já sei! Mais camiões!”
Usaram a bomba/granada. Eu disse-lhes: “vamos rebentar as casas todas?” Eles: “sim, porque depois algumas fazem-
se!”
Tiraram desenhos do caderno e arrumaram em caixas. Ao pegar no foguetão a J disse: “Temos de pôr isto mais
pequeno!” E foi buscar a bomba de ar. A J fez uma “caixa de coisas” e guardou no caderno dela.
Lista de elementos de registo (ficheiros) associados:
J – “caixa de coisas” no caderno.
Observações
A J já sabe usar/brincar com o ToonTalk sem dificuldades, até porque tem o jogo em casa. Sem qualquer referência
usou F1 para mandar o marciano embora.
O CR também já sabia fazer o robô “construtor”.
Session 3
Nome1 CR (4 anos)
Nome2 JG (4 anos)
Hora inicial 15h54 Hora final 16h08
Objectivos prévios
Explorar o ambiente do ToonTalk. Noções “dentro vs. fora”, ”vazia vs. cheia”.
Desenrolar e resultados gerais:
O CR já conhece os comandos básicos do ToonTalk para voar, sentar, levantar.
Eu – “Se juntarmos caixas...”
CR – “Eu sei, eu sei!... O rato vem e junta!”
Percebeu bem as noções “dentro e fora” da caixa, “vazia e cheia”.
Lista de elementos de registo (ficheiros) associados:
Caixa no caderno do ToonTalk: “caixa truca”.
Observações
A JG faltou.
O CR não fez o desenho no Paint por falta de tempo.
Session 4
Nome1 CR – 5
Nome2 JG – 5
Hora inicial 11:30 Hora final 12:00
Objectivos prévios
Colocar nome nos telhados das casas.
Ensinar o robô a fazer robôs construtores de casas.
Desenrolar e resultados gerais:
Ambos já sabem fazer o robô construtor de casas sem dificuldade.
Eu: “O que é que podemos fazer para sabermos de quem são as casa?”
JG – “As minhas são as cor-de-rosa.”
Eu: “E que tal pormos o nome no telhado?”
Eles – “Boa!”
A JG aprendeu à 1ª a pôr o nome no telhado. Ao ver o resultado começou a bater os pés de alegria e disse: “vou faer
outra!”.
Lista de elementos de registo (ficheiros) associados:
Cidade com nomes nos telhados.
Observações
Não tivémos tempo de ensinar o robô a fazer robôs construtores de casas.
O CR também aprendeu com facilidade mas tem alguma ansiedade o que lhe dificulta a execução das tarefas.
Observações
O CR está a trabalhar muito bem com a JG. Quando o CR pegou no aspirador, alterou a sua função. Ao cuspir disse a
JG: “O CR fez o aspirador a cuspir, que nojo!!”.
Querem decorar o avião!!
Session 6
Nome1 JG – 5
Nome2 CR – 5
Hora inicial 11h26 Hora final 11h53
Objectivos prévios
Trabalhar imagens do Natal para decoração de casas no ToonTalk.
Desenrolar e resultados gerais:
A JG achou melhor reduzir o desenho para o pôr na parede. Depois resolvemos fazer uma casa que levasse com um
ninho e experimentou dar um desenho ao pássaro.
Perguntou como sabia qual era a casa nova. Expliquei que seria a que estava a mais – que a situação inicial. Depois
decorámos o telhado para podermos identificar a casa.
O CR também conseguiu perceber que o passarinho leva tudo para o ninho e decorou o telhado com o desenho de
Natal.
Lista de elementos de registo (ficheiros) associados:
Cidade ToonTalk, com os passarinhos com os nomes.
Desenhos de Natal – Paint.
Observações
A intenção é que na próxima semana possamos trocar prendas.
A JG quiz pôr um passarinho a viver na casa, para saber que era a casa dela. Depois disse: “Mas se eu pusesse o
passarinho maior, sabia melhor que era a minha casa!”
Session 7
GRUPO: CR e JG
IDADE: 5 anos
DATA: 4-02-03
HORA DE INÍCIO: 11h48m
HORA DE TERMINUS: 12h00m
OBJECTIVOS PRÉVIOS: colocar o nome no telhado. Ensinar o robot a colocar o nome no telhado.
DESENROLAR E RESULTADOS GERAIS: a JG tem muito à- vontade no toontalk. A JG, após ter escrito o
nome no telhado, assume isso como um dado e não vai verificar.
Ao ensinar o robot a colocar o nome no telhado também não verifica se ele aprendeu o que lhe ensinou.
Expliquei-lhe que eu também só sei que ela sabe algo que lhe ensinei se a vir a fazê-lo.
OBSERVAÇÕES: a JG diz: “ Eu já sei tudo”. Só depois de lhe mostrar que pode ainda haver coisas que não
sabe é que ela dá conta que ainda há muito a aprender e “inventar”.
O CR faltou.
Group 8
Session 1
Nome1 IM (5 anos)
Nome2 S (5 anos)
Hora inicial 14h25 Hora final 14h48
Objectivos prévios
Trabalhar a capacidade de concentração com a IM. O S poderá aprender a ser mais paciente, uma vez que é bastante
ansioso.
Desenrolar e resultados gerais:
Identificaram o “avião”.
O S já sabe fazer o “robô construtor”. Os dois fizeram muitas casas e foram vê-las.
A IM usou o rato pela 1ª vez pelo que, precisou da minha ajuda para coordenar movimentos.
14h42-Os colegas foram para os cantos e a IM quis ir para a casinha: “Não quero jogar mais, quero a casinha”.
Lista de elementos de registo (ficheiros) associados:
-
Observações
A IM tem necessidades educativas. Esteve a trabalhar concentrada mas com o alvoroço repentino dos colegas (porque
a educadora mandou) perdeu a concentração.
O S quis continuar para trabalhar com o aspirador e rebentar uma casa.
Session 2
Nome1 IM (5 anos)
Nome2 S (5 anos)
Hora inicial 15h20 Hora final 15h52
Objectivos prévios
Trabalhar a concentração – com a IM.
Trabalhar o relacionamento em trabalho com o S.
Desenrolar e resultados gerais:
O S entrou bem no jogo e conseguiu segurar bem o caderno.
Também sabe utilizar as ferramentas do Paint.
A IM gostou de desenhar no Paint. Ajudei-a, pois foi o 1º contacto que teve com o Paint e, como tal, de início estava
“Assustada” por não conseguir. A IM gosta de ouvir os sons do ToonTalk. Ficou a virar páginas do caderno para ouvir
o som. Treinou o pegar e largar coisas. Quanto ao desenho no Paint, a satisfação foi notória. Já de volta ao ToonTalk
disse: “O meu desenho está giro!”
15h49 - A IM perdeu a concentração pois a educadora mandou arrumar, aos outros meninos.
Lista de elementos de registo (ficheiros) associados:
Observações
O S tem já algumas mudanças no relacionamento, uma vez que tem que ser paciente e procurar ajudar a IM e não
recriminá-la, ou seja, aceitar a diferença.
Session 4
Nome1 IM – 5
Nome2 S–5
Hora inicial 14:06 Hora final 14:40
Objectivos prévios
Deixar explorar o ToonTalk para encontrar interesses. Trabalhar a concentração e motricidade fina com a IM.
Aprender a colocar nomes no telhado.
Desenrolar e resultados gerais:
“Vamos aprender a saber quais são as casas do S e as da IM?” IM (animada): “Vamos, tá bem!”.
O S perguntou o que era as luzes que dão do lado da “casa”/telhado. Respondi que eram as luzes que saiem da casa.
O S aprendeu a pôr o nome no telhado e sai da casa e levanta vôo para verificar o nome no telhado.
A IM mostrou muito interesse em trabalhar. (A IM manipula os objectos da caixa de ferramentas.)
Lista de elementos de registo (ficheiros) associados:
Cidade com nomes, S e IM.
Observações
A IM disse que tinha de estar no computador: “Tenho de trabalhar muito para aprender.”
A IM gosta de trabalhar, experimentar e tentar fazer as coisas sozinha. Tive de lhe “pedir” para a ajudar porque ela
dizia “não consigo” mas evitava ajuda.
Session 5
Nome1 IM – 5
Nome2 S–5
Hora inicial 14:15 Hora final 14:46
Objectivos prévios
Trabalhar o controlo do aspirador englobando a noção de “limpeza”.
Trabalhar a concentração com a IM.
Desenrolar e resultados gerais:
O S “desarrumou” a casa, depois levantou-se para ver o quanto desarrumou. Depois esteve a aspirar. Não tem
quaisquer dificuldades e gosta de estar no computador o tempo inteiro (se pudesse!).
A IM evita que eu a ajude. De vez em quando fala com o boneco: “vai, entra!”.
A IM não associa o “limpa-o-pó” com um aspirador.
Lista de elementos de registo (ficheiros) associados:
Cidade ToonTalk.
Observações
O S gosta de explorar. Aprendeu a decorar a casa por for, pois queria fazer um jardim.
No computador, a IM é muito observadora. Esteve muito calma, sossegada e interessada em trabalhar.
Session 7
NOME: Stefano
IDADE: 5 anos
DATA: 23-01-03
HORA DE INÍCIO: 10h09
HORA DE TERMINUS: 10h28
OBJECTIVOS PRÉVIOS: realizar uma cidade em que as casas tivessem as fotos das crianças
DESENROLAR E RESULTADOS GERAIS: o Stefano visualiza facilmente as fotos que deseja. No Toontalk
tive de lhe explicar o que é uma moldura. Depois conseguiu colocar a foto na moldura sem ajuda e conseguiu encontrar
a parede/ sensor. Teve ajuda para encontrar o caderno de sensores.
Session 8
GRUPO: S e IM
IDADE: 5 anos
DATA: 13- 02- 03
HORA DE INÍCIO: 15h40m
HORA DE TERMINUS: 16h00m
OBJECTIVOS PRÉVIOS: colocar desenhos da visita à azenha na parede
DESENROLAR E RESULTADOS GERAIS: o S fez a actividade sem dificuldade. Lembrou - se de como
ensinar o robot, dando uma caixa dupla comas coisas necessárias ao robot. A IM conseguiu colocar o desenho na parede
com dicas que o colega lhe foi dando. Não trabalhou a programação do robot pois ainda lhe é muito confusa a
abstracção.
OBSERVAÇÕES: a IM já tinha a mãe à espera mas quis ficar no computador a acabar a actividade.
Session 9
GRUPO: IM e S
IDADE: 5 anos
DATA: 4-02-03
HORA DE INÍCIO: 14h 22m
HORA DE TERMINUS: 14h40m
OBJECTIVOS PRÉVIOS: colocar o nome no telhado.
DESENROLAR E RESULTADOS GERAIS: o S, depois de ensinar o robot, lembrou-se de usar a caixa que
criara para ser mais rápido. A IM conseguiu pôr o nome no telhado. Para programar o robot precisou de ajuda. Não se
referiu a verificar o que ensinara ao robot.
OBSERVAÇÕES: a IM ficou sorridente por ir “ter uma casa”.
Group 9
Session 1
Nome1 AM (5 anos)
Nome2
Hora inicial 14h50 Hora final 15h05
Objectivos prévios
Apresentação e contacto com o “rato”. Explorar e conhecer o ambiente do ToonTalk.
Desenrolar e resultados gerais:
Identificar o avião.
Eu: “Por baixo do avião está o quê, AM?”
AM: “Riscos...”
Não teve dificuldade em aprender a sentar e levantar. Fez 2 pássaros gémeos a que deu o nome “os manos pássaros”,
depois ajudei-a a guardar a caixa com os dois pássaros no caderno.
Lista de elementos de registo (ficheiros) associados:
Caderno – caixa com os “manos pássaros”
Observações
A AM brincou pela 1ª vez no computador. É irmã gémea da IM mas quis separá-las pois a AM, noutros espaços, vive
as “frustrações” que a irmã não sente! Fica envergonhada com as “não realizações da irmã”. Como tal, achei que seria
benéfico trabalharem separadas.
Session 2
Nome1 AM (5 anos)
Nome2 V (5 anos)
Hora inicial 14h45 Hora final 15h15
Objectivos prévios
Explorar caixa do ToonTalk. Colocar o V como forte colaborador da AM.
Desenrolar e resultados gerais:
Não tem dificuldades a sentar o boneco. O V desenhou uma cara de homem. Depois apagou a cara e fez um barco com
uns salva-vidas e peixinhos no mar. Quando quisemos sair do ToonTalk disse-lhe “Vamos levantar?” e o V levantou-
se da cadeira. A AM precisou de ajuda no Paint, pois ainda não domina os movimentos com o rato. Foi a 1ª vez que a
AM trabalhou no Paint.
Lista de elementos de registo (ficheiros) associados:
Desenhos do Paint.
Observações
Como foi a 1ª vez que a AM desenhou no Paint, ajudei-a para evitar a “frustração”.
No ToonTalk ainda tem dificuldade em manipular o rato e usar ferramentas, não conseguindo fazê-lo sozinha.
Session 4
Nome1 AM
Nome2 V
Hora inicial 14:42 Hora final 15:12
Objectivos prévios
Desenvolver a capacidade de desenho no Paint, com a AM.
Aprender a colocar o nome nos telhados da cidade ToonTalk.
Desenrolar e resultados gerais:
O V mal entrou na casa do ToonTalk: “Vou rebentar a casa”. Contudo, esqueceu-se que para rebentar a casa tinha de
segurar a bomba na mão.
Eu “O que podemos fazer para saber de quem são as casas?” V – “Podemos dar dinheiro ao senhor e ficamos lá!”
Expliquei que também nos desenhos é o nome que nos permite saber quem os fez.
A AM só consegue pôr o nome no telhado com ajuda.
Lista de elementos de registo (ficheiros) associados:
Desenhos sobre as abóboras – no Paint. Cidade ToonTalk.
Observações
O V hoje está um bocado impaciente, concentrou-se quando descobriu como pôr o nome no telhado. Disse que queria
pôr o nome numa “casa de férias”:
Session 5
Nome1 AM – 5
Nome2 V-5
Hora inicial 11:34 Hora final 11:59
Objectivos prévios
Trabalhar o controlo do aspirador, abordando a importância de mantermos o nosso espaço limpo.
Desenrolar e resultados gerais:
O V consegue trabalhar bem com as duas mãos e consegue usar bem o aspirador, contudo por vezes altera as funções
do aspirador sem querer.
Começou a usa a varinha: “Paula, queres ver uma coisa?” – e copiou aspiradores.
A AM trabalhou o tirar coisas da caixa de ferramentas mas teve dificuldades. Percebeu a utilidade do aspirador,
embora não o saiba, ainda, usar sozinha.
Lista de elementos de registo (ficheiros) associados:
Cidade ToonTalk com nomes nos telhados.
Observações
A AM e o V estão com níveis de trabalho muito diferentes. A AM ainda não controla os movimentos da mão do
ToonTalk.
Session 7
GRUPO: AM e V
IDADE: 5 anos
DATA: 4-02-03
HORA DE INÍCIO: 9h50m
HORA DE TERMINUS: 10h20m
OBJECTIVOS PRÉVIOS: colocar o nome no telhado. Ensinar o robot a colocar o nome no telhado.
DESENROLAR E RESULTADOS GERAIS: o V concentra- se mais quando é a AM a mexer no rato pois gosta
de explicar à colega.
O V controla o boneco e o rato mas é um pouco trapalhão, o que faz com que, por vezes, clique sem ser
necessário.
Eu- “Porque é que o robot pára?”
V- “ Porque está vazia, a caixa”.
A AM não aterra numa casa. A AM só trabalhou o nome no telhado e precisou de ajuda pois estava muito
distraída.
OBSERVAÇÕES: a AM esteve muito desconcentrada. A educadora estava a falar das ganchas e a mostrá-las e a
AM não parava de olhar para ela.
Session 8
GRUPO: AM e V
IDADE: 5 anos
DATA: 13- 02- 03
HORA DE INÍCIO: 10h10m
HORA DE TERMINUS: 10h42m
OBJECTIVOS PRÉVIOS: colocar o desenho na parede e ensinar o robot a fazer o mesmo
DESENROLAR E RESULTADOS GERAIS: Eu- “o que precisamos para colocar o desenho na parede?”
V- “ vou buscar a fita cola e colo”.
O V não saiu do pensamento do robot sem que lhe lembrasse. Depois, a fazer sozinho, o V ia ensinar o robot fora
do pensamento, mas já saiu do pensamento do robot.
A AM não programou o robot pois, como de costume, estava muito distraída e, como tal, esteve a trabalhar
colocando ela o desenho na parede.
OBSERVAÇÕES: a AM não sabe como levantar o boneco.
O V, trocando com a AM para trabalhar ela com o rato, também se distraiu.
Group 10
Session 1a
Nome1 AX (3 anos)
Nome2
Hora inicial 11h40 Hora final 12h02
Objectivos prévios
Aferir coisas que o AX já faz no ToonTalk quase que “naturalmente”.
Desenrolar e resultados gerais:
A cidade que o AX tem já desde o ano 2001/2002 está com muitas casas.
Sozinho, foi para a memória do robô.
Eu – “Que estás a fazer, AX?”
AX – “Estou a ensinar o robô a fazer casas. Olha pra isto...”
Contudo, não verificava se o robô de facto fazia o que ele lhe ensinou.
Lista de elementos de registo (ficheiros) associados:
Desenho do Paint.
Observações
No Paint quis apagar o 1º desenho que fez e fazer de novo.
Observações
Com o aspirador e a varinha ainda tem alguma dificuldade em perceber que tem que tê-los na mão para os poder usar.
Session 2
Nome1 AX (3 anos)
Nome2 G (4 anos)
Hora inicial 10h30 Hora final 10h45
Objectivos prévios
Noções: “vazio” vs. “cheio” e “dentro” vs. “fora”.
Desenrolar e resultados gerais:
Na construção de caixas
Eu - Para que é que podem servir as caixas?
AX – “Pra meter coisas.”
Eu – “Então se isto for a nossa mala de viagem, o que é que lhe vais pôr dentro?”
AX – “Vou levar um robô, um camião, uma bomba, um número, um camião e uma balança. Já está.”
Entrou para o pensamento do robô: “vou ensinar o robô a explodir a caixa...”
Eu – Afinal o que é que lhe estás a ensinar?
AX: A fazer casas.
Lista de elementos de registo (ficheiros) associados:
Desenho do Paint e caixa de "coisas para viagem" no caderno do ToonTalk.
Observações
AX: os passarinhos levam as coisas para o ninho para os filhotes comerem.
Estive a explicar ao AX que se der uma caixa vazia ao robô o que lhe ensinar ele vai fazer sempre seguido.
AX: fica sempre a fazer, é?
Depois expliquei-lhe como se deve ensinar o robô.
Session 3
Nome1 AX - 4
Nome2
Hora inicial 10:51 Hora final 11:26
Objectivos prévios
Programar o robô para colocar o nome no telhado.
Começou por aprender a colocar o nome no telhado.
Desenrolar e resultados gerais:
Não se lembrava de usar a caixa que fica feita. Ia fazer outro robô, fazendo outra caixa.
Ficou sorridente ao ver o nome dele no telhado, quis fazer mais.
“Tem os números verdes!”, não era o sensor certo que ele tinha fixado. Mas na 2ª tentativa fez direito. Já se levantou
para verificar se o nome estava no telhado.
Lista de elementos de registo (ficheiros) associados:
Robô que põe nome no telhado – no caderno do ToonTalk.
Observações
“Vou fazer o nome nas casas todas”.
Virou-se para os colegas: “Estas casas todas vão ser minhas.”
Já queria decorar a casa.
O AX, se o deixarem, fica a trabalhar no computador indefinidamente.
Observações
Quando usou a bomba de ar, o AX soltou uma grande exclamação: “O robô está a encher!”
Ao chegar à casa “AX”, o AX já disse: “ah, tenho muitas coisas para aspirar!”
O AX propôs ao G dar coisas ao passarinho. Perguntei-lhe porquê. AX: “Ele põe no ninho.”
Session 5
Nome1 AX – 4
Nome2 G–4
Hora inicial 9h20 Hora final 9h47
Objectivos prévios
Trabalhar imagens de Natal para decorar a casa ToonTalk.
Desenrolar e resultados gerais:
O AX entra no ToonTalk e começa a brincar a tirar coisas da caixa e a aspirar. Tem o cuidado de ligar e desligar o
aspirador.
Depois fomos buscar o desenho de Natal do AX. Ele quis guardar o desenho no caderno. Ao tentar pôr o desenho mais
pequeno, teve dificuldade porque não soube alterar as funções da bomba de ar. Fez camiões pequenos para tentar
procurar ver se conseguia construir casas pequeninas.
O G teve de rever alguns comandos “básicos”, pois tem faltado a sessões do ToonTalk.
Lista de elementos de registo (ficheiros) associados:
Cidade ToonTalk.
Observações
O AX gosta de ajudar o G, explicando-lhe o que tem de fazer.
Ao dizer para levantar o boneco, o G levantou o boneco que tinha na mão.
Session 6
NOME: AX
IDADE: 4 anos
DATA:23-01-03
HORA DE INÍCIO: 10h30
HORA DE TERMINUS: 10h40
OBJECTIVOS PRÉVIOS: realizar uma cidade em que as casas tivessem as fotos das crianças
DESENROLAR E RESULTADOS GERAIS: o AX sabe como reduzir a foto e procurar em cadernos sem ajuda.
Só precisa que lhe indiquem quais os cadernos certos a usar.
Session 11
NOMES: AX e G
IDADE: 4 anos
DATA: 19- 05-03
HORA DE INÍCIO: 15h37m
HORA DE TERMINUS: 16h02m
DESENROLAR E RESULTADOS GERAIS: o AX explicou ao G como pôr o desenho na parede verdadeira,
através do caderno. Disse para ir buscar a parede ao caderno, para abrir e depois colocar o desenho na parede.
O AX começou por colocar o desenho dele mais pequeno, antes mesmo de usá –lo para pôr na parede. Encontrou
o caderno simplificado dos sensores. Tirou logo a parede e a casa pois disse “vou fazer tudo ao mesmo tempo”, para
explicar que ia fazer rápido o que tinha de fazer.
O AX colocou o nome sem dificuldades na entrada de casa. Quis guardar as coisas que fez sem eu lho dizer.
O G também consegue entender o que tem de fazer para colocar nome ou desenho mas a um ritmo muito
diferente do AX, que consegue abstrair –se e entender que colocando o desenho ou nome na parede ou casa “faz de
conta” ele vai aparecer “na grande”.
O AX quis depois ensinar o robô a colocar o nome na parede. Tentou fazê –lo dando uma caixa vazia ao robô.
Expliquei - lhe depois que era melhor dar uma caixa já com o nome ao robô.
O AX, ao ver o robô aspirar depois de ter feito o que lhe ensinou, disse:”Este robô é malandro!”. Expliquei –lhe
que ele faz o que nós fazemos antes de sair do toontalk ou seja, deixa tudo arrumado.
Group 11
Session 1
Nome1 AL – 5
Nome2
Hora inicial 14:07 Hora final 14:34
Objectivos prévios
Exploração do ambiente ToonTalk. Robô construtor de casas. Pôr o nome no telhado. Usar bomba de ar.
Desenrolar e resultados gerais:
A AL já conhece o jogo. Não se recordava dos diferentes botões para levantar, voar, aterrar.
Ao pôr coisas dentro de caixas e ver o rato a sobrepor letras riu estridentemente.
A AL quiz que o robô levasse um ninho para a casa.
Deu coisas ao passarinho para o ver levar coisas.
Depois de escrever o nome em duas casas fez uma casa para uma amiga (JG).
Lista de elementos de registo (ficheiros) associados:
Cidade com nomes.
Observações
É a 1ª sessão (acompanhada) deste ano lectivo, da AL.
Num dos telhados colocou uma flor, depois quis colocar também o nome, para se saber que a casa era dela.
Session 2
Nome1 AL
Nome2
Hora inicial 11:40 Hora final 12:02
Objectivos prévios
Trabalhar o controlo da bomba de ar e do aspirador.
A limpeza do espaço de trabalho e de brincadeiras.
Desenrolar e resultados gerais:
A AL não tem quaisquer dificuldades em utilizar os objectos da caixa de ferramentas. Também conseguiu perceber
que P = pequeno e G = grande.
Gosta de mandar construir casas e sai para, de helicóptero, ver as casas que construiu: “Olhas as casas que mandei
fazer” (disse apontando). Sem lhe dar instruções quis pôr o nome no telhado. Só perguntou onde desfolhar o caderno.
Lista de elementos de registo (ficheiros) associados:
Observações
Ja sabe usa F1, sem eu fazer qualquer referência, para mandar o marciano embora.
Para pôr o nome no telhado tentou fazê-lo sem estar dentro de casa.
Session 3
Nome1 AL
Nome2
Hora inicial 15h12 Hora final 15h28
Objectivos prévios
Usar os desenhos do Paint para decorar uma casa na cidade do ToonTalk. Aprender que o passarinho leva as coisas
para o ninho.
Desenrolar e resultados gerais:
A AL precisou de ajuda para encontrar o caderno de sensores. Quis decorar também o telhado com o desenho de
Natal.
A AL ao usar a bomba de ar perguntou como é que fazia para pôr as coisas pequenas. Disse-lhe que é na letra P e ela
disse que ainda não sabe essa letra.
Percebeu que o passarinho leva as coisas para o ninho e experimentou dar-lhe o nome para ele levar para outra casa
onde estava o ninho.
Lista de elementos de registo (ficheiros) associados:
Desenho do Paint, cidade ToonTalk.
Observações
A AL sugeriu que era bom usarmos um rato sem fio!!
Session 4
NOME: AL
IDADE: 5 anos
DATA: 4-02-03
HORA DE INÍCIO: 15h31m
HORA DE TERMINUS: 15h46m
OBJECTIVOS PRÉVIOS: colocar o nome no telhado e ensinar o robot a fazer o mesmo.
DESENROLAR E RESULTADOS GERAIS: a AL precisou que lhe lembrasse de procurar o telhado/ sensor no
caderno, para escrever o nome. A AL perguntou como se levantava.
Não reparou na caixa igual à que tinha dado ao robot.
Saiu da casa para verificar que o nome estava no telhado e depois disse para voltarmos para a casa para arrumar
tudo.
Session 5
NOME: AL
IDADE: 5 anos
DATA:
HORA DE INÍCIO: 15h42m
HORA DE TERMINUS: 15h57m
OBJECTIVOS PRÉVIOS: já referidos
DESENROLAR E RESULTADOS GERAIS: a AL percebeu e explicou que estava a fazer igual. Ás vezes
acontece -lhe largar uns objectos sobre outros sem querer.
Para ensinar o robô a fazer casas a AL pensou precisar de uma caixa e de um camião, pois robô já tinha (o que
queria ensinar!).
Disse que tinha de sair do pensamento do robô.
Não usa a caixa inicial.
Aprendeu a copiar a caixa para que o robot não pare.
AL –“Temos que ensinar coisas e para não parar temos de ensina -lo a fazer truques com a varinha mágica.”
OBSERVAÇÕES:
Session 7
NOMES: AL e CA
IDADE: 5 anos
DATA: 20- 05-03
HORA DE INÍCIO: 15h25m
HORA DE TERMINUS: 15h49m
OBJECTIVOS PRÉVIOS:
DESENROLAR E RESULTADOS GERAIS: a AL já não se recordava como decorar a parede.
Estiveram a pôr o nome na casa. A CA relembrou a AL onde levantava o boneco. A CA ao guardar o que fez no
caderno quis colocar de um lado o que fez e do outro o nome, como costumamos fazer. A AL e a CA conseguiram
perceber a actividade.
OBSERVAÇÕES: como a U está para a Ucrânia, a CA fez com a AL
Session 8
NOMES: AL
IDADE: 5 anos
DATA: 03- 06-03
HORA DE INÍCIO: 10h10m
HORA DE TERMINUS: 10h30m
OBJECTIVOS PRÉVIOS: já referidos
DESENROLAR E RESULTADOS GERAIS: para pôr o nome no telhado disse que precisava de letras e do
telhado.
Foi verificar se o nome estava no telhado.
Teve dúvidas em sair do pensamento do robô.
A AL coloca a caixa para o pensamento na zona branca.
A AL gosta sempre de arrumar o que desarrumou no toontalk, deixando as casas arrumadas.
Observações:
Uma falha que notei foi que ao colocar o robô a funcionar, tendo de lhe dar uma caixa azul, a que se encontrava
no chão da casa, fica sempre por trás do pensamento do robô, sendo difícil para as miúdas ir descobri-lo para dar ao
robô.
Session 2
This matches session 2b in group 10.
Nome1 J
Nome2 IT
Hora inicial 9:40 Hora final 10:00
Objectivos prévios
Relação de 1 para 1, relação de 1 pássaro –> n (ninhos)
Pergunta->O que é que o pássaro fazia ao objecto que nós lhe dávamos na relação de 1 pássaro para 1 ninho.
Depois o que é que o pássaro fazia se copiasse os ninhos? Onde é que ele iria pôr o objecto?
Depois entrei no pensamento do robô para os miúdos o programarem a fazer a relação de 1 pássaro para n ninhos.
Neste caso, copiei apenas 3 ninhos.
Inicialmente, expus as duas situações fazendo as perguntas para ver como reagiram.
Desenrolar e resultados gerais:
J: para pegar no ninho levantaram o rato do tapete. Em relação à segunda pergunta, disse que o pássaro morria.
Sabem como é que se entra no pensamento do robô. Conseguiu descobrir a caixa azul por detrás do robô para o pôr a
funcionar.
Achou piada no pensamento do robô estar a utilizar o aspirador e por ser tão pequenino com pernas e olhos.
IT: Resposta à pergunta: se calhar come-os e depois, morre.
Lista de elementos de registo (ficheiros) associados:
Observações
Group 2
Session 1
Nome1 F
Nome2 M
Hora inicial 14:50 Hora final 15:10
Objectivos prévios:
Construção de casas
Desenrolar e resultados gerais:
São dois miúdos que já dominam razoavelmente o computador. Estiveram a ouvir a minha explicação e depois
fizeram bastante bem, tendo sido a minha intervenção no que diz respeito a ajuda muito pouco.
Observações:
Session 2
Nome1 F
Nome2 M
Hora inicial 10:00 Hora final 10:20
Objectivos prévios
Os mesmos
Desenrolar e resultados gerais:
Ambos não souberam responder à primeira pergunta. São muito calados. Em relação à segunda disseram que ia
colocá-los em todos os ninhos.
F: Depois de entrar no pensamento do robô ia pô-lo a fazer casas, mas depois conseguiu fazer sozinho o que estava a
fazer fora do pensamento do robô.
O M, depois de ver o F, entrou directamente no pensamento do robô e utilizou bem a varinha para fazer cópias dos
ninhos. Saiu bem do pensamento do robô e conseguiu pô-lo a funcionar.
Lista de elementos de registo (ficheiros) associados:
Observações
Group 3
Session 1
Nome1 IF
Nome2 MG
Hora inicial 15:15 Hora final 15:40
Objectivos prévios:
Construção de casas
Desenrolar e resultados gerais:
São duas miúdas que ainda estão um pouco verdes no que diz respeito à motricidade fina. Sendo necessário
ainda a minha ajuda. Nestes dois casos eu ainda ajudei bastante, portanto as duas ainda não conseguiram fazer sozinhas.
Lista de elementos de registo (ficheiros) associados:
Observações:
Session 2a
This matches session 2a in group 7.
Nome1 FL
Nome2 IF
Hora inicial 14:41 Hora final 15:00
Objectivos prévios
Os mesmos
Desenrolar e resultados gerais:
IF: Ao colocar a pergunta na relação 1 para 1, disse que iria colocá-lo, o objecto, no ninho. Quando fiz a cópia dos
ninhos, também me disse que iria pôr o objecto num ninho. Então perguntei porque é que não vai pôr nos outros
ninhos também. Depois, ficou à espera do que poderia acontecer. Ainda se lembrou do que é que a varinha fazia e
que era para copiar.
FL: Colocava o objecto num só ninho porque há só um. Não conseguiu fazer sozinho, eu é que tive de o ajudar.
Sabem bem onde é sair e copiar.
Dentro do pensamento do robô, quando disse que era com a outra mão do robô, ele trocou a mão dele no rato.
Lista de elementos de registo (ficheiros) associados:
Observações
Observações
Group 4
Session 1
Nome1 AT
Nome2 CP
Hora inicial 15:40 Hora final 16:00
Objectivos prévios:
Construção de casas
Desenrolar e resultados gerais:
Aplica-se a mesma situação à da IF e MG.
Lista de elementos de registo (ficheiros) associados:
Observações:
Group 5
Session 1
Nome1 FM
Nome2 D
Hora inicial 9:30 Hora final 9:50
Objectivos prévios:
Construção de casas
Desenrolar e resultados gerais:
O FM tem um bom desempenho. Depois, como o D ainda não consegue desenvolver, eu é que tenho de fazer
tudo, o FM acabou por ajudar o D, dizendo-lhe como é que ele devia fazer.
Lista de elementos de registo (ficheiros) associados:
Observações:
Observações
Session 2b
This matches session 2b in group 9.
Nome1 BB
Nome2 FM
Hora inicial 10:40 Hora final 11:00
Objectivos prévios
Os mesmos.
Desenrolar e resultados gerais:
BB: resposta à primeira pergunta: vai é voar e vai-se embora.
Reposta à segunda: vai fazer mais pássaros. Queria tirar outro ninho e copiar mais pássaros. Pôs o robô a funcionar
com a caixa azul por trás do pensamento.
Disse: este robô é complicado porque ela não estava a colocá-lo onde queria. Disse a caixa vai sempre comigo.
FM: A CA explicava e punha a mão no FM para por a mão no monitor para ter muitos pássaros. Tive de o ajudar em
todos os passos.
Lista de elementos de registo (ficheiros) associados:
Observações
Group 6
Session 1
Nome1 FS
Nome2 C
Hora inicial 9:50 Hora final 10:10
Objectivos prévios:
Construção de casas
Desenrolar e resultados gerais:
O FS somente ao fim é que descobriu que o robô fazia igual, ficando um pouco admirado com a saída dos
camiões das casas.
A C conseguiu mais ou menos, tendo gostado de ver os camiões a construir as casas na ilha.
Lista de elementos de registo (ficheiros) associados:
Observações:
Session 2
This matches session 2b in group 7.
Nome1 DI
Nome2 FS
Observações
Group 7
Session 1
Nome1 FL
Nome2 DI
Hora inicial 10:10 Hora final 10:30
Objectivos prévios:
Construção de casas
Desenrolar e resultados gerais:
O DI é um miúdo que está sempre a fazer perguntas, lembrou-se bem da sessão anterior e pensou que iríamos
fazer a mesma coisa. Conseguiu após a minha explicação fazer bem a actividade.
O FL ainda tenho de o ajudar bastante.
Lista de elementos de registo (ficheiros) associados:
Observações:
Session 2a
This matches session 2a in group 3.
Session 2b
This matches session 2 in group 6.
Group 8
Session 1
Nome1 B
Nome2 CA
Hora inicial 10:30 Hora final 10:50
Objectivos prévios:
Construção de casas
Desenrolar e resultados gerais:
A B ajudou a CA, depois da minha explicação. Ambas precisaram de pouco da minha ajuda.
Lista de elementos de registo (ficheiros) associados:
Observações:
Session 2
Nome1 CA
Nome2 B
Hora inicial 9:20 Hora final 9:40
Objectivos prévios
Observações
Group 9
Session 1
Nome1 BB
Nome2 L
Hora inicial 10:55 Hora final 11:20
Objectivos prévios:
Construção de casas
Desenrolar e resultados gerais:
A BB já não precisou muito da minha ajuda e conseguiu, após a explicação, fazer o exercício, sem problemas.
O L é o oposto, eu é que tive de colocar a minha mão no rato e fazer quase tudo.
Lista de elementos de registo (ficheiros) associados:
Observações:
Session 2a
This matches session 1 in group 12.
Session 2b
This matches session 2b in group 5.
Group 10
Session 1
Nome1 J
Nome2 MA
Hora inicial 11:20 Hora final 11:40
Objectivos prévios:
Construção de casas
Desenrolar e resultados gerais:
A J conseguiu descobrir a caixa atrás do pensamento do robô.
Antes, tinha pedido para ir ver a onde fora parar o camião.
A MA, depois de ver a J, conseguiu sozinha fazer a actividade.
Lista de elementos de registo (ficheiros) associados:
Observações:
Session 2a
This matches session 2b in group 3.
Session 2b
This matches session 2 in group 1.
Observações:
Session 2a
This matches session 2a in group 5.
Session 2b
Nome1 AC
Nome2
Hora inicial 11:20 Hora final 11:45
Objectivos prévios
Os mesmos.
Desenrolar e resultados gerais:
A AC não fala quase nada e tive de estar a fazer-lhe tudo. Não quer ficar muito tempo no computador.
Lista de elementos de registo (ficheiros) associados:
Observações
Group 12
Session 1
This matches session 2a in group 9.
Observações:
Na sua totalidade estas crianças não tinham tido contacto com o computador, algumas estão no jardim pela
primeira vez.
O Toon Talk provocou-lhes admiração, entusiasmo e interesse.
Session 2
Data: 17/10/2002 Grupo: F/JO
Hora Inicial: 14.15h Hora Final: 15.45h
Objectivos prévios:
Conhecer
Explorar/Brincar
Mexer objectos
Manipular
Desenrolar e resultados finais:
As crianças ainda não exploraram totalmente o jogo, daí que as estratégias para os objectivos que definam uma
actividade ainda se torne difícil.
As crianças carregaram camiões com caixas e pretendiam despejá-los. O facto de lhe ter dito que com um
camião transportando um objecto e um robô poderia construir uma casa, quiseram fazê-lo repetidas vezes. As caixas e
os números dentro das mesmas foi o que mais fizeram.
“ Vou pôr números para dar os anos da B...”
Observações:
As crianças já interiorizaram um pouco o jogo em si, ou seja as suas componentes e certas finalidades.
Session 3
Data: 28/11/2002 Grupo: JO/F
Hora Inicial: 14.45h Hora Final: 15.30h
Objectivos prévios:
Manipular o caderno
Manipular os objectos sabendo as suas funções,
Articular acções com o tema do Jardim.
Desenrolar e resultados finais:
O JO e o F tiraram caixas e letras para fazerem o nome e colocaram nas caixas, depois tornavam a tirar e com a
bomba aumentaram e diminuíram para verem o grande e o pequeno. O F gosta de escrever o nome e tirar do caderno os
camiões com os bonecos para brincar. O JO constrói casas e depois vai vê-las navegando no helicóptero.
Lista de elementos de registo (ficheiros) associados:
Observações:
O JO disse que a bomba de encher era a bomba da gasolina. O F gostava que os bonecos, que são de imagem
saíssem do camião para brincarem com ele.
Session 4
Data: 13/01/2003 Grupo: JO/F
Hora Inicial: 10.45h Hora Final: 11.15h
Objectivos prévios:
Manipular o caderno
Manipular os objectos sabendo as suas funções,
Articular acções com o tema do Jardim.
Desenrolar e resultados finais:
Hoje decidiu-se em grande grupo que se a partir do toon talk os símbolos para os cabides da sala de jardim. O JO
e o F antes de trazerem a fotografia, com é habitual quiseram andar com o helicóptero, depois sendo a sua preferência
brincar com os camiões resolveram colocar caixas e robôs e construir muitas casas. Já querem “fazer”, o nome para em
seguida colocar no telhado, onde podemos registar o seu sentimento de posse e de algo que conseguiram construir.
Depois quiseram trazer a fotografia para o toon talk para elaborarem a moldura.
Lista de elementos de registo (ficheiros) associados:
Observações:
Nota-se que percebem o que estão a fazer e que no quarto da casa é o sítio dos brinquedos.
Observações:
O JO, explicou ao Frederico, “o homem foge mas carrego no botão do avião e ele vêm porque o outro foi para o
lixo.”
Group 2
Session 1
Data: 18/10/2002 Grupo: A/L
Hora Inicial: 10h. Hora Final: 10.45h
Objectivos prévios:
Explorar/Brincar
Mexer objectos
Manipular
Encaixar
Desenrolar e resultados finais:
A A aderiu muito bem ao jogo, e está sempre aberta a novas descobertas.
Mexe bem o rato por isso consegue muito bem agarrar e largar objectos. A A utilizou a bomba de encher e
resolveu aumentar os números, “ vou encher números...” o L contrapôs a colega dizendo, “ não, não, a bomba é para
encher os pneus dos camiões”. O L quis mexer com o aspirador e chamou-lhe peixe gordo, “vou passeá-lo”.
A A já compreendeu que pode aspirar o que não consegue arrumar na caixa.
Lista de elementos de registo (ficheiros) associados:
Observações:
Nesta sessão as crianças já coordenam o rato em simultâneo com os movimentos dos objectos que pretendem
mexer. O ambiente do jogo já lhes é familiar, podendo-se avançar para actividades direccionadas e interligá-la com as
da sala.
Observações:
Já têm a noção de ajoelhar baixar o helicóptero, entrar nas casas e das ferramentas da mala.
Session 3
Data: 28/11/2002 Grupo: A/L
Hora Inicial: 9.45 Hora Final: 10h
Objectivos prévios:
Manipular o caderno
Manipular os objectos sabendo as suas funções,
Articular acções com o tema do Jardim.
Desenrolar e resultados finais:
A A tirou caixas, ninhos e robôs. A A gosta de ver os pássaros a saírem dos ninhos, depois faz jogos de faz de
conta, como se estivesse a brincar com bonecos no chão. Fala sozinho e com os “bonecos”, com o pássaro e o robô
dando-lhes ordens. De vez em quando vai andar de helicóptero para ir fazer compras. Depois regressa e percorre o
caderno para tirar objectos, a árvore, os bonecos e as flores para fazer quadros. O L é mais caladinho mas adere ás
brincadeiras da A. Este tira da mala os camiões para transportar coisas e fazer casas.
Lista de elementos de registo (ficheiros) associados:
Observações:
Estamos a preparar algo alusivo ao Natal para trabalhar no toon talk.
Session 4
Data: 28/11/2002 Grupo: A/L
Hora Inicial: 15.30h Hora Final: 15.45h
Objectivos prévios:
Manipular o caderno
Manipular os objectos sabendo as suas funções,
Articular acções com o tema do Jardim.
Desenrolar e resultados finais:
A A e o L quiseram voltar ao toon talk, para acabarem as “construções”.
Observações:
São crianças muito pequenas, no entanto já interiorizaram o jogo e trazem muitas das suas vivências para o
pequeno ecrã, como se dele fizessem parte num mundo do faz de conta.
Session 5
Data: 13/01/2003 Grupo: A/L
Hora Inicial: 10.00h Hora Final: 10.30h
Objectivos prévios:
Manipular o caderno
Manipular os objectos sabendo as suas funções,
Articular acções com o tema do Jardim.
Desenrolar e resultados finais:
Hoje decidiu-se em grande grupo que se a partir do toon talk os símbolos para os cabides da sala de jardim. A A
e o L escolheram a moldura no caderno, escreveram o nome a partir da letra e trouxeram a fotografia para o toon talk e
depois de colocada na moldura com o respectivo nome imprimimos.
Lista de elementos de registo (ficheiros) associados:
Observações:
O facto de trabalharem no toon talk criando algo e terem ao mesmo tempo colocado a sua imagem dentro deste é
algo muito delirante e positivo para eles. Ficaram entusiasmadissímos com tal facto.
“ olha, o boneco já não está sozinho eu já estou lá.” (L)
Group 3
Session 1
Data: 21/10/2002 Grupo: JG/C
Hora Inicial: 9.45h Hora Final: 10.15h
Objectivos prévios:
Mexer objectos
Manipular
Colocar objectos nas caixas
Escrever nomes nas caixas
Desenrolar e resultados finais:
Anteriormente a esta sessão, a actividade da sala tinha sido culinária, mais propriamente “Biscoitos”.
Trabalhamos no paint os desenhos da receita como registo acompanhado do registo escrito feito no Word. Deste modo,
propus transportarmos esta actividade para o toon talk. Não foi possível porque as crianças ainda necessitaram explorar
um pouco mais. Resolvi direccionar para o trabalho de caixas e colocar o que iam fazendo no caderno.
O Helicóptero continua a ser a preferência das crianças. No caso do JG e da C, quiseram andar de helicóptero
acompanhavam o barulho deste com vocalizações. O efeito da bomba a estoirar também foi feito repetidamente.
Lista de elementos de registo (ficheiros) associados:
Observações:
O JG e a C têm 3 anos, gostam do toon talk, a exploração dos objectos ainda foi feita com muita vivacidade. A
curiosidade pelo funcionamento nota-se na constante pergunta, “...e isto para que serve?”, “vou ver, sim?...”
Observações:
A C divertiu-se muito com os passarinhos mas tinha pena deles porque não tinham mãe.
Group 4
Session 1
Data: 21/10/2002 Grupo: P/FI
Hora Inicial: 11.15h Hora Final: 11.45h
Objectivos prévios:
Mexer objectos
Manipular
Colocar objectos nas caixas
Escrever nomes nas caixas
Desenrolar e resultados finais:
O P manuseia bem o rato, tem destreza manual, o que ajuda bastante no trabalho no toon talk. Ao entrar no ecrã
foi decidido. Colocou caixas em vários camiões para construir muitas casas. O P, lembrou-se da nossa conversa e disse
que uma das casas seria o armário dos biscoitos.
Adora explodir com as casas, (o pai é técnico de explosivos em obras e ele referiu fazer como o pai). Tirou um
robô e trabalhou o pensamento com caixas.
Em todos os camiões que tirava colocava caixas com objectos diferentes e com os robôs, e resolveu a certa altura
utilizar a varinha para os duplicar.
A FI só quis andar de helicóptero à deriva.
Lista de elementos de registo (ficheiros) associados:
Observações:
As crianças mantem-se entusiasmadas, ainda não querem fazer actividades direccionadas, continuam a explorar a
função dos objectos exploram.
Session 2
Data: 13/01/2003 Grupo: FI/P
Hora Inicial: 11.30h Hora Final: 12.00h
Objectivos prévios:
Manipular o caderno
Manipular os objectos sabendo as suas funções,
Articular acções com o tema do Jardim.
Observações:
O P e a FI já se sentem á vontade no toon talk, e interagem bem os dois. A actividade e a possibilidade de
trazerem as fotografias deles para o toon talk aproximou-os mais do jogo tornando-o mais íntimo.
O P chegou a comentar:
“ Eu já consegui entrar para alí...olha ...”
Group 5
Session 1
Data: 21/10/2002 Grupo: JA/CA
Hora Inicial: 11.45h Hora Final: 12h
Objectivos prévios:
Mexer objectos
Manipular
Colocar objectos nas caixas
Escrever nomes nas caixas
Desenrolar e resultados finais:
Colocaram objectos nas caixas, trabalharam objectos nas caixas e colocaram imagens no caderno. Quiseram
fazer o nome, (são dos 5 anos). Escreveram-no nas caixas. No fim aspiraram tudo não quiseram arrumar.
Lista de elementos de registo (ficheiros) associados:
Observações:
(O trabalho não ficou completo, estava na hora do almoço.)
Estas duas crianças, tem 5 anos e já aceitam actividades sugeridas.
Session 2
Data: 28/11/2002 Grupo: JA/CA
Hora Inicial: 11h Hora Final: 11.45h
Objectivos prévios:
Manipular o caderno
Manipular os objectos sabendo as suas funções,
Articular acções com o tema do Jardim.
Desenrolar e resultados finais:
A JA e a CA já se movimentam bem no jogo. Trabalhamos com caixas algumas noções de tamanhos, de dentro e
fora e de sequências. Elas gostam imenso de trabalhar com o caderno, construindo caixas com nomes e desenhos e
colocando no caderno. Fazem construções de palavras e sequências de números.
Lista de elementos de registo (ficheiros) associados:
Observações:
Estamos a preparar algo alusivo ao Natal para trabalhar no toon talk. A CA disse que gostava de fechar o
caderno para ver a capa.
Group 6
Session 1
Data: 28/11/2002 Grupo: E/S
Hora Inicial: 10.5h Hora Final: 11h
Objectivos prévios:
Manipular os objectos sabendo as suas funções,
Articular acções com o tema do Jardim.
Desenrolar e resultados finais:
O E e a S gostam de experimentar todos os objectos da mala. Os camiões são os seus preferidos. O E já coloca
caixas robôs e objectos nos camiões para construir muitas casas “quando vier da Suíça”.
Lista de elementos de registo (ficheiros) associados:
Observações:
O E, “ A Bomba é para cantar os parabéns.”
648 Framework for Computer Programming in Preschool and Kindergarten
Universidade de Trás-os-Montes e Alto Douro
Annex IX
—
Report on activities conducted by two second-year trainees of
the Early Childhood Education baccalaureate
Introdução
Este relatório consiste na delineação do trabalho realizado no Jardim de Infância de Parada de Cunhos com um
grupo de 18 crianças de 3, 4 e 5 anos com o jogo Toon Talk. Integrado na nossa prática de Disciplina de Observação
das Actividades Educativas II, o trabalho foi feito durante o período das actividades livres (momento em que as crianças
circulam nos vários espaços da sala). Animámos o cantinho do Computador com o grande grupo, explorando o Toon
Talk e com um grupo pequeno, de 4 crianças, às quais fizemos uma proposta específica integrada no projecto “Vamos
Descobrir Portugal” desenvolvido ao longo do semestre.
O nosso trabalho divide-se principalmente em duas partes, o registo diário com o pequeno e o grande grupo.
Ambas as partes estão subdivididas em objectivos, comentários das crianças, avaliação e registos (em tabelas no grande
grupo e imagens do Toon no pequeno grupo). Os registos do pequeno grupo estão completados com ficheiros (em
anexo no CD) das várias evoluções que a Cidade sofreu (pasta CIDADE), a localização das pastas está abaixo do título
«Registos/observações do dia…». Note-se que o CD contém ainda este relatório (ficheiro Toon), pastas (identificadas)
com imagens do Toon (PrintScreen) realizadas e ainda uma pasta com os ficheiros dos crash´s dos dias
correspondentes.
Quando tivemos problemas técnicos as crianças tinham conhecimento, era inevitável, mas tentamos sempre que
isso não constituísse um problema para o avanço do trabalho. Achámos relevante colocar alguns comentários das
observações das crianças mediante a ocorrência desses acontecimentos.
Ilustração 13 Casa da Rita (Padeira Brites) vista da parede exterior e interior da casa.
Ilustração 14 Casa da Rita: armário de ferramentas (baixo) e produtos (em cima) e guarda-roupa.
Ilustração 15 Casa da Carina (Teresa Limpeza) vista da parede exterior e interior da casa.
Ilustração 16 Casa da Carina: guarda-roupa e armário de ferramentas (baixo) e produtos (em cima).
Ilustração 17 Casa do David (Jardineiro Jasmim) vista da parede exterior e interior da casa.
Ilustração 18 Casa do David: guarda-roupa e armário de ferramentas (baixo) e produtos (em cima).
Ilustração 19 Casa do Miguel (Carteiro João) vista da parede exterior e interior da casa.
Ilustração 20 Casa do Miguel: guarda-roupa e armário de ferramentas (baixo) e produtos (em cima).
Ilustração 22 Interior da casa do David (Jardineiro Jasmim), vista geral, mesa dos pássaros, guarda-roupa e
armário de produtos e utensílios.
Ilustração 23 Interior da casa da Rita (Padeira Brites), vista geral, mesa dos pássaros, guarda-roupa e armário
de produtos e utensílios.
Ilustração 24 Interior da casa da Carina (Teresa Limpeza), vista geral, armário dos pássaros, guarda-roupa e
armário de produtos e utensílios.
Ilustração 25 Interior da casa do Miguel (Carteiro João), vista geral, armário dos pássaros, guarda-roupa e
armário de produtos e utensílios.
Ilustração 26 Casa do Miguel (Carteiro João), vista do exterior e interior e mesa dos pedidos.
Ilustração 27 Casa da Rita (Padeira Brites), vista do exterior e interior e armário dos pedidos.
Ilustração 28 Casa da Carina (Teresa Limpeza), vista do exterior e interior e mesa dos pedidos.
Ilustração 29 Casa da Rita (Padeira Brites), vista do exterior, armário dos pedidos e guarda-roupa.
Ilustração 30 Casa do David (Jardineiro Jasmim), vista do exterior e armário dos pedidos.
Ilustração 31 Casa da Carina (Teresa Limpeza), vista do exterior e mesa dos pedidos.
Ilustração 32 Casa do Miguel (Carteiro João), vista do exterior e mesa dos pedidos.
Ilustração 39 Envio da carta do Jardineiro Jasmim (David) para a Padeira Brites (Rita) através dos CTT
(Miguel).
Conclusão/Avaliação
Ao finalizarmos este trabalho pensamos que conseguimos realizar um bom trabalho com as crianças, todos nós
aprendemos e divertimo-nos muito. Constamos que as crianças gostaram do jogo desde o início e que não jogaram
tantas vezes como o desejariam.
As principais dificuldades que sentimos na realização do trabalho foi a falta de tempo, uma vez por semana era
muito pouco para avançar com o trabalho, as crianças no início esqueciam-se de algumas coisas.
Quando se trabalhou com as crianças (pequeno grupo) dias seguidos notou-se um grande avanço e com isso um
crescente entusiasmo. As crianças interiorizaram mais facilmente o objectivo da Cidade, ao início ainda estavam um
pouco confusas. Perto do final, já tinham memorizado as teclas F1, F2, etc. e assim chamavam os instrumentos que
necessitavam sem lhes pegar; quando necessitavam de algum desenho dirigiam-se à Casa dos Desenhos e mostravam
um grande à vontade de deslocação na Cidade, iam a pé de um lado para o outro sem necessitar do helicóptero para se
orientarem.
Grande Grupo
Gostámos de jogar no Toon Talk.
Aprendemos a jogar com as teclas.
Explodimos as casas.
Com o helicóptero passeávamos para baixo e para cima.
Brincámos com o pássaro e tentámos enganá-lo, mas não conseguimos.
Com a bomba fazíamos as coisas pequenas e grandes.
Aspirámos as coisas com o aspirador e cuspimos.
O Rato Marretas colava as coisas.
Gostámos do jogo e foi fácil jogar.
Pequeno Grupo
Fizemos muitas trocas: bolos, flores, pinheiro, ecoponto.
A Rita enganou-se na encomenda, mandou para o Jasmim, pediu desculpa e depois enviou para a
Teresa.
Conseguimos arrumar todas as casas. Ao princípio foi difícil mas depois arrumamos tudo.
Gostávamos de continuar a jogar.
Já sabíamos as teclas todas para jogar, só precisávamos de ajuda para escrever.
Annex X
—
Logs of the activities conducted in a home setting in Medford,
MA, USA
Game History:
N generally plays games such as "Blue's Treasure Hunt" and "Putt-Putt joins the Race." On weekends he also
plays Zangband, "Planet Hot-wheels" and most of the Yahoo games.
Intent:
To make N. aware of and comfortable with the basic tools in toontalk by August 25, when he is to receive his
own copy of TT as a gift.
7-23-04 6:40pm-7:15pm
Plan:
Introduce N. to the basic interface of toon-
talk. Show how houses can be decorated and
decorate one with his assistance.
Reasoning:
Get N. comfortable with and interested in the
toontalk.
Start:
N. was slightly irritable and tired at the start,
he'd had a fairly long day.
Lesson:
In this lessen we decorated two houses together. In the first house I decorated while he suggested what pictures
to place. On the second house he decorated the inside, but grew tired and wanted me to finish. I ended up showing him
more than I'd initially intended. Along with the basics of adding pictures, I also taught him how to use Pumpy, Dusty,
navigating a notebook and removing items from it and the basic idea of typing in letter tiles. He learned each of the
basic concepts behind these fairly quickly, and had no trouble understanding that the thing you wanted to effect should
be shaking. He had some trouble understanding the difference between littler and shorter. He had little trouble using the
helicopter, and obviously found it intriguing, though he was somewhat uneasy dealing with navigation in general. He
showed considerable trepidation regarding moving the hand past the apparent bounds of the screen and had to be
encouraged to navigate the floor.
N's Questions/Observations:
Where's Tooly's mouth? <He came to the conclusion it must be on the top>
Why is the house door open when we're inside?
We're stepping on our things! <The things left on the floor, he was a touch alarmed>
End:
He was obviously excited, and was interested in continuing this form of play.
His words:
He repeatedly commented that it looked just like a game. After playing and describing it to his parents, he
described Marty as the green guy who tells you what to do when you don't understand something, Pumpy as the purple
guy who makes things wider or narrower, taller or shorter, big or little and the robot, who he'd seen in the picture on the
CD, as being the blue guy you teach to do things (this came from my description, we'll probably start with the robot
next week).
My Thoughts:
Though I showed more than initially intended none of it has any bearing on the weekend's work as presently
planned. He's picking it up well and was fairly comfortable doing it with a little hand holding, it'll be interesting to see
how he progresses.
7-24-04 4:05pm-5:10pm
Plan:
Introduce the mechanism for editing pictures
in toontalk.
Reasoning:
Show continuity from previous styles of play
to toontalk.
Start:
N was a little riled up today, he'd been rather
sick the night before and slept a bit late.
Lesson:
Today we decorated another house, this time the theme was to be a garden with flowers inside, vegetables
outside and implements on the top. We started out looking for flowers for the inside, but there was only one in the
notebook. So I then walked him through the process of taking a black square and editing it to be a drawing of his
choice. He was able to pick up the process fairly quickly. On getting three different kinds of flower I showed him how
to make many of the same thing using the wand. Interestingly he didn't seem nearly as amused by this as he was by
using Pumpy to make them larger and smaller.
I also showed him how to use a truck to build a new house.
I had intended for the session to only be half an hour long, but I'm obviously trying to squeeze too much into the
time since it took over any hour before we were done. He grew somewhat bored with the project midway through the
vegetables and had to be redirected towards it more than once.
He spent a fair amount of time exploring the limits of the world, finding how far his hand could reach on the
floor, whether he could get into the house by walking through the wall next to the door, seeing how far he could walk in
the world itself, and how far the helicopter could fly. He's obviously become more comfortable with the helicopter and
was a little irked to find that he couldn't land on the house, but tried for about 5 minutes.
He seems to be particularly interested in Tooly, he spent a while seeing how Tooly followed him. Maggie just
didn't seem to interest him.
He seemed to get a little frustrated when dealing with the mouse because it frequently required him to either pick
up the mouse and put it back to keep it on the pad, or to use the entire desk as his surface for the mouse, he generally
chose the latter.
He also wanted to look through each step of the process of making the new pictures in detail, wanting the screen
where TT asks what you want to do with the picture in hand to be read to him from the top down. This is typical
behavior for N.
End:
Still riled up.
N's Questions/Observations:
Why can the toolbox walk on the water? (at the bottom edge of the world)
Hey, I can walk through the wall!
His Words:
What did we do: We made a new house and we had to decorate it, that what our project was today.
Did you learn anything: We learned how to build a house.
My Thoughts:
He seems to be growing bored fairly quickly, part is simply is present mood, but I think I need to add more
variety with what we're doing. I might add the robots tomorrow instead of waiting until next week, I'll have to think on
it. Other possibilities would be to add a variety of small projects to what we're doing.
7-25-04 12:00pm-2:30pm
With a break from 12:30 to 1:15 for lunch and Gilligan's Island.
Plan:
Teach the basics of training a robot. Intended task is to make the robot count and go through the alphabet.
Reasoning:
Start a new form of play in toontalk and introduce the beginning of programming.
Start:
He was in a fairly relaxed mood today.
Lesson:
I started out showing N the basics of
programming a robot by teaching a robot to count
up, introduced how to deal with when the robot
expected something that it wasn't holding. He
understood these decently well, we then used the
scale to teach it to count to 10, and then 100. He
rapidly picked up the idea of how the scale works,
comparing how the scale looked to holding his
hands either even or with one above the other.
We then started making a 'supprise' for his
mother we did this by first making a background
picture and programming a robot to layer several
other pictures on top of it. Despite this process
taking significantly longer than the other projects he
remained actively interested until the end.
End:
Somewhat excited.
His Words:
My Thoughts:
I suspect there were a couple of factors involved with his continued interest, the first was the intent to give his
mother a present. Second because of the combination of putting the picture together and programming the robot there
was enough variety to keep him amused despite the added complexity.
7-30-04 2:30pm-4:15pm
Plan:
Today is going to be focused more on inspiring that instructing. I'm going to demonstrate some of the small
simple things that can be done in toontalk that are still amusing.
Reasoning:
The main idea is to inspire N. to continue playing with Toontalk, to insure that it doesn't become a chore.
Start:
N. was in a decent mood today, feeling alert and in the mood for playing.
End:
He was restless afterwards. I suspect that this was due to a combination of the heat, it's been a hot day and the
room itself is hot, and the length of the session.
My Thoughts:
Overall this was a fairly productive session, I think I achieved my intended goal, but not in the way I'd planned.
The surprising result was that N. actively interested in the debugging process. For a programmer this is often
considered the most frustrating task, for N. it was a natural extension of play, and in fact probably the closest we have
done to the play he is accustomed to. This is partly because of an average American boy's tendency towards playing
fix-it with toy tools etc. Also he and I have a history of "debugging play" where, for example, a toy train will not run
on the track properly, normally this is a cause for distress but we've turned this into a game of it's own by exploring
what has occurred to cause it and discussing it. Because of this, it is safe to say today was one of the most successful
sessions in terms of getting and holding his interest. Instead of having to judge when he was too bored to continue I had
to choose to stop because of time constraints and judging how tired he was. When I ended the session we were still
having trouble getting the "talking robots" working, we'd started having them say longer phrases and they were
vacuuming them up prematurely, and he told me he wanted to go back to fixing them tomorrow. The major draw back
to this kind of session is he was not directly involved, though he gave verbal input, and I made a point of asking his
opinion in the problems he made no direct action himself, but I think at this stage it is more important that he become
familiar with the system and learn to enjoy working with it than that he push though it because he should be getting
involved.
7-31-04 2:00pm-3:00pm
Plan:
Continuing on yesterday's theme. Today I'm going to make a fairly complicated program with his assistance.
We're going to make make a flower that grows in several stages.
Reasoning:
We're going to continue to do moderately complex, interesting programs.
Start:
Fairly alert, interested in play.
Lesson:
Due to time constraints todays session was somewhat shorter. Today we started by attempting to make a flower
that grew in several stages. Unfortunately we were stopped at an early stage by a bug in toontalk. The experience in
general was similar to yesterday's experience. He took a slightly more active roll, operating some of the tools and
helping to edit a picture of a leaf. We then started a more organized version of the recursive program for blowing up
the buildings. Here the buildings would be built one at a time and when a set number of buildings was reached they
would all be blown up at once. Unfortunately this did not work out as hoped due to a lack of understanding of how the
robots deal with nests on my part. We then proceeded to work on the standard recursive blowing up buildings program,
which he watched until we ended the session.
His Words:
We were changing a leaf and blowing up the city.
My Thoughts:
Today's session was a strong reminder of the importance of testing out ideas before presenting them in a learning
situation. Working on the fly can be ok for small parts of a project, but it is very important to practice in advance
before trying it with a child. Though I think N. enjoyed the session and learned some from it, he clearly gained less
than he would have if I'd been prepared both for the error in toontalk and had full understanding of how the given
program would perform when run.
08-07-04 2:00pm-3:00pm
Plan:
Construct robot that will cause a rectangle to cycle through all of its colors.
Reasoning:
This is a fairly simple project to execute, but N is still likelly to find it to be amusing.
Start:
N was in a good mood.
Lesson:
We worked through the process of creating a robot that would just add to the "picture #" sensor of a rectangle
repeatedly and stuck it on the back of the rectangle. N thought it was neat, but it flickered too fast for his taste, we then
went about the process of putting a delay in. We had little trouble doing this and were able to change the speed to his
satisfaction. He then said that he wanted to make it so it would only do it once, we decided to hold off on this project
for another day.
End:
Slightly hyperactive.
My Thoughts:
I'm particularly excited by the fact that this is the first time that N has taken a creative interest in what we're
doing it. It suggests that he's both become sufficiently comfortable with the medium to imagine what it can do and
remained sufficiently interested to want to impliment it.
08-08-04 1:50pm-3:20pm
Plan:
Continue yesterday's project by making the color square cycle only once. I'm going to attempt to get N more
directly involved in the creative process now that he's becoming more comfortable with the system.
Reasoning:
To help to focus his present interest.
Start:
He was in the mood to be paid attention to.
Lesson:
As planned we progressed through the process of making a color square cycle only once, with N doing more of
the work. I made a point of at each step asking his opinion of what we should do to solve a given problem. I also had
End:
Slightly more insistent on the attention.
N's Questions/Observations:
Why is everything made out of lego's? (I responded that it was because we built programs with it, to which he
responded "But lego's are a toy.")
My Thoughts:
A good session, he navigated the system well, and is able to at least to some extent think in toontalk. He was
noticibly disturbed by the fact that robots on the back of pictures don't always look like they're working properly. In
this case, though there were two robots that were doing their job on the back of the picture they both had boxes that
contained red squares.
08-09-04 3:20pm-4:10pm
Plan:
Another attempt at the robot team that distributes other teams one at a time, then blows up all of the houses at
once.
Reasoning:
The amusement of both N and myself.
Start:
He was pretty relaxed today.
Lesson:
Today's was intended largely to be mostly me working and talking through as I did it. We wrote up the program
with minimal trouble, other than there is presently a glitch somewhere that causes TT to freeze. Unfortunately there's
still something in the program that doesn't quite work as anticipated and though we were able to produce all of the
houses, the final explosion didn't occur.
End:
A little impatient.
N's Questions/Observations:
My Thoughts:
You would think that I would have learned after last weekend, you'd be wrong. I thought I had this figured out,
but hadn't planned on a couple of glitches in TT itself, but these border on random. Mostly, I still need to get my own
head wrapped around the TT paradigm. The previous two days were carefully planned, today was intended more to be
just tossing together an amusing toy to play with, I have to remember in these circumstances, even the toys need to be
carefully planned.
Annex XI
—
Sample activity sheet for preschool teachers: Storage Levels
Initial activity
Considering that a sequence of activities based on “Arbour Day” is taking place in the garden,
this suggestion is that initially a set of drawings is assembled, each drawing covering a small feature
of the theme. A global, theme-wide picture can also be produced. ToonTalk is used to store all
images. The final result may (and should) be somewhat disorganized, as demonstrated in figure 1.
So that the background image doesn’t get in the way of the activity development, it can be
glued to the ground. This initial activity allows children to develop basic manipulation activities
(pick, drop, enlarge, shrink, etc.).
Central activity
Storing things in notebooks
Having the pictures on the floor all the time, taking up a lot a space, isn’t the most practical
way to store them. Truth be told, they are more readily accessible, but they can also easily be lost,
vacuumed, “ruined” (by being drop on one another), etc.
These disadvantages are examples of motives that can be used to introduce the notebooks as a
storage solution. Figure 3 shows the use of 3 notebooks to save previously separated images. A
piece of text was used to describe each image, but that wasn’t absolutely necessary.
Final comments
Since an image archive is being produced, its very important for it to be used in other
activities. If there is a printer available, for instance, the images can be used in other off-computer
activities of the preschool room. They can also, obviously, be used in other computer or ToonTalk-
related activities.
Finally, it should be stressed that the aim is to use this activity as a method for exploration,
to try and find, for each children, strategies that allow her to understand “navigation” through a
multi-level organizational structure, becoming capable of creating and following it, in order to
obtain what she wants.
Annex XII
—
Sample activity sheet for preschool teachers: communication
channels (birds)
Initial activity
Considering an activity sequence in the preschool room, under the theme “professions”, this
activity proposes that all children play in the same ToonTalk city. It is assumed that each child
plays the role of a professional, taking responsibility for the decoration and preparation of a house
for that professional (example: figure 1).
Figure 1 – City with houses for three professionals (plus a “pictures” house”)
Each house should have a “warehouse” or “products"
section, related to its professional (vd. figure 2).
Products can be generic images, photographs, children-
made drawings, etc. These can be turned into infinite stacks,
so that the activity can take place in a more straightforward
manner. For this very reason, background images can be
glued to the house floor.
This initial activity allows time for children to develop
basic manipulation skills.
Central activity
Announcing services
When a professional is ready to provide services to the community, the activity can move on
into this phase. It’s the teacher’s role to decide when that time comes. Examples: when there are
enough products; when, besides having products, the house is properly decorated; when besides
products and decoration, there is a uniform; etc...
In order to provide services to the community, it is proposed that in this activity the children
playing a professional’s role will ANNOUNCE those services, using his/her bird. I.e.: he/she
creates a bird, makes copies of it, and distributes them around town. So that its purpose is
understood as a service-request point, the placement of a bird can be played, theatre-like, by saying,
for instance “I’m the baker. For when you want to order something from me, here’s a bird: use it to
place an order.”
As each professional announces available
services, at each house several birds will become
available (figure 3).
In this picture, birds have the name of a
profession on their shirts. Actually, it’s preferable for
birds to have an image identifying the service, instead
of text.
Performing an order
When, due to an activity taking place in the
preschool room, a product becomes necessary, any
child can order it from the adequate professional. Each
Figure 3 – Performing an order
order is composed, at a minimum, by a box with a
description of the request, and the identification of the
requester.
Figure 3, shows an order, which is being placed by the mailman (identified by the mailman’s
hat): the mailman is requesting “1 bolo” (1 cake). So probably the request will be handed to the
baker’s bird.
Notice that the text “1 cake” could be replaced by the Picture of a cake (drawn by the
requesting children, for instance).
Order delivery
Thus, the moment of delivery is reached. This can occur in two ways.
1. If the child that issued the order (the nurse, for instance) still hasn’t
distributed his/her birds, the only way is for the baker to walk up to the
nurse’s house, to deliver the order.
2. If there’s a bird available, from the ordering child, it can deliver the order (the fastest
and most convenient way) or still make the delivery by foot.
Potential developments
After integrally exploring this process, there is no mandatory need to abandon it. Several
ideas may have arisen throughout the activity, worth exploring.
A few sample possibilities were considered:
Buying and selling. Parcels may require a payment, which in turns allows the
introduction of sending and receiving money; a record of outstanding debts may be
kept; a record of payments made and settled accounts; a bank can be created in the
city; etc.
Automatic dispatching. The nest where requests arrive may be handled by a robot.
This can be taught by the children, to perform some activity automatically, for each
received request, for instance: update a request list; provide automated replies; etc.
Quality control. The delivery of a parcel can include a “copy of the request", so that
the receiver may check the order contents, to see if they are right. For instance: a hole
for the order, another hole for the original request.
It should be noted that except for the “automatic dispatching”, the remaining activities can
also be made in the preschool room, without using ToonTalk or the computer; they are way of
exploring the computer activity by linking it with more physical activities, for instance.