Stage de Master 2 Recherche en Informatique -...

Stage de Master 2 Recherche en InformatiqueLaboratoire de Recherche en Informatique Équipe in|situ|

Des commandes gestuelles« multi-dimensionnelles »

David BonnetSous la direction deCaroline Appert

Remerciements

Je remercie en premier lieu Caroline Appert, mon encadrante de stage.

Je remercie Wendy Mackay et Michel Beaudouin-Lafon, mon futur directeur de thèse, pour, tout simple-ment, exister. Sans eux, leur travail titanesque et leurs multiples accomplissements, la recherche en inter-action homme-machine en France n’aurait certainement pas été aussi épanouie qu’aujourd’hui et j’aurais probablement eu beaucoup plus de mal à trouver des personnes qui partagent cette passion.

Milles mercis à Clément Pillias, qui s’est toujours rendu disponible pour écouter mes idées les plus farfe-lues et m’aider à les rendre… moins farfelues, surtout avant que j’aille les présenter à Caroline.

Un grand merci à Rodrigo Andrade de Almeida pour m’avoir donné de multiples références et idées, le tout avec un air brésilien très chaleureux et relaxant.

Je remercie bien évidemment tous les membres d’in|situ| pour leur support, leur gentillesse et leur aide précieuse.

INRIA / CNRS — Équipe in|situ|" 3

Sommaire

1. Introduction! 5

1.1. Problème abordé 5

2. État de l'art ! 7

2.1. Systèmes d’entrée gestuelle 7

2.2. Apport cognitif 8

2.3. Algorithmes de reconnaissance 9

2.4. Guides et techniques d’apprentissage 10

2.5. Conception de vocabulaires de gestes 12

2.6. Applications 12

2.7. Conclusion 16

3. SAM! 17

3.1. Première approche 18

3.2. Description 19

3.3. Applications 23

4. ThumbRock! 25

4.1. Motivation 25

4.2. Description 27

4.3. Calibration 31

5. Conclusion! 35

4" INRIA / CNRS — Équipe in|situ|

1. Introduction

L’interaction gestuelle recouvre une réalité très large allant du langage engageant tout le corps utilisé dans les dispositifs à grandeur humaine (systèmes de réalité virtuelle, tables interactives, etc.) aux suites de points en deux dimensions capturés par les dispositifs de taille plus réduite (tablettes tactiles, smartpho-nes, etc.). L’interaction gestuelle, qui repose sur l’association entre une commande et une suite de points, a motivé de nombreux travaux de recherche sur plus d'un demi-siècle pour proposer des algorithmes per-mettant de reconnaître des formes, des guides visuels pour faciliter l'apprentissage de gestes, des recom-mandations sur la conception de vocabulaires de gestes et des exemples concrets d'applications.

L'objectif de ce stage est d’utiliser une approche, encore peu considérée par la recherche, qui consiste à étudier les caractéristiques dynamiques des gestes afin d’augmenter le pouvoir d’expression de l’interac-tion gestuelle sans avoir recours à des formes complexes et difficiles à mémoriser.

Pour cela, les smartphones et appareils similaires forment un contexte d'étude particulièrement intéressant en introduisant deux contraintes majeures d'interaction. D'une part, pour répondre aux exigences de por-tabilité, la taille réduite de l'écran tactile restreint les gestes sur un espace exigu et à deux dimensions. Ainsi, il limite l'expression des gestes principalement basés, et discriminés, sur la forme et balise le travail de recherche en le restreignant au domaine, déjà très vaste, des tracés réalisés dans un plan. D'autre part, l'utilisateur peut indiquer des positions sur l'écran tactile uniquement lorsque le doigt est en contact avec sa surface (Buxton et al., 1985). Aucun autre mode ne permet de spécifier une suite de points, contraire-ment au traditionnel ordinateur de bureau où le curseur peut être déplacé avec la souris dans deux états : en maintenant le bouton de la souris enfoncé ou en le laissant relevé.

1.1. Problème abordé

Il s’agit d’identifier des propriétés dynamiques remarquables que l’utilisateur est capable de spécifier. Ces schémas dynamiques doivent être systématiquement assortis d'un algorithme capable de les reconnaître efficacement et d'indices graphiques (feedback et feed-forward) permettant leur apprentissage. Cependant, l'espace de conception défini par les dispositifs mobiles sus-mentionnés soulève plusieurs problématiques précises.

Tout d'abord, l'utilisateur préfère manipuler l'appareil mobile avec une seule main (Karlson et al., 2008), l'autre main étant réservée pour interagir avec l'environnement, tenir un objet ou alors maintenir l'équili-bre. De cette manière, seul le pouce est disponible, ce qui rend certaines cibles graphiques difficiles à atteindre et restreint davantage l'espace d'interaction pour effectuer des gestes.

De plus, les doigts peuvent masquer des zones importantes de l'écran, ce qui peut handicaper l'apprentis-sage et l'exploration d'ensembles de commandes. La plupart des guides visuels pour soutenir l’apprentis-sage et la découverte des gestes sont alors moins pertinents et la question d’envisager d'autres techniques d'apprentissage s’impose.

Enfin, les commandes gestuelles peuvent entrer en conflit avec les interactions déjà utilisées sur les dispo-sitifs mobiles. Par exemple, tout déplacement du doigt sur une page web est actuellement interprété comme un défilement de la page (scroll). Pouvoir passer dans un mode permettant d’entrer des comman-des gestuelles et revenir au mode d’interaction usuel est donc indispensable.


Pour retrouver une richesse d’interaction proche de celle que nous connaissons sur les ordinateurs porta-bles ou de bureau, ces contraintes obligent à explorer d'autres dimensions pour augmenter la capacité d’encodage des gestes.


2. État de l'art

Encouragé par l'essor des smartphones, et des tablettes tactiles, de plus en plus de systèmes interactifs reposent sur l’interaction gestuelle. La littérature concernant ce domaine étant particulièrement vaste, nous nous restreindrons aux gestes effectués dans un plan et à la présentation des travaux de recherche majeurs qui leur sont consacrés.

Sketchpad (Sutherland, 1963) fait figure de précurseur dans le paysage de l'interaction homme-machine. Il s'agit du premier système permettant à l'utilisateur d'entrer un geste, à l’aide d’un stylo optique, pour créer et modifier des formes géométriques par manipulation directe.

Sketchpad — (a) Différentes instances d’un objet (ici un rivet) avec des dimensions et orientations variées.(b) Manipulation 3D et vues multiples sur un même objet.

Les travaux que nous allons présenter s'inscrivent dans la lignée des problématiques soulevées par Sketchpad : le développement de nouveaux périphériques d'entrée gestuelle plus performants et fiables, la création d'algorithmes permettant de reconnaître les gestes effectués, la mise en œuvre de guides et d'in-dices permettant d'apprendre des vocabulaires de gestes et enfin la proposition de méthodes permettant de les rendre efficaces. Ces projets de recherche sont également motivés par des applications qui vont au-de-là des outils de dessin, que nous décrirons également.

2.1. Systèmes d’entrée gestuelle

Ce qui suit est un court historique permettant de situer dans l’ordre chronologique l’apparition de nou-veaux appareils d’entrée gestuelle plane :

■ Vers 1950, le Light Gun (Everett, ~1950) fut le premier périphérique optique capable de lire la position d'un point sur un écran afin d'effectuer des diagnostics.

■ En 1952, le premier Trackball (Cranston et Longstaff, 1952) fut inventé et se présentait comme une grande souris inversée. L’utilisateur manipulait la boule, maintenue sur des coussins d’air pour minimiser les frictions, à l’intérieur du socle inamovible.

■ En 1957, le Lightpen (Gurley, 1957) adopte la forme d'un stylo et est le premier du genre à pou-voir être utilisé sur un écran.

(a) (b)


■ En 1963, arrive la « Rand Tablet » (Davis et Ellis, 1963), l'ancêtre des tablettes graphiques telles que nous les connaissons aujourd'hui.

■ Dès 1964, la souris (English et Engelbart, 1967) fut inventée.

■ En 1965, un mécanisme fonctionnel d'écran tactile capacitif est décrit (Johnson, 1965).

■ En 1972, le premier écran tactile à être massivement distribué dans l'état d'Illinois voit le jour (Ebeling et al., 1972). Des lumières infrarouges réparties sur le cadre intérieur de l’écran permet-tant de détecter la présence d’un doigt sur l’écran.

■ En 1982, le premier appareil multi-touch (Mehta, 1982) est créé. Il repose sur l'emploi d'une caméra placée derrière une plaque de verre rétroéclairée filmant les ombres créées par la main de l'utilisateur. Le flux vidéo est alors numérisé et transmis à un processeur pour analyse.

■ En 1983, ce qui semble être le premier appareil tactile sur le marché, le HP 150, est apparu (HP, 1983).

■ En 1984, le premier écran multi-touch avec une nappe de détection transparente est inventée (Boie, 1984).

■ Enfin, en 2009, ThinSight, le premier écran LCD doté de capteurs optiques sur toute sa surface (Izadi et al., 2009), permettant d'émettre et de capter de la lumière est réalisé. Il permet alors de lire et même scanner tout objet sur ou proche de la surface de l'écran.

2.2. Apport cognitif

Appert et Zhai (2009) montrent au travers d’une étude empirique le fort potentiel des raccourcis gestuels. Les participants ont su apprendre plus rapidement davantage de gestes arbitraires (jusqu’à 16) que de rac-courcis claviers en ayant su les restituer avec moins d’erreurs.

Light Gun Trackball Lightpen

Rand Tablet Souris Touch Screen


Temps et mémorisation correcte de commandes en fonction du nombre de fois qu’elles ont été vues

2.3. Algorithmes de reconnaissance

Plusieurs algorithmes de reconnaissance de gestes ont été mis au point. Le plus connu est celui de Rubine (1991), qui utilise un mécanisme d’apprentissage supervisé. Il classifie les gestes selon 13 caractéristi-ques, dont les angles initiaux, la longueur du tracé, les dimensions du rectangle englobant, mais aussi la vitesse maximale et la durée du geste. La qualité des données d'entraînement (les gestes) pour le recon-naisseur de Rubine, comme pour tout algorithme d'apprentissage, est primordiale. Pour le rendre plus précis (efficace), il doit être entraîné avec un grand nombre d'exemples suffisamment diversifiés pour refléter les variations entre les utilisateurs et les différents contextes d'utilisation. Cette diversité naturelle est généralement difficile à obtenir en laboratoire où les gestes sont réalisés de manière consciente (con-trôlée, artificielle). Par ailleurs, ces reconnaisseurs fonctionnent souvent comme des boîtes noires conte-nant des données définies dans un espace à n dimensions, rendant leur implémentation difficile à vérifier et à corriger.

