1. Find the problem.
2. Represent the problem.
3. Plan a problem solution.
4. Execute the plan.
5. Check the solution.
6. Reflect to consolidate learning.
1. Elaborate and maintain a common understanding of the problem and, more generally, common ground (relevant concepts to be used, issues to be considered, possible actions, etc.).
2. Identify and define the tasks the group intends to address and how they will be addressed; plan how work will be divided and articulated.
3. Manage the articulation of work (monitor and regulate the process, reconsider tasks, or roles, etc.).
1. Provide learners with a transposition of the co-construction notion/level as a phase and/or place relative to the elaboration (and, in case of difficulty, revision) of the tasks to be considered. It may be a place in the sense that learners are offered specific editors to elaborate these constructions and a phase in the sense they are led to consider this task before engaging in the actual solving process.
2. Provide learners with a transposition of the co-operation level as a phase and/or a place relative to the definition of how tasks will be fulfilled, e.g., the role of each member or the sequencing.
3. Provide learners with a transposition of the co-ordination level as a phase and/or a place relative to fulfilling tasks (e.g., in our case study, measuring or calculating values).
4. Make the elaborated organization constantly visible to the group (primo-definition and revisions).
5. Allow learners, in context, to come back to a preceding phase and change what had been defined (bottom-up transitions via the notion of phase).
6. Allow learners, in context, to change what had been defined at a preceding phase (bottom-up transitions) without going back to this phase as such. For example, they must be allowed to change the division of work while they are fulfilling individual tasks, without skipping to the phase or place when/where division of labor (as such) was initially defined.
7. Keep interfaces and, in particular, interfaces relative to the definition of the plan and its implementation, close to each other.
5.3.1 Co-Construction Notion/Level Representing an attempt to support learners on the co-construction level (co-construction: conceptualizing or re-conceptualizing the organization in relation to shared objects), the task-editor (see Fig. 3) allows elaboration and revision of the notions used and the tasks considered. With respect to the model, the design decision is to lead learners to consider co-construction issues by making them list and define the notions and the tasks they intend to consider (and, within this process, interact on this issue and take shared decisions).
The editor prompts learners to define the data and actions they will need as a list of tasks (which will be automatically transformed into a structure—an array— within which they can distribute work and enact the plan in the following step). Tasks are defined as a structured line (upper part of the interface) mentioning the involved notion as defined by learners (e.g., “cars that stop”), the name adopted by the group to denote the data (e.g., “distance between two stops”), a textual description (to improve their chances of understanding each other), what is to be carried out in relation to this data (from a list of possible actions provided as a support, e.g., “measure”) and the given priority if useful. The interface is shared and the chat allows synchronous interaction. Each line is to be collectively acknowledged via the voting tool (not presented here) before being moved to the “list of acknowledged tasks” (lower part of the interface). However, a learner may force the vote, avoiding excessive constraints (this requires an explicit action). Learners may return to any line at any time.
The resulting list of tasks forms a kind of general problem-solving plan and, via the fact that they are referred to by the tasks, a list of notions (e.g., “distance between two stops,” “duration of the race,” or “speed”).
Learners are first offered to use this task-editor in Phase 1, where it suggests identifying the tasks (and underlying notions) that must be achieved to collect the required data. It is again offered in Phase 2, where it suggests identifying the tasks to calculate where to put learners' cars according to the tutor's one.
5.3.2 Co-Operation and Co-Ordination Notions/Levels Representing an attempt to support learners on the co-operation (co-operation: actors are active in considering the shared goals; they relate to each other and make corrective adjustments according to the overall goal co-construction) and co-ordination levels (co-ordination: actors concentrate on the subtasks they have been assigned; their work relates to a common goal, but their individual actions are only externally related to each other; they carry out the overall task from the point of view of their individual activity), the array-editor (see Fig. 4) offers two modes allowing 1) distribution of work and 2) enactment of the plan. With respect to the model, the design decision is to lead learners to consider co-operation issues by asking them to distribute and redistribute tasks (and, within this process, interact on this issue and take shared decisions), and to support top-down and bottom-up processing by allowing them to be implemented within quasi-identical (initial division of work) or identical (revisions) interfaces.
The interface is an array whose structure is generated from the list of tasks collectively constructed with the task-editor. For every line (every task) of the general plan, and every object involved in the solving (i.e., each car), a column per learner is generated (in Fig. 4, the array-editor content has been initialized from another plan than the one featured in Fig. 3, as a way to show tasks and notions defined by different groups). As a result, a line in the array denotes a task (e.g., line 1: data = “arrival time” and action = “measure”) and, for each car, three cells that may be used to denote the fact that learner L#1, L#2, and/or L#3 will address this task. The fact that car/task pairs are associated with one column per learner allows them to delegate tasks to just one, two, or three of them.
When learners move from the task-editor, the array-editor is tuned in definition-mode. All cells are initialized with “?”, i.e., none of the task is initially attributed. Learners are prompted to declare who will carry out each task by clicking in the corresponding cells. For instance, learner L#i may declare he/she will carry out Task T#j for Car#k by clicking on the relevant cell; the “?” is replaced by an “OK” in the corresponding cell of the L#i column. Learners may interact via the chat to coordinate (as examples of interactions: “ Cristina, you make line 1234”; “ to better organize ourselves I make the cars 7 8 9, you share the others it will be quicker.” As the interface is shared, each learner is aware of the other learners' declarations.
Used in this definition-mode, the array-editor leads learners to consider co-operation issues. The result is a more precise plan (list of tasks is refined or confirmed; tasks are distributed).
Once learners decide they are over with the definition-mode (i.e., distributing tasks), they can skip to the execution-mode (here again, this requires a vote). Now, the cells marked as “OK” become editable, i.e., the relevant learner can edit the value. The shared interface allows every learner to know what he/she is supposed to do and what the others are doing. The problem-solving evolution is denoted by the fact that the “OKs” are gradually replaced by values (see Fig. 4).
Used in this execution-mode, the array-editor supports learners at the co-ordination level. As an example, we can see in Fig. 4, line 2 that L#2 has achieved the task “measure arrival time” for car#0, car#1, and car#2 (values = 5.7, 28.3, and 19.4). L#1 and L#3 have both completed the task “calculate average speed (constant) of cars” for car#0 (values = 0.25 and 0.246) and car#1 (values} = 0.05 and 0.049), and plan to address it for car#2.
Learners are first offered to use the array-editor in Phase 1. It suggests distributing (and, then, offers a structure for achieving) the tasks that must be achieved to collect the required data. The editor is also offered in Phase 2, where it suggests distributing (and, then, offers a structure for achieving) the tasks required for calculate where to put learners' cars according to the tutor's one (here, the array is restricted to the three involved cars).
5.3.4 Transversal Design Principles and Features The other principles listed in Section 4 find the following implementations.
The elaborated organization is reified by the array and made visible at all times, including when the plan is executed. In fact, the same representation is used to define and execute the plan.
Learners may skip from the array-editor definition-mode to the execution-mode while some tasks have not yet been attributed. We can see in Fig. 4 co-occurrence of nonattributed tasks (“?”), attributed tasks (“OK”) and already achieved tasks (numerical values). Learners can also add tasks at any moment. We can see in Fig. 4, line 9, an example of a task “Duration of a stop,” incompletely defined, which has been added after the other tasks had been already distributed and, for some of them, achieved. In other words, learners may define and enact partial plans, and also modify their plan at any moment. This feature was inferred from the exploratory experience that showed learners often engaged in problem solving before their plan was complete. It corresponds with the fact that the model's levels correspond to analytical distinctions and activity may take place simultaneously at all levels.
Learners can change decisions by coming back to a preceding interface or mode but, also, in context (not going back to this phase as such). As an example, when using the array-editor, they can change the allocation of a task by coming back to the definition-mode of the array-editor. This denotes an explicit intention of reconsidering what had been previously decided. When they skip back, the change is reported (without reinitializing the overall array, i.e., not losing the already calculated values). However, learners may also change any element (addition, deletion, change, or allocation of a task) while remaining in the array-editor in execution-mode, in context, by clicking on the relevant lines and/or cells (this is the case of line 9, which has been directly added in the array-editor). In other words, moving from the organization to the problem-solving activities, and vice versa, may consist in a change of phase/place (in the sense introduced previously) or in different uses of the array-editor in execution mode. Here again, allowing in-context changes is in line with the model and corresponds to patterns observed during the experiments.
The interfaces relative to defining and implementing the plan are, in fact, functionally quasi-identical. When skipping from the list of tasks to the attribution of the tasks and, then, to the edition of values, there is little conceptual change and surprise for learners. With respect to the model, the design decision is to implement the fact that as co-construction, co-operation, and co-ordination notions are analytical distinctions, they should not necessarily correspond to different interfaces or features. Co-operation and co-ordination are often intertwined. From a user-interface perspective, it thus makes sense to propose very similar interfaces and keep the system as simple as possible. In contrast, co-construction requires a different interface. Moreover, it indeed makes sense to lead learners to consider specifically this task (see Section 2). The system implements this by the fact that 1) it offers a specific interface and 2) the items listed via the interface initialize the array-interface, which is the one that constitutes the center of learners' activity.
Table 2. System's Usage, Final Study (Step#5 in Table 1), General Figures
P. Moguel and P. Tchounikine are with the Grenoble Informatics Laboratory, University of Grenoble 1, 961 rue de la Houille Blanche, ENSE3 Ampère, Bâtiment B, BP 46, 38402 Grenoble Cedex, France.
E-mail: Patrice.Moguel@metapatrice.com, Pierre.Tchounikine@imag.fr.
A. Tricot is with the CLLE-LTC Laboratory, University of Toulouse II, IUFM, 56 Avenue de l'URSS, 31 078 Toulouse cedex 4, France.
Manuscript received 4 Feb. 2011; revised 29 June 2011; accepted 20 Oct. 2011; published online 5 Dec. 2011.
For information on obtaining reprints of this article, please send e-mail to: firstname.lastname@example.org, and reference IEEECS Log Number TLT-2011-02-0011.
Digital Object Identifier no. 10.1109/TLT.2011.30.
1. Some CSCL literature dissociates the notions of “cooperation” (work is accomplished by the division of labor among participants) and “collaboration” (learners engage in a coordinated effort to solve the problem together) [ 17]. As we believe this distinction is often a matter of the degree of granularity, of point of view or concern, we use “collective” as a broad concept (as in “collective challenge”), but quote other authors' original wording when citing specific works or referring to the literature in general.
2. In fact, some groups ask for extra time in Phase 1 (preparing data) or Phase 2 (measuring where to put the cars). Allowing them for some limited extra time does not impact the setting and avoids generating frustration. In the final study, all groups using the system felt close to a solution and asked for additional time to finish their calculus, and Phase 2 in fact lasted for an average of 53 minutes (see Table 2). This also exemplifies the playful nature of the setting, and its impact on learners' engagement.
Patrice Moguel received the PhD degree. Currently, he is working as a mathematics teacher in Andorra.
Pierre Tchounikine received the PhD degree. Currently, he is working as a professor of computer science at the University of Grenoble, France. He leads a pluridisciplinary team, dedicated to the design and analysis of computer-based learning environments.
André Tricot received the PhD degree. Currently, he is working as a professor of psychology at the University of Toulouse, France. He heads a team named “Learning, Motivation, Metacognition” in the CLLE-LTC laboratory.