Organisation globale de MIRLEGADEE

5.4.1 Navigation ... 177 5.4.2 Mur d’idées /Ideas Wall ... 178 5.4.3 Global specifications ... 179 5.4.4 Scénario ... 186

5.5 Implémentation de MIRLEGADEE ... 189

5.5.1 Le langage de programmation ... 189 5.5.2 Formats des fichiers de sortie ... 189 5.5.3 Accès à MIRLEGADEE à partir de LEGADEE ... 189 5.5.4 Architecture de MIRLEGADEE ... 190

5.6 Le processus de conception de MRLG à travers MIRLEGADEE ... 190 SYNTHESE ... 192

MRLG

5.1 Rappel des verrous identifiés et objectifs de l’environnement auteur

Notre prototype MIRLEGADEE (MIxed Reality LEarning GAme DEsign Environment) vise à mettre en œuvre les propositions faites au Chapitre 4, en réponse aux problèmes identifiés dans la conception de MRLG. Il intègre donc le modèle de description f-MRLG (décrit dans la section 4.3) et les aides à la créativité (décrites dans la section 4.4), et répond aux mêmes objectifs. Mais nous pouvons au travers de cet environnement auteur dépasser les limites du modèle, soulevées avec l’évaluation de f-MRLG au Chapitre 4, et apporter des aides supplémentaires aux concepteurs. Le tableau suivant récapitule les problèmes auxquels sont confrontés ces derniers au cours de la conception de MRLG, et de quelle façon nous proposons d’apporter des réponses à ces problèmes avec MIRLEGADEE :

Verrous dans la conception de

MRLG ^{Réponses apportées par MIRLEGADEE}

Identifier et définir clairement ses besoins ou le projet (verrou décrit en 2.6.1). Pour cela, les concepteurs doivent connaître tous les éléments à définir. De plus, puisqu’il existe diverses situations de conception de MRLG, chaque équipe doit pouvoir aborder la conception en fonction de ses priorités.

L’environnement s’articule autour du modèle de description f-MRLG, décrit dans la section 4.3. La présentation des éléments du modèle est un moyen pour le concepteur de penser à tous les aspects à définir. L’outil doit être flexible pour soutenir les différentes situations de conception.

Explorer (verrou décrit en 2.6.2) et générer des idées (verrou décrit en

2.6.3). Étant donné les nombreuses

dimensions d’un MRLG, chaque concepteur ne peut connaître tous les domaines.

MIRLEGADEE guide les concepteurs en leur présentant les aides à la créativité définies dans la section 4.4. Il les aide ainsi dans l’exploration des solutions possibles. La description de types de jeu, ainsi que la présentation d’exemples d’utilisation de dispositifs, servent de sources d’inspiration pour les concepteurs.

Vérifier, faire des choix cohérents (verrou décrit en 2.6.4). Le concepteur doit évaluer la cohérence des idées proposées avec les contraintes et solutions déjà choisies. Il doit ainsi utiliser les ressorts de jeu et les systèmes de RM à bon escient pour favoriser l’apprentissage.

MIRLEGADEE inclut les recommandations définies dans la section 4.4. Celles-ci aident les concepteurs à faire des choix cohérents en leur donnant des informations sur la pertinence des éléments concernés (les types de jeux et systèmes de RM). De plus, la création d’un schéma définissant la position des participants et dispositifs de RM facilite la vérification des choix représentés. En réalisant ce schéma, les concepteurs vont identifier les incohérences, ou au contraire valider l’ensemble.

MRLG

Verrous dans la conception de

MRLG ^{Réponses apportées par MIRLEGADEE}

Structurer les idées, organiser leur représentation (verrou décrit en

2.6.5)

Les idées du concepteur sont structurées par le modèle sous-jacent f-MRLG, qui permet une représentation structurée, complète et claire du MRLG.

Communiquer (verrou décrit en

2.6.6) avec d’autres concepteurs

issus de domaines différents et avec l’équipe de réalisation.

MIRLEGADEE reprend le vocabulaire défini par le modèle f-MRLG. De même que le modèle, l’environnement auteur fournit donc un vocabulaire commun à une équipe de conception.

L’environnement auteur permet de formaliser les idées des concepteurs pour l’équipe de réalisation. L’export dans un format xml (exécutable par un moteur d’exécution adapté) facilite le travail de réalisation.

Etre guidé dans le processus de conception (verrou décrit en 2.6.7)

