Pour évaluer notre langage de modélisation M4L, nous l’avons utilisé pour modéliser plusieurs exemples d’interfaces mobiles multimodales. Ces exemples sont les versions mul- timodales des applications déjà existantes issues du projet MOANO ou des différentes « app- markets ». Ils regroupent les différents évènements d’interaction, la complexité des combi- naisons entre évènements d’interaction en entrée et en sortie et ne nécessitent généralement pas beaucoup de code fonctionnel (car ce sont les interfaces qui nous intéressent particuliè- rement, ici). Dans cette section, nous allons présenter trois exemples d’applications : « Mul- timodal Kitchen Unit Converter »1, « Drum Pad » et « Multimodal Google ! »2. Les autres exemples sont disponibles dans la documentation de l’approche3.
Multimodal Kitchen Unit Converter. Cette application aide à cuisiner. Elle permet la conversion des volumes (Pint, Quart, Tbsp, Tsp, Liter) et des poids (Lbs, Oz, Kg, Gram, Mg) pour les utiliser dans la cuisine et la pâtisserie.
1. https://play.google.com/store/apps/details?id=com.MultimodalKitchenUnitConvertermma (dernière consultation le 24/06/2014)
2. http://www.lifl.fr/~eloualin/mmgoogle.html (dernière consultation le 24/06/2014) 3. http://www.lifl.fr/~eloualin/tool.html (dernière consultation le 24/06/2014)
FIGURE6.1 – Le modèle de l’application « Multimodal Kitchen Unit Converter »
En plus du « touch » (pointage tactile), l’utilisateur de l’application peut parler, secouer (accéléromètre), masquer le capteur de proximité et orienter le téléphone vers le haut ou vers le bas afin de convertir les mesures (poids et volumes). Pour entrer une valeur dans l’appli- cation, l’utilisateur peut l’écrire en utilisant le clavier tactile ou dicter la valeur (en cliquant sur le bouton « - » du volume pour l’activer) s’il ne veut pas toucher l’écran. De même, l’utilisateur peut appuyer sur le bouton « Convert » ou secouer le téléphone pour obtenir le résultat. Enfin, pour passer du volume au poids (ou l’inverse), il peut appuyer sur le bouton « Weight » (ou « Volum ») en utilisant un « touch » ou bien en orientant le téléphone vers le bas (ou vers le haut) tout en masquant le capteur de proximité. En sortie, le système affiche les résultats des conversions. Les figures 6.1 et 6.2 montrent respectivement le modèle et des captures d’écran de l’application générée.
Dans cet exemple, M4L nous a permis de modéliser facilement les complémentarités entre l’orientation du téléphone et le masquage du capteur de proximité. Il a permis également la modélisation claire du dynamisme de l’application : les interactions de l’utilisateur final et les feedbacks système (les changements qui peuvent s’appliquer sur les zones d’édition et d’affichage des résultats).
FIGURE6.2 – Des captures d’écran de l’application « Multimodal Kitchen Unit Converter » sous Android
Ainsi, le seul code que le développeur/concepteur doit ajouter est le code fonctionnel de conversion (12% de l’application uniquement).
Drum Pad. Il s’agit d’une application pour créer de la musique avec « une batterie vir- tuelle » (un ensemble de fûts, cymbales, et autres percussions). L’utilisateur peut toucher (tactile) des boutons correspondant aux différentes percussions afin de créer une musique particulière, il peut secouer le téléphone et appuyer en même temps sur le bouton « + » du volume pour enregistrer sa musique et secouer en appuyant sur le bouton « - » du volume pour arrêter l’enregistrement.
Les figures 6.3 et 6.4 présentent respectivement le modèle et des captures d’écran de l’appli- cation.
Dans cet exemple, le secouage du téléphone a été modélisé une seule fois alors qu’il est utilisé dans deux complémentarités différentes (appliquées sur le même état). Cela montre un mécanisme de concision que le langage M4L propose pour réduire la complexité des mo- dèles et augmenter leur lisibilité.
L’application a été générée à 100% sur Android. Le concepteur/développeur devait juste ajouter les sons sous forme des fichiers mp3.
FIGURE6.3 – Le modèle de l’application « Drum Pad »
Multimodal Google. Cette application hybride permet d’utiliser le site web mobile Google d’une façon multimodale. L’utilisateur peut écrire un mot clé puis toucher le bouton « search » ou secouer le téléphone pour chercher les résultats. Il peut aussi couvrir le capteur de proxi- mité pour supprimer le mot clé écrit rapidement. Cependant, cette dernière interaction ne fonctionne que sous Firefox actuellement, car c’est le seul navigateur qui supporte le capteur de proximité.
Les figures 6.5 et 6.6 présentent respectivement le modèle et des captures d’écran de l’application.
Cet exemple nous a montré que M4L fournit la possibilité de modéliser des états externes de l’application. Cependant, la génération du code de passage vers ces états n’est actuelle- ment possible que pour les applications web.
FIGURE 6.4 – Des captures d’écran de l’application « Drum Pad » sous Android
L’application « Multimodal Google » a été générée à 100% en html5 et css3. Par contre, cer- taines retouches ont été ajoutées dans le fichier css afin de rendre l’interface graphique plus belle.
FIGURE6.6 – Des captures d’écran de l’application « Multimodal Google » sous HTML5
Ces trois applications, ainsi que les autres exemples modélisés, nous ont permis de vé- rifier l’efficacité de M4L quant à la modélisation des différents types d’interaction mobiles multimodales. Elles nous ont aussi permis de détecter les points forts et faibles du langage :
Les points forts :
– M4L modélise tout le dynamisme de l’application, c’est-à-dire les évènements d’inter- action en entrée et en sortie, ainsi que les retours d’information système. Cela donne une vue générale des interactions et augmente le pourcentage de génération de code de l’interface.
– Il présente un niveau d’abstraction élevé pour la gestion de l’aspect synchronisation temporelle (complémentarité, redondance, etc.).
– Il présente aussi certains mécanismes pour réduire la complexité des modèles (les états qui regroupent les évènements en sortie, la modélisation une fois des interactions uti- lisées plusieurs fois, etc.).
Les points faibles :
– M4L est basé sur un nombre important d’associations qui peuvent être difficiles à modéliser.
– Il ne modélise pas les aspects graphiques tels que les animations par exemple.