Since february, I have been working for a research center in Pedagogy. One of my main tasks was to work on a European project called PALETTE. This project – in summary – aims to set up, build, and develop software that will propagate virtual communities of practice in the context of training. Beautiful idea, isn’t it? Especially because this project was put up on the basis of free and open-sourced engineering software. Such project, however, carries with it some difficulties. In addition of the usual problems of communication linked to the management of such a broad social network of European researchers, the project is regularly confronted with basic obstacles – a result of varied and differing comprehension of certain key concepts.

It was, initially, the concept of tool, which posed problems. From the point of view of a computer scientist, a tool, is a software. From the pedagogue point of view, it is less simpler. It could be a software (within the meaning of technology), if we speak about software dedicated to e-learning for example, but it is also a pedagogical instrument. Thus the term, in the sense of pedagogical tool, can be used for naming the syllabus of a course, such as those of bibliographical references, or about the simple concepts.

As one can imagine, this quickly led to a situation wherein each person starts thinking that his comprehension of the concept is the same as what others have come to understand, or worse, that they are convinced that its meaning is somehow already imbedded in its translation.

After being confronted with these issues, we have concluded that sharing a common reference frame will be one of the subjacent objectives of the research project. In the particular case of the concept of tool, the solution adopted after numerous discussions on the subject, was to keep only the tool term for more generic concepts, and later on replace it with words that can clearly signify their functionalities / properties / services depending on whether there is a need for deeper discussion. The first obstacle was crossed, and until today, it has helped us in producing project reports, which proved to be beneficial in building relationships between partners.

Later on, however, it was the concept of scenario that eventually posed problems on mutual comprehension in a way that was more evident and challenging.

Concept of scenario

A scenario, in the common language indicates, “an unfolding of planned or envisaged events”. The term covers several meanings. We can speak about scenario in the sense of forecast, of projection or prospective evaluation, as well as in cinematography, theater, and romance – and why not in teaching. The arguments for creating scenarios are also varied : while meteorologists
refer to charts taken by satellites in order to make empirical projections, certain data developer make UML in order to create scenarios for the use of their tools (sic). However, this does not tell us which way these various methods of doing do can be compatible, opposed, concurrent, or parallel. Thus we have a need to be more concrete.

If we consider a simple technical device, like this slide for child (picture), and that we decide to work above in order to work out a scenario. Several options are possible according to the point of view from which we are placing ourselves:

• An engineer/developer would explain that this device makes it possible for a human being with two fully functional legs to climb the steps (built from material that is able to support a maximum weight of 60 kilograms) in order to reach sufficient height and get inertia necessary for the body to go down on the smooth board.
• A specialist in sciences and technologies studies will look closely at the action of the involved agents (may they be human or not-human) in order to study their limits as well as the artefactual constraints. In any case, he will not be allowed to blame the technical device, and even less the ontology of the human actors. His vision, contrary to that of the engineer, will be exclusively descriptive (at best, he will be able to make prospective evaluations).
• As for the pedagogue, he will have an opposite starting point. Whereas the engineer develops a technical device according to a succession of imagined actions; the pedagogue, on the other hand, reflects in term of actions only if these have a purpose other than merely the actions themselves. Thus, a teaching scenario will not take into account the use of the technical device in itself but focuses more at the outcome of it, which in itself already exceeds the activity of use. The psychomotrician will consider the slide as a device that allows the infant to pay close attention to of his movements and his weight so that he becomes more aware of his physical capacities as well as his limitations.

The question that needs to be asked, involves finding out whether the engineer / developer needs the assistance of the pedagogue in order to make the slide functional, and so equally if the pedagogue should also know the technical engineering of the developer in order for him to successfully work out related scenarios of training. The answer to this question is obviously yes, if not, a project like PALETTE would not have come into existence. But it is a matter of knowing where and at which time the intersection between the points of view must occur. We can imagine, at the very least, three contrasted situations:

• Either we consider that it is necessary that the technical devices are developed and completed so that the pedagogue will be allowed to eventually be included in the process, but only near or at the end. One thus asks for to the engineer ideal ways to use their tools and the pedagogue then assumes the responsibility of building teaching scenarios around the preset ideal scenarios by the developers. In this case, the role of the pedagogue possibly consists of giving some recommendations to the developers at the end of the process (on ergonomic or accessibility aspects).
• Or, we consider that creating the design progresses in such a way that there is equal respect for the technical requirements as well as the teaching ones. The work then will be done by co-construction with permanent feedback between the various actors. In this case of figure, we speak about methodology using agile development or in spiral. One will then understand that these are the tendencies, which have the most success (at least at the point of view of project’s director).
• On the last assumption, the engineers will need the recommendations of the pedagogues from the beginning, before the very first step. This presupposes that the pedagogues already have ideal scenarios for the training beforehand and have thought of the very precise ideas on the way in which these must be later on conceived.

Until now, I have not found a solution to these problems. The only conclusion that I can draw is that it appears inconceivable to me that by approaching scenarios from two divergent points of view (that are those of the engineers and those of the pedagogues), we will arrive at a point of conciliation.