L’environnement auteur accompagne le processus de conception que nous avons modélisé en 2.4. Il s’agit donc de soutenir une conception itérative grâce à un outil flexible.

Tableau 14 - Verrous dans la conception de MRLG et réponses apportées par MIRLEGADEE

5.2 Extension d’un environnement auteur existant

Nous choisissons de repartir de l’environnement auteur LEGADEE (Marfisi-Schottman, 2012) et de l’adapter pour en faire un environnement auteur soutenant la conception des MRLG. Nous présentons dans cette partie les raisons de ce choix, puis revenons sur des éléments de LEGADEE (déjà présenté en 3.1.1.1) afin de préciser ce que nous conservons et ce que nous modifions.

5.2.1 Justification du choix de LEGADEE

LEGADEE constitue une base de départ intéressante par rapport à nos propositions car il se base sur un modèle de scénarisation que nous avons en partie repris pour proposer f-MRGL (voir section 4.2). En particulier, nous réutilisons la modélisation parallèle d’un scénario pédagogique et de la mise en scène ludique, prévue pour les LG informatisés mais aussi pertinente dans le cas de MRLG.

Nous avons présenté et analysé les atouts et limites LEGADEE pour la conception de MRLG dans l’état de l’art, section 3.1.1.1. Il ressort de cette analyse que LEGADEE donne une bonne vision globale du scénario et permet

aux concepteurs de LG de structurer et de formaliser leurs idées. Mais la scénarisation détaillée doit être adaptée. En effet, les écrans (niveau le plus précis de la scénarisation ludique) sont conçus pour scénariser uniquement des interactions de navigation dans des écrans et doivent donc être modifiés pour prendre en compte les interactions en Réalité Mixte. De plus, nous avons besoin de compléter LEGADEE en amont de la scénarisation afin que les concepteurs puissent décrire des éléments du contexte de manière plus précise, sur le modèle des spécifications globales de f-MRLG (décrites en 4.3.1). Nous présentons dans la partie suivante (5.2.2) comment ces éléments peuvent être ajoutés ou adaptés. La reprise de LEGADEE présente aussi quelques inconvénients. En effet, comme tous les environnements informatiques, LEGADEE contraint la conception. Ce problème a déjà été soulevé par Shipman & Marshall (1999), qui mettent en évidence les problèmes liés à la manipulation d'outils numériques de manière générale. Ils mettent par exemple en avant l'effort de formalisation que ces outils induisent, lorsque les utilisateurs doivent accomplir certaines tâches prématurément comme nommer un fichier avant d’avoir une idée claire de son contenu. De manière similaire, LEGADEE impose de construire la structure globale du scénario (niveau modules et missions) avant de détailler le contenu (création de niveaux inférieurs du scénario). Nous ne pouvons modifier cet aspect de l’outil.

Un autre point bloquant identifié est la limitation du nombre de niveaux de granularité proposé, qui est fixé à 3. Dans les résultats de l’évaluation de notre modèle quelques participants ont précisé que le nombre de niveaux imposé dans le scénario était trop grand pour la tâche demandée (voir la section 4.5.5.1). De manière plus générale, il nous semble que les MRLG sont très différents de l’un à l’autre, et nécessiteraient un nombre indéfini de niveaux (qu’il soit supérieur ou inférieur à 3). Mais ce système de niveaux indéterminé est a priori difficilement conciliable, d’un point de vue utilisabilité, avec la description simultanée d’un scénario pédagogique et d’un scénario ludique.

En résumé, malgré quelques limites, reprendre LEGADEE plutôt que de commencer le développement d’un nouvel outil nous permet de nous concentrer sur les problématiques spécifiques à la conception d’un MRLG.

5.2.2 Eléments de LEGADEE à adapter

L’environnement auteur MIRLEGADEE est une extension de LEGADEE (Marfisi-Schottman et al., 2010). LEGADEE (LEarning GAme DEsign Environment) est un environnement d’aide à la conception de Learning Games informatisés qui reprend les 7 étapes de la conception d’un LG définis par Marfisi-Schottman (voir section 2.2.1.1). Ces étapes sont accessibles par un menu en haut de l’environnement de conception, visible dans la Figure 89. En cliquant sur une étape, les concepteurs ont accès à une description de celle-ci et aux outils spécifiques destinés à la réalisation des tâches qui la composent. L’ordre de ces étapes n’est pas imposé mais simplement suggéré.

MRLG

Figure 89 - Menu de LEGADEE pour les étapes de la conception

