EP2718920A1 - Dispositif electronique d'apprentissage personnel - Google Patents
Dispositif electronique d'apprentissage personnelInfo
- Publication number
- EP2718920A1 EP2718920A1 EP12731517.4A EP12731517A EP2718920A1 EP 2718920 A1 EP2718920 A1 EP 2718920A1 EP 12731517 A EP12731517 A EP 12731517A EP 2718920 A1 EP2718920 A1 EP 2718920A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- data
- interaction
- exercise
- question
- test
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Classifications
-
- G—PHYSICS
- G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
- G09B—EDUCATIONAL OR DEMONSTRATION APPLIANCES; APPLIANCES FOR TEACHING, OR COMMUNICATING WITH, THE BLIND, DEAF OR MUTE; MODELS; PLANETARIA; GLOBES; MAPS; DIAGRAMS
- G09B7/00—Electrically-operated teaching apparatus or devices working with questions and answers
- G09B7/06—Electrically-operated teaching apparatus or devices working with questions and answers of the multiple-choice answer-type, i.e. where a given question is provided with a series of answers and a choice has to be made from the answers
-
- G—PHYSICS
- G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
- G09B—EDUCATIONAL OR DEMONSTRATION APPLIANCES; APPLIANCES FOR TEACHING, OR COMMUNICATING WITH, THE BLIND, DEAF OR MUTE; MODELS; PLANETARIA; GLOBES; MAPS; DIAGRAMS
- G09B5/00—Electrically-operated educational appliances
- G09B5/02—Electrically-operated educational appliances with visual presentation of the material to be studied, e.g. using film strip
-
- G—PHYSICS
- G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
- G09B—EDUCATIONAL OR DEMONSTRATION APPLIANCES; APPLIANCES FOR TEACHING, OR COMMUNICATING WITH, THE BLIND, DEAF OR MUTE; MODELS; PLANETARIA; GLOBES; MAPS; DIAGRAMS
- G09B7/00—Electrically-operated teaching apparatus or devices working with questions and answers
Definitions
- the invention relates to electronic personal learning devices.
- Computing has now taken a full-fledged place in all areas of modern life, from internet-controlled clock radios to cars equipped with digital jukeboxes to electronic cookbooks, not to mention its omnipresence in our professional lives. This omnipresence has also spread to the learning sectors, whether in a professional or educational setting.
- Computer learning software is currently based on two main formats.
- the first format is a very immersive format, in which a universe is created around the envisaged learning, and the final software is almost equivalent to a modern video game in terms of complexity, which is also worth the title. of "serious games”.
- the second format is a very simplistic format, in which the learning comes down to a simple page, often of the web page type, which contains a multiple choice questionnaire (MCQ).
- MCI multiple choice questionnaire
- These programs are actually "simplistic games". This type of software is unsatisfactory because it offers no interactivity - with the user. On the other hand, these softwares are often very poor graphically, which limits very strongly the immersion of the user. Finally, as they are limited to multiple choice, it is not possible to provide exercises with a sufficient diversity of activity, nor adapted to all types of learning.
- the invention improves the situation.
- the invention proposes an electronic device for personal learning, comprising a controller capable of controlling a display engine of a graphical interface, according to exercise data and as a function of interaction data inputted by the user via an input interface.
- the exercise data includes a plurality of context item datasets, including for each set presentation data and value data, and a training data set including question data, data of test and validation data.
- the input interface allows the user to modify the value data of a context element, and / or to associate two or more context elements with each other as interaction data.
- the controller is arranged to select current question data, and, in response to interaction data designating at least one given context element, is further arranged to:
- test function comprising:
- FIG. 1 represents an exemplary computer environment implementing the invention
- FIG. 2 represents an implementation diagram of a learning software according to the invention
- FIG. 3 represents a functional diagram showing the operation of a device of FIG. 2,
- FIG. 4 represents a functional diagram of an operation of FIG. 3
- FIG. 5 represents a functional diagram of another operation of FIG. 2.
- the computer environment shown in FIG. 1 comprises a creation station 2, a descriptive file storage space 4, a content storage space 6, a network 8 and a computer station 10.
- the creation station 2 enables a computer to be created. creator to design one or more learning programs according to the teachings of the invention.
- the creation station 2 may be a conventional computer, which executes a specialized program for creating learning programs. More particularly, this program may include a specific interface adapted to the program format of the invention. Such a program may have the advantage of being easy to use, to offer a direct visual rendering of the learning program created, and to include functions to automatically check certain rules relating to the format and the language of the device of the invention. .
- the creation station 2 may be a conventional computer equipped with a simple word processing program, from which the creator will directly write the description of the exercise or exercises and achieve the corresponding content associations.
- storage spaces 4 and 6 The purpose of storage spaces 4 and 6 is to store the computer elements that will abstractly define the learning programs and the exercises they contain. Thus, the storage space 4 receives files which will subsequently be referenced by the term "Desc_Fi". These files are text files and contain a description of each exercise. This description will be explained further in the following, and includes a simplified graphic description of the exercise, as well as the definition of all the sound, visual and educational interactions of the exercise.
- a given file of the storage space 4 corresponds to a single exercise, which can then be called independently by any program having access to the storage space 4.
- each file storage space 4 corresponds to a learning program, and can therefore include several exercises that can be called when this program is executed.
- the storage space 6 receives all the content data that is associated with the files of the storage space 4. More specifically, it has been explained that each file of the storage space 4 includes a textual description of the storage space. 'a exercise. This description contains references to image files, and / or sounds, and / or videos. These are the files that are stored in the storage space 6.
- the storage spaces 4 and 6 can be made in many ways. Thus, these storage spaces can be located on a hard disk or any other storage medium of the creation station 2, or on any storage space accessible from the creation station 2, such as a remotely hosted storage space accessible by Internet or otherwise.
- the storage spaces 4 and 6 are distinguished here to highlight the difference between the files they receive. However, these spaces can be made both within the same directory of a given storage medium than in several separate directories of this storage medium. They can also be distributed over several different storage media.
- the files of the storage space 4 and the file of the storage space 6 may be encapsulated in an exercise data container.
- the storage spaces 4 and 6 are made accessible by a network 8 to the station 10.
- the network 8 can be a local area network, or any type of wide area network, including the Internet.
- the storage spaces 4 and 6 may be reproduced on a storage medium such as a hard disk, a CD-ROM or a DVD executed on the station 10.
- the computer station 10 can be any type of computer station known. The only constraint is that this station is capable of executing the program of the invention and that it is able to access the storage spaces 4 and 6. More precisely, the invention can be implemented via the Internet, c. that is, a user of station 10 will visit a website. This website includes a program that will interpret the files of the storage spaces 4 and 6 and return them to the station 10 in the form of a web page.
- FIG. 2 represents an example of operation of the invention on the station 10.
- the computer station 10 which is an electronic device for personal learning.
- the personal learning device 10 receives a file 20 from the storage space 4, and a file 22 from the storage space 6.
- the files 20 and 22 correspond to a chosen exercise.
- the file 20 includes the exercise data that describes it, and the file 22 includes the content data of the exercise.
- the files 20 and 22 are transmitted to a controller 24 of the personal electronic learning device 10.
- the controller 24 comprises a weaver 26 and a motor 28.
- the weaver 26 has the function of generating an exercise 30 ready to be displayed by the motor 28, on command of the controller 24.
- FIG. 3 represents a functional diagram of the operation of the device of the invention.
- the controller 24 receives the file 20 in an operation 300. In this example, this operation takes place at the station 10. In other embodiments, this step could be carried out remotely , on a server.
- the weaver 26 checks the contents of the file 20.
- the device 10 is based on the use of an exercise description file that obeys a particular syntax, which makes it possible to integrate a maximum information in a minimum of space.
- the file 20 is written in XML, according to a syntax and a grammar of the invention. However, any other hierarchical format programming language could be adapted to implement the invention.
- FIG. 4 represents an example of implementation of the operation 320.
- the verification of the file 20 begins with an operation 400 of verification of the syntax of this file.
- the weaver 26 checks the XML syntax of the file 20.
- the exercise description file includes several discrete parts forming exercise data.
- a first part includes parameter declarations, such as the functional type of exercise (card, number, letter, button, deferred or not, etc.), and instructions on the type of learning ( of the type "collect the paired cards together", “calculate the sum of the cards”, etc.), forming exercise data.
- parameter declarations such as the functional type of exercise (card, number, letter, button, deferred or not, etc.)
- instructions on the type of learning of the type "collect the paired cards together", “calculate the sum of the cards”, etc.
- a second part includes the description of the contextual elements of the exercise, such as the set, the interaction elements, the different plans, etc.
- this second part comes to specify their identifier, their starting location, and their nature. Indeed, in a card exercise for example, some elements are cards to move from one place to another.
- a starting block is defined in which several areas are defined which each contain an interaction element.
- An arrival block is also defined, in which several arrival zones are defined, for the realization of the exercise. Sounds can be associated with each interaction element to increase the user's immersion.
- a third part includes a truth table that contains the answer to the exercise and that forms validation data.
- the third part also includes tests to validate answers to exercise questions forming test data and messages to the user based on his answers. The operation of these elements will be described further with Figure 5.
- the third part is the "dynamic" part of the description of the exercise.
- a fourth part includes statements of graphic data, and possibly sound, to access the contents declared above in the other second and third parts.
- the operation 320 continues with an operation 420 in which the grammar of the file 20 is checked. More specifically, this operation verifies that the file is described in accordance with the four-part structure described above, and that this structure is consistent.
- the weaver 26 can correct them on the fly to allow the fastest possible execution for the user. Alternatively, or where the error can not be corrected directly by the weaver 26, a message is issued to indicate to the user that the exercise can not be performed.
- operations 400 and 420 terminate successfully, file 22 is called in an operation 440 to allow the content data it contains to merge with that of file 20. This is done in an operation 340, with the merge of the file 22 which contains the content data declared with the file 20, to form an executable exercise.
- the executable exercise may be obfuscated or not, contained in a Flash file or in another multimedia content plugin, or implemented as a web page type AJAX, aspx, php , jsp or other.
- FIG. 5 shows an example of implementation of operation 360. This implementation starts in 500 by receiving exercise data as merged with operation 340.
- a variable Curr Q id receives the index of the first question of the exercise. Then, controller 24 initiates an exercise execution loop.
- This loop starts in an operation 510 with a function Displ () which displays the information relating to the current question of the exercise.
- Displ displays the information relating to the current question of the exercise.
- an exercise can include several questions. The progression in each exercise is conditioned by obtaining a correct answer to each current question, until there is no more question.
- the information relating to the current question there is, where necessary, the resetting of the set and the interaction elements of the exercise, as described for each question in the second part of the question. 20. This reset can be omitted when the questions are scheduled to be chained.
- An event detection sub-loop 515 is then started, in which the controller 24 waits for an action input by a user input interface to be performed.
- An example of such an action is the realization of a "drag-and-drop" of a card to a given location. As long as this operation 515 does not detect an action, nothing happens.
- a test is performed in an operation 520 to determine whether this action is a simple interaction action, such as click on a decor item, a help button, or a move operation. an interaction element, or if this action is an answer to a question, which must be checked.
- a function Upd_Glob_Var () is started in an operation 530.
- the exercises of the invention are intended to be executed in application environments mainly intended for display and presentation, such as the Flash or other environment of this type. Under these conditions, the programming possibilities are limited, and it is not possible to maintain global variables in a simple way.
- global variable is meant any information that is useful for the exercise, such as the number of cards in an arrival zone, the sum of the values of cards placed in an arrival zone, etc.
- each exercise belongs to a type family, to which is associated a set of variables to calculate at each interaction.
- Types of exercises include:
- the global variables that are calculated for each interaction include:
- a function Resp () determines in an operation 535 whether the detected interaction implies an answer to a question or not.
- the detected interaction can be of several kinds. However, whatever the interaction, the interaction data has the effect of modifying the value data of a given element.
- the interaction can be to change the value of a card, or the state of a button, or to enter a text string. It then becomes clear that it is a question of changing the value data of a given element, that is to say the map, the text string or the button.
- the interaction consists in associating a card with a given zone, the situation does not differ: it is the value data of the zone that are modified, to receive an identifier of the card in question.
- the detected interaction does not involve an answer, then it is a delayed correction exercise. It is therefore only to display the interaction, via the operation 525.
- this operation may include the verification of certain conditions depending on the exercise. For example, if the exercise is deferred, and the question is to gather cards with vowels written on it, the operation 525 can issue a message when a consonant is selected to assist the user.
- any interaction is an answer, and is evaluated instantly.
- the question is "Put in the net all the fish bearing even numbers”.
- This exercise is an immediate correction card type exercise, for which every card in a net is checked if it is in the right place.
- a delayed correction exercise it is the pressing of a specific button, indicating that the user has finished, which triggers the detection of a response.
- a function Test () is started in an operation 540 to correct the response.
- the function Test () will analyze if the answer that was made by the user is correct.
- the function Test () will perform one or more tests described in the third part of the file 20, and designated by the variable Curr_Q_id. These tests may be based on the values of some of the interaction elements, or on value data indicating the association of two interacting elements between them.
- the Test () function will first parse the test formulas designated by the Curr_Q_id variable, in order to translate them into parsable code in the runtime environment.
- the function Test determines whether the response (s) is correct.
- buttons for a question where some buttons must be activated according to their value, it is the states of the buttons that will be tested, • etc.
- the Test () function will include a larger number of tests for a delayed correction exercise than for an immediate correction exercise. Indeed in an immediate correction exercise, only one response is tested with each interaction, while a delayed-correction exercise the Test () function corrects all responses.
- a value indicates whether the answer is correct or false. This value is tested in an operation 540. If there was an error, then the function Displ () is called to display a corresponding message in an operation 555, and the loop resumes in 510. As a variant, the operation 555 can completely reset the GUI, or just indicate the error.
- variable Curr_Q_id is incremented in an operation 560. This goes to the next question of the exercise. Then, a test is performed by an End () function in an operation 560 to determine if the exercise is complete.
- This test can for example consist of analyzing whether the Curr Q id variable corresponds to a question index or not, or to look at the number of answers (and therefore questions) in the truth table.
- the loop resumes in 510 with the display of the data relating to this question, and waiting for an answer.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Business, Economics & Management (AREA)
- Physics & Mathematics (AREA)
- Educational Administration (AREA)
- Educational Technology (AREA)
- General Physics & Mathematics (AREA)
- Electrically Operated Instructional Devices (AREA)
Abstract
Un dispositif électronique d'apprentissage personnel comprend un contrôleur (24) propre à commander un moteur d'affichage d'une interface graphique, en fonction de données d'exercice et de données d'interaction saisies par l'utilisateur, via une interface d'entrée. Les données d'exercice comprennent : •. une pluralité de jeu de données d'élément de contexte, comprenant pour chaque jeu des données de présentation et des données de valeur, •. un jeu de données d'apprentissage, comprenant des données de question, des données de test et des données de validation. L'interface d'entrée (10) permet à l'utilisateur d'entrer des données d'interaction, pour déplacer un élément de contexte ou pour modifier les données de valeur d'un élément de contexte.
Description
Dispositif électronique d'apprentissage personnel
L'invention concerne les dispositifs électroniques d'apprentissage personnel. L'informatique a maintenant pris une place à part entière dans tous les secteurs de la vie moderne, des radios réveils commandés par Internet aux voitures équipées de jukebox numériques en passant par les livres de cuisine électroniques, sans oublier son omniprésence dans notre vie professionnelle. Cette omniprésence s'est également étendue aux secteurs de l'apprentissage, qu'il soit dans un cadre professionnel ou éducatif. Il existe maintenant des offres d'apprentissage par ordinateur pour les langues ou pour d'autres domaines, adaptées à un public jeune ou plus mature. Les logiciels d'apprentissage par ordinateur reposent actuellement sur deux formats principaux.
Le premier format est un format très immersif, dans lequel un univers est créé autour de l'apprentissage envisagé, et le logiciel final est presque équivalent à un jeu vidéo moderne en termes de complexité, ce qui vaut d'ailleurs à ces logiciels le titre de "serious games" ("jeux sérieux").
Ce type de logiciel, bien que très efficace, présente le désavantage d'être très complexe à mettre en œuvre, d'être peu portable entre diverses plateformes, et peu reproductible. En fait, il faut repartir de zéro à chaque fois que l'on crée un nouveau logiciel. Et même le changement de quelques comportements simples au sein d'un logiciel déjà programmé peut poser de sérieux problèmes.
Le deuxième format est un format très simpliste, dans lequel l'apprentissage se résume à une simple page, souvent de type page web, qui contient un questionnaire à choix multiples (QCM). Ces logiciels sont en fait des "jeux simplistes".
Ce type de logiciel n'est pas satisfaisant car il n'offre aucune interactivité - avec l'utilisateur. D'autre part, ces logiciels sont souvent très pauvres graphiquement, ce qui limite très fortement l'immersion de l'utilisateur. Enfin, comme ils sont limités aux QCM, il n'est pas possible de fournir des exercices avec une diversité suffisante d'activité, ni adaptée à tous les types d'apprentissages.
L'invention vient améliorer la situation.
À cet effet, l'invention propose un dispositif électronique d'apprentissage personnel, comprenant un contrôleur propre à commander un moteur d'affichage d'une interface graphique, en fonction de données d'exercice et en fonction de données d'interaction saisies par l'utilisateur, via une interface d'entrée.
Les données d'exercice comprennent une pluralité de jeu de données d'élément de contexte, comprenant pour chaque jeu des données de présentation et des données de valeur, et un jeu de données d'apprentissage, comprenant des données de question, des données de test et des données de validation.
L'interface d'entrée permet à l'utilisateur de modifier les données de valeur d'un élément de contexte, et/ou d'associer deux ou plusieurs éléments de contexte entre eux, en tant que données d'interaction.
Le contrôleur est agencé pour sélectionner des données de question courantes, et, en réponse à des données d'interaction désignant au moins un élément de contexte donné, est en outre agencé pour :
• commander le moteur pour modifier l'interface graphique en fonction des données de présentation de l'élément de contexte donné pour représenter l'interaction désignée par les données d'interaction,
• exécuter une fonction de test, ladite fonction de test comprenant :
o la détermination que les données de valeur associées à l'élément de contexte donné satisfont les données de validation, en fonction des données de question courantes et des données de test,
o l'émission d'un message sonore et/ou graphique en fonction de cette détermination, et la mise à jour sélective des données de question courantes et,
o la terminaison de l'exercice en fonction des données de question courantes.
Ce dispositif est très avantageux, car il permet d'offrir un apprentissage de qualité, à la manière des jeux sérieux, tout en offrant la souplesse de programmation des jeux simplistes. D'autres caractéristiques et avantages de l'invention apparaîtront mieux à la lecture de la description qui suit, tirée d'exemples donnés à titre illustratif et non limitatif, tirés des dessins sur lesquels :
la figure 1 représente un exemple d'environnement informatique mettant en œuvre l'invention,
- la figure 2 représente un schéma de mise en œuvre d'un logiciel d'apprentissage selon l'invention,
la figure 3 représente un diagramme fonctionnel montrant le fonctionnement d'un dispositif de la figure 2,
la figure 4 représente un diagramme fonctionnel d'une opération de la figure 3, et - la figure 5 représente un diagramme fonctionnel d'une autre opération de la figure 2.
Les dessins et la description ci-après contiennent, pour l'essentiel, des éléments de caractère certain. Ils pourront donc non seulement servir à mieux faire comprendre la présente invention, mais aussi contribuer à sa définition, le cas échéant.
La présente description est de nature à faire intervenir des éléments susceptibles de protection par le droit d'auteur et/ou le copyright. Le titulaire des droits n'a pas d'objection à la reproduction à l'identique par quiconque du présent document de brevet ou de sa description, telle qu'elle apparaît dans les dossiers officiels. Pour le reste, il réserve intégralement ses droits.
Le domaine des dispositifs électroniques d'apprentissage est un domaine particulier.
D'un côté, une immersion poussée et une ambiance spécifique sont souhaitables pour améliorer l'apprentissage, à la manière des jeux vidéos. Cela signifie que le contenu et l'interaction doivent être assez riches.
De l'autre côté, une reproduction aisée est souhaitable, car il faut de nombreux exercices variés pour réaliser un apprentissage efficace. Cela signifie donc qu'il est important de ne pas recommencer à zéro à chaque fois.
Cela peut paraître contradictoire. C'est d'ailleurs à partir de ce constat que les logiciels d'apprentissage ont été réalisés à ce jour : les uns (les "jeux sérieux") privilégient l'immersion et l'interaction au détriment de la reproductibilité, alors que les autres (les "jeux simplistes") privilégient la reproductibilité au détriment de l'immersion et de l'interaction.
Mais en réalité, aucune de ces deux approches n'est bonne. Et le système représenté sur la figure 1 vient apporter une solution qui montre que les besoins spécifiques aux logiciels d'apprentissage ne sont pas contradictoires.
L'environnement informatique représenté sur la figure 1 comprend un poste de création 2, un espace de stockage de fichier descriptif 4, un espace de stockage de contenu 6, un réseau 8 et un poste informatique 10. Le poste de création 2 permet à un créateur de concevoir un ou plusieurs programmes d'apprentissage conformes aux enseignements de l'invention.
Dans une première variante, le poste de création 2 peut être un ordinateur classique, qui exécute un programme spécialisé pour la création de programmes d'apprentissage. Plus particulièrement, ce programme peut comprendre une interface spécifique adaptée au format de programmes de l'invention.
Un tel programme peut présenter l'avantage d'être aisé à utiliser, d'offrir un rendu visuel direct du programme d'apprentissage créé, et comprendre des fonctions pour vérifier automatiquement certaines règles relatives au format et au langage du dispositif de l'invention.
Dans une deuxième variante, le poste de création 2 peut être un ordinateur classique muni d'un simple programme de traitement de texte, à partir duquel le créateur va écrire directement la description du ou des exercices et réaliser les associations de contenu qui lui correspondent.
Les espaces de stockage 4 et 6 ont pour fonction le stockage des éléments informatiques qui vont définir abstraitement les programmes d'apprentissage et les exercices qu'ils contiennent. Ainsi, l'espace de stockage 4 reçoit des fichiers qui seront par la suite référencés par le terme "Desc_Fi". Ces fichiers sont des fichiers de type texte et contiennent une description de chaque exercice. Cette description sera explicitée plus avant dans ce qui suit, et comprend une description graphique simplifiée de l'exercice, ainsi que la définition de l'ensemble des interactions sonores, visuelles et éducatives de l'exercice.
Selon une première variante, un fichier donné de l'espace de stockage 4 correspond à un unique exercice, qui peut ensuite être appelé indépendamment par n'importe quel programme ayant accès à l'espace de stockage 4. Selon une deuxième variante, chaque fichier de l'espace de stockage 4 correspond à un programme d'apprentissage, et peut donc comprendre plusieurs exercices qui peuvent être appelés lorsque ce programme est exécuté.
L'espace de stockage 6 reçoit pour sa part toutes les données de contenu qui sont associées aux fichiers de l'espace de stockage 4. Plus précisément, il a été expliqué que chaque fichier de l'espace de stockage 4 comprend une description textuelle d'un
exercice. Cette description contient des références à des fichiers images, et/ou sons, et/ou vidéos. Ce sont ces fichiers qui sont stockés dans l'espace de stockage 6.
Les espaces de stockage 4 et 6 peuvent être réalisés de très nombreuses manières. Ainsi, ces espaces de stockage peuvent être situés sur un disque dur ou tout autre support de stockage du poste de création 2, ou sur tout espace de stockage accessible depuis le poste de création 2, comme un espace de stockage hébergé à distance, accessible par Internet ou autrement. Les espaces de stockage 4 et 6 sont ici distingués pour mettre en valeur la différence entre les fichiers qu'ils reçoivent. Cependant, ces espaces peuvent être réalisés aussi bien au sein d'un même répertoire d'un support de stockage donné que dans plusieurs répertoires distincts de ce support de stockage. Ils peuvent également être répartis sur plusieurs supports de stockage distincts.
Une fois l'exercice créé, il est entièrement décrit par le fichier qui lui correspond dans l'espace de stockage 4 et par les fichiers de contenu correspondants dans l'espace de stockage 6. En variante, le fichiers de l'espace de stockage 4 et le fichier de l'espace de stockage 6 peuvent être encapsulés dans un conteneur de données d'exercice.
Les espaces de stockage 4 et 6 sont rendus accessibles par un réseau 8 au poste 10. Le réseau 8 peut être un réseau local, ou tout type de réseau étendu, y compris l'Internet. Dans une autre variante, les espaces de stockage 4 et 6 peuvent être reproduits sur un support de stockage tel un disque dur, un CD-ROM ou un DVD exécuté sur le poste 10.
Le poste informatique 10 peut être tout type de poste informatique connu. La seule contrainte est que ce poste soit capable d'exécuter le programme de l'invention et qu'il soit capable d'accéder aux espaces de stockage 4 et 6. Plus précisément, l'invention peut être mise en place par Internet, c'est-à-dire qu'un utilisateur du poste 10 va visiter un site web. Ce site web comprend un programme qui
va interpréter les fichiers des espaces de stockage 4 et 6 et les restituer au poste 10 sous la forme d'une page web.
En variante, l'invention peut être mise sur un support de stockage comme précisé plus haut, et le programme qui interprète et restitue les fichiers des espaces de stockage 4 et 6 est stocké avec eux sur ce support. Il faut alors que le poste 10 soit capable d'exécuter ce programme, tant d'un point de vue de la compatibilité de système d'exploitation que des capacités de calcul. Enfin, ces deux variantes peuvent être combinées, c'est-à-dire que certains fichiers peuvent être accessibles par Internet ou un autre réseau étendu, tandis que d'autres sont présents sur un support physique. Cela s'applique tant aux fichiers des espaces de stockage 4 et 6 qu'au programme pour les interpréter et les restituer. La figure 2 représente un exemple de fonctionnement de l'invention sur le poste 10. Dans cet exemple, le poste informatique 10 qui est un dispositif électronique d'apprentissage personnel.
Le dispositif électronique d'apprentissage personnel 10 reçoit un fichier 20 de l'espace de stockage 4, et un fichier 22 de l'espace de stockage 6. Les fichiers 20 et 22 correspondent à un exercice choisi. Le fichier 20 comprend les données d'exercice qui le décrivent, et le fichier 22 comprend les données de contenu de l'exercice.
Les fichiers 20 et 22 sont transmis à un contrôleur 24 du dispositif électronique d'apprentissage personnel 10. Le contrôleur 24 comprend un tisseur 26 et un moteur 28.
Le tisseur 26 a pour fonction la génération d'un exercice 30 prêt à être affiché par le moteur 28, sur commande du contrôleur 24. La figure 3 représente un diagramme fonctionnel du fonctionnement du dispositif de l'invention.
Comme on peut le voir sur cette figure, le contrôleur 24 reçoit le fichier 20 dans une opération 300. Dans cet exemple, cette opération a lieu au niveau du poste 10. Dans d'autres modes de réalisation, cette étape pourrait être réalisée à distance, sur un serveur. Ensuite, dans une opération 320, le tisseur 26 vérifie le contenu du fichier 20. En effet, le dispositif 10 repose sur l'utilisation d'un fichier de description d'exercice obéissant à une syntaxe particulière, qui permet d'intégrer un maximum d'informations en un minimum de place. Dans l'exemple décrit ici, le fichier 20 est écrit en XML, selon une syntaxe et une grammaire propres à l'invention. Cependant, tout autre langage de programmation à format hiérarchique pourrait être adapté pour mettre en œuvre l'invention.
La figure 4 représente un exemple de mise en œuvre de l'opération 320. La vérification du fichier 20 commence par une opération 400 de vérification de la syntaxe de ce fichier. Pour cela, le tisseur 26 vérifie la syntaxe XML du fichier 20.
Cela est important, car bien qu'il soit prévu un programme de génération automatique de fichier de description d'exercice, il est également possible de les écrire à la main.
Dans l'exemple décrit ici, le fichier de description d'exercice comprend plusieurs parties distinctes formant données d'exercice.
Une première partie comprend des déclarations de paramètres, tel que le type fonctionnel d'exercice (à cartes, à chiffres, à lettres, à boutons, à correction différée ou pas, etc.), et des instructions sur le type d'apprentissage (du type "rassembler les cartes paires ensemble", "calculer la somme des cartes", etc.), formant données d'exercice.
Une deuxième partie comprend la description des éléments de contexte de l'exercice, comme le décor, les éléments d'interaction, les différents plans, etc.
Pour les éléments d'interaction, qui peuvent donc être déplacés et/ou modifiés, cette deuxième partie vient préciser leur identifiant, leur emplacement de départ, ainsi que leur nature. En effet, dans un exercice à cartes par exemple, certains éléments sont des cartes à déplacer d'un endroit vers un autre.
Un bloc de départ est donc défini, dans lequel sont définies plusieurs zones qui contiennent chacune un élément d'interaction. Un bloc d'arrivée est également défini, dans lequel sont définies plusieurs zones d'arrivée, pour la réalisation de l'exercice. Des sons peuvent être associés à chaque élément d'interaction afin d'augmenter l'immersion de l'utilisateur.
Une troisième partie comprend une table de vérité qui contient la réponse à l'exercice et qui forme des données de validation. La troisième partie comprend également des tests de validation des réponses aux questions de l'exercice formant données de test et des messages à l'intention de l'utilisateur en fonction de ses réponses. Le fonctionnement de ces éléments sera décrit plus avant avec la figure 5. La troisième partie constitue la partie "dynamique" de la description de l'exercice.
Enfin, une quatrième partie comprend des déclarations de données graphiques, et éventuellement sonores, permettant d'accéder aux contenus déclarés plus haut dans les autres deuxième et troisième parties.
Une fois la syntaxe du fichier 20 vérifiée, l'opération 320 se poursuit avec une opération 420 dans laquelle la grammaire du fichier 20 est vérifiée. Plus précisément, cette opération vérifie que le fichier 20 est décrit conformément à la structure en quatre parties décrite plus haut, et que cette structure est cohérente.
Lorsqu'il existe des problèmes de syntaxe et/ou de grammaire simples, le tisseur 26 peut les corriger à la volée pour permettre une exécution la plus rapide possible pour l'utilisateur. En variante, ou lorsque l'erreur ne peut pas être corrigée directement par le tisseur 26, un message est émis pour indiquer à l'utilisateur que l'exercice ne peut pas être exécuté.
Lorsque les opérations 400 et 420 se terminent avec succès, le fichier 22 est appelé dans une opération 440 afin de permettre la fusion des données de contenu qu'il renferme avec celles du fichier 20. Cela est réalisé dans une opération 340, avec la fusion du fichier 22 qui contient les données de contenu déclarées avec le fichier 20, pour former un exercice exécutable.
Selon les modes de réalisation, l'exercice exécutable pourra être obfusqué ou pas, contenu dans un fichier Flash ou dans un autre plugin de contenu multimédia, ou être mis en œuvre sous la forme d'une page web de type AJAX, aspx, php, jsp ou autre.
Enfin, ce programme est exécuté dans une opération 360, jusqu'à ce que la fin de l'exercice soit déterminée. La figure 5 représente un exemple de mise en œuvre de l'opération 360. Cette implémentation commence en 500 par la réception des données de l'exercice telles que fusionnées à l'opération 340.
Ces données correspondent à l'ensemble des paramètres globaux de l'exercice, ainsi que la déclaration de chacun des objets d'interaction et des questions de l'exercice, avec leurs identifiants correspondants.
Dans une opération 505, une variable Curr Q id reçoit l'indice de la première question de l'exercice. Ensuite, le contrôleur 24 lance une boucle d'exécution de l'exercice.
Cette boucle commence dans une opération 510 avec une fonction Displ() qui affiche les informations relatives à la question courante de l'exercice. En effet, un exercice peut comprendre plusieurs questions. La progression dans chaque exercice est conditionnée par l'obtention d'une réponse correcte à chaque question courante, jusqu'à ce qu'il n'y ait plus de question.
Parmi les informations relatives à la question courante, il y a, lorsque c'est nécessaire, la remise à zéro du décor et des éléments d'interaction de l'exercice, conformément à ce qui est décrit pour chaque question dans la deuxième partie du fichier 20. Cette remise à zéro peut être omise lorsque les questions sont prévues pour être enchaînées.
C'est par exemple le cas lorsqu'une première question prévoit de réunir toutes les cartes paires, et que la deuxième question prévoit par exemple de réunir toutes les cartes multiples de trois : il n'est pas nécessaire de remettre toutes les cartes dans leur emplacement de départ, et la position de fin d'une question peut ainsi servir de position de départ à une question suivante.
Une sous-boucle 515 de détection d'événement est alors lancée, dans laquelle le contrôleur 24 attend qu'une action saisie par une interface d'entrée utilisateur soit réalisée. Un exemple d'une telle action est la réalisation d'un "glisser-déplacer" d'une carte vers un emplacement donné. Tant que cette opération 515 ne détecte pas d'action, rien ne se passe.
Lorsqu'une action est détectée, un test est réalisé dans une opération 520 pour déterminer si cette action est une action d'interaction simple, de type clic sur un élément du décor, sur un bouton d'aide, ou une opération de déplacement d'un élément d'interaction, ou si cette action constitue une réponse à une question, qu'il faut donc vérifier.
Dans le premier cas, il s'agit de modifier l'interface graphique de l'exercice et/ou émettre un son ou un autre retour à l'utilisateur en réponse à l'interaction. Cela est réalisé par la fonction Displ() dans une opération 525.
Dans le deuxième cas, une fonction Upd_Glob_Var() est lancée dans une opération 530. Les exercices de l'invention sont prévus pour être exécutés dans des environnements applicatifs principalement destinés à l'affichage et à la présentation, comme le Flash ou autre environnement de ce type.
Dans ces conditions, les possibilités de programmation sont limitées, et il n'est pas possible de maintenir des variables globales de manière simple. Par variable globale, on entend toute information qui est utile à l'exercice, comme le nombre de cartes dans une zone d'arrivée, la somme des valeurs des cartes posées dans une zone d'arrivée, etc.
Ce problème est contourné en recalculant à chaque interaction une quantité choisie de valeurs. Ainsi, le fait de calculer des valeurs correspondant aux variables globales à chaque interaction détectée permet de compenser l'absence de variables globales à proprement parler.
Les valeurs à calculer à chaque interaction sont définies par les données de l'exercice. Ainsi, chaque exercice appartient à une famille type, à laquelle est associée un ensemble de variables à calculer à chaque interaction. Parmi les types d'exercices possibles, on compte :
- les exercices à cartes à correction immédiate ou différée,
- les exercices à boutons à correction immédiate ou différée,
- les exercices à coloriage à correction immédiate ou différée, et
- les exercices à zone de texte à correction immédiate ou différée.
Pour les exercices à cartes à correction immédiate ou différée, les variables globales qui sont calculées à chaque interaction comprennent :
- un tableau des identifiants de cartes en fonction de l'emplacement de chaque carte,
- un tableau des valeurs des cartes en fonction de l'emplacement de chaque carte, - une somme des valeurs des cartes en fonction de leur emplacement,
- etc.
Pour les exercices à boutons à correction immédiate ou différée, les variables globales qui sont calculées à chaque interaction comprennent :
- un tableau des valeurs des boutons affichés, classés par identifiant croissant,
- un tableau de l'état d'activation des boutons affichés, classés par identifiant croissant,
- un nombre de boutons activés/modifiés,
- etc.
Pour les exercices à zone de texte, les variables globales qui sont calculées à chaque interaction comprennent :
- un tableau des chaînes de caractères affichées dans chaque zone de texte,
- un nombre de zone de texte non vides,
- un caractère courant,
- etc.
Une fois ces variables mises à jour, une fonction Resp() détermine dans une opération 535 si l'interaction détectée implique une réponse à une question ou pas.
L'interaction détectée peut être de plusieurs natures. Cependant, quelque soit l'interaction, les données d'interaction ont pour effet de modifier les données de valeur d'un élément donné.
En effet, l'interaction peut consister à changer la valeur d'une carte, ou l'état d'un bouton, ou à entrer une chaîne de texte. Il apparaît alors clairement qu'il s'agit de changer les données de valeur d'un élément donné, c'est-à-dire la carte, la chaîne de texte ou le bouton. Lorsque l'interaction consiste à associer une carte à une zone donnée, la situation ne diffère pas : ce sont les données de valeur de la zone qui sont modifiées, pour recevoir un identifiant de la carte en question.
Si l'interaction détectée n'implique pas une réponse, alors il s'agit d'un exercice à correction différée. Il s'agit donc uniquement d'afficher l'interaction, via l'opération 525. Selon l'exercice cette opération peut comprendre la vérification de certaines conditions en fonction de l'exercice. Par exemple, si l'exercice est à correction différée, et que la question est de réunir des cartes sur lesquelles sont inscrites des voyelles, l'opération 525 peut émettre un message lorsqu'une consonne est sélectionnée, pour aider l'utilisateur.
Dans le cas d'un exercice à correction immédiate, toute interaction constitue une réponse, et est évaluée instantanément. Par exemple, dans l'écran représenté sur la
figure 1, la question est "Mets dans le filet tous les poissons portant des nombres pairs". Cet exercice est un exercice de type carte à correction immédiate, pour lequel il est vérifié à chaque carte déposée dans un filet si elle est au bon endroit. Dans le cas d'un exercice à correction différée, c'est l'appui sur un bouton spécifique, indiquant que l'utilisateur a terminé, qui déclenche la détection d'une réponse.
Ensuite, une fonction Test() est lancée dans une opération 540 pour corriger la réponse. En fonction de la variable Curr_Q_id, la fonction Test() va analyser si la réponse qui a été formulée par l'utilisateur est correcte. Pour cela, la fonction Test() va réaliser un ou plusieurs tests décrits dans la troisième partie du fichier 20, et désignées par la variable Curr_Q_id. Ces tests peuvent être basés sur les valeurs de certains des éléments d'interaction, ou sur des données de valeur désignant l'association de deux éléments d'interaction entre eux. Ici encore, comme l'environnement est principalement graphique, la fonction Test() va d'abord analyser syntaxiquement les formules des tests désignés par la variable Curr_Q_id, afin de les transcrire en code analysable dans l'environnement d'exécution.
Ensuite, sur la base des variables globales mises à jour dans l'opération 530 et des tests retranscrits, la fonction Test() détermine si la ou les réponses est correcte.
D'une manière pratique, divers tests peuvent être réalisés en fonction de l'exercice :
• pour une question qui consiste à calculer la sommes de cartes et à l'inscrire dans une carte de résultat, ce sont les données de la valeur de cette carte qui vont être testées ;
• pour une question où les cartes paires doivent être réunies dans une zone particulière, ce sont les données de valeur indiquant l'association carte-zone qui vont être testées,
• pour une question où un texte particulier doit être inscrit dans une zone de texte, ce sont les données de texte qui vont être testées,
• pour une question où certains boutons doivent être activés en fonction de leur valeur, ce sont les états des boutons qui vont être testés,
• etc.
Typiquement, la fonction Test() comprendra un nombre de tests plus importants pour un exercice à correction différée que pour un exercice à correction immédiate. En effet dans un exercice à correction immédiate, une seule réponse est testée avec chaque interaction, alors qu'un exercice à correction différée la fonction Test() corrige toutes les réponses.
En sortie de la fonction Test(), une valeur indique si la réponse est correcte ou fausse. Cette valeur est testée dans une opération 540. S'il y a eu une erreur, alors la fonction Displ() est appelée pour afficher un message correspondant dans une opération 555, et la boucle reprend en 510. En variante, l'opération 555 peut réinitialiser totalement l'interface graphique, ou simplement indiquer l'erreur.
Si la réponse est correcte, la variable Curr_Q_id est incrémentée dans une opération 560. Cela permet de passer à la question suivante de l'exercice. Ensuite, un test est réalisé par une fonction Fin() dans une opération 560 pour déterminer si l'exercice est terminé.
Ce test peut par exemple consister à analyser si la variable Curr Q id correspond à un indice de question ou pas, ou à regarder le nombre de réponses (et donc de questions) dans la table de vérité.
S'il reste une question, alors la boucle reprend en 510 avec l'affichage des données relatives à cette question, et l'attente d'une réponse.
Sinon, l'exercice se termine en 570, avec l'émission optionnelle d'un message de félicitation à l'utilisateur.
Claims
1. Dispositif électronique d'apprentissage personnel, comprenant un contrôleur (24) propre à commander un moteur d'affichage d'une interface graphique, en fonction de données d'exercice et en fonction de données d'interaction saisies par l'utilisateur, via une interface d'entrée,
caractérisé en ce que les données d'exercice comprennent :
• une pluralité de jeu de données d'élément de contexte, comprenant pour chaque jeu des données de présentation et des données de valeur,
• un jeu de données d'apprentissage, comprenant des données de question, des données de test et des données de validation,
l'interface d'entrée (10) permettant à l'utilisateur d'entrer des données d'interaction, pour déplacer un élément de contexte ou pour modifier les données de valeur d'un élément de contexte,
le contrôleur (24) étant agencé pour sélectionner des données de question courantes, et, en réponse à des données d'interaction désignant au moins un élément de contexte donné, étant en outre agencé pour :
• commander le moteur pour modifier l'interface graphique en fonction des données de présentation de l'élément de contexte donné pour représenter l'interaction désignée par les données d'interaction,
• calculer des données de variables globales en fonction des données d'interaction, des données de valeur des éléments de contexte, et des données de question,
• exécuter sélectivement une fonction de test, ladite fonction de test comprenant :
o la sélection des données de tests et des données de validation désignées par les données de question courantes,
o la détermination que les données de valeur associées à l'élément de contexte donné satisfont les données de validation sélectionnées, en fonction des données de variables globales calculées et des données de test sélectionnées, o l'émission d'un message sonore et/ou graphique en fonction de cette détermination, et la mise à jour sélective des données de question courantes et,
o la terminaison de l'exercice en fonction des données de question courantes.
2. Dispositif selon la revendication 1, dans lequel le contrôleur (24) est agencé pour exécuter la fonction de test lorsque les données d'interaction indiquent une réponse.
3. Dispositif selon la revendication 2, dans lequel le contrôleur (24) est agencé pour déterminer si les données d'interaction indiquent une réponse en fonction des données de question.
4. Dispositif selon l'une des revendications 1 à 3, dans lequel le contrôleur (24) est agencé pour afficher un message d'erreur lorsque la fonction de test détermine que les données de valeur associées à l'élément de contexte donné ne satisfont pas les données de validation déterminées, en fonction des données de variables globales calculées et des données de test déterminées.
5. Dispositif selon l'une des revendications 1 à 4, dans lequel les éléments de contextes sont choisis dans le groupe comprenant une carte, un bouton, une zone de texte, et une zone de dépôt de carte.
6. Dispositif selon l'une des revendications 1 à 5, dans lequel les données de questions comprennent une indication textuelle et/ou sonore de la question.
7. Dispositif selon l'une des revendications 1 à 6, dans lequel les données de présentation comprennent des données graphiques.
8. Dispositif selon la revendication 7, dans lequel les données de présentation comprennent des données sonores.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
FR1101752A FR2976391A1 (fr) | 2011-06-08 | 2011-06-08 | Dispositif electronique d'apprentissage personnel. |
PCT/FR2012/000228 WO2012168576A1 (fr) | 2011-06-08 | 2012-06-07 | Dispositif electronique d'apprentissage personnel |
Publications (1)
Publication Number | Publication Date |
---|---|
EP2718920A1 true EP2718920A1 (fr) | 2014-04-16 |
Family
ID=46456838
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP12731517.4A Withdrawn EP2718920A1 (fr) | 2011-06-08 | 2012-06-07 | Dispositif electronique d'apprentissage personnel |
Country Status (4)
Country | Link |
---|---|
US (1) | US20140113265A1 (fr) |
EP (1) | EP2718920A1 (fr) |
FR (1) | FR2976391A1 (fr) |
WO (1) | WO2012168576A1 (fr) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104464424A (zh) * | 2013-09-18 | 2015-03-25 | 国家电网公司 | 游戏数据处理方法及装置 |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
AU2002361616A1 (en) * | 2001-11-13 | 2003-05-26 | Prometric Inc. | Extensible exam language (xxl) protocol for computer based testing |
-
2011
- 2011-06-08 FR FR1101752A patent/FR2976391A1/fr active Pending
-
2012
- 2012-06-07 EP EP12731517.4A patent/EP2718920A1/fr not_active Withdrawn
- 2012-06-07 US US14/124,417 patent/US20140113265A1/en not_active Abandoned
- 2012-06-07 WO PCT/FR2012/000228 patent/WO2012168576A1/fr active Application Filing
Non-Patent Citations (1)
Title |
---|
See references of WO2012168576A1 * |
Also Published As
Publication number | Publication date |
---|---|
US20140113265A1 (en) | 2014-04-24 |
WO2012168576A1 (fr) | 2012-12-13 |
FR2976391A1 (fr) | 2012-12-14 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20210124562A1 (en) | Conversational user interface agent development environment | |
US10608974B2 (en) | Computer-based authoring tool for narrative content delivered by an interactive message-based delivery system | |
US9031493B2 (en) | Custom narration of electronic books | |
Sheppard et al. | Beginning progressive web app development | |
US20170337841A1 (en) | Interactive multimedia story creation application | |
US20080028313A1 (en) | Generation and implementation of dynamic surveys | |
US20090083710A1 (en) | Systems and methods for creating, collaborating, and presenting software demonstrations, and methods of marketing of the same | |
Lal | Digital design essentials: 100 ways to design better desktop, web, and mobile interfaces | |
Rahman | Beginning Microsoft Kinect for Windows SDK 2.0: Motion and Depth Sensing for Natural User Interfaces | |
US10579220B2 (en) | Method and system for story development with a dynamic grid | |
Rodger | Beginning mobile application development in the cloud | |
Herman et al. | Instagram for business for dummies | |
Dawson | Future-Proof Web Design | |
EP3497674B1 (fr) | Système de composition ou de modification de séquences de réalité virtuelle, procédé de composition et système de lecture desdites séquences | |
US20210134177A1 (en) | System and method for displaying voice-animated multimedia content | |
Richards | Getting Started with Streamlit for Data Science: Create and deploy Streamlit web applications from scratch in Python | |
Negus | Linux Bible 2009 Edition: Boot Up Ubuntu, Fedora, KNOPPIX, Debian, OpenSUSE, and More | |
EP2718920A1 (fr) | Dispositif electronique d'apprentissage personnel | |
WO2013016707A1 (fr) | Applications interactives de contenu numérique | |
EP2489185B1 (fr) | Procede pour rajouter un contenu vocal a un contenu video et dispositif mettant en oeuvre le procede | |
KR20140075715A (ko) | 자전적 인터페이스 | |
Rossi et al. | The New Media Writing Prize Special Collection | |
Feiler | IOS App Development for Dummies | |
Coggan | Unity Game Audio Implementation: A Practical Guide for Beginners | |
Coepp | Introducing Qt 6 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
17P | Request for examination filed |
Effective date: 20131203 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
DAX | Request for extension of the european patent (deleted) | ||
17Q | First examination report despatched |
Effective date: 20160622 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN |
|
18D | Application deemed to be withdrawn |
Effective date: 20161103 |