Plus récemment, l'approche consistant à se baser sur des modèles de gestes (templates) a regagné l'atten-tion des chercheurs et fait l'objet de plusieurs applications dans la reconnaissance de tracés. Ainsi, le re-connaisseur $1 (Wobbrock et al., 2007) s'abroge de la nécessité de l'apprentissage en s’appuyant sur un ensemble de modèles gestuels. Il permet d'être facilement utilisable pour le prototypage rapide d'applica-tions basées sur les gestes. Néanmoins, l'algorithme testant incrémentalement différentes rotations du geste, la durée de calcul augmente rapidement avec la taille du vocabulaire utilisé.

Le Protractor (Li, 2010) étend l'algorithme $1 en apportant une solution analytique qui permet de déter-miner immédiatement la rotation optimale entre le geste entré et celui du vocabulaire.

Protractor — Le temps requis pour reconnaître un geste augmente avec le nombre d’exemples de gestes. Protractor est significativement plus rapide que le reconnaisseur 1$.

L'algorithme d'Appert et Bau (Appert et Bau , 2010) permet de reconnaître les gestes et de déterminer leur échelle en cours de tracé (reconnaisseur à priori). Il se base pour cela sur un vecteur d'angles que fait chaque segment avec un axe de référence.

Tim

e (i

n m

s)

Shortcut within Item Frequency

stroke shortcuts

keyboard shortcuts


Rec

all

stroke shortcuts

keyboard shortcuts


Err

ors

stroke shortcuts

keyboard shortcuts

Figure 4. T ime, Recall and Error by Shortcut ! Frequency

5000

Tim

eR

ecal

l

stroke shortcuts

keyboard shortcuts

Figure 5. Time and Recall performance according to the number oftimes a command has been seen

100

75

50

25

0

stroke shortcuts

keyboard shortcuts

menu

S0

1S

02

S1

3S

12

S11

S1

0S

09

S0

8S

07

S0

6S

05

S0

4S

03

S1

4

Figure 6. Percentage of use of each technique in retest on the secondday (by participant)

cuts learned and to see which type of shortcuts they pre-ferred. Figure 6 shows each individual participants percent-age of use for each technique (Keyboard, Stroke and Menu).Although varied by individual, on average significantly morestroke shortcuts than keyboard shortcuts were used (F1,13 =

43, p < .0001). The overall mean percentages of use for thethree techniques were: 77.7 % Stroke, 20.3 % Keyboard,2 % Menu.

Finally, answers to the post hoc questionnaire showed thatall of the participants had intensive previous experience withkeyboard shortcuts in their everyday activity (about 15-20different shortcuts) and that none of them had ever used strokes.

Despite this experience bias in favor of keyboard shortcuts,the answers to the final question where they had to fill thetable revealed that they had learned stroke shortcuts betterthan keyboard shortcuts in this study. On average 11.6 strokeshortcuts and 4 keyboard shortcuts were correctly answered.The participants’ confidence level was also higher with strokeshortcuts (11.7/14 on average; 14 means complete confi-dence on all commands tested) than with keyboard shortcuts(4.2/14 on average).

The participants’ open remarks confirmed some of the anal-yses that led to our hypothesis. Strokes gave them richerclues to make up an association (more levels of process-ing) between a command and its arbitrarily assigned stroke:“I thought of this stroke as fish because the shape’s strokemakes me think about a basin” or “I associated this strokewith a jump and I see karate as a sport where people jump”.Interestingly, no two people mentioned the same trick to as-sociate a stroke with a command.

In summary, although the purpose of stroke shortcuts is notto replace or compete against either menu selection or key-board shortcuts, the experiment clearly shows that strokeshortcuts can be as efficient as or more advantageous thankeyboard shortcuts. After enough practice, the total trialcompletion times including both recall and execution wereindistinguishable between the two types of shortcuts. How-ever with the same fixed amount of practice, the participantssuccessfully recalled more shortcuts and made fewer errorsin the Stroke condition than in the Keyboard condition.On the second day the participants chose to use stroke short-cuts significantly more often than keyboard shortcuts, andcorrectly recalled about 3 times as many stroke shortcuts askeyboard shortcuts.

STROKE SHORTCUTS AND UI DEVELOPMENTThe study we conducted suggests that stroke gestures can beused as command shortcuts that are as effective as, or evenmore effective than, keyboard shortcuts. However, imple-menting stroke shortcuts in real applications is more chal-lenging than implementing keyboard shortcuts because com-

CHI 2009 ~ Gesture UIs April 9th, 2009 ~ Boston, MA, USA

2293

section, Protractor acquires the vector representation of a gesture by aligning the gesture7s indicative orientation. Since the indicative angle is only an approximate measure of a gesture7s orientation, the alignment in the preprocessing cannot completely remove the noise in gesture orientation. This can lead to an imprecise measure of similarity and hence an incorrect prediction. To address this issue, at runtime, Protractor rotates a template by an extra amount so that it results in a minimum angular distance with the unknown gesture and better reflects their similarity. Previous work [4] performs similar rotation to find a minimum mean Euclidean distance between trajectories. However, it used an iterative approach to search for such a rotation, which is time-consuming and the rotation found can be suboptimal.

In contrast, Protractor employs a closed-form solution to find a rotation that leads to the minimum angular distance. As we will see in the experiment section, this closed-form solution enables Protractor to outperform previous recognizers in both recognition accuracy and speed. Here I give the closed-form solution.

Since we intend to rotate a preprocessed template gesture t by a hypothetical amount � so that the resulting angular distance is the minimum (i.e., the similarity reaches its maximum), we formalize this intuition as:

�optimal � argmin��

arccosvt �� vg

vt �� vg

��

��

��

�� (4)

vt(�) represents the vector acquired after rotating template t by �. Note that this is on top of the alignment rotation that is performed in the preprocessing. As we intend to minimize the cosine distance with respect to �, we find

d arccosvt �� vg

vt �� vg

��

��

��

��

d�� 0 (5)

Solving Equation (5) gives the following solution:

�optimal � arctan ba

(6)

where a is the dot product of vt and vg (see Equation 2) and b is given in Equation 7.

b � xtiygi � ytixgi� �i�1

n

(7)

With �optimal calculated, we can easily acquire the maximum similarity (the inverse minimum cosine distance) between the two vectors. We then use this similarity as the score for how well gesture template t predicts the unknown gesture g. The gesture template that has the highest score becomes the top choice in the N-best candidate list.

PERFORMANCE EVALUATIONS To understand how well Protractor performs, I compared it with its closest peer, the $1 recognizer [4], by repeating the same experiment on the same data set where the $1 recognizer showed advantages over both the Rubine [2] and the DTW recognizers [5]. The data set includes 4800 samples for 16 gesture symbols collected from 10 participants (e.g., a star) [4]. The experiment was conducted on a Dell Precision T3400 with a 2.4GHz Intel Quad CoreTM2 CPU and 4 GB memory running Ubuntu Linux.

Overall, Protractor and the $1 recognizer generated a similar error rate curve in response to different training sample sizes (see Figure 2). Although the overall Poisson regression model for predicting errors was statistically significant (p<.0001), the major contributor to this significance is the training sample size and there was no significant difference between the recognizers (p=.602). However, Protractor is significantly faster than the $1 recognizer (see Figure 3). Although the time needed for recognizing a gesture increases linearly for both recognizers as the number of training samples grows, the $1 recognizer increases at a much rapid rate. For example, when 9 training samples are used for each of the 16 symbols, the $1 recognizer took over 3 ms to recognize a gesture, while it took Protractor less than ½ ms to do so.

Number of training samples per gesture category

Figure 2. The error rates of both the $1 recognizer and Protractor decrease as more training samples are used.

Number of training samples per gesture category

Figure 3. The milliseconds needed for recognizing a gesture grows as the number of training samples increases. Protractor

runs significantly faster than the $1 recognizer.

CHI 2010: Everyday Gestures April 10–15, 2010, Atlanta, GA, USA

2171


2.4. Guides et techniques d’apprentissage

Plusieurs projets de recherche ont étudié et mis au point des techniques dans le but de soutenir l'utilisateur dans la découverte et l'apprentissage de gestes.

Deux mécanismes sont utilisés : le feedforward, qui renseigne sur la forme des gestes et leur association avec une commande particulière, et le feedback, qui informe sur la reconnaissance du geste pendant ou après sa réalisation.

Ces mécanismes mettent en jeu deux modes : le mode expert et le mode novice. Dans le mode expert, seul le tracé effectué est affiché ainsi que, une fois le geste accompli, le nom de la commande sélection-née ou alors directement le résultat de l'opération. L'utilisateur bascule dans le mode novice lors d'une hésitation caractérisée par une absence de mouvement du périphérique d’entrée. Ce mode consiste en général à afficher les gestes possibles avec le nom ou le symbole des commandes associées. L'efficacité des techniques proposées résulte dans la façon de passer du mode novice au mode expert.

2.4.1. Menus

La plupart des menus permettent de déclencher une commande en faisant un tracé particulier. Leur appa-rence visuelle informe des commandes disponibles et du geste à réaliser pour les sélectionner, ce qui fait qu’ils peuvent être considérés comme des guides gestuels.

Les Marking Menus (Kurtenbach et Buxton, 1991) étendent le principe des menus circulaires (Callahan et al., 1988) en introduisant ces deux modes. Dans le mode expert, l'utilisateur fait une marque dans la direc-tion du secteur désiré sans que le menu soit affiché, alors qu'il l'est dans le mode novice.

Marking Menu — Exemple de sélection d’un élément du menu dans deux modes

Des études empiriques (Kurtenbach et Buxton, 1993) montrent que les utilisateurs peuvent faire des mar-ques jusque dans 12 directions différentes avec un taux d'erreur acceptable. Les Marking Menus hiérar-chiques (Kurtenbach et Buxton, 1993) permettent alors d'augmenter le nombre de commandes en faisant des gestes en forme de zigzags. Une autre variante, les Multi-Strokes Menus (Zhao et Balakrishnan, 2007) permettent d’augmenter davantage le nombre de commandes et de réduire l’espace requis puisque la na-vigation dans la hiérarchie se fait à l’aide de traits discontinus. Cette richesse accrue de commandes se fait néanmoins au prix d’une difficulté de mémorisation plus grande, la seule dimension de direction n'étant pas très expressive.

Afin d'y remédier, les Marking Menus hybrides (Isokoski et Käki, 2002), tout comme les Flower Menus (Bailly et al., 2008), introduisent une dimension supplémentaire : les courbures, optionnelles, à la fin des gestes, les rendent plus faciles à retenir et conviennent également à une utilisation sur de petites surfaces tactiles.

(a) Mode novice (b) Mode expert


