Étude de cas UX : du templating à la documentation technique
Factoriser l’interface pour définir l’API
TL;DR
Je propose au cours de cet article de parcourir étape par étape ma démarche design concernant la refonte UX d’une application pour tablette. Cette refonte passe par l’analyse de l’application existante et la considération des retours utilisateur, puis par itération par la refonte ergonomique de l’interface pour ensuite évoluer vers des gabarits (templates) et des modèles d’éléments. La particularité de cette démarche design se trouve dans l’élaboration parallèle d’une documentation technique paramétrant et rationalisant chaque élément de l’interface.
Je suis designer d’interaction depuis quelques années, en Diplôme Supérieur d’Arts Appliqués au Pôle Supérieur de Design de Villefontaine. Par passion, je suis également développeur web depuis 7 ans. Ainsi, mon profil de creative developer oriente ma manière de pratiquer le design et ce, selon moi, de façon positive. En effet, les logiques du code et de la programmation amènent à une perception rationnelle et pragmatique de ce qui nous entoure, autant dans la manière de qualifier les problèmes que dans les moyens à mettre en œuvre pour les résoudre.
L’étude de cas que je propose ici convoque explicitement ces deux aspects de mon profil : mes compétences en design et mes compétences en structuration de données. En marge du débat type “Should designers learn to code?”, ce projet est une démonstration parmi d’autres de la collaboration du design et du code au sein de la même pratique.
Pour ce projet nommé Ludomuse, j’ai été intégré dans l’équipe du centre d’innovation numérique Erasme aujourd’hui Service Usages Numériques de la métropole de Lyon. Patrick Vincent m’a initialement briefé puis accompagné tout au long de la démarche.
(Petit aparté vocabulaire)
Dans cet article, je vais utiliser des termes techniques qui ne sont pas systématiquement maîtrisés par tout le monde. Je vous propose ici quelques définitions et explications afin que vous puissiez apprécier l’article sans obstacle majeur.
UX : en anglais User Experience, ce terme cible l’expérience de l’utilisateur, sa manière d’utiliser une interface, ses ressentis, ses difficultés, son confort d’interaction, etc. Ici, la démarche UX consiste à optimiser l’expérience de l’utilisateur en simplifiant la navigation, en améliorant son appropriation de l’interface et en répondant à ses réels besoins et usages.
Template : ici, un template est un modèle d’organisation des éléments d’un écran. Par exemple, disposer six carrés en grille, à la suite ou placés aléatoirement sont trois templates différents ; nous pouvons aussi les nommer “compositions” ou “gabarits”. Dans ce projet, un template permet de placer des éléments de la même manière sur différents écrans en utilisant ce même template.
Production transversale : l’objectif de chacun des jeux de ce projet est d’accomplir une mission (trouver la recette de LU) en collectant des récompenses (les ingrédients) grâce à des mini-jeux. La production transversale est donc la collecte de ces récompenses tout au long de la session de jeu.
JSON : le JavaScript Object Notation est un format de données qui permet de transmettre des données d’un programme à un autre. Le JSON représente des tableaux ou des objets décrits sous forme de texte.
API : une interface de programmation permet à un programme de mettre à disposition certaines de ses données à d’autres programmes en vue d’une utilisation tierce. Par exemple, Facebook propose une API permettant à d’autres applications de connaître la liste de vos amis, les posts de votre mur, les pages que vous aimez, etc.
Objet : en programmation, un objet est une entité, une « chose », qui possède des propriétés la définissant. Par exemple, une voiture peut être de couleur rouge et avoir 5 places : en code, l’objet « voiture » possède deux paramètres « couleur » et « nombre de places » ayant pour valeurs respectives « rouge » et « 5 ».
Le projet Ludomuse, un moteur de jeux mobiles et collaboratifs
Les jeux mobiles et autres variantes de jeux de pistes se multiplient dans les musées et sont connus pour créer de la motivation auprès des plus jeunes. Toutefois, même si les jeunes publics utilisent ces dispositifs pendant de longues durées, ce n’est pas toujours au bénéfice de l’expérience de visite ou de l’acquisition de savoirs et de repères culturels.
Ludomuse veut s’appuyer sur la gamification des interactions physiques et interpersonnelles offertes par deux appareils mobiles en réseau, pour générer des démarches cognitives d’appropriation et de transmission culturelle.
Retenu dans de cadre l’appel à projet services culturels innovants 2014–2015 du Ministère de la Culture, le projet Ludomuse vise à produire une plateforme ouverte de jeux mobiles collaboratifs. Ce projet opensource permettra la réalisation de jeux interactifs destinés à plusieurs appareils connectés.
Deux premiers jeux sont actuellement testés au Château des ducs de Bretagne — musée d’histoire de Nantes — et au Musée Cernuschi — musée des arts de l’Asie de la Ville de Paris.
Analyse de l’interface existante
Ma démarche démarre par l’analyse de l’application actuelle. Cette application tourne sur plusieurs tablettes, de 5 à 7 pouces. Voici quelques interfaces utilisées dans l’application pour les expérimentations publiques d’un des jeux (le musée de la Biscuiterie LU) :
J’ai constaté une hétérogénéité majeure entre les différents écrans d’un même jeu : aucune structuration de l’information récurrente ne permet de poser une grille de lecture ni de guider l’utilisateur dans sa compréhension des contenus. Aussi, l’univers graphique choisi pour les écrans back-office (écran de connexion (fig. 1) et tableau de bord du jeu (fig. 2) se confronte à l’univers graphique prononcé du jeu (fig. 3, fig. 4, fig. 5). Ici, l’expérience utilisateur n’est pas considérée, au profit d’une démonstration technique de jouabilité ; choix qui se justifie bien sûr dans des contraintes de temps serrées et dans l’objectif d’expérimenter in situ.
J’ai alors imprimé en noir et blanc les storyboards et les écrans clés afin de les annoter avec post-it et marqueurs : c’est ici que sont nées les premières esquisses. Manipuler les interfaces papier implique une mise en espace où l’esprit et le corps s’impliquent dans la pratique, dans une approche quasi immédiate avec le support :
De mes analyses ont émergé des directives de réflexion :
- Expliciter et définir les typologies d’écran, puis abstraire les éléments structurels de l’interface : il s’agira de redessiner chaque écran pour modéliser des templates déclinables et d’unifier les éléments similaires ;
- Recentrer l’application sur la narration unique : il s’agira de focaliser l’application sur la narration de chaque jeu, la production transversale comme logique directrice ;
- Délimiter et rationaliser la personnalisation graphique du jeu : il s’agira de convertir l’application en un « outil » de mise en narration interactive de contenus : mises en page, cohérence visuelle, couleurs et images, structures et grilles, etc.
Distinguer les écrans pour les abstraire
Pour définir les typologies d’écran, j’ai mis à plat toutes les interfaces à disposition. Reprenons neuf écrans clés d’un jeu :
Chaque écran peut logiquement se placer dans un ordre chronologique suivant le storyboard du jeu. La structure d’une session de jeu comprend la configuration du jeu (inscription du pseudonyme du joueur, définition du rôle du joueur dans le jeu, choix du partenaire, lancement du jeu) puis un cycle répété de mini-jeux avec un retour permanent à la production transversale (tableau de bord) :
En considérant nos écrans clés, nous pouvons les regrouper sous ces trois catégories « Configuration du jeu », « Tableau de bord » et « Mini-jeu » :
On remarque toutefois une grande diversité d’écrans dans les mini-jeux. En effet, certains écrans affichent de l’information sans nécessiter d’interaction de l’utilisateur, d’autres au contraire requièrent cette interaction. On peut alors préciser la structure du mini-jeu en distinguant l’introduction qui contextualise le mini-jeu, l’interaction et la récompense :
Ce qui réorganise les écrans comme suit :
Dans la configuration du jeu se succèdent des écrans de saisie et des écrans d’information. Le tableau de bord synthétise la narration globale et est l’intermédiaire de chaque étape d’interaction. L’introduction et la récompense affichent de l’information, alors que l’interaction appelle l’implication de l’utilisateur. On peut donc affirmer trois typologies d’écran :
- L’écran d’information, qui affiche de l’information et structure la narration : il peut contenir du texte, de l’image ou tout autre support multimédia (vidéo, son) ;
- L’écran d’interaction, qui intègre le spectateur dans la production transversale et qui est par conséquent un écran de saisie d’information aussi en amont du jeu (pseudonyme, rôle, partenaire) ;
- Le tableau de bord, qui ancre chaque étape d’interaction (mini-jeu) dans une narration globale et qui permet à l’utilisateur de connaître sa progression dans la session de jeu.
L’écran d’information, moteur de la narration
Mon travail d’analyse des éléments individuels a commencé par l’écran d’information. Selon moi, cet écran a un véritable potentiel de déclinaison : position du texte, mise en valeur de l’image, variabilité du média. Voici une sélection de 9 écrans d’information extraits du storyboard du jeu de la biscuiterie LU :
Certains écrans présentent le texte sur une demie largeur, tantôt à gauche tantôt à droite voire sur la largeur totale de l’écran ; d’autres incrustent l’information dans un visuel (septième écran, « Victoire »). De même, l’instruction pour passer à l’étape suivante est présente sous ces deux formes, texte et image (premier écran, « Touchez pour commencer »). Une image mascotte placée en vis-à-vis accompagne ou non l’information.
Ces différentes compositions méritent donc une rationalisation structurelle pour les décliner selon une charte imposée, la volonté étant d’étendre les possibles tout en gardant une cohérence d’ensemble.
Ainsi, j’ai effectué des déclinaisons de disposition du texte dans l’écran, occupant un tiers, la moitié, deux tiers ou la totalité de la largeur. La question s’est posée de proposer également cette variabilité sur la hauteur du bloc texte : en effet, si l’image impactante occupe l’espace supérieur de l’écran, la juxtaposition du texte dans l’espace inférieur de l’écran semble judicieuse.
Afin d’éviter des contrastes insuffisants entre le texte et l’image en arrière-plan, j’ai proposé le cartouche : un filtre de couleur (noir ou blanc à ce stade de la démarche) à opacité réduite permettant d’optimiser la lisibilité du texte tout en l’intégrant dans l’esthétique graphique de l’écran.
Ainsi, le bloc texte peut s’assimiler à un « objet » disposant de différents paramètres :
- Son contenu, l’information textuelle
- Sa couleur de texte
- Sa largeur, limitée à quatre valeurs : 100%, 2/3, 50% et 1/3 de l’écran
- Sa hauteur, elle aussi limitée à quatre valeurs : 100%, 2/3, 50% et 1/3 de l’écran
- Son ancrage, sa position dans l’écran
- L’affichage ou non de son cartouche
- Si le cartouche est affiché, sa couleur de fond
En décrivant chaque paramètre et ses valeurs possibles, je tends à une conversion structurante des données pouvant être stockées numériquement dans un format de données tel que JSON. J’aborde plus bas dans cet article cette phase de documentation technique de la charte.
Le tableau de bord, cœur de la production transversale
Actuellement, le tableau de bord se structure en deux zones horizontales : la zone supérieure affiche les informations relatives à l’utilisateur de la tablette, donc son pseudonyme, une vignette de profil, le nombre de points accumulés durant la session de jeu et l’état de sa progression au sein d’une étape d’interaction. La zone inférieure affiche les informations du partenaire de jeu. Deux modes d’affichage sont disponibles : le premier n’affiche que les informations de l’utilisateur courant, le second permet une comparaison entre les deux joueurs. Les items de la chronologie sont composés de deux bulles : la première contient un aperçu de la récompense obtenue et la seconde permet d’afficher la consigne de l’étape d’interaction en la touchant sur la tablette :
On constate une volonté claire de mettre en avant la co-présence des deux joueurs sur une même interface ; cependant, la composition de l’écran n’est pas si pertinente avec beaucoup d’espace perdu, et l’intention perd de sa valeur. J’ai décidé de focaliser la nouvelle interface davantage sur la narration transversale. En effet, la quête de la session de jeu est l’élément moteur du dispositif : collecter toutes les récompenses pour achever la mission initiale. Cette transformation implique donc une valorisation des étapes d’interaction et donc des récompenses au sein du tableau de bord.
Recentrer l’application autour d’une expérience unique et collaborative plutôt que sur un outil technique de médiation narrative
Chaque récompense est désormais représentée sous forme de « carte ». Cette carte peut afficher un terme clé, une description, un visuel et une image de fond : la personnalisation de chaque carte est donc ouverte.
Pour les narrations non-linéaires (où les deux joueurs peuvent collecter les récompenses dans un ordre arbitraire), un principe d’affichage en cartes réduites est proposé :
Ainsi, selon la narration, la collecte des récompenses peut être motivée par la progression dans l’activité (temporalité) ou par la quantité restante pour achever la quête (espace). Un troisième affichage permet de s’adapter à un scénario géolocalisé dans le musée avec par exemple, une récompense dans chaque salle d’exposition :
Comment intégrer ces cartes dans le tableau de bord ? L’ancienne interface consacrait un tiers de la largeur de l’écran aux informations des deux joueurs. Or, sur une tablette inférieure à 6" proche de la phablet, l’espace est précieux : c’est pourquoi j’exploite la largeur totale de l’écran pour l’affichage des cartes.
Dans un premier jet du tableau de bord, je compose l’écran en trois espaces horizontaux : une barre supérieure informant des deux joueurs et de leurs scores avec l’objectif global, un espace central permettant de naviguer entre les cartes, et une barre inférieure contenant une vue globale de la session de jeu et le call to action principal « Jouer ».
Ce nouveau tableau de bord se concentre désormais sur les récompenses et sur l’activité-même, mais des espaces restent peu optimisés. En effet, pourquoi séparer les deux joueurs dans une situation de collaboration ? Aussi, l’espace en bas à gauche permet d’afficher des informations propres à chaque scénario, mais peut sans doute être amélioré.
Ici, les deux joueurs sont regroupés en haut à gauche, avec leurs scores confondus déporté en dessous des informations de la session de jeu. Après avoir observé une situation de test des deux tablettes, il s’est trouvé que les scores des deux joueurs sont identiques tout du long puisqu’ils participent aux mêmes mini-jeux. Ainsi, n’afficher qu’une seule valeur est moins perturbant pour la compréhension immédiate de l’interface et renforce la collaboration. Néanmoins, l’espace en bas à droite est inoccupé et le bouton « Jouer » en haut à droite est difficilement accessible d’une main.
Après diverses itérations et une recherche parallèle sur l’ergonomie de la navigation au sein de l’application (voir la prochaine partie de cet article), la barre supérieure a été placée en bas de l’écran, avec les joueurs, l’objectif du jeu et le call to action. Au dessus, une synthèse de l’activité permet aux joueurs de se positionner dans le temps, avec quelques informations annexes. Enfin, l’affichage des cartes est au cœur du tableau de bord. Dans une forme plus aboutie, l’affichage des pins sur une map permet de naviguer librement :
Améliorer l’ergonomie de la navigation
La structure d’une activité est simple : après la configuration du jeu se déroule une boucle répétée d’étapes d’interaction comprenant des écrans d’information et des écrans d’interaction. Des éléments de navigation permettent d’accéder à l’écran suivant, de revenir à l’écran précédent, de mettre en pause une vidéo ou un son ou encore depuis le tableau de bord de lancer le mini-jeu suivant. Actuellement, ces éléments de navigation sont graphiquement incohérents et inconstants :
Dans le premier écran, les deux flèches vertes permettent de revenir ou d’aller à l’écran suivant, alors que le bouton noir permet de mettre en pause le média. Dans le deuxième écran, la flèche à droite de l’écran permet de jouer au prochain mini-jeu. Chacun de ces éléments devrait avoir une uniformité pour être immédiatement assimilé par l’utilisateur comme des boutons d’action, des éléments interactifs qui attendent leur déclenchement.
À travers les différents écrans du jeu, j’ai souhaité imposer une grille unique pour la surcouche de navigation : cela signifie qu’une action destinée à avancer dans le temps sera placé au même endroit quelque soit l’écran, de même pour le retour dans le temps.
Cette grille est relativement simple : les deux boutons majoritairement présents dans l’application sont placés en bas à gauche et en bas à droite. Suivant le sens de lecture occidental, le bouton de droite permet d’avancer (« Suivant », « Jouer ») et le bouton de gauche permet de reculer (« Précédent »).
On constate ici que les boutons s’alignent sur la hauteur de la barre inférieure pour obtenir, quelque soit l’écran, un “bloc” de navigation optimal. Sur le deuxième écran, un bouton « Pause » est placé dans le coin supérieur gauche, avec la même esthétique que les boutons inférieurs. Tous les boutons sont en surimpression sur les écrans nécessitant une navigation pour conserver une unité.
Dans les éléments récurrents, les consignes des écrans d’interaction méritent également une rationalisation. Actuellement, la consigne est placée dans un cartouche personnalisé :
Cependant, l’absence de règles cadrant le contraste visuel, la taille et la couleur du texte peut mener à des dérives. C’est pourquoi un espace d’information similaire à la barre inférieure se place désormais en haut des écrans d’interaction :
Cet élément, également en surimpression, est stratégiquement placé au dessus du contenu afin de suivre l’ordre de lecture : la consigne puis les choix proposés. Cependant, on notera l’absence d’éléments de navigation « Précédent » ou « Suivant » : en effet, pour accéder à l’étape suivante, il faut répondre à la consigne, donc il faut interagir avec les choix proposés.
Éviter toute frustration de l’utilisateur en lui indiquant comment se comporter dans le musée et comment interagir avec l’interface
Sans indication ni légende, l’utilisateur peut être perdu, d’autant que le dispositif va aussi être utilisé par des profils peu ou pas habitués par le support numérique. De même, lorsque l’utilisateur répond faux ou doit effectuer une action indépendante de la tablette (échanger avec son partenaire, se rendre à un endroit du musée), une information doit figurer sur l’écran. Après avoir échangé avec Patrick, chef du projet Ludomuse, nous avons convenu de l’importance d’une information présente sur quasi tous les écrans indiquant à l’utilisateur quoi faire et comment, tel un assistant référant du comportement à adopter.
J’ai donc intégré ce nouvel espace d’information dans la grille, entre les deux éléments de navigation principaux dans la barre inférieure. Cet emplacement ne perturbe pas le sens de lecture de l’écran, et ajoute de la cohérence lorsque le call to action principal nécessite une action préalable pour être actif :
Cet espace d’information peut donc coexister en vis-à-vis avec la consigne ou sur un écran d’information. Aussi, puisque l’utilisateur joue avec son partenaire, des soucis de connectivité peuvent se manifester, ou un joueur peut avoir à attendre si son partenaire est en retard dans la lecture des écrans : dans ces cas, il faut que l’utilisateur soit notifié. Nous pouvons alors facilement ajouter une information guidant l’utilisateur conformément à notre charte.
Pour anticiper le maquettage graphique (UI), j’ai considéré la superposition des éléments de navigation : les boutons d’action sont placés au plus près de l’utilisateur sur l’axe Z et ne peuvent être recouverts par aucun autre élément. Pour contrôler graphiquement cette superposition, les boutons chevauchent en offset la zone d’information. Puisque les extrémités des boutons et de cette zone sont obliques, l’œil est naturellement orienté vers l’élément de navigation principal :
Pour accompagner ces informations, un registre de pictogrammes sera proposé avec la charte et la documentation technique. Ces pictogrammes regroupent les indications d’interaction (toucher, faire glisser, déplacer), les indications d’état de l’utilisateur (écouter, parler, se déplacer, attendre) et les indications callback (réponse juste, réponse fausse, récompense obtenue). À priori, ces images seront communes à tous les jeux, donc propre au moteur Ludomuse, afin de conserver une constance entre chaque application. Ce choix sera remis en question dans les phases ultérieures du projet.
Intégrer la configuration du jeu dans l’expérience fluide de l’utilisateur
Les anciennes interfaces des écrans de configuration n’étaient pas optimisées pour une expérience agréable et fluide de l’utilisateur. En effet, les interactions étaient très techniques et peu adoucies par leur formalisation visuelle :
Dans l’ordre, l’utilisateur entre son pseudonyme, valide, définit son genre, attend la détection des tablettes alentour, sélectionne son partenaire, définit son rôle, valide et attend son partenaire ; une fois la synchronisation réussie, le jeu est lancé.
L’utilisateur arrive donc directement sur un champ de saisie. Ici, ce champ est trop petit et peu mis en valeur par la composition de l’écran. De même, le bouton de validation n’est pas dans le même espace que le champ, séparés entre eux par deux fonds colorés distincts.
Puisque cet écran est relativement vide, je propose d’intégrer également le choix du genre. Je profite de la charte pour rappeler en haut l’étape de configuration (d’ailleurs, il serait judicieux de préciser « Étape 1/3 » afin de canaliser davantage la patience de l’utilisateur) et en bas l’interaction attendue par l’interface. Le sens de lecture propose un schéma question/réponse : « Quel est ton nom ? » auquel l’utilisateur répond grâce au champ de saisie. Le bouton « Suivant » est présent mais inactif tant que le champ est vide : ceci lui permet d’assimiler l’action prochaine à effectuer aidé par le texte informatif dans la zone inférieure.
Le choix du genre aurait pu être le bouton de validation : dès lors que j’ai entré mon prénom et que je touche « Femme » ou « Homme », je n’ai plus d’information à apporter sur cet écran, donc je passe à l’écran suivant. Ce scénario a été prototypé dans la phase itérative pour chaque écran de configuration, et l’expérience se trouvait moins fluide. En effet, l’utilisateur ne sachant pas où toucher d’abord, puis constatant la transition « surprise » au prochain écran, se sentait frustré de réapprendre à chaque fois la structure du nouvel écran pour progresser. En imposant un bouton « Suivant » constant sur tous les écrans de configuration, l’utilisateur n’a aucun effort à fournir pour naviguer dans l’application et l’expérience est fluidifiée.
J’ai placé le choix du rôle à la suite, extrait de l’écran de choix du partenaire. Dans le dispositif, chaque joueur peut avoir le rôle du « petit » ou du « grand ». Cette précision conditionnera la facilité des mini-jeux, l’affichage d’une bulle d’aide et la répartition des interactions lors des collaborations. Cet écran permet donc de définir son rôle avant de sélectionner son partenaire, puisque son propre rôle n’évoluera pas selon le partenaire. De plus, les écrans de configuration suivent désormais une logique : d’abord les informations personnelles (pseudonyme, genre), puis le rôle dans le jeu (auto-conversion dans l’univers du jeu) et enfin le choix du partenaire (immersion dans le jeu) pour démarrer.
L’étape 3 consiste à choisir son partenaire parmi les tablettes présentes autour de l’utilisateur. Un écran de substitution accompagne l’utilisateur avec une indication de l’action en cours. J’ai volontairement omis le bouton « Actualiser » car il fait doublon à l’actualisation automatique en arrière-plan et il relève d’un fait technique que l’utilisateur n’a pas à maîtriser.
Pour anticiper la mise en place future du dispositif dans les musées, j’ai ajouté un écran au démarrage de l’application, avant que l’utilisateur n’entre son pseudonyme. Cet écran permet d’introduire l’utilisateur au contexte du jeu, et Patrick m’a pertinemment orienté vers un écran personnalisable par le musée parent du dispositif. Ainsi, un message de bienvenue par le musée ainsi qu’une image (son logo ou une photographie) permettent d’affirmer le début de l’expérience de l’utilisateur.
Moduler et abstraire : du design au code
En parallèle de cette démarche UX, j’ai pris en compte la phase de développement et de mise en œuvre technique de ces nouvelles maquettes. Tout au long des itérations, l’objectif était de simplifier mais aussi de faire émerger des similarités entre les éléments et entre les typologies d’écran pour simplifier leur intégration. En effet, le jeu est développé à l’aide d’un framework C++ (Cocos2D) : c’est pourquoi j’ai défini des entités, des objets structurés pour être déclinables et paramétrables.
Sur les écrans d’information, on remarque la présence récurrente d’un texte, d’un espace d’information dans la zone inférieure de l’écran ainsi qu’un ou deux éléments de navigation. Chaque entité est donc devenu un modèle :
TextItem
Le texte est considéré comme un objet TextItem qui prend comme paramètres son contenu, sa largeur, sa hauteur, son ancrage, l’affichage ou non de son cartouche, et la couleur de son cartouche.
Pour chaque objet, je définis le type de la valeur que prend chacun de ces paramètres, et les possibles valeurs. Des valeurs par défaut sont héritées des méta modèles (voir la partie suivante de cet article). Pour préciser : le tableau ci-dessus est également fourni comme livrable aux développeurs.
NavItem
Chacun des boutons de navigation est considéré comme un objet NavItem, qui prend pour paramètres son contenu, son icône, son ancrage dans l’écran, la couleur de son texte quand l’élément est actif ou inactif, sa couleur de fond quand l’élément est actif ou inactif ainsi que son état ici encore actif ou inactif. Avec toutes ces combinaisons, il est possible de décliner tous les boutons de navigation nécessaires dans l’application pourtant hérités du même modèle.
InfoItem
Les espaces d’information ancrés en haut ou en bas de l’écran recouvrent les mêmes paramètres d’affichage, à savoir leur contenu, leur position et leur icône si présente, et peuvent donc se regrouper sous l’objet InfoItem.
FieldItem
Les écrans d’interaction intègrent aussi des NavItem et des InfoItem. Il faut définir des modèles pour les éléments interactifs. On pourrait avoir un objet pour chaque typologie de champ : bouton, champ texte, élément draggable, élément droppable, multichoix… Pour factoriser au mieux, j’ai déclaré un objet FieldItem qui est parent de tous les types de champ. Il sera possible pour les développeurs de créer des objets enfant pour chaque type héritant de FieldItem.
FieldSet
Pour définir la grille d’affichage des FieldItem sur chaque écran, un objet invisible parent nommé FieldSet les englobe. Sa structure est donc très simple :
RewardItem
Le tableau de bord synthétise les récompenses obtenues et à obtenir pour poursuivre l’activité. Puisque ces éléments sont récurrents, nous les interprétons en tant qu’objets par des RewardItem. Ces objets définissent leur contenu, leur couleur de fond, leur image de fond, leur description et leur état (obtenu ou à obtenir).
MediaItem
Un autre objet est proposé pour ajouter des images, des vidéos, des intégrations (embed) de cartes géographiques ou des sons. L’objet MediaItem permet donc d’intégrer des ressources audiovisuelles, prenant notamment pour paramètres son type de média, sa source et sa position dans l’écran.
De la v1… à la v1.0.1
Une démarche de documentation amène inévitablement aux requestionnements des conventions d’écriture, des constantes à utiliser et des améliorations des structures. Après avoir appliqué mon modèle à quelques écrans, j’ai remarqué plusieurs optimisations allant dans le sens d’un système de template JSON (voir la partie suivante de cet article). C’est pourquoi les suffixes Item de tous les objets (TextItem, InfoItem, RewardItem) sont retirés. Cela permet d’une part de simplifier les nomenclatures, et surtout d’être strictement plus rigoureux : en effet, un RewardItem n’est pas qu’un item visible sur l’écran mais est un objet contenant des données. Un Reward est donc plus générique.
Aussi, l’objet MediaItem est maintenant décomposé en Image, Video, Sound et Embed pour simplifier leur mise en place technique. L’objet FieldItem est reconsidéré en tant que champ de saisie uniquement sous le nom Input. Pourquoi ? En parcourant les divers scénarios et les différentes briques d’interaction, j’ai remarqué que n’importe quel élément peut « devenir » interactif : une vidéo à déplacer dans une zone, une image à replacer dans un puzzle, un son à partager à son partenaire, etc. Appliquer des paramètres supplémentaires à FieldItem, alors méta modèle, n’aurait pas été pertinent. Par conséquent, tous les objets pourront être interactifs : touchables, déplaçables, cochables, etc.
Les tableaux techniques sont mis à jour et sont accompagnés d’une documentation linéaire, expliquant le rôle de chaque paramètre et présentant la structure JSON par défaut de chaque objet. Dans la prochaine partie, j’expliquerai le principe de surcouche et l’attribution des valeurs par défaut.
La manière de structurer les données en JSON a été également revue pour adopter les modèles de template. L’ancienne structure déclarait l’application (app) et ses paramètres (couleurs, images, sons), puis déclarait en enfant les écrans (screens) avec pour chacun leurs paramètres, et dans chaque écran étaient déclarés les éléments affichés à l’écran (items) avec leurs paramètres également. La relation hiérarchique était donc : app > screens > screen > items > item.
La nouvelle structure modifie l’indexation des éléments et ajoute la dimension des templates, comme ceci : app > screens > navigation + information + content > elements > item.
Désormais, chaque écran est séparé en trois plans :
- Les éléments de navigation qui sont au premier plan et conditionnent la manière de naviguer d’un écran à l’autre ;
- Les éléments d’information qui guident l’utilisateur dans les actions à effectuer pour interagir et naviguer ;
- Les éléments de contenu qui sont manipulables ou non par l’utilisateur et qui formalisent l’écran.
Chacun de ces plans peut se baser sur un template JSON en appelant son identifiant : ainsi, les éléments instanciés sont intégrés dans le template. Pour aller plus loin, je vais expliquer le modèle de templating proposé.
Générer des templates pour décliner des écrans
On a déjà identifié trois typologies d’écran (information, interaction, tableau de bord) mais on peut constater des compositions d’écran similaires. Ces similarités se justifient par la récurrence de briques d’interaction (puzzle, transfert d’images au partenaire, quiz) ou de nombre de contenus.
Les templates permettent donc d’utiliser des structures communes pour décliner plus rapidement les écrans de jeu. Par exemple, en fournissant neuf images au template créé pour le puzzle, les contenus sont automatiquement mis en page dans une grille avec les éléments prêts à être manipulés par l’utilisateur.
Nous avons adapté la structure des données pour les utiliser avec des templates : il faut maintenant définir la structure de ces templates.
Chaque template est identifié par un nom slug (identifiant sans accent ni caractère spécial) et détaille les éléments présents à l’écran. Chaque élément est une entité dont le type est précisé (Text, Reward, Grid…) et dont les paramètres adaptés au template sont précisés. Ainsi, par exemple, chaque élément du puzzle est défini par le template comme étant organisé dans une grille. Cela permet aussi d’affecter techniquement des événements aux éléments interactifs afin de vérifier leur position et de valider le puzzle.
Chaque entité déclarée dans un template dispose d’un identifiant unique, ce qui lui permet d’être substituée par l’objet instancié dans la définition de l’écran. Autrement dit, le template crée un objet paramétré (a) ; un élément (b) défini dans la structure de l’écran peut prendre le rôle de (a) en héritant de ses paramètres vi un connector commun ; (b) peut même ajouter ou écraser des paramètres hérités de (a) — ici, (b) ajoute les paramètres snap et alignItems et écrase la valeur de cols pour devenir 2 au lieu de 3. Ainsi, le template propose une structure prédéfinie mais modulable.
Prenons maintenant l’exemple d’un template destiné à un écran d’information composé d’un texte et d’une image : ce type de structure est récurrent dans la narration d’un jeu, avec une mascotte en vis-à-vis d’une information. On a donc cette structure de template :
Ce template paramètre par défaut le texte à droite et l’image à gauche. Pourtant, certains écrans peuvent placer la mascotte à droite et le texte à gauche. Dans ce cas, un deuxième template peut être utilisé. Sinon, et c’est une fonctionnalité permise par l’héritage des paramètres, ce même template peut être décliné comme ceci :
L’ancrage du texte et la position de l’image sont surcouchés par la structure de données et écrasent les paramètres définis par le template. Avec le même template, on obtient donc deux déclinaisons. La surcouche est aussi utilisée dans l’application pour l’attribution des valeurs par défaut : couleurs des éléments, comportements, positions, etc.
Un des objectifs de cette démarche design est d’optimiser la production des jeux pour Ludomuse en automatisant les actions d’uniformisation et de stylisation des écrans. C’est pourquoi dès la création d’un jeu, des variables sont à définir. Par exemple, la couleur principale du jeu une fois précisée génère automatiquement les couleurs associées (tons clairs, tons sombres) et les attribue aux éléments de l’application. Ainsi, quasi tous les éléments sont colorés dès la création du jeu. Par conséquent, chaque typologie d’objet hérite de ces couleurs attribuées, mais il est possible de surcoucher indépendamment chacun de leurs paramètres. Il est donc possible de remplacer la couleur compilée des boutons de navigation par une autre couleur définie par la définition globale de l’objet Nav. Bien sûr, un élément peut aussi surcoucher ses paramètres lorsqu’il est instancié dans la structure de données. Pour résumer, notre surcouche en cascade fonctionne ainsi :
Développer des outils pour faciliter la prise en main de la nouvelle charte
Au terme de la démarche, j’ai pris conscience de l’ampleur des modifications sur le projet. En effet, le cœur du système doit être quasi entièrement repensé pour comprendre des objets, pour intégrer les templates et pour adapter les scénarios existants. Avant de briefer les développeurs, j’ai développé en plus de la documentation deux outils leur permettant de prendre en main le plus efficacement possible la nouvelle architecture de données.
Le premier outil permet de générer la structure de données JSON d’un écran via une interface. Dans chacun des trois plans de l’écran, on peut ajouter un objet en le sélectionnant dans une liste : cet objet s’ajoute alors comme item et se génère en JSON dans l’espace de droite. Dans une utilisation plus avancée, le JSON de l’objet peut aussi être modifié et personnalisé :
Cet outil est placé sur le GitHub du projet et permet aux développeurs d’accéder aux JSON par défaut de chaque objet en plus de les trouver dans la doc :
Le second outil permet aux développeurs de générer une palette par défaut suivant une seule couleur principale. Cette couleur est alors traitée automatiquement afin de générer des tons plus clairs et des tons plus foncés attribués aux éléments de l’écran :
Un aperçu rapide en CSS permet de prévisualiser les éléments, et un code JSON est généré pour être placé dans l’en-tête de l’app.
Conclusion
Après la présentation de cette nouvelle architecture, les développeurs se sont montrés satisfaits et se lancent dans le développement dans quelques semaines. En parallèle, les acteurs des musées qui créent les scénarios et donc les écrans de jeu sont aussi enthousiastes et se réjouissent de la rationalisation des éléments méta (la consigne en haut, l’ordre/indication en bas, les éléments latéraux de navigation).
J’ai souhaité vous partager cette démarche design car elle a convoqué diverses compétences et des moyens complémentaires pour l’aborder. Il y a bien sûr des points à revoir, des choix à optimiser, des détails à peaufiner, et cet article est aussi pour moi un moyen d’avoir un retour réflexif sur ma propre pratique. J’ai la chance de pouvoir suivre le projet Ludomuse en 2016 au cours de ma mission chez Erasme, dans l’objectif d’assister aux retours utilisateurs.
Merci à vous d’avoir lu cet article (ou d’avoir scrollé pour arriver jusqu’ici, au choix) ; n’hésitez pas à annoter l’article pour toutes vos remarques, et suivons-nous sur Twitter pour échanger plus directement :)
Twitter : @kevinvennitti
