Bibliothèque des types d’évènements d’interaction

Lors de la définition de notre langage de modélisation M4L, nous avons rencontré le pro- blème de précision des évènements d’interaction en entrée et en sortie (chapitre 4, section 4.2). Pour résoudre ce problème, nous avons décidé de permettre la précision des évènements au niveau modèle en utilisant une bibliothèque.

FIGURE5.25 – Les sections de la palette de modélisation

Cette bibliothèque fournit les différents types d’évènements d’interaction qui peuvent être utilisés par un simple glisser-déposer à partir de la palette de l’environnement de modéli- sation de MIMIC [36]. Elle permet non seulement aux concepteurs d’identifier les types d’évènements possibles, mais leur fournit aussi des modèles réutilisables modélisant ces évènements.

Nous avons défini les éléments de la bibliothèque en deux étapes. Premièrement, nous avons identifié et testé les différents types d’interaction basés sur chaque capteur en entrée ou en sortie. Puis, en deuxième étape, nous avons préparé des modèles prêts à l’emploi qui modélisent les évènements utilisant ces différents types d’interaction. Pour créer ces mo- dèles, nous avons adopté le principe des modèles paramétrables (des templates de modèles) qui n’encapsulent pas de code, mais créent des instances avec des propriétés pré-remplies de certains concepts et associations. La bibliothèque contient actuellement 34 types d’évène- ments en entrée et 54 en sortie (dont 50 sont des widgets). Bien sûr, elle n’est pas exhaustive et d’autres types peuvent être intégrés.

5.1.3.1 Types d’évènements en entrée

Dans le chapitre 2 (tableau 2.3), nous avons donné une description complète de capteurs sur mobile (pour l’année 2013-2014). Nous avons aussi listé quelques types d’interaction qui peuvent être créés à base de ces capteurs (les « types d’évènements »). Pour créer notre bibliothèque, nous avons commencé par l’implémentation et le test de ces types d’interac- tion. L’implémentation était principalement sous Android, car c’est la plateforme la plus répandue. Le but était surtout de vérifier la faisabilité de ces types d’interaction et de récu- pérer les contraintes de leurs utilisations du point de vue utilisateur (indépendamment de la plateforme). Ces contraintes d’utilisation (pas encore validées par des expérimentations avec utilisateurs finaux) nous ont aidé, plus tard, pour la définition des contraintes de modélisation et de vérification des modèles (voir la section 5.3.2). Le tableau 5.3 présente les différents types d’interaction en entrée que nous avons identifiés, ainsi que leurs notations visuelles associées.

Type en

entrée Notation Modalité Combinaisons difficiles Contraintes d’utilisation

« Touch » Pointage tactile

La complémentarité avec le vocal et le secouage nécessite une fenêtre temporelle importante, la complé- mentarité est impossible avec la chute libre

Utilisation des gants, uti- lisation des deux mains (si une ou deux sont oc- cupées), la pluie

« Long

Touch » Pointage tactile Même chose que « Touch »

Nécessite un retour pour arrêter (généralement une petite vibration)

« Gestural

touch » Tactile gestuel

Nécessite une augmentation de la fenêtre temporelle pour les diffé- rentes complémentarités

Nécessite un retour vi- suel, la reconnaissance n’est pas toujours cor- recte

« Gestural

Multi-touch » Tactile gestuel

Complémentarité impossible car les deux mains sont utilisées

Il faut utiliser les deux mains

Vocal Parole

Redondance avec le tactile néces- site une fenêtre temporelle impor- tante

Nécessite une interac- tion préliminaire pour être déclenché, recon- naissance pas toujours correcte

Musique (En-

registrement) Musique

Complémentarité et redondance impossibles

Nécessite une interaction préliminaire pour être déclenché

Scan QR code Scan (mode gestuel) Complémentarité et redondance impossibles

Nécessite une interaction préliminaire pour être déclenché

Secouage Accélération Combinaison difficile avec le vocal (sauf en équivalence)

Impossible de voir l’écran au moment du secouage, nécessite un retour pour arrêter (autre que l’affichage)

Chute libre Accélération Impossible de coopérer en complé- mentarité ou redondance

Impossible de voir l’écran au moment de la chute, nécessite l’utili- sation des deux mains, risque de chute réelle

Accélération vers la droite Accélération vers la gauche Accélération vers le haut Accélération vers le bas

Accélération Combinaison difficile avec le vocal (sauf en équivalence)

Vue partielle de l’écran, mouvement de la main dif- ficile pour certaines per- sonnes Orientation vers le nord Orientation vers le sud Orientation vers l’est Orientation vers l’ouest Orientation

Peu d’opportunité de les utiliser en équivalence avec d’autres interac- tions

Nécessite plus de préci- sion

Orientation vers le haut Orientation vers le bas Orientation vers la droite Orientation vers la gauche

Orientation Combinaison difficile avec le vocal (sauf en équivalence)

Vue partielle de l’écran, mouvement de la main diffi- cile pour certaines personnes

« Blackout » Éclairage

Il faut généralement uti- liser les deux mains - Peut être confondu avec le tactile

« Illumina-

tion » Éclairage

Peu d’opportunité de l’utiliser en combinaison avec d’autres interac- tions

Difficile à effectuer (surtout à l’extérieur), il faut utiliser les deux mains