Enfin, les FlowMenus (Guimbretiére et Winogard, 2000) et les Control Menus (Pook et al., 2000) propo-sent de sélectionner une commande et de définir, dans la continuité du geste, la valeur d’un paramètre.

FlowMenu — Exemple d’utilisation pour définir le zoom à 100%.

2.4.2. Gestes iconiques

Les gestes iconiques sont, par leur expressivité, plus faciles à apprendre, mais nécessitent des guides plus élaborés. Les anti-sèches avec des animations en contexte (Kurtenbach et al., 1994) permettent à la fois de découvrir l'ensemble des commandes disponibles ainsi que la manière de les utiliser en conjonction avec un objet sélectionné. Par exemple, si l'opération de suppression d'un objet consiste à le barrer hori-zontalement, une animation barrera l'objet sélectionné invitant alors l'utilisateur à faire de même.

Ces guides sont néanmoins très gourmands en termes de surface d'affichage et l'absence de feedback con-tinu ne permet pas de savoir si le geste en train d'être réalisé est correctement reconnu ou pas. Fluid Sket-ches (Arvo et Novins, 2000) transforme au fur et à mesure le tracé en des formes simples (ronds, car-rés…) les plus proches. Il exige cependant de tracer une portion considérable de la forme avant de voir l'effet d'embellissement (notamment, plusieurs boucles sont requises avant que le système ne détecte un rond). La détection des coins en analysant les variations de la vitesse du tracé (Agar et Novins, 2003) permet alors de le segmenter plus facilement et d'appliquer plus rapidement la transformation sur des ob-jets polygonaux. Ainsi, un carré sera reconnu dès que le quatrième bord sera dessiné, au lieu de tracer deux fois son contour.

OctoPocus (Bau et Mackay, 2008) propose une aide plus sophistiquée en ne se limitant pas à des formes géométriques « classiques ». Elle consiste à afficher les chemins des gestes possibles à partir de la posi-tion actuelle du curseur et à faire varier en continu leur épaisseur pour informer de leur taux de reconnais-sance. Si l'un d'entre eux passe sous un certain seuil, le tracé correspondant disparaît complètement.

OctoPocus — Affichage de quatre commandes possibles. Un déplacement le long du chemin de la commande «IHM» entraîne la disparition ou l'amincissement des autres chemins,

car ils sont pas ou peu reconnus.

IHM

RVA

TAL

SMA

IHM

RVA


2.4.3. Gestes multi-touch

Principalement pour des raisons d’occlusion et de complexité visuelle, les guides précédents sont diffici-lement exploitables pour des gestes multi-touch. ShadowGuides (Freeman et al., 2009) affiche sur une zone déportée la main telle que vue par le système (une ombre) en la complétant avec des ombres, flèches et autres annotations graphiques symbolisant les positions possibles pour activer différentes commandes. L'impact positif sur la mémorisation par rapport aux vidéos montrant les gestes filmés est significatif.

Gesture Play (Bragdon et al., 2010) utilise une approche basée sur des métaphores physiques afin d'en-courager l'apprentissage de gestes. Bien que les utilisateurs n'aient pas retenu davantage les gestes par rapport à un apprentissage par vidéos, ils ont néanmoins montré plus d'intérêt et d'envie à apprendre les gestes en question.

2.5. Conception de vocabulaires de gestes

Les méthodes de mise au point de vocabulaires de gestes ont pour but de les rendre facile à réaliser, à apprendre et à mémoriser.

Pour les Marking Menus, Kurtenbach et Buxton (1993), se posent la question sur la manière de répartir les commandes dans les différents niveaux. Les résultats de l'étude montrent que les largeur et profondeur maximales sont respectivement de 8 et 2, le facteur limitant étant le nombre d'erreurs acceptable. Néan-moins, pour une quantité fixe de commandes, alterner entre 4x4x4 éléments et 8x8 éléments donne les mêmes résultats. Enfin, les performances identiques avec la souris et le stylet (avec un très léger avantage pour celui-ci) montrent que ces menus sont compatibles avec les souris.

Long et al. (2000) donnent un ensemble de recommandations de conception. Par exemple, la similitude perceptive des gestes est en corrélation avec des caractéristiques comme la courbure.

MicroRolls (Roudaut et al., 2009) propose un vocabulaire particulièrement large s’il est mis en rapport avec la taille des gestes. En effet, un MicroRoll s’opère en faisant simplement rouler le pouce, ce qui le rend particulièrement adapté aux appareils tactiles mobiles.

2.6. Applications

Cette section présente des applications de l’interaction gestuelle dans des domaines variés.

2.6.1. Dessin

Si Buxton et Rubine ont créé des logiciels de dessin (respectivement GEdit et GDP), c'est avant tout pour illustrer leurs théories ou algorithmes d'interaction gestuelle. Nous présentons ici quelques travaux dont le but est d'aller au-delà du simple prototype, et qui reprennent souvent des métaphores et techniques an-ciennes d'illustrations.

Ligne Claire (Baudel, 1994) s'inspire des méthodes des artistes de bande dessinée et permet d'éditer les tracés selon quatre modes. Le premier consiste à créer un trait, le second permet de modifier une partie d'un trait en retraçant le segment à ajuster, le troisième supprime un segment en le hachurant et le dernier permet de joindre deux extrémités. L'édition des lignes peut se faire alors de manière successive et natu-relle, sans détériorer le dessin en cours de réalisation.


Ligne Claire — Effet d’un tracé dans chacun des quatre modes

Digital Tape Drawing (Balakrishnan et al., 1999) reprend une technique utilisée par les graphistes d'au-tomobiles : l'utilisation de scotch photographique permettant d'obtenir une courbure particulière contrôlée avec les deux mains qu'il est difficile, voire impossible, d'obtenir avec un stylet numérique, à main levée.

SKETCH (Zeleznik et al., 1996) permet d'exploiter des tracés effectués sur un plan afin d'en faire des ob-jets tridimensionnels. En fonction de l'orientation et de la position des lignes par rapport au point d'ori-gine, certaines seront extrudées le long d'un trait ou alors par circonvolution. Cette technique autorise ainsi à obtenir des primitives aux dimensions voulues afin de réaliser rapidement une maquette.

Imaginary Interfaces (Gustafson et al. 2010) pousse le concept encore plus loin en effectuant des tracés dans l'espace devant soi qui peuvent être capturés par des téléphones dépourvus de tout écran. Une camé-ra infrarouge fixée sur la veste capte les mouvements de la main dominante dans le plan défini par la main non dominante, formant un « L » avec le pouce et l'index. Le seul feedback visuel des gestes effectués s'effectue alors dans l'imagination de l'utilisateur. Les tracés capturés peuvent par exemple être retransmis via le téléphone à un correspondant pour illustrer plus précisément le chemin qui le mène à l'endroit de-mandé auparavant.

Imaginary Interfaces — (a) Image brute de la caméra. (b) Version en noir et blanc.(c) Extraction des contours de la main. (d) Extraction des trois points de la main gauche

et du point saillant de la main droite. (e) Appareil de capture.


2.6.2. Texte

L'utilisation de gestes pour l'entrée de texte présente plusieurs avantages. La simple position des tracés procure suffisamment d'information au système pour alterner rapidement entre texte, schéma, formule mathématique, tableau… Alors que sur les systèmes traditionnels, l'emploi explicite de commandes ou de modes est souvent exigé pour y parvenir.

Les premiers reconnaisseurs de caractères datent de l'époque de Sketchpad : (Teitelman, 1964), (Brown, 1964) et (Bernstein, 1964). Celui du MessagePad (Apple, 1992-1998) était basé sur les mots. Cela permet de bénéficier du contexte pour corriger les fautes de frappe éventuelles, mais posait des problèmes lorsque le mot écrit ne figure pas dans le dictionnaire.

Certains reconnaisseurs utilisent des formes plus ou moins proches des caractères classiques, altérés au profit d'une entrée gestuelle plus rapide. Graffiti (Palm, 1996), utilisé par les assistants personnels tour-nant sous Palm OS, dispose d'un vocabulaire constitué de caractères majuscules simplifiés pour qu'ils soient réalisables en un seul trait, sans lever le stylet. Unistroke (Goldberg et Richardson, 1993), est dans la même lignée, mais propose un alphabet encore plus éloigné de l'alphabet traditionnel afin d'optimiser davantage la vitesse d'écriture. Une étude empirique (Castellucci et MacKenzie, 2008) montre qu'Unis-troke est plus rapide que Graffiti, au prix d'un temps d'apprentissage légèrement plus long.

Alphabets gestuels avec Graffiti (en haut) et Unistrokes (en bas)

D'autres systèmes ont une reconnaissance encore plus souple. Aha! InkWriter (Aha! Software Corp., 1993) reconnaît la morphologie d'un document rédigé à l'aide d'un stylet. Ainsi, sans en connaître la si-gnification, à partir des caractéristiques des tracés, il est en mesure de détecter des mots, des paragraphes et des schémas sans en connaître la moindre signification. Les connaissances sont suffisantes pour sup-primer un ou plusieurs mots d'un simple trait et réarranger les autres mots pour qu'ils occupent l'espace vide, comme dans un logiciel de traitement de texte. Les dessins peuvent être redimensionnés ou même embellis en les remplaçants par la forme primitive la plus proche (par exemple, un rond dessiné à main levée par un rond parfait).

S'il est naturel de vouloir réaliser avec un stylo numérique ce que nous faisons habituellement avec un stylo traditionnel (à savoir, dessiner et écrire des mots qui devront être reconnus par le système), la com-binaison geste et clavier logiciel (« softkeyboard ») peut se montrer plus efficace et moins sujette aux er-reurs. Par exemple, en combinant le clavier avec les Marking Menus (Hashimoto et Togasi, 1995), on peut, d'un geste court, à la fois entrer un caractère et un modifieur (« majuscule », « ctrl », « alt »…) ou alors accéder rapidement à des caractères spéciaux couramment utilisés comme « enter », « suppr », « es-pace ».


Un autre exemple intéressant est le système ShapeWriter (Zhai et Kristensson, 2003) qui permet de tracer un geste continu liant les lettres du mot à écrire plutôt que de taper sur chacune de ces lettres. Le support offert par le clavier gestuel sert de guide pour l’exécution des gestes disponibles tandis que les gestes, une fois mémorisés, permettront une entrée plus rapide du mot associé. Afin de pouvoir se reposer un clavier logiciel classique sans ambiguïté en cas de saisie gestuelle, ShapeWriter combine son reconnaisseur de formes avec un dictionnaire de mots.

ShapeWriter — Exemple de tracé pour écrire le mot « fun »