Nous avons identifié dans la section 2.3.5 que des différences existent entre ce processus de conception de LG informatisés et celui des MRLG. En particulier, pour un MRLG, les objectifs d’apprentissage ne seront pas toujours définis avant les éléments de jeu. Nous ne proposons pas non plus de composants réutilisables. En conséquence, le menu de navigation de LEGADEE n’est pas adapté à la conception de MRLG. De plus, un de nos objectifs est d’avoir un outil flexible, qui autorise la complétion des idées dans un ordre indéterminé a priori, afin d’assister toutes les situations de conception et de favoriser un processus de conception itératif. Or, la présentation d’étapes dans le menu incite les concepteurs à suivre la progression proposée et freine les itérations, même si rien ne les bride techniquement. Nous préférons donc proposer une approche différente, en choisissant de privilégier l’accès à tous les niveaux de description nécessaires à un MRLG. Nous construisons donc le menu de MIRLEGADEE autour de la partie scénario de LEGADEE, en ajoutant un accès à la partie amont de la conception, correspondant au niveau « spécifications globales » du modèle f-MRLG (décrit dans la section 4.3.1). Nous précisons de quelle manière cette partie, inexistante dans LEGADEE, est ajoutée par rapports aux pages existantes dans la section 5.3.

Pour la description du scénario, LEGADEE repose sur un modèle de scénarisation qui met en parallèle la structuration pédagogique, se décomposant en trois niveaux de granularité : Module, Acte et Activité, et la mise en scène ludique découpée en Mission, Séquence et Écran. L’interface de LEGADEE pour la scénarisation est illustrée Figure 56. Comme déjà précisé plus haut, les écrans doivent donc être modifiés car ils ne sont pas adaptés à la description d’interactions de RM (Figure 90). En effet, un écran inclut un titre, une image et une description. Si par exemple nous devons décrire l’interaction : « prendre une photo du QRcode matérialisant le checkpoint, au moyen de la caméra du smartphone », nous utiliserons certainement le titre « prendre une photo du QR code », mais l’image sera inutile et le concepteur ne sera pas guidé dans la

description de l’interaction et ne sera peut-être pas clair. Dans MIRLEGADEE, nous remplaçons donc les écrans, non adaptés, par des actions telles que décrites dans le modèle f-MRLG (voir section 4.3.2). Pour le même exemple, le concepteur définirait donc une action utilisateur ayant pour titre « prendre une photo », l’outil utilisé « appareil photo du smartphone », l’objet de la tâche « QRcode » et éventuellement une description plus précise comme le but de l’action, c'est-à-dire « définir où l’utilisateur se trouve pour provoquer l’affichage d’informations contextuelles ». Les actions sont illustrées par la Figure 103.

Nous conservons les autres éléments du scénario.

Figure 90 - Ecran (dernier niveau de la mise en scène ludique) dans LEGADEE

5.3 Organisation globale de MIRLEGADEE

Comme précisé dans le paragraphe précédent, nous basons le menu et donc l’architecture de notre environnement sur le modèle de description f-MRLG (décrit en 4.3). La Figure 91 présente l’organisation globale de MIRLEGADEE. Les couleurs indiquent ce qui est identique à LEGADEE (en vert), ce qui est légèrement modifié (en jaune), et les ajouts (en orange).

Comme le montre la Figure 91, la création de MRLG se fait depuis la page d’accueil de LEGADEE. Le concepteur peut, lors de la création d’un LG, préciser le type de celui-ci, c'est-à-dire indiquer si le jeu créé est un LG ou un MRLG (voir Annexe V). La sélection du type de jeu MRLG conditionne ensuite l’ouverture de MIRLEGADEE.

Nous avons vu dans le Chapitre 2 que les concepteurs ont besoin de représenter le MRLG de manière formelle, mais aussi de manière informelle. De plus, l’environnement auteur Adventure Author (Robertson et Nicholson, 2007), présenté en 3.3.2, illustre ce besoin puisqu’il inclut une mini-application pour écrire les idées sous forme de post-it. Ainsi, nous créons en amont du scénario une page dédiée aux idées « en vrac » : un mur d’idées. Les autres pages de conception, spécifications globales et scenario, correspondent au découpage du modèle f-MRLG. Les concepteurs peuvent naviguer librement entre ces trois

MRLG

grandes catégories de pages (mur d’idées, spécifications globales, et scénario), ce qui a pour but d’accompagner un processus de conception itératif.

Figure 91 - Architecture de MIRLEGADEE par rapport à l'environnement existant LEGADEE