International Journal of Technology and Design Education 12, 139–160, 2002. 2002 Kluwer Academic Publishers. Printed in the Netherlands.
Collaborative Problem Solving in a Control Technology Learning Environment, a Pilot Study JARI LAVONEN, VEIJO MEISALO & MATTI LATTU University of Helsinki, Department of Teacher Education, P.O. Box 38, FIN-00014 , Helsinki, Finland (E-mail:
[email protected]) ABSTRACT: We have investigated collaborative problem solving in a teaching experiment, which was organised for 34 eighth-grade pupils in a control technology learning environment. The participating teacher was trained by us and pupils had available kits, interfaces and computers equipped with a novel icon oriented programming tool, Empirica Control. Pupil activities were video recorded and the analysis proceeded through writing video protocols, edited into episodes and then classified into categories. Categories were mainly derived empirically. In the analysis, we used concepts such as collaboration and problem solving, in accordance with social constructivism. The data showed that typical learning processes were collaborative (62% of all episodes) as well as dynamic problem-solving processes, in several stages. Pupils worked quite independently of the teacher, as they learned to use the programming tool autonomously in their technology projects. It appears, however, that more teacher support, such as introducing handbooks, planning tools and advanced programming skills, would have been an advantage. Some ideas about further development of study processes in modern learning environments are discussed. Keywords: collaborative learning, control technology, learning environment, problem solving, programming
INTRODUCTION
Background of the Study In this paper we examine the potential of a learning environment, designed to promote problem solving in small groups and where a Windows-based icon-oriented programming tool is utilised. Our project Empirica Control for Technology Education (ECTE) was initiated in 1995 (Lavonen et al. 2001). We developed the Empirica Control for Windows 95, an icon-oriented programming tool, and the Empirica I/O Interface as necessary software and hardware for control technology problem-solving activities. To support teachers in their efforts to develop technology education, we have written handbooks and organised in-service training. Social constructivism was chosen as a framework relevant to the topic of the present paper, although we recognise the general critique on constructivism (Fox 2001). Within a selected social-constructivist perspective, we are interested in finding how problem solving is experienced socially, with a shared social experience and social negotiation. In practice, we examine the potential of the programming tool to promote problem solving in small groups, during control technology projects where the formal teaching of programming does not occur. Therefore, we are also interested
140
JARI LAVONEN ET AL.
in how our software and hardware can support pupils collaboration and what the teacher’s role is when she or he supports this collaboration. Collaborative problem solving in a learning environment A learning process in a learning environment can be considered a problemsolving activity (Voss 1987). Problems and problem solving have been defined in many ways in the technology education context (McCade 1990). For example the terms ‘designing’ and ‘trouble shooting’ are used occasionally as synonyms of ‘problem solving’. In this study, what is meant by problems are the ill-defined and multi-faceted real-world problems that are sought and identified in the environment (Higgins 1996, pp. 35–57; Lewis et al. 1998). Real-world problems motivate and should help to encourage the transfer of knowledge and skills by allowing students to put their knowledge to use (e.g., Resnick 1986). Characteristic of effective problem solving is a process, which consists of different stages. These include: identifying and formulating the problem; recognising and finding the facts related to the problem; setting the goals; generating alternatives (possible solutions); evaluating the alternatives and choosing the best one(s); implementing the chosen solution (building up a model/article/program); testing and evaluating it; determining if the problem is solved; and modifying the solution if necessary (De Luca 1993; McCormick et al. 1994; Higgins 1996, p. 19). A creative problem solving process is not linear and does not follow any strict pre-determined rules, because rational approaches miss the whole point of creativity. Such a process is most often iterative or dynamic, and contains a number of feedback loops to the basic outline (e.g., Barlex et al. 1991, p. 3; Welch 1999). Problem solving in small groups appears to provide additional benefits to problem-solving processes, as well as to learning (Parker 1991; Johnson & Johnson 1994; Johnson & Chung 1999). Terms like ‘groupwork’, ‘teamwork’, ‘co-operative learning’ or ‘collaborative teaching and learning’ are used when pupils are working in small groups with active social interaction. The choice of terms depends on which the selected theoretical framework of teaching and learning is or what the goals of learning and shape of activities are (Hennessy & Murphy 1999; Barak et al. 1999). All of them have different meanings from the perspective of technology education. In accordance with Hennessy and Murphy (1999), we use the term ‘collaboration’ to describe social interaction. This interaction is generally activated in groups where pupils talk and share their cognitive resources and work together to produce a single outcome. It is also typical that they establish joint goals and referents, make joint decisions, solve emerging problems, construct and modify solutions and even evaluate the outcomes through dialogue and action. Collaboration requires students to communicate actively (e.g., negotiate or dispute), work together (e.g., set goals, plan, generate alternatives) with the aim of producing a single outcome (e.g., an object, a program, or a technological
COLLABORATIVE PROBLEM SOLVING
141
process) and evaluating it through dialogue and action. On the other hand, fostering learning through collaboration requires continuous teacher support. Although Barak et al. (1999) and Hennessy and Murphy (1999) state arguments for differences in co-operative learning and collaboration from the perspective of technology education, some of these basic principles can be adapted to other domains as well, at least when planning a learning environment. A common feature of ways of how to emphasise creative problem solving in technology education is to place pupils in the midst of realistic, vaguely defined, complex and meaningful problems, with no obvious or ‘correct’ solutions (Lavonen et al. 2001). For example, Sellwood (1991, pp. 4–6), De Luca (1993) as well as Williams and Williams (1997) argue that problemsolving activities are an integral part of design and technology education, in contrast to instruction-following design and technology, reproducing articles and teacher-dominated work. On the other hand, pupils often omit essential stages of problem-solving processes, such as planning and ideation. Moreover, stages such as testing and evaluation are evident but are not used in the technology education context as described in problem-solving models (Welch 1999). Research questions It is obvious that classroom based research is needed to explore the role of a programming tool in facilitating pupils’ collaborative problem solving within control technology activities. This is important, if we wish to develop present learning environments further and facilitate pupils’ collaboration in control technology activities, such as programming, planning and evaluating. Our aim is to characterise the nature of collaboration and the components of the learning environment, which can foster or obstruct it (cf. Barak et al. 1999). We want to evaluate the nature of students’ collaborative problem-solving processes in the control technology learning environment in which the software and hardware developed in the ECTE project are used. New ideas for further development of the learning environment and the programming tool are also needed. The following questions directed this study. 1. What is the nature of pupils’ collaborative problem-solving activities in the control technology learning environment where an icon-oriented programming tool is utilised? 2. What is the teacher’s role in the learning process?
THE PROGRAMMING TOOL
Numerous investigations have been conducted in learning environments where computers, equipped with different kinds of software, interfaces and construction kits, have been used in control technology education
142
JARI LAVONEN ET AL.
(e.g., Lafer & Markert 1994). The common denominators for these studies are a hands-on approach, projects requiring problem solving and groupwork. The studies have often been performed in a Lego/Logo (Lego TC Logo) learning environment, with a focus on qualities of social interaction or problem-solving approaches. The original idea of Papert (1980) is that the students have an opportunity to acquire knowledge and skills (planning, learning, thinking), according to the principle of natural learning, by programming. Therefore, it is quite natural that in many investigations organised in Lego/Logo environments the aim has been to prove that this approach develops the students’ abilities or skills (e.g., Suomala 1993; Hutchinson & Whalen 1995, pp. 22–25; Järvinen 1998). We examine the assumption that social interaction can engage the pupils to solve control technology problems, without the teachers’ direct guidance, and to learn the basics of processes (e.g., feedback loops, automatic switches, and thermostats) in control technology. Therefore, the programming tool should be easy to use, supporting pupils’ programming and debugging. When developing the new tool, we expected that a graphical programming language, based on icons, could fit these purposes. The traditional, command-based languages, like Basic and Logo, require great care with program structure and spelling of the code. With such languages, the skill of using the tool, not problem solving, becomes the main aim. It has been reported, in particular (e.g., Pea 1983; Sparkes 1995; Järvinen 1998), that the syntax sensitivity of the Logo language makes programming difficult and frustrating for students. Instead of for collaborating and problem solving, the resources are used for learning programming. The visual orientation of our icon-based approach makes the programming perspicuous. A user can choose icons (input, output or command) in the palette window by pointing at them with a mouse and clicking. Programming could be tactile, linking icons with lines to form a flowchart structure. All the parameters for commands are then set from dialogue windows disclosed by pointing and clicking icons, which means fewer details to memorise. While running a program constructed by the Empirica Control, a blue ball moves along the flow chart, indicating which of the commands the computer is currently processing. The student can imagine that writing the program or programming is the same as making rules for the blue ball. This kind of mini-language approach (e.g., Brusilovsky et al. 1994) means that a student learns what programming is by studying how to control an actor. Furthermore, evaluation (debugging) of the program was planned to be easy. It corrects automatically several types of formal programming errors allowing more time for discussions and planning. It is also possible to see when observing the movements of the blue ball, how certain commands have an effect on a gate, a thermostat or other devices that pupils build up. Empirica Control acquires data from the environment via the Empirica I/O Interface. A user’s guide (Lavonen & Meisalo 1997a) and a handbook ‘Technology’ (Lavonen & Meisalo 1997b) contain basic commands and principles needed
COLLABORATIVE PROBLEM SOLVING
143
Figure 1. The Empirica Control programming environment. The program controls temperature and sets off an alarm when the temperature is above 22 °C. Similar programs have been routinely created by primary school pupils.
to utilise Empirica Control. The first volume of the handbook is a reference book that includes information about the basics of programming with Empirica Control. The second volume consists of guidance for the basic control technological systems, e.g., open and closed loop systems, including a sequence of input, process and output (see Hacker & Barden 1988, pp. 47–56). There are also examples of various control technology processes at home, in industry and in society.
THE EMPIRICAL STUDY
Our research can be described as a case study in which data are gathered by observations recorded in a field diary and videotaped recordings to analyse the pupils’ collaborative problem solving during control technology activities. Naturally, such an approach does not allow any broad generalisations to be made. However, this restriction was accepted at this exploratory stage of the research process (e.g., Strauss & Corbin 1990).
144
JARI LAVONEN ET AL.
Teaching experiment A teaching experiment was organised in spring 1998 in a university teachertraining school located in a city area. A total of 34 eighth-grade (14 year-old) pupils and one science teacher participated in the experiment. The course was an elective one, so the pupils had selected it from a range of options offered by the school. The pupils were divided into three separate groups, each of which was working in pairs with the control technology activities described below for 20 hours, two hours a day. The teacher assigned the pairs randomly. In the classroom there were seven computers (PCs, 486 processors) each equipped with the Empirica Control software, the Empirica Interface and a guidebook (Lavonen & Meisalo 1997a), as well as a Lasy robotics kit, and a set of cables and lamps. The pupils also had access to a metal and woodwork workshop with materials storage and machine tools. All pupils had used the computer before. The control technology theme was new to all pupils. The male teacher, who had long science teaching experience,1 was trained to use the Empirica Control software and the Empirica Interface in a threeday workshop. During the workshop he also became familiar with the control technology theme as well as the users’ guide and a handbook concerning technology education (Lavonen & Meisalo 1997b). He had developed his skills in using the software and hardware by himself. Before the teaching experiment he had been in contact with one of the researchers concerning the conduct of the experiment. During the first two hours of the teaching experiment, the key principles of making the connections with Empirica Interface, as well as the basic ideas of programming with Empirica Control, were introduced to the pupils. The teacher talked with pupils and demonstrated how they were expected to work in pairs within the projects. Pupils learned to use the software during problem-oriented projects, which were organised during the next 10–12 hours. Traditional teaching of the commands or their syntax was not organised and they were assumed to learn during the projects. Pupils also had the opportunity to seek information in the handbook during the project work. During the last six hours of the teaching experiment, the pupils carried out their ‘own project’, which involved setting the problem, planning, generating alternatives (composing), and constructing the structure of the system and the program, as well as evaluating the product. The learning of content (the basics of control technology and programming) on the one hand, and problem solving skills, including identifying and specifying the problem and developing ideation skills, on the other, were somewhat rivalling of importance. This was the case especially during the middle phase of the course. The projects in that part of the course were selected to familiarise pupils with typical inputs (digital, analog, keyboard), outputs (digital, voice, logger), commands (if, trigger, loop, repeat until, delay, and, or) and technological processes (e.g., automatic switches, thermostat, feedback loops, logical operations). Furthermore, projects were
COLLABORATIVE PROBLEM SOLVING
145
designed to familiarise the pupils with the basic stages of problem solving. For example, the project introducing automatic switches began with a story about the present situation in a block of flats where the inhabitants forgot to switch off the lights on the staircase and in the basement. From the point of view of programming, the pupils became familiar with digital input and output and the if-command during that project. From the point of view of problem solving, the pupils had to specify the problem, find facts and resources (needed in programming and model building), plan the project and generate possible solutions, construct the program and build the model, evaluate the model, and test the program (debug). In practice, both identifying the problem, and generating and evaluating alternatives were missing from the problem-solving processes almost entirely. Problem-solving processes were cut short, since the pupils had to learn programming and basic technological processes. Other projects during the middle phase of the course were boosting advertising outside and security of a factory gate. Data collection The field notes were written in the classroom and completed immediately after the school visits. The notes include facts as date, time and general circumstances, as well as observations about the pupils’ and teacher’s behaviour, and discussions during, before and after the videotaped periods. Video recording was the main data collection method, the activities of the pupils can be observed more than once (Savenye & Robinson 1996, p. 1184). We have field notes and videos from three different groups. One of the researchers, together with the teacher, selected a typical pair to monitor. Such a pair had usually succeeded in their activities, with limited teachers’ guidance. The recordings were carried out in the middle of the teaching experiment, when pupils worked on small teacher-set tasks. The recording was made from the beginning of the lesson and stopped after about one hour. Consequently, we recorded a total of 3 hours and 6 minutes of pupil activities. The videos include all kinds of pupil and teacher activities, e.g., the teacher’s short instructions in the beginning of the lesson and even incoherent behaviour of pupils. A Camcorder (Hi8) was placed so that simultaneously the computer screen as well as both pupils discussing could be seen while constructing the model. Even pupil discussions can be heard on the tapes. The field diary and the videotapes were the ‘rough data’ for analysis focussed on phenomena relevant to the study questions. Data analysis The review of the purpose of this study preceded our data analysis. We needed to describe both pupils’ collaborative problem-solving processes, and the teacher’s role in them. After the review, the researchers read the field notes, viewed the videotapes twice and discussed preliminary findings.
146
JARI LAVONEN ET AL.
The ‘field researcher’ (the one who had been present when the video recording took place) transliterated all verbal and non-verbal events on the videos. He played and replayed them at least four times, focussing on writing down verbatim all natural talk between the pupils and between the pupils and the teacher. These notes covered 36 standard pages. Another researcher confirmed the notes on the basis of the video recordings. This displayed data helped us to see patterns and led us to develop explanations, definitions of criteria for categories in further analysis, as well as more differentiated text, based on the videos and field notes (Huberman & Miles 1994, p. 433). Using the research questions as initial guides allowed us to search for the data for broad categories. The analysis began with two broad categories that reflected the primary focus of the study: stages in the problem-solving process and pupils’ collaborative social interaction during the problem solving activities. We used categories derived from our theoretical background as well as categories concluded by induction from the field and video notes. The main and sub categories, their definitions and examples from the notes typical of the categories are presented in Tables I and II. The field researcher wrote descriptions of the categories. The second researcher read the definitions focusing on the extent and independence of the categories in reference to the video notes. The descriptions were specified and refined on the basis of discussion between these two researchers. In addition to the categories described above, we may note that there was very little irrelevant behaviour. It is also interesting, that pupils often pointed to the flowchart with a finger or a mouse, when planning a program and programming (category PF in the Appendix), or debugging (category DF). Moreover, quite often the pupils watched simultaneously both the model and the blue ball moving in the flowchart, when debugging (category DM). After defining the categories (Tables I and II), all videotaped activities were analysed according to the ideas disclosed in the verbal (e.g., Pupil B: ‘Look at this if command . . .’) or operational (e.g., ‘Pupil A opens a dialogue box and . . .’) protocol analyses (shortly protocol analysis in the following, cf. Ericsson & Simon 1993; Welch 1999). The protocols were first segmented into episodes, and then coded on the basis of categories presented in Tables I and II. The episodes were selected so that during an episode only one kind of social interaction and task in problem solving occurs. Thus, it was possible to code each episode according to the stages in a problem-solving process and pupils’ social interaction during the problem-solving activities (cf. Huberman & Miles 1994, p. 446). Altogether, there were 862 episodes during the whole 187 minute videotaped period, with an average 28.2 second duration (note that there were 200 episodes, I11, I12, I13, and IP, when both pupils were acting alone without social interaction). The coding was revised by comparing the codes to the pupil’s behaviour as seen in the videos. The videos were viewed played and rewound
COLLABORATIVE PROBLEM SOLVING
147
TABLE I Descriptions of the categories of tasks in problem-solving activities. An activity can be that of a single pupil, of a pair, or of pupil(s) and their teacher. Examples of pupils’ typical behaviour in different categories are presented in the Appendix Problem-solving task Problem . . . Identifying Formulating Specifying
Description of the category P1 P11 P12 P13
Recognising and finding . . . Facts
P2 P21
Resources
P22
Planning . . . Whole project
P3 P31
Programming
P32
Model building
P33
Alternatives . . . Generating Evaluating
P4 P41 P42
Constructing Programming
P5 P51
Model building
P52
Evaluating Testing model
P6 P61
Debugging
P62
A problem of the whole project is identified or a problem during programming or model building is identified. The problem is formulated, shaped or defined. The problem is specified or restricted or an attempt is made to understand what the problem is.
Facts or ideas related to the problem are looked at in nongroup resources (the pupils read the manual or handbook or ask other groups or the teacher for help) Building blocks, wires and sensors needed in the project are sought.
The whole project is planned, goals or visions for solving the problem are set. No non-group resources are used (cf. P21). How to modify a program or how to add a single command to the program structure is planned. How to modify a construction or how to add a block to the construction is planned.
An original and new idea is generated. The idea is evaluated.
An icon is selected or placed in the flow chart; a dialogue box is opened, a parameter is modified, a program is opened or saved or a set up of the program is prepared. A model is constructed or an idea is put to practice (a building block is selected, blocks are combined, a sensor is connected to the interface, a lamp or a motor is connected to the interface or the interface is connected to the computer).
The model/construction is evaluated without executing the program. The system (program and model) is evaluated by executing the program with the aim to develop it further. While the program is executed, the pupils may watch the movement of the blue ball on the screen and/or look at how the model is behaving.
148
JARI LAVONEN ET AL.
TABLE II Descriptions of the categories of the pupils’ social interaction during problem-solving activities. Examples of pupils’ typical behaviour are presented in the Appendix Type of social interaction No interaction between the pair members I1 Own goals I11
Given goals
I12
Common goals
I13
Pupil-pupil interaction I2 Democratic I21
Domineering
I22
Pupil-teacher interaction Indirect guidance
I3
Direct guidance
I31
I32
Pupils ask questions I33
Teacher instruction
I34
Description of the category
Pupils work (plan, program, build or evaluate) alone A pupil asks a question of a member of another group, works in a way that is not directly connected to the goal of the activity as decided by the group. A pupil works following instructions of another pupil or the teacher. A pupil works towards goals set during the planning phase or preparatory discussions. Collaborative interaction occurs in a small group Pupils talk and work together to produce a single outcome, to set goals, to make decisions, to solve problems, to construct, program and modify solutions and evaluate the outcomes through dialogue. One pupil gives an order to another pupil, staggers an idea of another or works in a way that causes another pupil to withdraw while they are working together. Social interaction occurs between the teacher and the pupil(s) The teacher asks the pupils what they are doing or thinks aloud about how the program is working, or is just quiet and approves of what the pupils have done. The teacher says or shows how to find resources, to plan, build a model, select a command (icon) or parameters in a dialogue box or execute the program. Pupils ask the teacher questions looking for help in recognising facts or resources, planning, programming, building or debugging. The teacher gives the problem in the beginning of the lesson, explaining in general how building blocks are used or a program is constructed.
with the aim of making the coding reliable. A second researcher who took part in the description process of the categories, used the same descriptions of the categories and the same coding process for randomly-selected samples, 10% of the total collected protocols. The two coders reached a 75% consensus on coding the episodes. Disagreement was not systematic and equally frequent in the main categories P and I. The third researcher later classified a few randomly selected periods of the protocol. He did not take part in the above-mentioned discussion process, where descriptions were specified and modified. Consequently, he used only written descrip-
COLLABORATIVE PROBLEM SOLVING
149
tions of the categories in his work, referring more to the video recordings than to the written protocols. The compatibility between the classifications of the first and third researchers was high. Almost full consensus on coding the episodes was possible in all cases that could be thoroughly analysed in detail. Examples of coded data are presented in the Appendix.
RESULTS
Frequencies of the categories The frequencies of each category defined in the previous Chapter are presented in the matrix of Table III. Data were acquired in accordance with qualitative methodology and, therefore, were not intended for quantitative analysis. The main emphasis was on the interpretations drawn from primary data sources. It is possible, for example, to see in Table III what kinds of social interaction are typical at each stage of problem solving. Typical of pupils’ collaborative problem solving activities were programming (25% of all episodes), debugging (17%) and planning together through democratic dialogue (10%). This third type of activity was mostly to add a single command to the program or to fix a new item in the model. We see that identifying, formulating and specifying the problem (4%) and generating alternatives or evaluating them (2%) alone, together or with the teacher’s help, happened far less frequently. This field experiment nicely demonstrated pupil-centred activities. The most common social activity was of the nature of pupil-pupil interaction. In 62% of all episodes pupils talk and work together to produce a single outcome, to set goals, to make decisions, to solve problems, to construct, program, or modify solutions, or evaluate the outcomes through a dialogue. In 20% of all episodes a pupil works alone towards goals set during the planning phase or according to the discussion prior to the working phase. Social processes that occurred infrequently were the teacher’s direct guidance, dominating behaviour in a group or working alone towards one’s own or given goals. In summary, classification of episodes and frequencies of those episodes indicate that, in the control technology learning environment where an icon-oriented programming tool is utilised, the pupils were extremely active in problem solving. The teacher had taken the role of a tutor asking questions, which means clarifying the pupils’ ideas. The strong motivation can also be explained by several different factors. The elective nature of the course affects motivation, but the task-oriented collaborative approach and the equipment and programming tool used might also tend to strengthen motivation. In a more detailed analysis of the raw data (not presented in the Table), we were able to draw further conclusions. During both programming and debugging, pupils frequently pointed to the flowchart, often simultaneously watching the model and how the blue ball was moving along the
8 33
9
Total
Total
3
2 1 1
I31 I32 I33 I34
4
1
P12
1
4
P11
16
13
03
P13
Task in problem solving
I21 I22
I11 I12 I13
Social interaction
59
01
29
28
01
105
P21
046
003
001
016 001
003 003 019
P22
3
1
2
P31
131
92
01
19 01
59 02
10
P32
36
01
01
23 02
09
P33
14
12
02
P41
18
4
2
2
P42
259
017 008 004 007
164 008
004 001 046
P51
336
77
02 02 01 01
45 06
20
P52
TABLE III The frequencies of each category based on the descriptions presented in Tables I and II
24
01
17 01
05
P61
203
179
001
034 001
124 001
018
P62
826
079 015 009 014
511 021
008 004 165
Total
150 JARI LAVONEN ET AL.
151
COLLABORATIVE PROBLEM SOLVING
flowchart. While the pupils were planning the program or programming they pointed to the screen (flowchart, with a finger or a mouse) 62 times (70% of all program planning episodes). We may interpret that the features offered by the Empirica Control were valuable for pupils when they were planning and debugging. It appears easier to program and debug when the programming tool is visual and a mechanism exists to indicate which command is currently done when a program is executed. There were only 13 episodes (1.5%) where a pair was acting in a way that was irrelevant from the point of view of the goals of their group, and 23 episodes (2.6%) where a single pupil was behaving irrelevantly. Text search (Find operation) offers a possibility to evaluate how linear or dynamic/iterative the pupils’ problem-solving activity was. The frequencies of different kinds of linear and dynamic processes are presented in Table IV. The table indicates that 79% of problem-solving processes (or parts of these problem-solving processes) were not linear. Frequencies of social interaction processes are interesting, especially the social process where students are responsible for the other’s as well as for one’s own learning. For example, category I21 (democratic pupilpupil interaction) changed to the category I13 (pupil working towards common goals alone) 65 times and category I13 changed to the category I21 62 times. On the other hand, category I21 changed to the category I12 (pupil working towards given goals alone) once and never to I11 (pupil working towards own goals alone). This kind of behaviour indicates that pupils were responsible for one another’s learning as well as for their own, and they worked towards common goals. Collaboration enhances positive TABLE IV The frequencies of different kinds of linear and dynamic processes Process in problem solving
Frequency
Linear processes P2-P3-P5 or P2-P3-P3-P5 P3-P5-P6 or P3-P5-P5-P6 or P3-P5-P5-P5-P6 or P3-P5-P5-P5-P6 or P3-P4-P5-P6 or P2-P5-P5-P5-P5-P6 or P2-P3-P5-P5-P5-P6 Dynamic processes P2-P3-P2 or P2-P3-P3-P2 P3-P5-P3 or P3-P5-P5-P3 P3-P5-P5-P5-P5-P3 P5-P3-P5 or P5-P3-P3-P5 P6-P3-P6 or P6-P3-P3-P6 P5-P6-P5 or P5-P6-P6-P5 P5-P6-P6-P6-P6-P5 P6-P5-P6 or P6-P5-P5-P6 P6-P5-P5-P5-P5-P6
Frequency (total) 044
11 30 03 162
orP3-P2-P3 or P3-P2-P2-P3 or P3-P5-P5-P5-P3 or or P5-P3-P3-P3-P5 or P3-P6-P3 or P3-P6-P6-P3 or P5-P6-P6-P6-P5 or
14 22 32 15 42
or P6-P5-P5-P5-P6 or 37
152
JARI LAVONEN ET AL.
interdependence of the group members. As work with visual programming and a construction kit is a kind of ‘physical thinking’ (assisted by manipulating objects), the possibilities for shared problem solving are better than in normal ‘silent thinking’. Social process where the teacher stopped pupil activities and gave direct guidance (category I21 to category I32) occurred only 6 times (0.7% of all episodes). After direct guidance, the pupils continued 8 times with their democratic working-together. This observation confirms that the teacher had succeeded in behaving as a consultant in the learning environment. Critical incident analysis Above we presented the results in evaluating whether the pupils’ problem solving was collaborative. The observations based on the video recordings and field notes were also analysed, using the critical-incident method, to find other significant events in the learning process. This method is based on identifying critical factors in a variety of processes and has been used in various settings (Cummings et al. 1989; Steffler et al. 1998; Nakhleh & Krajcik 1993). The analysis revealed that the printed task assignments allowed a pair to work at their own pace. However, the tradition that the teacher is needed to confirm the completion of the task restricted the autonomy of this pair: A and B execute the program. A: ‘Look at the flow’. Both watch the motor and the program to evaluate the functions of the system. It seems that both are looking at where the teacher is and both are waiting. The teacher comes and asks how the system is working. The pupils explain and the teacher replies: ‘Fine, you can go on with the second problem.’ Therefore, it seems to be necessary to develop teacher-independent ways of tackling the evaluation phase. It seemed initially that difficulties were mostly due to a lack of planning. However, a closer look revealed that programming or selecting the appropriate icons, was the actual problem. For example, take a protocol describing one pair locating an exit-icon from the loop: A and B stop programming and begin to look around. After a few moments, they focus on their screen. They are looking at the screen and pointing their finger at the screen. . . . A starts to read the manual. A browses systematically through the index of the manual. B is looking at the screen. . . . A is browsing (non-systematically) through the manual. . . . B takes the mouse and opens one dialogue box. B soon starts to look around. He looks bored, and the situation has stalled. . . . A and B focus on the screen again. They then ask the teacher to come over. It is quite obvious that the pupils did not have the basic knowledge of programming, as formal teaching in this area had been almost non-existent. It could be argued further that better general learning skills could have helped in this case, as the pupils could hardly utilise the technology handbook and the examples it described. Therefore, the collaborative problem-solving approach seemed to cause trouble for some pupils. As they were directly taught very little, they lacked planning, programming and also creative skills.
COLLABORATIVE PROBLEM SOLVING
153
The third incident dealt with the pupils asking for help. When facing problems, the pupils hesitated to ask for the assistance of the teacher or their peers. However, it is possible that they did not recognise their need for assistance. The result was dead-ends, where the pupils were ‘silent’ in two ways: they did not ask for help, and they tried to look productive while editing the code in a trial-and-error manner. For a teacher, responding to such a situation is very hard, as a glance at the working pair does not reveal the need for help. An example of a trial and error approach (without planning) is as follows: A opens a dialogue box (If command) and changes the temperature. B watches. A starts the program; both look at the flowchart. A stops the program. A opens a dialogue box (If command) and changes the temperature setting. A starts the program; both look at the model (motor). A stops the program. A opens a dialogue box (If command) and changes the temperature setting. A starts the program; both watch the model (lamp or a motor). A stops the program execution. Both are looking at the model. B: ‘again the propeller jerks.’ A: ‘Oh, so there is the same phenomenon as earlier’. A opens a dialogue box (If command) and changes the temperature setting.
DISCUSSION
This article reports an attempt to stimulate collaborative problem solving in the learning environment where software and hardware, developed in the ECTE project, defined the physical nature of the learning environment. As the study focussed on the pedagogical nature of the learning environment, this section summarises the main results and discusses the learning processes of the pupils. A few instructional implications or implications to organise the learning environment will then be derived and even some suggestions for future development of the learning environment offered. As a summary of our theoretical framework of problem solving, we claim that creative problem solving has different stages and is enabled by language (occasioned through social interaction and mediated through control-technology activities), and the stages of the process are dynamic. Learning processes in the learning environment In the learning environment where Empirica Control software is utilised, it appears possible to organise collaborative problem-solving activities, which introduce the basic processes of the control technology to the pupils. Observations and videotapes indicate that a learning environment equipped with Empirica Control has the potential to help pupils to become active acquirers of knowledge and skills. It also appeared possible to place emphasis on the social nature of knowledge. In 62% of all episodes pupils talked and worked together or studied together in an interactive social setting.
154
JARI LAVONEN ET AL.
The present findings suggest that the pupils worked collaboratively. The pupils shared their cognitive resources, talked, recognised facts, planned, constructed and evaluated with the aim to solve problems and produce a single outcome through dialogue and action. During the projects, the teacher attempted to support working and learning in indirect ways, in order to foster higher cognitive and creative processes. The teacher’s role was mainly consultative. Pupils had the chance to ask for help or put questions to the teacher. Only 13% of the 117 episodes between the pupils and the teacher that were observed, were direct guidance by nature. The observations confirm that the teacher discussed the intention to develop thinking, reflection and creativity through questions with the pupils. We were thus quite satisfied with the role of the teacher because we know very well that after years of teaching using traditional methods, teachers face difficulties in promoting collaboration in classroom (e.g., Barak & Maymon 1998). In summary, our programming tool allowed pupils to learn collaboratively. Characteristic of pupils’ problem-solving processes was that they mainly consisted of four stages: recognising and finding the facts related to the problem (12% of all episodes), planning of programming or model building (16%), constructing a program or a model (39%) and evaluating a program or a model (24%). On the contrary, there were few signs of a creative or innovative phase preceding the active programming or building of the model (1.6% of all episodes). Moreover, only 3.8% of all episodes dealt with identifying, formulating and restricting the problem. Therefore, the activities should be approached rather by seeing the problems in the technological world around us and not in a technical way. Our data indicate that the problem-solving process was not linear but dynamic, and contained a number of feedback loops to the basic outline. Thus, 79% of problemsolving processes, or part of the problem-solving process, were interpreted as dynamic in nature (c.f. Barlex et al. 1991, p. 3; Welch 1999). The critical incident analysis revealed that work in the learning environment requires a new approach to learning and teaching. The teacher had to consider carefully how collaboration as well as the planning, programming, constructing, evaluating and utilising of handbooks were developed. Both the pupils and the teacher had problems in adapting to the new situation. Various skills can serve as learning tools, because the pupils can use them in diverse subject areas and for tasks of varying scope and specificity. In planning the use of the learning environment, the teacher has to make a decision about the knowledge and skills (e.g., planning, programming, evaluating) needed before the pupils can start to work with the collaborative problem-solving approach. Traditionally, this initial knowledge has been substantial and the problem-solving or applied phase has been more or less limited. In this experiment, this ratio was reversed. However, the results seem to suggest that some initial knowledge and skills are needed, rather than none. The pupils seemed, for example, to suffer from a lack of formal knowledge of programming and about the algorithm structures of programs.
COLLABORATIVE PROBLEM SOLVING
155
When collaborating, the pupils worked and discussed problems relevant to their work, striving to achieve common goals. There were obvious differences in the nature of collaboration between the various video-recorded sessions. The pupils were free to decide their tasks (e.g., model building or programming) in teams. They were also encouraged to switch or change the tasks now and then. In planning the activities, it was important to remember that pupils do not spontaneously produce collaboration, creative solutions and effective planning. Developing study processes in modern learning environments further In modern learning environments, including much pupil collaboration and problem-solving activities, teachers should be able to monitor and control a wide range of goals and help pupils in different activities. To implement effective learning, we need teaching professionals who can easily switch their attention from one domain-specific content or strategy/activity to another, as pupils work on their various problems. In our experiment, a brief glance did not show how pupils were proceeding and what kinds of problems they had. Our data show that there was no formal or systematic teaching of programming, planning tools, or problem-solving techniques. It appears that the pupils learned to use the commands needed in their technology projects autonomously. However, since our observation data show that some pupils had programming problems in spite of the teacher’s indirect guidance, the handbook should be introduced (but with care, not to prevent pupil autonomy). It was clearly seen in the videos (notes) that the pupils tried to glance over the handbook to find help for their problems. The difficulty was that they did not take the time needed to learn new knowledge, such as the program structures. Since it seems difficult to introduce manuals and handbooks to students in the learning environment, we suggest that the teacher should combine open-ended problem solving and studying the handbook with easy and short problems at the beginning of the period. Teaching and learning the planning tools for the whole project (e.g., flow chart, list of the inputs, outputs and processes) are needed, especially in open projects (despite the opinion of the teacher that planning might be boring). Only 0.3% of the episodes contained elements that could be connected to the planning process of the whole project. On the other hand, the Empirica Control software is itself a planning tool, because it illustrates the program as a block diagram and shows the progress as the program is being executed. This was seen clearly in a number of episodes where the pupils either pointed to the screen (flowchart with the finger or mouse) while planning or debugging, or were at the same time looking at the model and at how the blue ball was moving in the flowchart. Organising collaboration in a learning environment is not as easy as it seems. Pupils do not learn spontaneously, or by ‘teaching’, to collaborate in all stages of a problem-solving process. Varying the group size, members
156
JARI LAVONEN ET AL.
and duties allows individual involvement, as well as providing experiences in the functioning and organisation of groupwork. It is also important to prepare pupils for work on larger projects and in larger groups. In practice, we had to encourage pupils to discuss the work, ask questions and present alternate solutions, as well as to set goals and plan the project. In this discussion, different ideation techniques (Smith 1998, pp. 107–133) allow pupils to consider new solutions. The group should establish deadlines for the completion of each stage. Furthermore, special attention should also be given to various ‘team-player’ styles (e.g., contributor, collaborator, communicator, challenger and leader) (see Parker 1991, p. 63; Barak et al. 1999). Moreover, we agree with Hennessy and Murphy (1999, p. 2) that activity and collaboration between pupils requires continuous teacher support. Although the pupils easily evaluated in their projects how the program or machine works, they did not as easily discover ways to develop the work process. We want to emphasise, however, that pupils should even evaluate the whole process as well as collaboration. The group achievements and the individual pupils’ contribution to the collaboration and its achievements must be remarked on. It would be useful to develop a monitoring/ reporting tool (e.g., a questionnaire or portfolio) to keep groups focussed and advancing in their planning, constructing and evaluating. Consequently, different kinds of activities with pupil collaboration, or instructional strategies based on pupil collaboration, are needed (c.f. Johnson & Chung 1999). Moreover, how to introduce problem-solving activities and all stages connected to a problem-solving process is not an easy task. In particular, problem posing, planning of the whole project and ideation are difficult phases to introduce to pupils (c.f. Lewis et al. 1998). Collaboration and problem solving are necessary in productive learning environments and need to be integrated into the technology education curriculum. We suggested above some approaches for developing study processes in a modern learning environment further. It will be interesting to see whether these principles can be put into practice. We are continuing our efforts in several related projects.
NOTE 1. In Finland, we do not have a subject called ‘technology’, because it is taught decentralised in physics, chemistry, biology (science) and in technical work. Therefore science teaching experience means also technology teaching experience.
157
COLLABORATIVE PROBLEM SOLVING APPENDIX 1
Examples of how the protocols were first segmented into episodes, and how each episode was coded according to the pupils’ social interaction (I) and tasks in the problem-solving activity (P), during the problem-solving activities. In the last column, other categories (O) of the pupils’ operations are presented. ‘A’ and ‘B’ refer to the pupils in the analysed videos. Time
Episode
I
P
O
34.15
A continues browsing through the handbook. It seems that he can not find what he is looking for.
I13
P21
B is looking at the dialogue box. (He is clearly thinking).
I13
P32
34.35
Both A and B look at the dialogue box. B: ‘Let’s delete it. It should be passed.’
I21
P41
34.45
A short mention from B. B points to the screen with his finger.
I21
P32
34.52
A turns around and asks the teacher: ‘We cannot solve this. By no means! We can not find out how we could get it rotating all the time.’ B nods.
I33
P51
35.05
The teacher approaches the group: ‘Perhaps you should add another loop. What do you think?’ (The teacher’s hint is not direct guidance. It is interpreted as a question.)
I31
P51
35.15
Teacher: ‘What is your idea?’ B shows the system. B: ‘It should turn 90 degrees.’
I31
P32
35.22
Teacher: ‘Let’s look at how it behaves. Can you please execute the program?’ The teacher and the pupils watch how it rotates. B: ‘It should continue rotating . . .’ The teacher leaves the group.
I31
P62
35.42
The teacher leaves the group. B: ‘Lets add EXIT here.’ (The pupils are planning together and try to find a solution) A is looking carefully at what B is doing.
I21
P32
35.55
B adds an icon to the flowchart. A is watching and says something. B changes a parameter in the dialogue box.
I21
P51
36.02
Suddenly both push the start button (execute program) at the same time. (This means that both clearly understand that now is the time for debugging.) B pushes the push button. A is watching both the screen and the model. The program execution is stalled. A stops the program execution.
I21
P62
DM
36.18
A points to the screen where the needed new command can be added. Both are silent and they are obviously thinking hard.
I21
P32
PF
36.44
A makes the amendment. B is looking at what he is doing and points to the screen.
I21
P51
PF
37.09
A executes the program. Both are looking at the screen to see how the program is working. They are not satisfied.
I21
P62
PF
158
JARI LAVONEN ET AL.
REFERENCES Barak, M., Maymon, T. & Harel, G.: 1999, ‘Teamwork in Modern Organisations: Implications for Technology Education’, International Journal of Technology and Design Education 9(1), 85–101. Barak, M. & Maymon, T.: 1998, ‘Aspects of teamwork observed in a Technological Task in Junior High Schools’, Journal of Technological Education 9(2), 41–18. Barlex, D. M., Read, N., Fair, D. & Baker, C.: 1991, Deserting Starts Here, Hodder & Stoughton, Sevenoaks. Brusilovsky, P., Kouchnirenko, A., Miller, P. & Tomek, I.: 1994, ‘Teaching Programming to Novices: A Review of Approaches and Tools’, in Educational Multimedia and Hypermedia, 1994, Proceedings of ED-MEDIA 94-World Conference on Educational Multimedia and Hypermedia (Vancouver, British Columbia, Canada, June 25–30, 1994). ERIC ED388228. Cummings, A. L., Murray, H. G. & Martin, J.: 1989, ‘Protocol Analysis of the Social Problem Solving of Teachers’, American Education Research Journal 26(1), 25–43. De Luca, V. W.: 1993, ‘Survey of Technology Education Problem-Solving Activities’, The Technology Teacher 51(5), 26–30. Ericsson, K. A. & Simon, H. A.: 1993, Protocol Analysis Verbal Reports as Data, MIT Press, Cambridge MA. Fox, R.: 2001, ‘Constructivism Examined’, Oxford Review of Education 27(1), 23–35. Hacker, M. & Barden, R.: 1988, Living with Technology, Delmar, New York NY. Hennessy, S. & Murphy, P.: 1999, ‘The Potential for Collaborative Problem Solving in Design and Technology’, International Journal of Technology and Design Education 9(1), 1–36. Higgins, J. M.: 1996, 101 Creative Problem Solving Techniques: The Handbook of New Ideas for Business, New Management Publishing, Winter Park FL. Huberman, A. M. & Miles, M.: 1994, Qualitative Data Analysis: An Expanded Sourcebook, Sage, Thousand Oaks, CA. Hutchinson, E. J. & Whalen, M. T.: 1995, ‘Mathematics and Science: Female Students and LEGO TC Logo’, The Computing-Teacher 22(4), 22–25. Järvinen, E. M.: 1998, ‘The Lego/Logo Learning Environment in Technology Education: An Experiment in a Finnish Context’, Journal of Technology Education 9(2), 47–59. Johnson, S. D. & Chung, S.-P.: 1999, ‘The Effect of Thinking Aloud Pair Problem Solving (TAPPS) on the Troubleshooting Ability of Aviation Technician Students’, Journal of Industrial Teacher Education 37(1). Johnson, D. W. & Johnson, R. T.: 1994, Learning Together and Alone: Cooperative, Competitive, and Individualistic Learning (4th Ed.), Allyn & Bacon, Needham Heights, MA. Lafer, S. & Markert, A.: 1994, ‘Authentic Learning Situations and the Potential of Lego TC Logo’, Computers-in-the-Schools 11(1), 79–94. Lavonen, J. & Meisalo, V.: 1997a, Empirica Control käyttöohje [Operation manual for Empirica Control]. LUONTI-projekti, University of Helsinki, Department of Teacher Education, Helsinki. Lavonen, J. & Meisalo, V.: 1997b, Teknologia [Technology]. LUONTI-projekti, University of Helsinki, Department of Teacher Education, Helsinki. Lavonen, J., Meisalo, V. & Lattu, M.: 2001, ‘Problem Solving with an Icon Oriented Programming Tool’, Journal of Technology Education 12(2), 33–47. Lewis, T., Petrina, S. & Hill, A. M.: 1998, ‘Problem Posing-Adding a Creative Increment to Technological Problem Solving’, Journal of Industrial Teacher Education 36(1). McCade, J.: 1990, ‘Problem Solving: Much More Than Just Design’, Journal of Technology Education 2(1). McCormick, R., Murphy, P. & Hennessy, S.: 1994, ‘Problem-solving Processes in Technology Education: A Pilot Study’, International Journal of Technology and Design Education 4(1). Nakhleh, M. B. & Krajcik, J. S.: 1993, ‘A Protocol Analysis of the Influence of Technology
COLLABORATIVE PROBLEM SOLVING
159
on Students’ Actions, Verbal Commentary, and Thought Process during the Performance of Acid-Base Titrations’, Journal of Research in Science Teaching 30(9), 1149–1168. Papert, S.: 1980, Mind-Storms, Basic Books, New York. Parker, G.M.: 1991, Team Players and Teamwork: the Competitive Business Strategy, JosseyBass, San Francisco. Pea, R. D.: 1983, ‘Logo Programming and Problem Solving’, Paper presented at an American Educational Research Association Symposium (Montreal, Canada, April 1983) as ‘Chameleon in the Classroom: Developing Roles for Computers’. ERIC ED 319371. Resnick, L.: 1986, ‘Learning in School and Out’, Educational Researcher 16(9), 13–20. Savenye, W. C. & Robinson, R. S.: 1996, ‘Qualitative Research Issues and Methods: An Introduction for Educational Technologists’, in R. Jonassen (ed.), Handbook of Research for Educational Communications and Technology. A Project of the Association for Educational Communications and Technology (AECT), Prentice Hall International, London, pp. 1171–1195. Sellwood, P.: 1991, ‘The investigative Learning Process’, The Journal of the Design & Technology Teaching 24(1), 4–12. Smith, G.: 1998, ‘Idea Generation Techniques: A Formulary of Active Ingredients’, The Journal of Creative Behaviour 32(2), 107–133. Sparkes, R. A.: 1995, ‘In investigation on Year 7 Students Learning Control Logo’, Journal of Computer Assisted Learning 11(3), 182–191. Steffler, D. J., Varnhagen, C. K., Friesen, C. K. & Treiman, R.: 1998, ‘There’s More to Children’s Spelling Than the Errors They Make: Strategic and Automatic Processes for One-Syllable Words’, Journal of Educational Psychology 90(3), 492–505. Strauss, A. & Corbin, J.: 1990, Basics of Qualitative Research: Grounded Theory Procedures and Techniques, Sage Publications, Thousands Oaks, CA. Suomala, J.: 1993, ‘Natural Learning in a LEGO/Logo Learning Environment’, in P. Georgiadis et al. (eds.), Proceedings of the Fourth European Logo Conference. Athens, Greece, 28–31 August 1993. Doukas School, Athens, pp. 69–74. Voss, J. F.: 1987, ‘Learning and Transfer in Subject-matter Learning: A Problem-solving Model’, International Journal of Educational Research 11, 607–622. Welch, M.: 1999, ‘Analyzing the Tacit Strategies of Novice Designers’, Research in Science & Technological Education 17(1), 19–35. Williams, A. & Williams, J.: 1997, ‘Problem Based Learning: An Appropriate Methodology for Technology Education’, Research in Science & Technological Education 15(1), 91–103.
ABOUT THE AUTHORS Lecturer Jari Lavonen and Prof. Veijo Meisalo received their Ph.D.s at University of Helsinki. Matti Lattu, M.Ed., is a doctoral student and full-time researcher. Dr. Lavonen worked previously at the Teacher Training School, and he is now the co-ordinator of a staff development project. Prof. Meisalo is presently both the Head of the Department of Teacher Education and the Associate Dean of the Faculty of Education. Both of them are authors of several textbooks for science teacher education and for schools. The writers are presently doing research work at the Research Centre for Mathematics and Science Education, Department of Teacher Education, University of Helsinki. Empirica Control for Technology Education, the ECTE Project described and evaluated in this paper, is a part of the LUONTI Project, which organises research and development work in tree subprojects, the Get Electronics Project (the GEP), the ECTE project and the Empirica measurement system for Science Education project (the EMSE)). The general goal is to provide new, innovative and versatile learning materials and equipment for science and technology education. It means that computer programs, interfaces and sensors for school laboratories, teachers’ guides, and textbooks for schools have been developed. There is also
160
JARI LAVONEN ET AL.
an in-service training programme for teachers demonstrating the versatility of the approaches. Jari Lavonen Department of Teacher Education, University of Helsinki, Pb. Box 38, FIN00014 Helsinki, Finland, Fax: +358 9 19128114, e-mail:
[email protected], Office: +358 9 19128138; Veijo Meisalo, Fax: +358 9 19128114, e-mail:
[email protected], Office: +358 9 19128129; Matti Lattu, Fax: +358 9 19128073, e-mail:
[email protected], Office: +358 9 191 28059.