Précédemment, d’autres systèmes avaient proposé des représentations graphiques différentes des caractè-res alphanumériques. QuickWriting (Perlin, 1998) utilise notamment une disposition circulaire des carac-tères. L’utilisateur joint les lettres d’un même mot par un geste continu qui repasse par le centre entre chaque lettre. Pour lever l’ambiguïté entre des lettres adjacentes sur le cercle, Perlin propose d’utiliser la direction du geste juste après le franchissement de la lettre.

2.6.3. Musique

Les gestes sont aussi particulièrement pertinents dans des systèmes de notation qui comportent plus de dimensions que l’écriture.

Dans le cadre du Structured Sound Synthesis Project (SSSP), plusieurs logiciels dédiés aux compositeurs furent réalisés. L’un d’entre eux est un outil d’écriture de notes musicales, Char-rec (Buxton, 1979). Les notes sont insérées en démarrant le tracé à la position où elles doivent apparaître sur la portée et la forme du trait indique la durée de la note souhaitée (blanche, noire, croche, …). Il introduit alors la notion de raccourcis, de marques qui caricaturent l’objet à créer. Un geste spécifie hauteur, position et durée de la note (3 paramètres en un seul trait).

Musink (Tsandilas et al., 2009) permet aux compositeurs d’associer les caractéristiques de marques faites au stylo (par exemple, les dimensions du tracé, son envergure, la forme générale qui lui est associée…) à leurs logiciels de composition musicale.


2.6.4. Autres

Une technique récente, Data Miming (Holz et Wilson, 2011), consiste à utiliser les gestes pour sélection-ner un objet parmi un ensemble d’objets contenus dans une base de données. L’utilisateur décrit l’objet recherché en mimant, avec ses mains, sa forme, face à une caméra capable de détecter la profondeur. La vitesse de déplacement des mains permet de discriminer les gestes descriptifs, plus lents, des gestes tran-sitoires.

Il existe évidemment un grand nombre d’autres applications, comme le vocabulaire de gestes dédié au contrôle du trafic aérien (Chatty et Lecoanet, 1996) ou encore le système basé sur les gestes pour contrô-ler le comportement de robots à distance (Sakamoto et al., 2009).

2.7. Conclusion

L’interaction gestuelle peut, au travers d’outils et d’un vocabulaire de gestes bien défini, rendre accessible des fonctions qui l’étaient difficilement, voire pas du tout, avec les paradigmes usuels.

On remarque que peu de techniques utilisent les caractéristiques dynamiques du geste. Lorsque c’est le cas, comme dans l’algorithme de Rubine, le détecteur de polygones (Agar et Novins, 2003), ou encore Data Miming, elles restent néanmoins marginales et sont principalement utilisées pour aider à la distinc-tion de la forme des gestes.

Ainsi, sur le plan de la recherche, un certain nombre de voies restent à explorer, notamment l’étude des caractéristiques dynamiques, qui remet alors en question tous les points abordés précédemment (algo-rithmes, guides, conception de vocabulaires…).


3. SAM

Dans le contexte des dispositifs mobiles, il y a plusieurs besoins clairement identifiés à satisfaire :

■ activer beaucoup de commandes de tout type (ces appareils tendent à offrir l’expressivité d’un ordinateur de bureau, le vocabulaire d’entrée doit être potentiellement très riche),

■ éviter les problèmes d’occlusion,

■ éviter les problèmes d’inaccessibilité.

Un premier objectif fut donc de proposer un mode gestuel dans lequel l'utilisateur pourrait réaliser un grand nombre d'opérations diverses tout en restant dans le contexte d'une utilisation à une main (interac-tion avec le pouce). Or, proposer un vocabulaire gestuel nécessite également de concevoir des guides vi-suels afin de permettre à l'utilisateur de découvrir l'ensemble des commandes et de réduire la charge cog-nitive. En implémentant OctoPocus en JavaScript dans le but de pouvoir l’utiliser facilement sur différen-tes plateformes (figure 3.1), nous nous sommes aperçus que les gestes emblématiques impliquent des gui-des dont la complexité visuelle, les contraintes spatiales et l'occlusion, semblent peu appropriés pour une première approche de la problématique.

Figure 3.1 — Utilisation de la version implémentée en JavaScript sur un iPod touch

