Mon poste de travail : des marqueurs, des ardoises, du papier, des croquis, ma tasse et mon sablier

Étude de cas UX : du templating à la documentation technique

Factoriser l’interface pour définir l’API

TL;DR

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)

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

Crédits : © Erasme

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.

(Présentation du projet extraite du site d’Érasme)

Analyse de l’interface existante

Dans l’ordre : écran de connexion (fig. 1), tableau de bord du jeu (fig. 2), écran de jeu récepteur (fig. 3), écran de jeu avec volet latéral ouvert (fig. 4), écran de jeu émetteur (fig. 5)

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

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

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.

Dans l’ordre : deux écrans d’information sans cache, écran affichant un média vidéo, écran avec cache blanc

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

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

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.

Scénario du choix du partenaire : quatre états successifs, avec pour chaque une posture attendue différente (attendre, choisir, valider, attendre)

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

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

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

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

InfoItem

FieldItem

FieldSet

RewardItem

MediaItem

De la v1… à la v1.0.1

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.

Ancien modèle de structure JSON de l’application

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

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

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

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

Design technologist & UX interactive designer

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store