Soutenance mémoire
Télécharger le fichier pdf d’un mémoire de fin d’études
Gestion de fenêtres
Le composant du système permettant à l’utilisateur d’interagir avec les fenêtres et de les manipuler est appelé le gestionnaire de fenêtres. Nous suivons ici la ter-minologie de Myers [85] qui parle de “système de fenêtrage” pour les couches de bas niveau (rendu des fenêtres et capture des entrées) et utilise “gestionnaire de fenêtres” pour la partie qui se charge de l’interaction avec l’utilisateur : décoration des fenêtres, placement des fenêtres, opération de déplacement, iconification. . .
Le modèle de gestionnaire de fenêtres le plus répandu est celui dit des fenêtres recouvrantes. Dans ce modèle, les fenêtres sont disposées dans un espace en deux dimensions mais possèdent également une profondeur, c’est pourquoi certains qua-lifient parfois ce type d’espace de 2D 1/2 [23]. Les fenêtres peuvent donc se che-vaucher, une fenêtre plus “haute” que les autres masque tout ou partie de celles qui se trouvent en dessous.
Cependant ce modèle de fenêtrage (ou de partage des ressources écran) a mon-tré ses limites et surtout son incapacité à passer à l’échelle. On pourrait intituler ce mode de fonctionnement d’allocation manuelle d’espace d’affichage. Comme toute opération manuelle, si le nombre d’objets à allouer devient trop grand, l’utilisateur devient vite surchargé par la tâche d’allocation.
La recherche en IHM et l’industrie aussi bien que des développeurs indépen-dants enthousiastes ont tenté depuis plusieurs décennies de pallier à ces problèmes. Ces solutions vont de la conception de nouvelles interactions pour faciliter certains aspects de la gestion des fenêtres recouvrantes (typiquement le changement de fe-nêtre) à la conception de tout autre moyen de partager l’espace d’affichage.
Allocation de l’Espace d’Affichage
Un des problèmes majeurs de la gestion de fenêtres est l’allocation de l’espace d’affichage en deux dimensions, constitué par le (ou les) écran(s), aux différents contenus que l’utilisateur veut visualiser.
Alternatives au Chevauchement de Fenêtres
S’intéressant aux problèmes introduits par le recouvrement des fenêtres qui induit des zones invisibles pour l’utilisateur, une idée simple fait son apparition rapidement : ne plus permettre aux fenêtres de se chevaucher. Ce type de gestion-naires de fenêtres, par pavage de l’écran, a fait l’objet d’une étude dès 1986 [18] en le comparant au système de fenêtrage par chevauchement déjà considéré comme le fonctionnement prédominant. L’avantage de ce mode d’opération est de décharger l’utilisateur de nombreuses opérations de gestion des fenêtres par une gestion par-tiellement automatique de l’espace d’affichage mais au détriment du contrôle de l’utilisateur sur son espace d’affichage.
Afin de maximiser l’espace d’affichage utilisé, ce type de gestionnaire de fe-nêtres adopte souvent un comportement de remplissage : les fenêtres occupent le plus d’espace possible. Les premières versions du Xerox Star possédaient un ges-tionnaire de fenêtre qui utilisait un algorithme de placement des fenêtres conçu pour paver la surface de l’écran lorsque cela était possible.
Parmi les systèmes les plus populaires utilisés actuellement on peut citer Xmo-nad [109], Ion 2 et Ratpoison 3. Ces gestionnaires de fenêtres ont été conçus pour une utilisation sur des ordinateurs portables et une interaction au clavier et per-mettent plus ou moins facilement et plus ou moins interactivement de modifier la façon dont le système dispose et redimensionne les fenêtres. Par exemple, Xmonad dispose d’un grand nombre d’agencements pensés pour des scénarios d’utilisation particuliers : Gimp, fenêtres de messagerie instantanée. . .
Elastic Windows [65] fait figure d’exception au sein des gestionnaires de fe-nêtres par pavage. Ce gestionnaire propose en effet, en plus des caractéristiques exposées ci-dessus, une gestion groupée et hiérarchique des fenêtres. Plusieurs fe-nêtres peuvent être regroupées au sein d’une nouvelle fenêtre, elle-même pouvant être groupée avec d’autres fenêtres. Ces regroupements créent une hiérarchie de fenêtres sur laquelle il est possible d’interagir à tous les niveaux. L’allocation de l’espace d’affichage est gérée par le système sous forme de TreeMap [13] permet-tant d’utiliser la totalité de la surface d’affichage. Pour chaque groupe de fenêtres, ces dernières sont pavées dans leur fenêtre englobante de manière à occuper en-tièrement l’espace disponible. L’écran constitue la racine de cette hiérarchie (Fi-gure 1.3).
Scheme Constraints Window Manager (SCWM) [8] est un autre exemple de gestionnaire de fenêtres qui automatise la gestion de l’espace d’affichage. SCWM propose d’augmenter un gestionnaire classique, permettant le chevauchement de fenêtres, avec des contraintes entre fenêtres définies par l’utilisateur et gérées par un algorithme de résolution de contraintes [7]. Cependant les interactions pour spécifier les contraintes sont peu naturelles et reposent majoritairement sur des boites de dialogues de style “formulaire”.
La Tâche au Cœur de la Gestion de Fenêtres
Une autre piste largement explorée pour simplifier la gestion de fenêtres en réduisant le nombre d’entités à gérer simultanément tout en conservant la simplicité et la versatilité des gestionnaires de fenêtres classiques est d’introduire la notion de tâche ou d’activité. Cette notion, parfois définie de façon floue, permet de réduire le nombre de fenêtres en les groupant par utilisation et en n’affichant à un moment donné que les fenêtres utiles. En quelque sorte, la prise en compte des tâches ou des activités permet de diviser pour mieux régner.
L’incarnation la plus simple de ce principe se trouve dans les Espaces de Tra-vail Virtuels et fut introduit par Rooms [51] en 1986 : Chaque pièce (“room”) contient ses propres fenêtres. Une seule pièce est affichée à un instant donné, et l’on peut passer d’une pièce à l’autre par des portes. Dans certains systèmes, il est possible de définir des fenêtres qui sont affichées dans toutes les pièces, comme par exemple une horloge ou une application de messagerie. Cette solution, relati-vement simple, a rapidement été adoptée par nombre de gestionnaires de fenêtre destinés au système de fenêtrage X Window. Elle n’a fait son apparition que récem-ment en standard sous Mac OS X avec Spaces et est toujours absente (par défaut) de Microsoft Windows.
Une autre forme de groupement des fenêtres consiste à les imbriquer. Ainsi, dans d’anciennes versions de Windows, une application qui gére plusieurs docu-ments consiste en un fenêtre représentant l’application, elle-même contenant une fenêtre pour chaque document. En pratique, les utilisateurs ont tendance à maximi-ser la fenêtre de l’application, reproduisant ainsi un modèle proche de Rooms mais contraint par le fait que seuls les documents d’une même application peuvent être affichés ensemble.
D’autres systèmes ont par la suite étendu et amélioré le concept de tâche. Parmi les plus marquants, se trouvent des gestionnaires de fenêtres comme Task Gal-lery [98] qui introduit la 3ème dimension (voir la Figure 1.4). D’autres implémen-tations raffinent le concept de tâche et en améliore la prise en considération dans le gestionnaire de fenêtres. Parmi eux se trouve WindowScape [116] qui propose de prendre des “instantanés” de l’organisation de l’espace d’affichage à un moment donné afin de pouvoir y revenir ultérieurement par un simple clic.
Pour sa part, Scalable Fabric [97] propose d’utiliser un système de “focus + contexte” pour gérer les tâches de l’utilisateur. Dans la partie centrale de l’écran, les fenêtres se comportent normalement. Mais lorsque l’utilisateur déplace une fenêtre vers un bord de l’écran, celle-ci réduit sa taille pour ne plus occuper qu’une petite partie de l’espace d’affichage. Lors de leur déplacement sur les bords de l’écran il est également possible d’approcher une fenêtre soit d’une autre fenêtre pour créer un groupe, soit d’un groupe pour l’y ajouter. Nommer un groupe de fenêtres crée une tâche. Cliquer sur une fenêtre ou un groupe de fenêtres a pour effet de replacer tous les éléments à leur place antérieure.
Enfin, Elastic Windows [65] permet de regrouper les fenêtres en tâches elles-mêmes peuvant être regroupées, créant ainsi une hérarchie de fenêtres. Il est pos-sible d’appliquer des opérations à n’importe lequel de niveau hérarchique. Ces propriétés alliées à l’organisation des fenêtres par pavage 1.3 d’Elastic Windows permettent une gestion aisée des tâches. Par exemple, un programmeur pourrait organiser son espace en fonction des projets sur lesquels il travail, chaque projet se subdivisant en documentation et fichiers édités. Ainsi, le changement de projet deviens facile : paquer le projet courant puis dépaquer le projet suivant. De même lorsque l’utilisateur n’a pas besoin de la documentation, celle-ci peut rester paqué libérant de l’espace d’affichage pour l’édition des fichiers.
Contourner le Chevauchement
La possibilité de chevauchement des fenêtres est un avantage puisqu’elle per-met d’étendre virtuellement la surface d’affichage en rendant possible l’affichage de plus d’informations que ne le permettrait normalement l’écran. Cependant, elle entraîne une surcharge de manipulations pour l’utilisateur qui doit alors gérer ce recouvrement. Plusieurs tentatives ont été faites au cours du dernier quart de siècle pour résoudre le problème d’allocation par différentes techniques d’interaction semi-automatiques aidant l’utilisateur à gérer au mieux son espace d’affichage tout en permettant de garder cette possibilité de chevauchement.
Ishak et Feiner [62] (voir aussi [117]) proposent d’utiliser la transparence de façon contrôlée (uniquement sur des parties non importantes d’une fenêtre) pour visualiser le contenu, normalement caché de fenêtres recouvertes (partiellement ou complètement). Ils proposent également de pouvoir interagir avec le contenu ainsi découvert.
En améliorant une technique simple pour trouver l’emplacement idéal pour pla-cer un rectangle, sans recouvrement avec d’autres rectangles déjà placés [15], Bell et Feiner [14] proposent une représentation de l’espace d’affichage permettant de placer les fenêtres, qu’elles soient créées ou déplacées, à un emplacement empê-chant le recouvrement des fenêtres existantes. Cette technique permet de bénéficier de nombre des avantages des gestionnaires de fenêtres par pavage tout en conser-vant les avantages offerts par la possibilité de faire chevaucher les fenêtres. Dans le même ordre d’idée, Hutchings et Stasko [59] définissent deux nouvelles opéra-tions sur une (des) fenêtre(s) afin de faire “grandir” celle(s)-ci le plus possible sans qu’elle ne recouvre les autres fenêtres. La première opération agrandit simplement la fenêtre courante jusqu’à ce que ses bords ne buttent sur d’autres fenêtres. La se-conde, en plus d’agrandir la fenêtre courante, pousse également les autres fenêtres jusqu’à ce que l’ensemble des fenêtres occupe tout l’espace d’affichage disponible (l’écran) sans chevauchement.
Métisse [26], un système de fenêtrage X Window expérimental comportant un gestionnaire de fenêtres qui effectue son rendu en OpenGL, a exploré d’autres façons de réduire les chevauchements. Ainsi, Métisse propose à l’utilisateur des opérations de zoom et de rotation 3D pouvant être utilisées pour réduire le recou-vrement entre fenêtres. Le zoom est différent du redimensionnement car il applique un facteur d’échelle uniforme à tout le contenu de la fenêtre, ce qui évite de chan-ger son agencement. La rotation produit l’effet d’une porte que l’on ouvre, l’effet de perspective permettant de réduire sa largeur.
Autres Solutions
Devant la faible évolution des systèmes de fenêtrage ou tout du moins la faible adoption des avancées de la recherche dans les systèmes les plus répan-dus, les concepteurs d’applications ont commencé à implémenter eux-mêmes de mini-gestionnaires de contenus.
Les bibliothèques de composants graphiques de nombre de boîtes à outils de construction de logiciel (QT ou Java/Swing par exemple) fournissent en standard des espaces d’affichage pouvant contenir leurs propres fenêtres. Ces fenêtres sont très souvent “dockables”. Ceci signifie que, si l’utilisateur les approche du bord de la zone d’affichage, ces fenêtres se collent au bord, délaissant leur habillage et se comportant alors comme une boîte à outils. Ces mêmes bibliothèques proposent bien souvent la gestion plus ou moins avancée d’onglets qui sont un autre moyen de partager les ressources d’interaction entre différents contenus. Ce système d’on-glets a d’ailleurs été utilisé en 2001 par Beaudouin-Lafon [12] comme une manière d’améliorer les gestionnaires de fenêtres par chevauchement.
Un autre exemple de cette mouvance sont les navigateurs Internet. Ces logi-ciels se sont vus forcés d’évoluer fortement depuis ces dix dernières années devant l’explosion de l’utilisation de l’Internet et l’apparition de nombreuses applications en ligne et du “cloud computing”. Les utilisateurs passent de plus en plus de temps uniquement dans le navigateur qui devient peu à peu le nouveau “système”. Or, les développeurs de ces navigateurs ont depuis longtemps compris les limitations des systèmes de fenêtrage classique. Depuis ses débuts, Internet est surtout utilisé comme une ressource documentaire. De ce fait, une session de navigation sur Inter-net est le plus souvent une tâche d’exploration générant l’ouverture d’une multitude de pages Internet entraînant rapidement une surcharge des capacités de gestion de l’utilisateur muni des outils qui lui sont fournis par le système. Les concepteurs de navigateurs ont alors opté pour gérer l’ouverture des pages au sein même de leur application et ont adopté les onglets comme éléments de base, plus adaptés que les fenêtres recouvrantes pour l’exploration d’Internet : un onglet ouvert plus récem-ment est placé à droite d’un onglet ouvert il y a plus longtemps. Cette tendance s’accentue : À l’heure où les navigateurs Internet veulent devenir les nouveaux systèmes d’exploitation, ils continuent d’intégrer bien plus rapidement les éléments issus de la recherche que ne le font les systèmes traditionnels. Par exemple, le navi-gateur Firefox intègre un gestionnaire de pages qui propose les fonctions d’Exposé d’Apple et de bureau virtuel dans son outil Panorama [93] (Figure 1.6).
10/GUI 4 propose une approche différente de la gestion de fenêtres. Ce sys-tème prône l’utilisation d’une surface tactile multi-points à la place de la souris. Cette surface, aux dimensions de l’écran, permet une correspondance 1 :1 entre l’espace d’interaction et l’espace d’affichage. Au contraire des dispositifs mobile actuels, la surface tactile n’est pas confondue avec l’écran mais prends la place de la souris pour éviter les problèmes d’occlultation. 10/GUI cherche à simplifier la gestion des fenêtres en la limitant à une tâche en une seule dimension. Les fenêtres sont disposées linéairement, apparaissant à droite de l’écran et poussant les fe-nêtres précédentes vers la gauche, possiblement hors de vue. Les fenêtres occupent toutes la hauteur de l’écran et ne sont redimensionnables qu’en largeur. La puis-sance d’expression nécessaire à la gestion des fenêtres vient alors de l’utilisation de la technologie tactile multi-points. 10/GUI propose un vocabulaire de gestes dont la sémantique, c’est-à-dire la correspondance avec les commandes, dépend fonction du nombre de doigts utilisés. Les interactions avec un ou deux doigts sont destinées aux applications, alors que les interaction utilisant trois ou quatre doigts sont destinées au système. Il est ainsi possible de dezoomer pour avoir une vue plus large du ruban formé par les applications afin de trouver celle que l’on désire, réarranger les fenêtres ou tout simplement faire défiler le ruban.
Sélection et Changement de Fenêtre
La seconde opération essentielle d’un gestionnaire de fenêtres est la sélection de la fenêtre courante. Fondamentalement, cette opération se réduit à un problème de recherche. L’utilisateur à une idée de l’information qu’il recherche. Il doit re-trouver la fenêtre qui contient cette information parmi toutes celles actuellement ouvertes. Cette sélection est typiquement effectuée de trois manières différentes :
– À l’aide de la souris : L’utilisateur connaît déjà la fenêtre hébergeant l’infor-mation recherchée et au moins une partie de cette fenêtre est actuellement visible. Selon le système et les préférences de l’utilisateur, deux variantes d’activation sont généralement disponibles : 1) Le système considère que la fenêtre active est celle sous le curseur de la souris (“focus follows mouse”) ; 2) Le système considère que la fenêtre active est la dernière dans laquelle l’utilisateur a cliqué (“click to focus”).
– À l’aide du clavier : Une combinaison de touches tapées sur le clavier (gé-néralement Alt-Tab) permet de sélectionner successivement toutes les fe-nêtres. Là encore, plusieurs possibilités existent, allant d’une simple liste contenant le titre de chaque fenêtre à des miniature en temps réel des fe-nêtres.
– À l’aide d’objets tiers, comme la barre des tâches sous Windows ou tout autre système d’icônes.
|
Table des matières
1 Introduction & Motivations
1.1 La Notion de Fenêtre
1.2 Gestion de fenêtres
1.2.1 Allocation de l’Espace d’Affichage
Alternatives au Chevauchement de Fenêtres
La Tâche au Coeur de la Gestion de Fenêtres
Contourner le Chevauchement
Autres Solutions
1.2.2 Sélection et Changement de Fenêtre
1.3 Spatialité, Stabilité et Localité d’Interaction
1.4 Le problème
2 Power Tools
2.1 Introduction
2.2 Interaction avec des Historiques de Sélection, de Déplacement et de Copie
2.3 Comparaison de TimeShit à d’autres mécanisme d’historiques
2.4 DeskPop
2.5 StackLeafing
2.6 Couches de Fenêtres
2.7 Implémentation
2.8 Conclusion
3 Pointage sur Cibles Animées ou Surgissantes
3.1 Introduction
3.2 Motivations dans le cadre de la thèse
3.3 Expérience
3.3.1 Matériel
3.3.2 Participants
3.3.3 Tâche et procédure
3.3.4 Protocole
3.4 Résultats
3.5 Analyse Cinématique
3.6 Étendre la loi de Fitts
3.7 Conclusion
4 Perception de la Profondeur
4.1 Introduction
4.2 La tâche
4.3 Sujets et Matériel Utilisé
4.4 Protocole Expérimental
4.5 Prédictions
4.6 Résultats
4.7 Conclusion et Travaux Futurs
5 Interaction Rythmique
5.1 Introduction
5.2 Motivations
5.2.1 Avantages du Rythme comme Méthode d’Entrée
5.2.2 Utilisation des Motifs Rythmiques
5.3 État de l’art
5.4 Des Motifs Rythmiques pour l’Interaction
5.5 Expérience 1 : Reproduction de Motifs Rythmiques
5.5.1 Le Reconaisseur
5.5.2 Matériel et Participants
5.5.3 Stimulus
5.5.4 Feedbacks Utilisateur
5.5.5 Vocabulaire
5.5.6 La Tâche
5.5.7 Procédure et Schéma Expérimental
5.5.8 Résultats Quantitatifs
5.5.9 Résultats Qualitatifs
5.6 Outil d’Analyse : AnEwe
5.7 Un Classifieur de Motifs
5.8 Expérience 2 : Mémorisation des motifs rythmiques
5.8.1 Variables
5.8.2 La Tâche
5.8.3 Apparatus & Participants
5.8.4 Procédure et schéma expérimental
5.8.5 Résultats Quantitatifs
5.8.6 Résultats Qualitatifs
5.9 Conclusion
6 Conclusion et Perspectives
6.1 Stabilité Spatiale
6.1.1 Le problème
6.1.2 Les Contributions
6.1.3 Les Perspectives
6.2 Localité de l’Interaction
6.2.1 Le Problème
6.2.2 Les Contributions
6.2.3 Les Perspectives
Bibliographie
Télécharger le rapport complet