Nous avons donc décidé de baser notre solution sur les menus circulaires. Ce sont des guides gestuels simples (ils dirigent des tracés dans une direction) qui donnent la possibilité d'être augmentés facilement pour représenter, avec clarté, les différents types de commande : le déclenchement d'une opération (par exemple, ouvrir une application), l'activation ou la désactivation d'une option (par exemple, activer ou non le moyen de communication Bluetooth), la sélection d'une valeur dans une liste (par exemple, choisir un réseau wifi) et la spécification d'une valeur continue (comme le zoom dans un logiciel de cartographie) ou discrète (comme le choix d'une date pour un rendez-vous).

Curieusement, si la littérature regorge de présentations de différents types de menus, aucun ne répond à la fois aux problèmes d'exploration et d’accès à un grand nombre de fonctions. Comme l’évoque l’état de l’art précédent, la simple combinaison des techniques existantes n’est pas directement envisageable, car elles exploitent des pistes de réponse incompatibles. Lors de la conception du Swiss Army Menu (SAM), notre objectif était de créer une technique satisfaisant tous ces besoins.


3.1. Première approche

Dans les premières versions, nous avons envisagé de pouvoir déplacer le menu à distance, depuis n’im-porte quelle position de la surface de l’écran. En ajoutant de l’inertie, nous souhaitions ainsi répondre aux problèmes d’accessibilité du pouce en permettant de lancer le menu dans une direction donnée. Un élé-ment du menu est alors sélectionné lorsque le palet rouge, fixe, casse le bord extérieur de celui-ci (figure 3.2).

Figure 3.2 — Sélection d’un élément du menu en déchirant le bord extérieur

Les inconvénients sont néanmoins multiples : la lecture du menu est difficile lorsqu’il est en déplacement et aucun modèle simple ne permet de proposer une navigation dans une hiérarchie de commandes.

Poussés par la volonté d’exploiter la dynamique du geste (notamment, la vitesse), nous avons imaginé d’autres techniques mettant en jeu un pneu (figure 3.4-(a)). Celui-ci a l’avantage de proposer un feedback visuel clair qui informe immédiatement de la force avec laquelle le menu ou le palet s’est écrasé contre la paroi, ce qui a pour effet de déclencher une commande particulière.

Figure 3.3 — (a) Métaphore du pneu, la sélection se faisant lorsque l’épaisseur du pneu est nulle ou lorsque le pneu est en contact et que l’utilisateur relâche le pouce.

(b) Utilisation d’un palet que l’on lance sur un élément pour déclencher la commande associée.

Une autre idée fut d’utiliser un palet que l’on lance sur une commande ou au travers d’un lance-palet (fi-gure 3.4-(b)), dont l’utilisation est similaire à MagStick. Mais l’exploitation de l’inertie est trop difficile dans des conditions de mobilité.

De ces différentes approches, nous avons retenu le pointage indirect (mais contrôlé, sans accélération ou inertie) et d’autres propriétés que nous détaillons dans la section suivante.

Command 1

Command 4

Com

man

d 2 C

omm

and 3

Command 1

Command 4

Com

man

d 2 C

omm

and 3

Command 1

Command 4

Com

man

d 2 C

omm

and 3

PaletMenu circulaire

(mobile)

Pouce en contactavec l'écran

Smartphone

(a) (b)

Com

man

d 2C

Com

man

d 2D

Command 1D

Command 1C

Command 1B

Command 1A

Com

man

d 2B

Com

man

d 2A

CommandeSmartphoneLance-palet

Command 1

Command 2 Command 3

Command 4

Command 4

Command 3Command 2

Command 1

Zone dedéplacement

Pneu

Pie Menu

Palet


3.2. Description

L’utilisation de SAM se fait au travers d'un palet, évoluant dans une zone restreinte, qui peut être contrôlé depuis n'importe quelle position de l'écran (figure 3.4-(a)). Ce fonctionnement est en accord avec les ca-pacités physiologiques du pouce, lui permettant alors d'accéder facilement à toutes les commandes sans les masquer.

Italic

Underline

Font Size Style Font Size 17 pt

Commande

Basculeinactive

Basculeactive

Élastique

Circulaire

Sous-menu

Bord extérieur

Ruban élastique

Zone de contrôle

Zone inactive

Palet

(a) Exemple d’utilisation (b) Anatomie

Figure 3.4 — (a) Exemple d’utilisation et anatomie de SAM

3.2.1. ÉvénementsLa partie centrale du menu contenant le palet est composée de deux aires concentriques : une zone inac-tive et une zone de contrôle (figure 3.4-(b)). Elles sont séparées par un élastique noir, qui se déforme au contact du palet. L'interaction entre ces deux objets permet d'introduire un nouveau vocabulaire de trois types d'événements :

■ Contact : Le palet touche l’élastique (figure 3.5-(a)).

■ Étirementx : Le palet étire l’élastique d’une distance x (compris entre 0 et d) par rapport à l’état au repos (figure 3.5-(b)).

■ Traversée : Le palet traverse l’élastique s’il l’étire en se déplaçant vers un élément de type circu-laire ou un sous-menu et qu’il touche le bord extérieur (dans ce cas, x ≥ d, où d est la distance entre l’élastique et le bord extérieur). Il peut ensuite le retraverser pour revenir dans la zone in-active en déformant l’élastique dans l’autre sens d’une distance x ≥ d (figure 3.5-(c)).

Figure 3.5 — Types d’événements générés par l’interaction entre le palet et l’élastique

Ces événements permettent d'utiliser des types d'éléments variés, qui se distinguent chacun par des indi-ces graphiques explicites (figure 3.5). Dès que le palet touche l'élastique, l'élément le plus proche est sé-lectionné et si l'utilisateur lève le pouce, l'interaction avec le menu se termine. Sinon, lorsque le palet se

(a) Contact (b) Étirementx (c) Traversée

dx


trouve dans la zone inactive, il peut repositionner son pouce afin d'accommoder la prise en main (simi-laire au débrayage réalisé avec la souris).

3.2.2. Types d’éléments

Nous passons en revue la manière d'interagir avec ces différents éléments.

Lorsque l'élément commande est sélectionné, la fonction associée est déclenchée au moment où l'utilisa-teur relève le doigt.

Remplaçant les cases à cocher (sélection multiple) ou les boutons radio (sélection unique), l'élément bas-cule passe dans l'état opposé (actif ou inactif) lorsque le palet étire l'élastique jusqu'à toucher le bord exté-rieur. Si plusieurs éléments de ce type sont côte à côte, l'utilisateur peut les changer en glissant le palet le long du bord comme illustré dans la figure 3.6-(a). Lorsque plusieurs propriétés sont regroupées, comme c'est le cas avec les boutons radio, les éléments sont alors liés au travers d'un fil (figure 3.6-(b)). Déplacer le fil vers un des éléments l'écarte du précédent élément sélectionné afin d'assurer l’unicité.

Figure 3.6 — Apparence et utilisation de l’élément bascule

Si la plupart des menus existants contiennent des éléments associés à une commande ou un sous-menu, d'autres comme les Control Menus (Pook et al., 2000) et les FlowMenus (Guimbretière et Winograd, 2000) enrichissent l'interaction en permettant le contrôle continu de la valeur d'un paramètre d'une com-mande (par exemple, le zoom). Néanmoins, ces techniques ne sont pas facilement utilisables sur les appa-reils mobiles pour des raisons de place et les guides proposés ne sont pas suffisamment intuitifs et évoca-teurs de la fonction qu'ils représentent. Les éléments élastique et circulaire répondent alors à ces exigen-ces.

L'élément élastique, qui ne dispose pas d’équivalent dans les interfaces usuelles, permet de modifier une valeur en contrôlant la vitesse à laquelle elle est incrémentée ou décrémentée, selon la distance x d'étire-ment de l’élastique (figure 3.7-(a)).

L'élément circulaire permet de changer une valeur d'une manière semblable aux sliders. Lorsque le palet traverse l’élastique pour entrer dans la zone de contrôle, les autres éléments du menu disparaissent pour réduire l'occlusion et, dès lors, l'utilisateur peut déplacer le palet dans le sens horaire (respectivement an-tihoraire) afin d'incrémenter (respectivement décrémenter) la valeur (figure 3.7-(b)). Il peut également annuler l'édition de la valeur en revenant dans la zone inactive. Sinon, il valide la valeur en levant le pouce.

Italique

Souligné

Gras Style

Titre

Liste

Légende

Citation

Paragraphe

Section

(a) Sélection continue (b) Sélection unique


Figure 3.7 — Exemples d’utilisation des éléments élastiques et circulaires

Figure 3.8 — Étapes de la transition vers un sous-menu

La navigation dans la hiérarchie est assurée par l’élément sous-menu (figure 3.8). Il se déclenche comme l’élément commande, et permet alors, via plusieurs gestes directionnels, d’accéder à un élément ne se trouvant pas dans le premier niveau du menu. De plus, il permet de prévisualiser les éléments qu’il con-tient en traversant l’élastique. Les éléments du niveau actuel s’écartent alors pour laisser apparaître les éléments enfants, à l’instar du Wavelet Menu.

3.2.3. Élastique

La métaphore de l’élastique utilisée dans SAM est particulièrement intéressante. D’une part, elle offre un retour visuel plus riche dans l'esprit des guides Gesture Play (Bragdon et al., 2010). Contrairement aux menus circulaires à l'apparence statique, le caractère dynamique de l’élastique permet de découvrir et de saisir plus facilement le fonctionnement de SAM. D’autre part, l'élastique peut modifier le contrôle indi-rect du palet en amortissant les mouvements réalisés vers la périphérie s'il se trouve dans la zone inactive ou vers le centre dans l'autre cas. En se plaçant dans un système de coordonnées polaires (r, θ) ayant pour origine le centre de SAM, la simple équation de la figure 3.9 montre comment un déplacement du doigt mesuré par (∆r, ∆θ) est transformé pour être appliqué au palet (∆r', ∆θ') via les coefficients sr et sθ. Là encore, la valeur x de l'événement d'étirement est utilisée pour déterminer la valeur de sr : elle évolue en proportion inverse par rapport à x, tandis que sθ reste à 1.

(a) Élément élastique (b) Élément circulaire

Augmentertaille de police

Annuler

Diminuertaille de police

Taillede police 12 pt Taille

de police 17 pt

Augmentertaille de police

Diminuertaille de police

Taillede police 15 pt Annuler

Italic

Underline

Bold Style

Italic

Underline

Bold Style

Italic

Underline

Bold Style

Italic

Underline

Bold Style

Title

List

Legend

Citation

Paragraph

Section

Title

List

Legend

Citation

Paragraph

Section


Figure 3.9 — Altération du déplacement du palet

Cet amortissement permet de contrôler plus finement l'utilisation des éléments élastiques. Il peut égale-ment, dans le cas des éléments circulaires, empêcher que le palet quitte involontairement la zone de con-trôle en apportant plus de tolérance aux mouvements circulaires réalisés par l'utilisateur. Ce dernier devra alors faire des mouvements plus secs pour traverser l’élastique, ce qui créera des pics d’accélération si-gnificatifs qui seront plus faciles à détecter dans le mode expert, décrit ci-après.

3.2.4. Mode expert

En effet, SAM dispose d'un vrai mode expert, comme la plupart des menus circulaires. Il consiste à ne pas afficher le menu tant que l'utilisateur n'a pas marqué une courte pause (300 ms). Néanmoins, simplement masquer l'apparence du menu revient à s'exposer au risque que l'utilisateur ait une mauvaise idée du véri-table emplacement du palet. Des trajectoires voulues comme circulaires peuvent en réalité être des ellip-ses plus ou moins étroites et causer des passages involontaires entre la zone inactive et celle de contrôle. De même, les déplacements peuvent ne pas être assez longs et le palet peut, contrairement aux attentes, ne pas toucher l'élastique ou le bord extérieur.

Une version plus efficace de ce mode consiste à ne plus considérer la forme et la longueur du tracé, à l'ex-ception des éléments élastiques. L'orientation suffira à déterminer l’élément commande, bascule ou sous-menu à activer et les variations d'accélération permettront de déterminer quand le palet entre dans la zone de contrôle pour changer la valeur d'un élément circulaire.

3.2.5. Une solution complète

Certains travaux ont adapté des menus pour une utilisation sur un appareil mobile, mais souvent, ils cons-tituent des solutions isolées qui introduisent d'autres défauts. Par exemple, le Wavelet Menu (Francone et al., 2009) est une adaptation du Wave Menu (Bailly et al., 2007) facilitant l'exploration de l'ensemble hié-rarchique de catégories, mais ajoute le phénomène d'occlusion. De façon similaire, l'ArchMenu et le ThumbMenu (Huot et Lecolinet, 2007) mettent des commandes à portée de pouce, au prix d'une disposi-tion restreignant le nombre d'éléments.

D'autres techniques dédiées à une utilisation à une main d'un dispositif mobile proposent des solutions pour répondre aux problèmes d'occlusion et du champ d'action réduit du pouce. MagStick (Roudaut et al., 2008) permet, au travers d'un bâton télescopique virtuel, d'accéder à des régions inaccessibles de l'écran et d'éviter de masquer la zone d'intérêt en requérant d'éloigner le doigt de celle-ci pour pouvoir la sélec-tionner. ThumbSpace (Karlson et Bederson, 2008) permet d'accéder à n'importe quel point de l'écran en disposant, sous le pouce, un trackpad logiciel qui représente une taille réduite de l'écran.

Mais là encore, les solutions sont isolées et impossibles à agréger afin de pouvoir combiner leurs avanta-ges. SAM, qui emprunte son nom aux couteaux suisses, est le premier menu qui permette simultanément d’explorer aisément un ensemble de commandes, grâce à de petits déplacements du pouce, et de garantir une richesse fonctionnelle. Il a fait l’objet d’un article court rédigé en anglais, qui figure en annexe de ce rapport, et accepté à la conférence IHM ’11.


3.3. Applications

Les exemples d’utilisation présentés dans les précédentes figures (3.6 à 3.8), montrent les commandes qu’il serait possible de déclencher dans le cadre d’un logiciel de traitement de texte. L’exemple de la fi-gure 3.10 met en scène l’utilisation d’un élément circulaire pour modifier le zoom sur une carte. On peut également imaginer une utilisation de ce même élément pour retrouver un instant précis dans une vidéo.

Figure 3.10 — Étapes de l’utilisation de l’élément circulaire pour zoomer sur une carte

D’autres possibilités d’utilisation sont possibles en étendant le design de SAM. Notamment, en combi-nant un élément circulaire avec deux élastiques, on peut obtenir un sélecteur de couleur précis (figure 3.11). Nous prévoyons d’ailleurs de proposer une technique qui permette de sélectionner une valeur con-tinue définie sur trois dimensions et plus.

Figure 3.11 — Combinaison d’un élément circulaire avec deux élastiques (en gris)pour sélectionner une couleur (le palet est représenté par un cercle noir dans la zone colorée)

Zoom

Options

RotateTilt

Zoom

Options

RotateTilt

Zoom

+-

Couleur


4. ThumbRock

L’interaction avec un seul doigt (le pouce) sur une surface tactile mobile ne permet que d’utiliser un vo-cabulaire restreint d’événements. Nous allons voir comment ces restrictions se présentent et identifier des situations où la nécessité d’un nouvel événement, que nous baptisons ThumbRock, s’impose.

4.1. Motivation

4.1.1. Des états limitésLa plupart des appareils équipés d'un écran tactile détectent les gestes multi-points afin de proposer un large vocabulaire d'événements qui vient enrichir l'interaction avec l'utilisateur. Or, en se plaçant dans notre contexte d’utilisation à une main où l’interaction repose essentiellement sur le pouce, ce vocabulaire est drastiquement réduit et le restreint à un modèle à deux états (figure 4.1-(A)) (Buxton et al., 1985) :

■ état 0 (hors de portée) : le pouce n’est pas en contact avec la surface tactile et n’a donc aucun effet sur le système,

■ état 1 (mouvement) : le pouce est en contact avec la surface tactile et tout déplacement du doigt est détecté par le système.

Figure 4.1 — États et transitions réalisables avec une surface tactile (A) et une souris (B)

À partir de ce modèle, les transitions entre et sur ces états permettent d’établir un vocabulaire d'événe-ments de base que l'on retrouve sur la plupart des appareils tactiles mobiles du commerce :

■ un tap revient à réaliser une succession de transitions d’états 0-1-0 et permet principalement de faire une sélection discrète (par exemple, activer un bouton),

■ un déplacement consiste à emprunter la boucle dans l’état 1 et autorise alors la navigation dans une vue (par exemple, se déplacer sur une carte).

En considérant l’utilisation d’une souris à la place d’une surface tactile, nous obtenons également un mo-dèle à deux états, mais où seulement un état est en commun avec le précédent modèle (figure 4.1-B). L’état 1 (mouvement) correspond au mouvement du pointeur en réponse au déplacement physique de la souris et l’état 2 (déplacement) correspond au mouvement du pointeur lorsque le bouton de la souris est enfoncé. Ce modèle proposant deux états actifs, il permet alors d’établir un vocabulaire d’événements de base plus riche, en autorisant la réalisation d’un clic (transition 1-2-1), des opérations de pointage (transi-tions 1-1) ou encore des opérations de déplacements d’objets (transitions 2-2).

1 2

mouvement déplacement

bouton relâché

bouton enfoncé

0 1

hors de portée mouvement

contact

pas de contact

A B


4.1.2. Des événements virtuels

Afin de s’approcher de l'expressivité obtenue avec la souris, des solutions logicielles existent déjà pour enrichir le vocabulaire d’événements et les actions disponibles sur les surfaces tactiles. Notamment, le double-tap permet d'agrandir la zone visée dans un navigateur web (et de la réduire ensuite), la pause (immobilité du doigt sur la surface tactile pendant une courte durée) permet d'activer une loupe pour affi-ner la sélection (Vogel et Baudisch, 2007) ou encore le défilement à vitesse variable.

Néanmoins, le coût pour réaliser d’autres tâches courantes, comme la sélection de texte ou le déplacement d'objets, et le recours systématique à un mode d'édition, dans lequel on entre en tapant sur le bouton épo-nyme, sont autant d'exemples qui viennent souligner le fait que ce vocabulaire d'événements n’est pas suffisant.

4.1.3. L’exemple de la sélection de texte

Analysons plus en détail les transitions, dans le modèle à deux états de la surface tactile, que nécessite une opération de sélection de texte. Nous remarquons que, pour les deux méthodes proposées sous iOS (figure 4.3), l’utilisateur doit recourir à une commande gestuelle (double-tap ou tap-et-demi) pour sélec-tionner le mot sur lequel elle a été effectuée, et affiner ensuite en déplaçant les poignées bleues situées aux extrémités du rectangle bleu transparent de sélection (figure 4.2). Aucune ne permet de démarrer une sélection en spécifiant précisément la position à laquelle elle doit commencer.

Figure 4.2 — Rectangle de sélection en train d’être modifié au niveau de la poignée de gauche

Figure 4.3 — Opérations permettant d’effectuer une sélection sur iOS

1

00

double-tap : création de la sélection

1

0

0 1

hors de portée mouvement :modification

de la sélection

contact surpoignée desélection

relâchement :fin de la modification

de sélection

1

00

tap-et-demi : création de la sélection

1

0

mouvement :modification

de la sélection

relâchement :fin de la modification

de sélection

modification de la sélection


L’interaction pour sélectionner du texte avec précision est alors bien éloignée de celle, plus fluide, que l’on est mesure de trouver avec les ordinateurs de bureau en manipulant une souris (figure 4.4-(B)). Pour s’en approcher, il faudrait disposer d’un événement qu’il est possible de créer alors que le pouce est déjà en contact avec la surface de l’écran (figure 4.4-(A)), sans entrer en concurrence avec l’événement pause, qui permet d’afficher une loupe pour faciliter le positionnement du curseur à l’endroit où la sélection doit débuter.

Figure 4.4 — Opération de sélection souhaitée sur un appareil tactile (A)et opération de sélection avec une souris sur un ordinateur de bureau (B)

D’autres événements, similaires à l’anti-tap qui consiste à lever brièvement le doigt de la surface, ne sont pas des solutions acceptables, car ils peuvent être confondus avec d’autres interactions gestuelles (par exemple, avec un tap long, qui a pour effet d’afficher un menu avec les commandes « couper », « co-pier » et « coller », suivi d’une opération de déplacement en glissant le doigt sur la surface). D’ailleurs, il est difficilement envisageable de considérer de nouveaux événements en se basant sur les transitions 0-1 ou 1-0, tant celles-ci ont déjà utilisées dans le vocabulaire actuel.

Ainsi, ce qui manque est un événement permettant notamment de faire une sélection de texte avec une interaction ininterrompue, à l'instar de celle que l'on obtient avec les ordinateurs de bureau.

4.2. Description

Nous proposons le ThumbRock comme un nouvel événement. Il consiste à rouler le pouce sur la surface tactile, à l’instar de la séquence de gestes « roll-down » et « roll-up » du vocabulaire des MicroRolls (Roudaut et al., 2009). Ce roulement est détecté par le système comme un petit déplacement dont un tracé caractéristique est présenté dans la figure 4.5. Mais là où les MicroRolls sont détectés par un algorithme (dérivé de celui de Rubine) qui considère avant tout des dimensions de forme, celui du ThumbRock est principalement basé sur l'accélération1.

En effet, nous utilisons les propriétés physiologiques du pouce afin que l'utilisateur puisse le réaliser très rapidement (environ 300 ms). L'opération consiste à fléchir la phalange médiale tout en gardant le muscle fléchisseur de la phalange distale (l’extrémité du pouce) souple pour qu'elle puisse être collée contre la surface tactile. La semi-élasticité des articulations aide ensuite à replacer le pouce dans la posture initiale. Ainsi, ce mouvement cause une séquence de pics d'accélérations et de décélérations2 calculés par le sys-tème (figure 4.7).

1 2

mouvement :pointage débutde la sélection


de la sélection

bouton relâché :fin de sélection

bouton enfoncé :début de sélection

1': loupe0 1contact pause 2événement

début de sélection


de la sélection

relâchement

mouvement :pointage débutde la sélection

A B


1 Nous utilisons le terme accélération pour désigner la variation du module du vecteur vitesse.2 Nous désignons par le terme décélération une valeur négative de la variation du module du vecteur vitesse.

Figure 4.5 — Tracé d’un ThumbRock réalisé par un droitieret identification des trois points caractéristiques : p0, p1 et p2

4.2.1. Algorithme

L'algorithme permettant de détecter un ThumbRock est décrit par la machine à états représentée dans la figure 4.6. Les cinq états représentent les différentes étapes à parcourir afin de reconnaître un ThumbRock. Les transitions entre états sont déclenchées par des caractéristiques dynamiques particulières. D'autres transitions, appelées transitions d'annulation, permettent de réinitialiser la séquence d'états lorsque des conditions temporelles ou spatiales, résumées dans le tableau 4.1, sont invalidées.

La seule dynamique permet de segmenter le ThumbRock pour identifier les points caractéristiques p0, p1 et p2 et les distances de l’axe majeur des surfaces de contact respectives. De ce fait, l’algorithme ne néces-site aucune segmentation explicite (pause, tap, etc.) de la part de l’utilisateur. Ainsi, un ThumbRock peut être réalisé au milieu d’un geste, alors que le pouce est déjà en contact avec la surface tactile.

Figure 4.6 — Machine à états décrivant l’algorithme du ThumbRock

p0

p1

p2

Surface de l'écran tactile

0

1

2

3

4

5

picd'accélération pic de

décélération

accélérationnulle :

stocker p1

picd'accélération

pic dedécélération

accélération nulle :stocker p2 et annoncer le ThumbRock

déplacement :stocker p0

annulationn:stocker p0


Annulationn Condition vraie si :

1 Le temps passé dans cet état est supérieur à t1

2

Le temps passé dans cet état est supérieur à t2 Lors de l’enregistrement de p1 :■ la distance avec p0 est en-dehors de [dmin, dmax]■ la longueur de l’axe majeur de la surface de contact n’est pas

plus grande que m fois celle de l’état 0



5 Le temps passé dans cet état est supérieur à t5 Lors de l’enregistrement de p2, la distance avec p0 est supérieure à derror

Tableau 4.1 — Description des différentes conditions d’annulation

Figure 4.7 — Postures successives du pouce réalisant un ThumbRockavec le profil dynamique et les différents états associés

0 1 2 3 4 5 0

accélérationmin, j

accélérationmax, i

0 Temps

États :

t1 t2 t3 t4 t5

Vue de dessus :

Phalange distale

Phalange médiale

Surface tactile

Position détectée

p0 p1 p2

Vue de profil :

Surface de contact :Axe majeur

i=1

j=1

i=2

j=2


4.2.2. Paramètres

Plusieurs paramètres viennent calibrer l’algorithme :

■ Temporels : t1, t2, t3, t4, t5

■ Spatiaux : dmin, dmax, derror, m

■ Dynamiques (spatiaux-temporels) : accelerationmax,1, accelerationmax,2, accelerationmin,1, accele-rationmin,2

Néanmoins, ce sont les paramètres dynamiques, spatiaux et t3 qui sont les plus importants. Les paramètres temporels restants n’ont d’utilité que d’optimiser l’algorithme et de le forcer à s’invalider suffisamment tôt pour éviter des calculs inutiles.

4.2.3. Implémentation

Le reconnaisseur est implémenté en Objective-C pour le système iOS en sous-classant UIGestureReco-gnizer, qui est lui-même une machine à états. Il peut alors être facilement associé à une vue, comme l’il-lustre l’extrait de code ci-dessous :

ThumbRockRecognizer thumbRockRecognizer = [[ThumbRockRecognizer alloc] initwithTarget:aDelegate action:@selector(handleThumbRock:)];[aView addGestureRecognizer: thumbRockRecognizer];

Comme le tap, le ThumbRock est un événement discret (contrairement au pinch, qui est un événement continu). Le reconnaisseur alterne alors entre trois états : possible, reconnu et échec.

Figure 4.7 — Transitions entre les états possibles pourun reconnaisseur de gestes continus et le ThumbRock

Contrairement aux autres reconnaisseurs, celui du ThumbRock reste essentiellement dans l’état possible car, durant la réalisation d’un geste, un ThumbRock est toujours possible. Lorsqu’il est reconnu, il ne passe pas à l’état reconnu, car le système cesse alors de fournir au reconnaisseur les nouveaux événe-ments de contact UITouch, jusqu’à ce que le doigt soit relevé. Ce mécanisme montre bien que le construc-teur n’a pas prévu le cas où un événement serait segmenté autrement qu’en touchant ou relevant un doigt de la surface tactile. Il faut alors appeler manuellement les méthodes servant de callback de son delegate et rester dans l’état possible.

L’inconvénient est qu’il n’est pas possible, dans ce cas, d’utiliser la méthode native d’annulation de ges-tes. Si un ThumbRock est réalisé dans un contexte où la forme du geste qu'il segmente est importante (par exemple: trait d'un dessin, tracé d'un chemin, …), il faut annuler la suite de points générés par la réalisa-

began possible recognized

changed

ended cancelled

failed

ThumbRockRecognizer statesContinuous recognizer states


tion du ThumbRock. L'application doit alors disposer d’une méthode semblable à la signature ci-dessous et stocker les derniers points sur la durée maximale du ThumbRock :

- (void)cancelPointsAmount:(int)amount;

Enfin, il passe à l’état échec lorsque plus aucun doigt ne touche la surface tactile, afin de se conformer à la documentation de l’API. Cet état inhibant également tout futur événement de contact UITouch, il ne peut pas être considéré tant que l’utilisateur touche la surface tactile ; même dans des cas où l’apparition d’un ThumbRock est quasiment improbable (par exemple, lorsqu’il y a plusieurs points de contacts).

4.2.4. Comparaison avec le clicNous remarquons plusieurs similarités entre le ThumbRock et le clic ou le tap :

■ Tous deux commencent et terminent au même point.

■ Tout comme il existe des clics rapides et des clics longs, on peut envisager des ThumbRocks dont la durée t3, qui correspond au temps durant laquelle la phalange distale reste plaquée sur la surface tactile, peut être plus ou moins longue.

■ Tous deux peuvent être annulés à mi-parcours par l’utilisateur s’il se rend compte suffisamment tôt qu’il a commis une erreur. Cependant, dans le cas du clic, il doit déplacer le curseur, en gar-dant le bouton de la souris enfoncé, en dehors de la zone qui reçoit le clic alors que pour le ThumbRock, il lui suffirait de rouler le pouce lentement en avant vers la position initiale.

Ces similitudes tendent à renforcer l’idée que le ThumbRock est bien un événement.

4.3. Calibration

Afin de déterminer les bons paramètres de l’algorithme, nous avons préparé une séance d’enregistrement de vrais et faux ThumbRocks. Les vrais ThumbRocks sont enregistrés avec différentes conditions de début et de fin, ce qui permet d’obtenir un nombre important d’exemples variés qui renforcent la validité écolo-gique de son utilisation. Les faux ThumbRocks permettent de vérifier que l’algorithme ne détectera pas, ou bien très peu, de faux positifs, ce qui justifiera l’indépendance du ThumbRock face aux autres gestes et événements gestuels.

À l’issue de cette collecte de données, nous souhaitons également analyser les résultats afin de pouvoir répondre aux questions techniques suivantes :

■ L’amplitude des deuxièmes pics d’accélération et de décélération est-elle fonction de celle des premiers pics d’accélération et de décélération ? Durant l’étude préliminaire, nous avons vu qu’ils étaient systématiquement plus faibles.

■ Les points p0, p1 et p2 sélectionnés par le profil dynamique correspondent-ils exactement aux points définis de façon géométrique ? Quel serait le décalage entre ces deux méthodes de sélec-tion ?


4.3.1. Choix de la grille de positions

Plusieurs grilles ont été envisagées. La littérature existante ne propose qu’un exemple comparable, celui de l’étude des MicroRolls, qui emploie une grille 3x3. Dans des contextes proches (domaine de l’utilisa-tion en mobilité), des études faisant intervenir les claviers physiques des anciens téléphones ont égale-ment divisé l’écran avec une grille 3x3 (ZoneZoom, Robbins et al., 2004), d’autres utilisent des grilles 4x4 (Imaginary Interfaces). Aucune étude ne justifie le choix de la grille. Nous avons alors motivé le nôtre en fonction de différents critères :

■ Avoir une résolution assez fine pour couvrir l’ensemble de la surface tactile.

❏ Cela implique d’avoir des positions sur le bord et aux coins de l’écran.

■ Obtenir différents niveaux de difficulté de réalisation du ThumbRock (qui évoluent en arc de cercle à peu près autour de la jointure proximale du pouce).

■ Ne pas avoir trop de points afin d’éviter de complexifier inutilement l’analyse.

Figure 4.8 — Différentes grilles de positions envisagées

Après quelques essais, la grille répondant à ces critères est la grille 4x4.

4.3.2. Vrais ThumbRocks

La première partie de la collecte de données consiste à enregistrer des ThumbRocks que l’algorithme de-vra être en mesure de reconnaître. Faire varier la dynamique au début et à la fin d'un ThumbRock nous semble nécessaire puisque c'est cette caractéristique qui est le pilier principal dans la reconnaissance du ThumbRock. Les trois types d’événements basiques qu’il est possible de faire avant et après un Thum-bRock sont : pause, contact / relâchement et déplacement. Ils ont des dynamiques (notamment, la vi-tesse) différentes. Elle est :

■ nulle pour la pause,

■ positive pour les deux autres, avec un sens de déplacement variable :

❏ perpendiculaire par rapport à la surface tactile pour le contact / relâchement,

❏ sur le plan pour le déplacement.

En considérant deux axes de déplacement (l’un est vertical, l’autre est horizontal) autour de la position du ThumbRock, chacun dans les deux sens (respectivement nord/sud, sud/nord et ouest/est, est/ouest), nous capturons ainsi des ThumbRocks dans la plupart des contextes.

4x4 4x5 4x6

Thumb proximal axis


Tâche : La tâche consiste à effectuer un ThumbRock sur chacune des 16 positions de l'écran, en l'enca-drant avec l'un des trois types d'événements (pause, contact/relâchement, déplacement). Les positions sont indiquées à l'utilisateur par une croix de 4cm d'envergure. Les participants tiennent le dispositif avec leur main dominante et interagissent avec le pouce. Durant tout la durée de l'expérience, ils peuvent reposi-tionner leur main sur l'appareil tant qu'ils ne s'aident pas de l'autre main. Au début de chaque bloc, un message indique quel événement doit être utilisé pour encadrer le ThumbRock. La tâche diffère en fonc-tion de l’événement :

■ Pause : le participant pose le pouce sur la cible puis attend 300ms avant de faire un ThumbRock. Ensuite, il attend à nouveau 300ms avant de relever le doigt. Un feedback sonore et visuel, décrit dans la figure 4.9, informe de l’écoulement des durées.

Figure 4.9 — Enregistrement d’un ThumbRock entre deux événements pause

■ Contact / relâchement : le participant pose le pouce sur la cible, fait un ThumbRock, puis relève immédiatement le pouce.

■ Déplacement : le participant pose le pouce sur la première extrémité du segment, glisse le pouce le long du segment jusqu’à être au milieu de la croix, fait un ThumbRock, puis poursuit jusqu’à l’autre extrémité du segment. Là encore, un feedback sonore et visuel signale lorsque le pouce est au centre de la croix.

Matériel : Les techniques ont été implémentées en Objective-C (Cocoa Touch) et fonctionnent sur iOS 4.2. L’expérience a été réalisée sur un iPod touch de seconde génération (résolution : 640x480 px, densité : 163 ppi) relié par wifi à un ordinateur portable sur lequel tourne Touchstone (Mackay et al., 2007).

Design expérimental : Un carré latin a été utilisé pour contrebalancer l’ordre des séries de 3 blocs (dont un d'entraînement) de 16 positions entre les participants. Les positions au sein d'un bloc sont aléatoires.

Pour résumer, le design expérimental est le suivant : 16 Positions x (1+1+4) Événements encadrant x (2+1) Répétitions = 288 ThumbRocks (15 minutes) par participant.

4.3.3. Faux ThumbRocks

La seconde partie consiste à mimer des ThumbRocks afin de tester la robustesse de l’algorithme en s’assu-rant qu’il ne les reconnaisse pas.

Figure 4.10 — Étapes de l’enregistrement de ThumbRocks pour une position.

Contact

ThumbRockPause Pause

Relâchement

300 ms 300 ms

Couleur du fond de l'écran

Temps

p0

p1

p0'

p1'

A — Recording phase B — Axis computation C — Mimic phase


Pour cela, nous utilisons les points p0 et p1 des ThumbRocks enregistrés précédemment qui ont été enca-drés par des événements pause pour déterminer un segment qui représente l’axe moyen (figure 4.10).

Tâche : La tâche consiste à faire 3 mouvements de va-et-vient le long de chacun des 16 segments. Les participants tiennent le dispositif de la même manière qu’à la première étape. Au début de chaque bloc, un message indique de quelle manière il faut faire ces opérations de va-et-vient :

■ Le plus précisément possible, en s’écartant peu de la trajectoire fixée par le segment.

■ Le plus rapidement possible.

Dans les deux cas, un feedback sonore et visuel informe le participant à chaque fois qu’il atteint une ex-trémité du segment (figure 4.11).

Figure 11 — Feedback sonore et visuel durant l’enregistrement du va-et-vient.

Design expérimental : Un carré latin a été utilisé pour contrebalancer l’ordre des séries de 3 blocs (dont un d'entraînement) de 16 segments entre les participants. Les segments sont présentés dans un ordre aléa-toire au sein d'un bloc et sont propres à un participant.

Pour résumer, le design expérimental est le suivant : 16 Segments x 2 Types de va-et-vient x (2+1) Répéti-tions x 3 Va-et-vient = 288 Faux ThumbRocks (10 minutes) par participant.

4.3.4. Mesures

Nous enregistrons, pour chaque point détecté, sa position, l’instant à laquelle il a été détecté et la taille de l’axe majeur de la surface de contact.

La récolte de données étant en cours de réalisation, nous ne pouvons pas encore décrire les résultats. En nous basant sur les études préliminaires, nous sommes néanmoins certains que l’algorithme est en mesure de détecter efficacement un ThumbRock avec un taux d’erreur minimal.

répété 3 fois

Contact Relâchement

Couleur du fond de l'écran

Position sur le segment

Temps

P0

P1

P0


5. Conclusion

Une analyse critique de l'état de l'art a permis de motiver la conception de deux techniques complémen-taires, plus précisément un menu et un événement, qui étendent considérablement l'interaction dans le contexte d'une utilisation à une main d'un dispositif mobile. Avec le pouce, l'utilisateur peut faire un ThumbRock pour invoquer SAM et accéder ainsi à l'ensemble des fonctions proposées par la plupart des applications.

La dynamique du geste est utilisée, dans SAM, pour mieux comprendre les intentions de l’utilisateur dans le mode expert. Dans le ThumbRock, elle est mise au service de la segmentation afin de faciliter la détec-tion de cet événement.

Des travaux futurs permettent de les étendre. Notamment, SAM pourrait recevoir de nouveaux types d’éléments qui seraient en mesure de définir des paramètres sur plusieurs dimensions en proposant une interaction plus efficace que celles proposées par les techniques actuelles. Aussi, le cas de l'utilisation d'un élément circulaire dans SAM nous a suscité l'idée de permettre à l'utilisateur de se focaliser sur la dyna-mique du geste en contraignant la trajectoire du palet à des formes précises. Un projet en cours d'élabora-tion consiste à faire de même, mais avec des gestes emblématiques. Il s'agit de fixer un palet sur un en-semble de rails prédéfinis qui contiendraient des indices visuels pour informer de la vitesse à laquelle réaliser le geste afin de déclencher la commande désirée. Cependant, SAM nous a aussi montré qu'un ac-cessoire virtuel tel qu'un élastique et le pointage indirect peuvent conditionner les gestes de l'utilisateur au niveau de l'accélération. Explorer d’autres guides de ce genre est une piste envisagée.

Enfin, l’approche utilisée pour le ThumbRock, qui consiste à utiliser des machines à états pour décrire la dynamique du geste, nous semble être un modèle prometteur qui pourrait s’appliquer à bien d’autres types de gestes. Par ailleurs, le caractère descriptif de ces machines à états permettrait d'en extraire facilement des guides visuels explicites, que nous envisageons d'explorer par la suite.


Références

P. Agar et K. Novins, « Polygon recognition in sketch-based interfaces with immediate and continuous feedback », in Proceedings of the 1st international conference on Computer graphics and interactive techniques in Australasia and South East Asia, New York, NY, USA, 2003, p. 147–150.

C. Appert et O. Bau, « Scale detection for a priori gesture recognition », Proceedings of the 28th international con-ference on Human factors in computing systems, p. 879–882, 2010.

C. Appert et S. Zhai, « Using strokes as command shortcuts: cognitive benefits and toolkit support », in Proceedings of the 27th international conference on Human factors in computing systems, New York, NY, USA, 2009, p. 2289–2298.

J. Arvo et K. Novins, « Fluid sketches: continuous recognition and morphing of simple hand-drawn shapes », Pro-ceedings of the 13th annual ACM symposium on User interface software and technology, p. 73–80, 2000.

G. Bailly, E. Lecolinet, et L. Nigay, « Quinze ans de recherche sur les menus: critères et propriétés des techniques de menus », in Proceedings of the 19th International Conference of the Association Francophone d’Interaction Homme-Machine, New York, NY, USA, 2007, p. 119–126.

G. Bailly, E. Lecolinet, et L. Nigay, « Flower menus: a new type of marking menu with large menu breadth, within groups and efficient expert mode memorization », Proceedings of the working conference on Advanced visual inter-faces, p. 15–22, 2008.

R. Balakrishnan, G. Fitzmaurice, G. Kurtenbach, et W. Buxton, « Digital tape drawing », in Proceedings of the 12th annual ACM symposium on User interface software and technology, New York, NY, USA, 1999, p. 161–169.

O. Bau et W. E. Mackay, « OctoPocus: a dynamic guide for learning gesture-based command sets », Proceedings of the 21st annual ACM symposium on User interface software and technology, p. 37–46, 2008.

T. Baudel, « A mark-based interaction paradigm for free-hand drawing », in Proceedings of the 7th annual ACM symposium on User interface software and technology, New York, NY, USA, 1994, p. 185–192.

E. A. Bier, M. C. Stone, K. Pier, W. Buxton, et T. D. DeRose, « Toolglass and magic lenses: the see-through interfa-ce », in Proceedings of the 20th annual conference on Computer graphics and interactive techniques, New York, NY, USA, 1993, p. 73–80.

B. Boie, Multi-Touch Touch Screen, Bell Labs, Murray Hill, N.J., 1984.

A. Bragdon, A. Uguray, D. Wigdor, S. Anagnostopoulos, R. Zeleznik, et R. Feman, « Gesture play: motivating online gesture learning with fun, positive reinforcement and physical metaphors », ACM International Conference on Inter-active Tabletops and Surfaces, p. 39–48, 2010.

S. J. Castellucci et I. S. MacKenzie, « Graffiti vs. unistrokes: an empirical comparison », Proceeding of the twenty-sixth annual SIGCHI conference on Human factors in computing systems, p. 305–308, 2008.

S. Chatty et P. Lecoanet, « Pen computing for air traffic control », in Proceedings of the SIGCHI conference on Hu-man factors in computing systems: common ground, New York, NY, USA, 1996, p. 87–94.

T. Cranston et F. Longstaff, Trackball, Ferranti Canada.

M.R. Davis et T.O. Ellis, The Rand Tablet: A Man-Machine Graphical Communication Device, Proceedings of the Fall Joint Computer Conference, 1964a, 325.

Ebeling, F.A., Johnson, R.L. & Goldhor, R.S., Uof Illinois, Champaign. Infrared Light beam x-y position encoder for display devices. US Patent 3,775,560, Filed Feb 1972 / Issued Nov. 1973.

W.K. English et D.C. Engelbart, Display Selection Techniques for Text Manipulation, IEEE Transactions on Human-Factors in Electronics, 1967, 8(1), 5-15.


D. Freeman, H. Benko, M. R. Morris, et D. Wigdor, « ShadowGuides: visualizations for in-situ learning of multi-touch and whole-hand gestures », Proceedings of the ACM International Conference on Interactive Tabletops and Surfaces, p. 165–172, 2009.

D. Goldberg et C. Richardson, « Touch-typing with a stylus », in Proceedings of the INTERACT ’93 and CHI '93 conference on Human factors in computing systems, New York, NY, USA, 1993, p. 80–87.

F. Guimbretière et T. Winograd, « FlowMenu: combining command, text, and data entry », Proceedings of the 13th annual ACM symposium on User interface software and technology, p. 213–216, 2000.

B.M. Gurley et C.E. Woodward, Light-pen links computer to operator, Electronics, 1966, 32, 85-87.

S. Gustafson, D. Bierwirth, et P. Baudisch, « Imaginary interfaces: spatial interaction with empty hands and without visual feedback », Proceedings of the 23nd annual ACM symposium on User interface software and technology, p. 3–12, 2010.

M. Hashimoto et M. Togasi, « A virtual oval keyboard and a vector input method for pen-based character input », in Conference companion on Human factors in computing systems, New York, NY, USA, 1995, p. 254–255.

HP-150 touchscreen personal computer with HP 9121 dual drives, 1983 : http://www.hp.com/hpinfo/abouthp/histnfacts/ museum/personalsystems/0031/

P. Isokoski et M. Käki, « Comparison of two touchpad-based methods for numeric entry », Proceedings of the SIGCHI conference on Human factors in computing systems: Changing our world, changing ourselves, p. 25–32, 2002.

S. Izadi et al., « ThinSight: a thin form-factor interactive surface technology », Communications of the ACM, vol. 52, p. 90–98, déc. 2009.

Johnson, E.A. (1965). Touch Display – A novel input/output device for computers. Electronics Letters, 1(8), 219-220.

Karlson, A.K. et Bederson, B.B. One-handed touchscreen input for legacy applications. Proceeding of the twenty-sixth annual SIGCHI conf. on Human factors in computing systems, ACM (2008), 1399–1408.

P.-O. Kristensson et S. Zhai, « SHARK2: a large vocabulary shorthand writing system for pen-based computers », in Proceedings of the 17th annual ACM symposium on User interface software and technology, New York, NY, USA, 2004, p. 43–52.

G. Kurtenbach, T. P. Moran, et W. Buxton, « Contextual animation of gestural commands », COMPUTER GRAPHICS FORUM, vol. 13, p. 83--90, 1994.

G. Kurtenbach et W. Buxton, « Issues in combining marking and direct manipulation techniques », Proceedings of the 4th annual ACM symposium on User interface software and technology, p. 137–144, 1991.

G. Kurtenbach et W. Buxton, « The limits of expert performance using hierarchic marking menus », Proceedings of the INTERACT ’93 and CHI '93 conference on Human factors in computing systems, p. 482–487, 1993.

Y. Li, « Protractor: a fast and accurate gesture recognizer », Proceedings of the 28th international conference on Hu-man factors in computing systems, p. 2169–2172, 2010.

J. Long, J. A. Landay, L. A. Rowe, et J. Michiels, « Visual similarity of pen gestures », Proceedings of the SIGCHI conference on Human factors in computing systems, p. 360–367, 2000.

Metha, Nimish (1982), A Flexible Machine Interface, M.A.Sc. Thesis, Department of Electrical Engineering, Univer-sity of Toronto.

M. Nancel, S. Huot, et M. Beaudouin-Lafon, « Un espace de conception fondé sur une analyse morphologique des techniques de menus », Proceedings of the 21st International Conference on Association Francophone d’Interaction Homme-Machine, p. 13–22, 2009.

K. Perlin, « Quikwriting: continuous stylus-based text entry », in Proceedings of the 11th annual ACM symposium on User interface software and technology, New York, NY, USA, 1998, p. 215–216.

S. Pook, E. Lecolinet, G. Vaysseix, et E. Barillot, « Control menus: excecution and control in a single interactor », CHI ’00 extended abstracts on Human factors in computing systems, p. 263–264, 2000.

Roudaut, A., Huot, S., et Lecolinet, E. TapTap and MagStick: improving one-handed target acquisition on small touch-screens. Proc. of the working conf. on Advanced visual interfaces, ACM (2008), 146–153.


A. Roudaut, E. Lecolinet, et Y. Guiard, « MicroRolls: expanding touch-screen input vocabulary by distinguishing rolls vs. slides of the thumb », Proceedings of the 27th international conference on Human factors in computing sys-tems, p. 927–936, 2009.

D. Rubine, « Specifying gestures by example », ACM SIGGRAPH Computer Graphics, vol. 25, p. 329–337, juill. 1991.

D. Sakamoto, K. Honda, M. Inami, et T. Igarashi, « Sketch and run: a stroke-based interface for home robots », Pro-ceedings of the 27th international conference on Human factors in computing systems, p. 197–200, 2009.

I. E. Sutherland, « Sketchpad: a man-machine graphical communication system », Proceedings of the May 21-23, 1963, spring joint computer conference, p. 329–346, 1963.

T. Tsandilas, C. Letondal, et W. E. Mackay, « Musink: composing music through augmented drawing », in Procee-dings of the 27th international conference on Human factors in computing systems, New York, NY, USA, 2009, p. 819–828.

J. O. Wobbrock, A. D. Wilson, et Y. Li, « Gestures without libraries, toolkits or training: a $1 recognizer for user in-terface prototypes », Proceedings of the 20th annual ACM symposium on User interface software and technology, p. 159–168, 2007.

R. C. Zeleznik, K. P. Herndon, et J. F. Hughes, « SKETCH: an interface for sketching 3D scenes », Proceedings of the 23rd annual conference on Computer graphics and interactive techniques, p. 163–170, 1996.

S. Zhai et P.-O. Kristensson, « Shorthand writing on stylus keyboard », in Proceedings of the SIGCHI conference on Human factors in computing systems, New York, NY, USA, 2003, p. 97–104.

Zhai, S., Kristensson, P.O., Gong, P., et al. Shapewriter on the iphone: from the laboratory to the real world. Procee-dings of the 27th international conference extended abstracts on Human factors in computing systems, ACM (2009), 2667–2670.

S. Zhao et R. Balakrishnan, « Simple vs. compound mark hierarchical marking menus », Proceedings of the 17th annual ACM symposium on User interface software and technology, p. 33–42, 2004.


Stage de Master 2 Recherche en Informatique -...

Documents

Transcript of Stage de Master 2 Recherche en Informatique -...