« S’appro-

cher » Proximité

Peut être confondu avec le tactile et sur- tout avec l’éclairage -Généralement, il faut utiliser les deux mains

« S’éloigner » Proximité

Peu d’opportunité de l’utiliser en combinaison avec d’autres interac- tions

Pas toujours vue comme une interaction

« Positionne-

ment » Localisation

Très utile en concurrence et peu dans les autres combinaisons

Nécessite l’acceptation de l’utilisateur

FIGURE5.26 – La section des évènements en entrée dans la palette

Après l’étape d’identification, nous avons ajouté les modèles paramétrables des types d’évènements dans la deuxième section de la palette (section pour les différents types d’évè- nements en entrée) (voir figure 5.26). Nous les avons classés par groupe de modalités d’inter- action, c’est-à-dire que chaque groupe contient les types d’évènements d’une seule modalité. Ainsi, les concepteurs peuvent déterminer rapidement les modalités lors du choix des évène- ments pour la modélisation. L’action qui sera effectuée lors de l’utilisation d’un de ces types d’évènements dans un modèle consiste à créer un modèle paramétrable qui instancie deux concepts et une association : « Input event », « Input type » et l’association entre les deux. Les deux instances des concepts seront reliées avec l’instance de l’association et les attributs de l’instance du type d’évènement seront remplis par le nom de l’évènement et la modalité d’interaction associée (figure 5.27).

Après la sélection d’un élément de la palette, le concepteur aura la possibilité de remplir les attributs de l’instance de l’événement en entrée. Par exemple, si un concepteur sélectionne le type « Touch » à partir de la palette et l’ajoute dans le modèle, deux instances seront créées : une instance d’évènement (le carré dans la figure 5.27) et une instance du type (l’icône de la main dans la figure 5.27).

5.1.3.2 Types d’évènements en sortie

De même que pour les évènements en entrée, nous avons aussi implémenté et testé les interactions en sortie afin de vérifier leur faisabilité et de récupérer les contraintes de leur utilisation du point de vue utilisateur. Le tableau 5.4 présente les différents types d’interac- tion en sortie que nous avons identifiés, leurs notations visuelles associées et les contraintes de leur utilisation.

Type en

sortie Notation Modalité Combinaisons difficiles Contraintes d’utilisation

« Musique » Musique Combinaison difficile avec la syn- thèse vocale

Pas utile dans des en- vironnements bruyants, nécessite un volume éleve

Vibration

courte Vibration / Peut être imperceptible

Vibration

Synthèse vo-

cale Synthèse vocale

Combinaison difficile avec la mu- sique (surtout en concurrence)

Généralement il faut affi- cher le texte associé (en redondance), la pronon- ciation n’est pas toujours correcte

Widgets Affichage / L’affichage nécessite de l’ergonomie

TABLE5.4 – Les types d’interaction en entrée

Nous avons ajouté les modèles paramétrables des types d’évènements en sortie dans deux sections de la palette : la section pour les types d’évènements permanents et la section pour les types d’évènements transitoires. Comme pour les types d’évènements en entrée, ces types ont été classés par modalités d’interaction dans les deux sections (figure 5.28). L’action, qui sera effectuée lors de l’utilisation d’un de ces types dans un état d’interaction, consiste à créer un modèle paramétrable qui instancie deux concepts et une association : « Output event », « Output type » et l’association entre les deux. Les deux instances des concepts seront re- liées avec l’instance de l’association et les attributs de l’instance du type d’évènement seront remplis par le nom de l’évènement et la modalité d’interaction associée (figure 5.29).

Après la sélection d’un élément, le concepteur aura la possibilité de remplir les attributs de l’instance de l’événement en sortie. Par exemple, si un concepteur sélectionne le type « Short vibration » et l’ajoute dans un état de son modèle, deux instances seront créées : une instance d’évènement (le rectangle dans la figure 5.29) et une instance du type (l’icône de vibration dans la figure 5.29). L’instance du type est déjà prête (le nom « Short vibration » et modalité « Vibration »), tandis que l’évènement nécessite l’intervention du concepteur pour le paramétrer (il ajoute le nom « vibrate » par exemple). Les deux instances sont reliées par l’association afin de spécifier que l’évènement « vibrate » est de type vibration courte (« In EType » = « Short vibration ») (l’association est définie graphiquement par le fait que le type est affiché au bord de l’évènement).

Dans cette section, nous avons défini la partie graphique (visuelle) de notre approche ainsi que la bibliothèque des types d’évènements d’interaction en entrée et en sortie. Nous reconnaissons que la définition d’une notation visuelle qui respecte les différents critères de physique des notations n’a pas été facile (un exemple avec les différentes notations est pré- senté dans l’annexe A).

FIGURE5.28 – Les sections des types d’évènements en sortie dans la palette

FIGURE5.29 – Un exemple d’un évènement transitoire de vibration en sortie

La création de la bibliothèque n’était pas simple non plus, surtout lors de l’identification des différents types. Cette bibliothèque reste ouverte pour l’intégration d’autres types d’évène- ments basés sur les anciens ou les nouveaux capteurs.

Dans la section suivante, nous allons présenter les générateurs de code de notre approche. Ces générateurs se basent sur les modèles graphiques pour générer le code sous les diffé- rentes plateformes.