# Postdiction de commandes à partir de l'évolution de l'état d'une interface

Gilles Bailly, Nassim Ahmed Ali, Christian Zhuang, Alexandra Xia, Julien Gori

► To cite this version:

Gilles Bailly, Nassim Ahmed Ali, Christian Zhuang, Alexandra Xia, Julien Gori. Postdiction de commandes à partir de l'évolution de l'état d'une interface. IHM'25 - 36e Conférence Internationale Francophone sur l'Interaction Humain-Machine, Nov 2025, Toulouse, France. 10.1145/3765712.3765732. hal-05294681

HAL Id: hal-05294681

https://hal.science/hal-05294681v1

Submitted on 2 Oct 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# The Postdiction as an approach to recommand commands based on interface state evolution
## Postdiction de commandes à partir de l'évolution de l'état d'une interface

Gilles Bailly

Sorbonne Université, CNRS, ISIR

Paris, France

gilles.bailly@sorbonne-universite.fr

Nassim Ahmed Ali

Sorbonne Université, CNRS, ISIR

Paris, France

nassim.ahmed_ali@etu.sorbonne-universite.fr

Christian Zhuang

Sorbonne Université, CNRS, ISIR

Paris, France

christian.zhuang.1@etu.sorbonne-universite.fr

Alexandra Xia

Sorbonne Université, CNRS, ISIR

Paris, France

alexandre.xia.1@etu.sorbonne-universite.fr

Julien Gori

Sorbonne Université, CNRS, INSERM,

ISIR

Paris, France

gori@isir.upmc.fr

## Abstract

Users use only a limited subset of software commands. This article introduces a novel approach to discovering commands in graphical user interfaces. Unlike previous approaches to recommend a command, which relies on command prediction - determining what the user wants to do in the future - our approach relies on command postdiction - explaining how a task in the past could have been performed more efficiently. Given the current state of the interface and previous states, our approach infers the command that would have been most appropriate and suggests it to the users. We discuss three case studies: shape, image and text editors. For each of them, we study the feasibility of the approach through proofs of concept. Finally, we discuss the challenges posed by deploying post-diction in existing software.

## Résumé

Les utilisateurs n'utilisent qu'un sous-ensemble restreint des commandes disponibles dans les logiciels. Cet article présente une nouvelle approche pour découvrir des commandes dans les interfaces graphiques. Contrairement aux approches précédentes dont la recommandation de commandes repose sur la prédiction de commandes - déterminer ce que l'utilisateur veut faire dans le futur -, notre approche réalise de la postdiction - expliquer comment une tâche dans le passé aurait pu être réalisée plus efficacement. Étant donné l'état courant de l'interface et les états précédents, cette approche infère la commande qui aurait été la plus appropriée et la suggère aux utilisateurs. Nous la discutons sur trois cas d'étude : éditeur de formes, d'images et de texte. Pour chacun d'entre eux, nous étudions la faisabilité de l'approche à travers des preuves de

concept. Enfin, nous discutons les défis que pose le déploiement de la postdiction dans des logiciels existants.

## CCS Concepts

* Human-centered computing → HCI theory, concepts and models.

## Keywords

Command selection, Discovery, recommendation system

## Mots clés

Sélection de commandes, Découverte, systèmes de recommandation

## ACM Reference Format:

Gilles Bailly, Nassim Ahmed Ali, Christian Zhuang, Alexandra Xia, and Julien Gori. 2025. The Postdiction as an approach to recommand commands based on interface state evolution. In *The 36th Conference on l'Interaction Humain-Machine (IHM '25), November 03-07, 2025, Toulouse, France*. ACM, New York, NY, USA, 15 pages. https://doi.org/10.1145/3765712.3765732

## 1 Introduction

Les applications telles que Word, Powerpoint, Photoshop ou VS Code proposent des centaines de commandes permettant théoriquement un haut niveau de productivité. On retrouve des commandes basiques, habituellement réservés aux novices, mais aussi des commandes avancées, destinées aux utilisateurs plus experts. Ces commandes avancées augmentent la productivité en réduisant le nombre d'actions (de commandes) à effectuer [3]. Par exemple, la commande "Aligner à gauche" de Powerpoint aligne un ensemble d'objets sélectionnés sur leur côté gauche. Elle est équivalente à déplacer manuellement chaque élément jusqu'à ce que l'alignement visuel semble suffisant. Un autre exemple est l'outil "Supprimer les yeux rouges" dans Photoshop qui est plus efficace que colorier manuellement la pupille de l'oeil en noir à l'aide d'un pinceau.

Pourtant de nombreux utilisateurs, même experts, ne les utilisent pas [3, 20]. Par exemple, Matejka et al. [20] indiquent que la plupart des utilisateurs n'utilisent environ que 30 commandes sur

<figure><img src="image_2.png" /></figure>

This work is licensed under a Creative Commons Attribution 4.0 International License.
IHM '25, Toulouse, France

© 2025 Copyright held by the owner/author(s).
ACM ISBN 979-8-4007-1522-8/25/11
https://doi.org/10.1145/3765712.3765732
les milliers disponibles dans AutoDesk AutoCad. Une des raisons principales est que les utilisateurs ne connaissent pas ces commandes, de nombreuses applications ne favorisant pas la découverte de nouvelles commandes [3, 6, 15]. Certaines commandes sont même inaccessibles depuis les menus, par exemple "Commenter un paragraphe" dans Overleaf.

Plusieurs solutions ont été proposées pour faciliter la découverte de commandes comme "Conseil du jour" (Tip of the day) qui recommande une commande (et explique son effet) à l'ouverture du logiciel, l'assistant virtuel "Clippy", qui proposait son assistance en fonction du contexte de la tâche, ou CommunityCommands [20] qui recommande à l'utilisateur les commandes qu'il n'utilise pas, mais qui sont utilisées par sa communauté. Ces solutions reposent sur la **prédiction** de quelles commandes seraient utiles pour l'utilisateur avec le risque que le système de recommandation se trompe, c.a.d. qu'il propose une commande qui n'est pas pertinente pour la tâche actuelle [20]. En conséquences, les utilisateurs peuvent développer une adversité face à ce genre de situations, en particulier quand les erreurs sont trop nombreuses — ce qui a été fatal à Clippy d'ailleurs.

Dans cet article, nous proposons une nouvelle approche pour découvrir des commandes. L'originalité de notre approche est de remplacer la prédiction par de la **postdiction** de commandes: Au lieu d'essayer de deviner ce que l'utilisateur veut faire dans le **futur** (prédiction), notre approche vise à expliquer comment une tâche dans le **passé** aurait pu être réalisée plus efficacement (postdiction). Plus précisément, notre approche compare l'état courant de l'interface $E_t$ (e.g. le canevas de Photoshop) avec les états précédents $E_{t-1}, E_{t-2}, \dots, E_{t-n}$ pour estimer à posteriori la plus courte séquence de commandes pour passer de $E_{t-n}$ à $E_t$. Si cette séquence est différente de celle exécutée par l'utilisateur, le système recommande la ou les commandes qui auraient réduit le plus le nombre d'actions à réaliser. Pour poursuivre l'exemple de Photoshop, un utilisateur pourrait utiliser de nombreux coups de pinceau noirs pour assombrir les pixels de la pupille. En analysant l'état de l'image (ici les pixels autour des yeux) avant et après les multiples coups de pinceau, le système recommanderait l'outil "Supprimer les yeux rouges" (voir Figure 1).

Cette approche aurait l'avantage de garantir un haut niveau de pertinence de la recommandation proposée à l'utilisateur: en théorie, la commande (1) est en lien avec la tâche proposée, (2) n'a pas été utilisée par l'utilisateur et (3) diminue le nombre d'actions nécessaire par rapport aux habitudes de l'utilisateur. C'est une différence majeure avec les approches précédentes où le nombre de mauvaises recommandations est élevé, plus de 20% dans le cas le plus favorable [20].

L'objectif de cet article est donc (1) d'étudier si la postdiction est possible et si oui, (2) d'étudier comment la définir et (3) comment l'implémenter.

Nos contributions sont (1) la présentation de la postdiction comme nouvelle approche pour découvrir des commandes et deux méthodes (en avant et en arrière) pour instancier cette approche; (2) trois preuves de concept (éditeur de formes, d'images et de texte), incluant des évaluations techniques, pour étudier la faisabilité de l'approche; (3) une discussion sur les défis pour déployer cette approche en pratique.

## 2 Travaux précédents

Notre travail s'inscrit dans la littérature sur l'apprentissage des logiciels (software learnability) [12] et plus spécifiquement sur l'assistance pour découvrir de nouvelles fonctionnalités [12] et commandes [3]. Cet aspect est important pour deux raisons : (1) les utilisateurs ne connaissent qu'un nombre limité de commandes [20]; (2) La découverte d'une commande précède la ou les sélections de cette commande. En effet, les techniques d'interaction pour faciliter la sélection de commandes ne sont utiles que lorsque les utilisateurs connaissent ces commandes (p.ex [1, 9, 17, 27]). Par exemple, optimiser la position de la commande "Supprimer les yeux rouges" n'est pertinent que si les utilisateurs utilisent et donc connaissent déjà cette commande. L'assistance pour la découverte de commandes et pour la sélection de commandes sont donc complémentaires. Nous décrivons maintenant les mécanismes existants et les systèmes de recommandation pour découvrir de nouvelles commandes.

### 2.1 Mécanismes existants pour favoriser la découverte de nouvelles commandes

L'interaction entre utilisateurs est une des sources principales de découverte de nouvelles commandes [28]. Par exemple, l'utilisateur peut demander de l'aide pour réaliser une tâche / s'améliorer; parfois ce peut être une autre personne (par exemple un collègue) qui regarde au-dessus de l'épaule ("over-the-shoulder") de l'utilisateur et spontanément lui indique une nouvelle commande qui pourrait lui être utile. Les utilisateurs peuvent également découvrir des commandes en cherchant dans la documentation d'un logiciel ou sur internet (Google, stackoverflow, reddit, etc.) [21] Mais cette approche est moins efficace [24], en partie car l'utilisateur n'imagine pas forcement que des commandes avancées existent, et de plus, elle force l'utilisateur à quitter temporairement l'application pour faire sa recherche, tout comme les agents intelligents et chatbots modernes basés sur des grands modèles de langage comme ChatGPT. Enfin, lorsque l'utilisateur n'est pas à l'initiative, il peut recevoir des newsletters [18, 23].

### 2.2 Des systèmes de recommandation pour suggérer de nouvelles commandes

Les systèmes de recommandation de commandes sont des outils pour diriger les utilisateurs vers des commandes utiles pour eux. Ils sont conçus pour adapter l'application aux besoins et préférences individuels de l'utilisateur et supporter le manque de connaissance sur le large ensemble des commandes disponibles. Nous discutons les systèmes de recommandation existant en comparant leurs entraées et sorties.

En entrée. En entrée, les systèmes de recommandation s'appuient sur le contexte pour recommander une commande. Le contexte est généralement représenté par l'environnement où se trouve l'utilisateur et l'historique complet des commandes exécutées, par ex. une séquence < "Brush"; "Copy"; "Paste", "Brush", etc. >. Typiquement le système recommande des commandes qui ne sont pas dans l'historique et dont les bénéfices peuvent être sur le long terme. Cette approche fournit des "suggestions globales" [20]. Au contraire, les "suggestions opportunistes" [20] prennent surtout en compte l'environnement courant de l'utilisateur et les commandes
exécutées récemment pour faire des recommandations (p.ex. CNTX [7]), typiquement recommander "coller" si l'utilisateur a exécuté "Copier". En théorie, ces recommandations peuvent être immédiatement exécutée. Le contexte prend parfois en compte l'historique des commandes exécutées par la communauté de l'utilisateur (p.ex. OWL [14], CommunityCommands [20] ou Patina [19]). Cette approche recommande les commandes fréquemment utilisées par la communauté, mais pas par celui qui reçoit la recommandation (p.ex. Most Popular [21]). Cette approche suppose que les besoins et les objectifs de l'utilisateur sont les mêmes que ceux de son groupe / de sa communauté. Cependant, des logiciels comme Photoshop peuvent être utilisés par un large éventail d'utilisateurs pour une grande variété d'activités. Il n'est donc pas évident que l'utilisation «moyenne» des commandes par un groupe soit pertinente pour la tâche en cours d'un utilisateur donné. Une variante consiste alors au préalable à filtrer les membres de la communauté et retenir uniquement ceux qui ont un profil similaire à l'utilisateur recevant la recommandation (p.ex. CODIS [29]). Bien que cette approche basée communauté puisse être utile à l'échelle d'une organisation avec un groupe d'experts travaillant sur des tâches bien définies, elle ne s'adapte pas nécessairement aux utilisateurs occasionnels. De plus, cette approche ne fonctionne pas lorsqu'une application a été mise à jour avec des commandes avancées car le groupe n'a pas encore utilisé ces nouvelles commandes.

Contrairement à ces solutions dont les entrées reposent sur l'historique des commandes de l'utilisateur et/ou de la communauté, les entrées de notre approche repose sur l'historique des états de l'interface (p.ex. la matrice de pixels pour Photoshop). Cette différence est fondamentale, car l'utilisation de la commande "Brush" n'est pas suffisante pour savoir que l'utilisateur "enlève les yeux rouges" sur l'image.

*En sortie.* Les systèmes de recommandation posent de nombreux défis tels que "quand", "où" ou "comment" présenter une recommandation [8]. Pour plus d'informations, nous redirigeons le lecteur vers [8, 22]. Le défi sur lequel se concentre cet article est "quelle" recommandation fournir à l'utilisateur. C'est un défi difficile. En effet, les travaux précédents affirment que les recommandations proposées sont rarement pertinentes pour l'utilisateur [13], p.ex., parce qu'elles ne correspondent pas à la tâche courante de l'utilisateur. Au contraire, par construction, notre approche vise à recommander une commande en lien avec la tâche de l'utilisateur : une commande permettant d'arriver dans le même état courant en réalisant moins d'actions.

En résumé, les travaux précédents ne garantissent pas la pertinence des recommandations à la fois en termes de contenu (c'est-à-dire de commande recommandée) et de temporalité, c'est-à-dire quand la recommandation est délivrée car il est difficile de prédire ce que veut faire l'utilisateur.

## 3 Postdiction de commandes

Notre approche de postdiction est illustrée figure 1. Nous clarifions d'abord notre approche, la terminologie associée et sa couverture. Nous décrivons ensuite précisément le problème et les méthodes pour l'adresser. Nous justifions d'abord pourquoi il est en principe

plus facile d'obtenir des suggestions de commandes pertinentes avec de la postdiction comparé à de la prédiction. Nous entendons par une suggestion de commande pertinente une commande suggérée qui (1) permet d'atteindre l'état final plus efficacement que sans la suggestion et (2) en lien avec la tâche en cours.

### 3.1 Prédiction vs. postdiction

Les approches existantes font de la prédiction : étant donné l'historique d'interaction, les systèmes visent à déterminer ce que voudrait faire l'utilisateur dans le futur pour faire des recommandations en conséquence. Les approches par prédiction doivent donc répondre à deux défis: prédire l'état final voulu par l'utilisateur, par exemple en inférant son intention, puis proposer une commande avancée qui permet de relier l'état courant à l'état final le plus efficacement possible. Comme ce problème de prédiction est très difficile, les recommandations ne sont pas toujours pertinentes [20], ce qui peut poser des questions d'acceptabilité de ces systèmes par les utilisateurs. Au contraire, notre approche fait de la postdiction. La postdiction est "l'analyse ou explication rétroactive des événements passés basée sur les données ou connaissances actuelles". Notre approche ne fait donc aucune hypothèse sur le futur, elle explique seulement comment une tâche aurait pu être réalisée plus efficacement dans le passé. Le but étant de trouver une manière plus efficace de passer d'un état initial à un état final déjà connu, il devrait être plus facile de suggérer une commande avancée pertinente.

Notre approche introduit alors deux principaux défis:

(1) Comment déterminer une commande avancée à partir de l'historique des états de l'interface?

(2) Quand et comment informer l'utilisateur de la commande avancée?

Ces deux défis étant largement indépendants, et le deuxième défi étant un problème plus large et déjà partiellement traité dans la littérature [8, 22], nous nous concentrons sur le premier défi.

### 3.2 États, commandes avancées: Définitions et périmètre

3.2.1 État d'un l'interface. Nous définissons l'état de l'interface ($E_t$) à la date $t$, comme une représentation interne du document, que l'utilisateur peut éditer ou non. L'état $n$ est pas unique, et il peut y avoir plusieurs états pour un même document. Par exemple, dans un éditeur de forme comme PowerPoint, on peut définir un état qui contient une liste d'objets graphique avec l'ensemble de ses propriétés (forme, couleur, épaisseur des bords, etc.). Pour un éditeur d'images comme Photoshop, on peut définir un état qui contient une image uniquement, ou alors additionnellement l'ensemble des canvas et propriétés associés. Pour un éditeur de texte, ça peut être le texte, avec ou sans décorations. En plus des caractéristiques du document, d'autres informations peuvent s'avérer parfois utile pour faire de la postdiction de commandes, comme la position du curseur, qui ne sont généralement pas sauvegardé dans un fichier. Nous définissons donc au sens large l'état de l'interface comme une représentation interne du document, potentiellement augmentée de toutes les informations utiles comme la position du curseur ou le
<figure><img src="image_3.png" /><figcaption>Figure 1: Concept. L'utilisateur à exécuté 7 fois la commande "Stroke" pour peindre à la main les pupilles en noire. Le système compare l'état courant de l'image $E_t$ avec les états précédents de l'image pour faire de la postdiction de commandes. Le système reconnaît que appliquer la seule commande "Supprimer les yeux rouges" sur $E_{t-7}$ aurait permis d'obtenir le même résultat $E_t$ que la séquence des 7 commandes "Stroke". Il suggère alors la commande "Supprimer les yeux rouges" à l'utilisateur.</figcaption></figure>

contenu du "clipboard", voir de l'historique des commandes <fnref n="1" />. Cette définition de l'état doit être adaptée au cas par cas.; par exemple il peut souvent être judicieux de travailler sur une représentation réduite d'un état (voir les l'éditeur d'images et de texte)

### 3.2.2 Commande.
Une **commande** (*c*) est une méthode permettant un changement de l'état de l'interface [2]. Au regard du problème traité dans cet article, nous soulignons plusieurs propriétés d'une commande à considérer lorsque l'on fait de la postdiction:

* modalité. Il existe souvent plusieurs modalités pour exécuter une même commande, comme cliquer sur l'item d'un menu, exécuter un raccourci clavier où entrer son nom dans une console [2]. Notre approche est agnostique à la modalité utilisée, mais la recommandation peut présenter une ou plusieurs modalités (voir Figure 2).

* paramètres. Les commandes peuvent avoir 0, 1 ou plusieurs paramètres <fnref n="2" />. La commande "Coller" est une commande sans paramètres, elle colle juste le contenu du "clipboard". Une commande effectuant une rotation à un objet a un paramètre qui spécifie l'angle de la rotation. Nous considérons uniquement les commandes sans paramètres car plus simple à traiter; nous rediscutons cette limitation en discussion.

* stochasticité. Si pour un état donné de l'interface, l'exécution de la commande produit toujours le même effet, la commande est déterministe, sinon elle est stochastique. La plupart des commandes sont déterministes. Pour autant, certaines commandes, comme celle ajoutant du bruit à une image peuvent produire des résultats (légèrement) différents. Nos preuves de concept couvrent des commandes déterministes, bien que l'approche reste valide pour des commandes stochastiques,

par exemple quand nous utilisons des classificateurs entraînés (voir section 3.5).

* in/surjectivité. Une commande “c” est dite injective s’il n’existe pas deux états $E_1$ et $E_2$ pour lesquels le résultat de la commande *c* est identique<fnref n="3" />. Un exemple de commande non injective est une commande de type “Clear”, qui vide l’interface de tous ses éléments : peu importe l’état de départ, on aboutit toujours au même état d’arrivée qui est une interface vide. Une commande “c” est surjective, si tous les états de l’interface peuvent être le résultat de *c*. En pratique, les commandes ne sont pas surjectives<fnref n="4" />. Cette propriété a une influence limitée sur notre approche; en effet, il n’existe pas de lien établi à notre connaissance entre le caractère injectif ou surjectif d’une fonction (commande) et la capacité a classifier cette dernière. Le fait que les commandes ne soient en général pas surjectives est un atout pour la classification: puisque certains états ne sont atteignables qu’avec certaines commandes, les autres sont donc éliminées.

### 3.2.3 Commande avancée.
Une **commande avancée** est une commande dont l'effet est équivalent à l'exécution de plusieurs commandes et/ou actions de l'utilisateur dans un état donné. Certaines commandes avancées sont des combinaisons de commandes existantes, par exemple "duplicher" combine "copier" et "coller". Ces commandes, que l'on appellera *commandes avancées par combinaison*, sont susceptibles d'être identifiées par des règles agissant directement sur l'historique des commandes. D'autre commandes, qu'on appellera *commandes avancées complexes* combinent plusieurs

<footnote n="1">¹Certains travaux précédents s'appuient sur l'historique de commandes, mais pour faire de la prédiction plutôt que de la postdiction.</footnote>

<footnote n="2">²La notion de paramètre de commandes peut s'avérer difficile à définir précisément. Du point de vue de l'utilisateur, une commande peut être perçue sans paramètres alors qu'au niveau système, c'est une fonction avec des arguments. De la même façon, la notion de paramètre dépend de la définition (stricte ou large) de l'état de l'interface. Les coordonnées du curseur peuvent être des paramètres d'une commande ou un attribut de l'état de l'interface</footnote>

<footnote n="3">³Autrement dit, pour "c" une commande injective et deux états $E_1$ et $E_2$, si $c(E_1) = c(E_2)$, alors on a $E_1 = E_2$. Une commande injective est donc une commande où on peut déduire $E_1$ uniquement à partir de $c(E_1)$ et de $c$. De nombreuses commandes de sélection de texte sont injectives, par exemple MAJ + Flèche Droite ajoute le caractère à la droite du curseur à la sélection actuelle; à partir de la nouvelle sélection, sachant que la dernière commande exécutée était MAJ + flèche droite, je peux revenir sans ambiguïté à la sélection originale.</footnote>

<footnote n="4">⁴La définition technique de surjectivité fait intervenir l'espace d'arrivée; en fonction de celui-ci, une même fonction peut être surjective ou non. Par exemple, la fonction carré: $x \to \sqrt{x}$ est surjective sur $\mathbb{R}^+$ mais pas sur $\mathbb{R}$. Ici, on considère l'ensemble des états possibles comme espace d'arrivée.</footnote>
commandes mais aussi actions de l'utilisateur. Par exemple, la commande "rechercher et remplacer" — qui identifie toutes les itérations d'une certaine chaîne de caractères dans un document et les remplace par une autre — peut être effectué en naviguant à travers le document et en effectuant la tâche de recherche et de remplacement à la main. C'est pour ce type de commande avancées que notre approche par comparaison d'état initial et final est particulièrement pertinente, puisque la seule séquence d'actions effectuée par l'utilisateur est très peu informative hors du contexte de l'état du document.

## 3.3 Formulation du problème

À l'instant $t$, le système compare l'état courant de l'interface $E_t$ avec les états précédents de l'interface $E_{t-1}, \dots, E_{t-n}$. Le système considère chaque paire$^5$ d'états $<E_t; E_{t-x}>$, $x \in \{1, \dots, n\}$ et recherche s'il existe une commande avancée qui transforme $E_{t-x}$ en $E_t$. Si une telle commande $c^*$ existe, ceci signifie que les $x$ commandes exécutées par l'utilisateur auraient pu être remplacées par la seule commande $c^*$, et le système peut alors la recommander. Plus $x$ est grand, plus il est a priori intéressant d'utiliser $c^*$.

## 3.4 Comment déterminer une commande avancée à partir de l'historique des états de l'interface?

Nous proposons deux méthodes pour déterminer une commande avancée :

**Méthode en avant.** La méthode **en avant** consiste à exécuter sur chaque état passé $E_{t-n}$ l'ensemble des $k$ commandes avancées et de comparer les états résultants $I = \{c_1(E_{t-n}), \dots, c_k(E_{t-n})\}$ à l'état courant $E_t$. S'il existe une commande $c_i$ telle que $E_t$ soit suffisamment similaire à $c_i(E_{t-n})$ alors $c_i$ est candidat pour être recommandée à l'utilisateur. Cette méthode, bien que simple, a l'inconvénient d'être coûteuse: après chaque action de l'utilisateur, il faut appliquer chaque commande à l'avant dernier état courant. Ceci peut rapidement s'avérer coûteux en temps de calcul si le nombre de commandes avancées est important et/ou si certaines commandes sont complexes. Si aucune commande avancée n'est identifiée, il faut alors stocker ces états, puisque potentiellement l'utilisateur y arrivera avec $n-1$ actions supplémentaires. Ainsi, le nombre d'état à sauvegarder est de l'ordre de $k \times n$. Il faudra générer encore plus d'états si la commande possède des paramètres. En raison du coût en temps de calcul et de stockage, nous n'avons pas considéré cette méthode pour instancier notre approche dans cet article.

**Méthode en arrière.** Contrairement à la méthode en avant, La méthode **en arrière** est peu coûteuse en temps de calcul et de stockage à appliquer en direct. Cependant, elle demande plus de travail en amont. Elle consiste à apprendre la fonction $<E_t; E_{t-n}> \to c$. Il est facile de déterminer l'état d'arrivée $E_{t+1}$ à partir de l'état de départ $E_t$ et de la commande $c$, c.a.d. ($c(E_{t-1}) \to E_t$): il suffit d'appliquer la commande à l'interface et d'observer son nouvel état;

c'est ce qui est fait dans la méthode en avant. Par contre, retrouver $c$ à partir de $E_{t-1}$ et $E_t: <E_t; E_{t-1}> \to c$, est plus compliqué$^6$. Pour résoudre ce problème, c.a.d. inférer une commande à partir d'un état de départ et d'arrivée, nous proposons d'utiliser un classifieur qui, à partir d'une paire d'état, renvoie une commande. Le classifieur peut-être aussi bien un réseaux de neurones entraîné qu'un classifieur explicitement décrit par des règles (voir ci-dessous).

## 3.5 Les étapes de la méthode en arrière

Notre approche se décompose en quatre étapes. Les étapes 1 et 2 sont réalisées pendant la phase de conception, c'est à dire en amont de l'interaction, alors que les étapes 3 et 4 sont réalisées pendant l'interaction.

**Étape 1. Représenter l'état de l'interface.** L'état de l'interface peut s'avérer complexe soit par sa structure soit par sa taille. La première étape consiste donc à choisir comment simplifier l'état de l'interface en une représentation appropriée pour le reste de la méthode. Par exemple, nous pouvons réduire la résolution de l'image pour un éditeur d'images ou représenter un texte sous forme forme d'un vecteur contenant le nombre d'occurrences de chaque mot (bag of words). On peut tout à fait considérer plusieurs représentations de l'état. Les exemples de la section 4 illustrent plusieurs de ces représentations.

**Étape 2. Apprendre la fonction $<E_t; E_{t-1}> \to c$.** La "méthode en arrière" nécessite de retrouver $c$ à partir de $E_{t-1}$ et $E_t$. Nous proposons d'entraîner un classifieur, qui, à partir d'une paire d'état renvoie une commande. La méthode est agnostique au type de classifieur; nous en considérons en particulier deux types :

* **Classifieur à base de règles (heuristiques).** Le premier classifieur repose sur des heuristiques spécifiques à chaque logiciel et chaque commande. Par exemple, dans le cas d'un éditeur de forme géométrique, il est possible d'élaborer un algorithme simple vérifiant si un sous-ensemble de formes viennent d'être alignées sur le canvas, p.ex. en comparant la position de divers points de référence. Si tel est le cas, le classifieur proposera "Align Left". L'inconvénient est que le développeur doit développer ces heuristiques pour chaque commande, ce qui peut vite s'avérer coûteux.

* **Classifieur entraîné.** Une méthode alternative consiste à entraîner un classifieur (p.ex. un réseau de neurones avec en entrée une paire d'états $<E_t; E_{t-1}>$ et en sortie une commande $c$. Pour collecter la base d'apprentissage, deux méthodes sont possibles et peuvent être combinées. La première consiste à élaborer un robot/agent qui génère aléatoirement un grand nombre d'états de départs et qui applique des commandes de l'application et sauvegarde l'état d'arrivée. En prenant l'exemple de Photoshop, le robot dispose d'une base de données d'images et applique les différents commandes, par ex. des filtres. La seconde méthode consiste à enregistrer

<footnote>$^5$On pourrait se demander pourquoi on n'évalue pas toutes les paires d'états, par exemple $<E_t - 2; E_{t-6}>$. En fait, c'est inutile, puisque cette paire aura déjà été considérée à $T = t - 2$ par la paire $<E_T; E_{T-4}>$. Heureusement, car il aurait fallu en considérer $(\frac{t}{2}) \approx n^2/2$, alors qu'il suffit ici de $n$ paires.</footnote>

<footnote>$^6$retrouver l'état de départ $E_{t-1}$ à partir de $E_t$ et $c: <E_t; c> \to E_{t-1}$ est également compliqué. Il est potentiellement utile pour les commandes de type "Undo"). En particulier, retrouver l'unique $E_{t-1}$ à partir de $E_t$ et $c$ suppose que $c$ soit injective c.a.d. que l'image $E_t$ de $c$ est associée à un unique état $E_{t-1}$, et que son inverse $c^{-1}$ soit définie. En pratique, les problèmes de non-injectivité se contournent souvent en enregistrant les états de l'interface dans le temps (approche la plus classique pour implémenter la méthode "Undo").</footnote>
(log) l'activité d'un groupe d'utilisateurs pour constituer cette base de donnée (nous revenons sur la question de la privauté en discussion). Cette approche garantie d'avoir des états plus représentatifs des états réels des utilisateurs, mais peut souffrir d'un manque de diversité et d'équilibres de commandes (les mêmes commandes sont très souvent utilisées, la plupart des commandes sont très peu voir pas utilisées [10]).

Étape 3. Déterminer les commandes avancées pour chaque change-
ment d'états. Cette deuxième étape détermine si une séquence de
commandes qui vient d'être exécutée aurait pu être remplacée par
une commande avancée. Premièrement, les représentations d'état
de l'interface sont calculées. Ensuite,

* pour la méthode en avant, toutes les commandes potentielles sont appliquées à l'interface, et pour chacune, la nouvelle représentation de l'état est calculée. Ces représentations sont gardées en mémoire tant qu'une commande avancée n'a pas été identifiée.

* Pour la méthode en arrière, on applique en entrée du classi-
fieur décrit à l'étape 1 bis toutes les paires d'états de l'historique
contenant l'état courant $E_t; E_{t-x}$ avec $x \in \{1, \dots, n\}$, $n$ étant
la longueur de l'historique utilisé. Pour chaque paire, le clas-
sifieur associé à la représentation retourne la commande $c_x$
qu'il juge la plus probable. Cela signifie en particulier que
le classifieur proposera toujours une commande même si
aucune commande avancée n'est possible. Certains classi-
fieurs émettent des indices supplémentaires $\theta_x$; par exemple
le classifieur entraîné que nous considérons renvoie aussi un
score de confiance $0 \le p(c_x) \le 1$ associée avec la commande
$c_x$.

Étape 4. Choisir la commande avancée la plus pertinente. Après l'étape 2, nous avons une liste de $n-1$ tuples $\{E_t; E_{t-x}, c_x, \theta_x\}$ pour chaque représentation. Une règle de décision détermine alors quelle commande suggérer. Par exemple, si l'on dispose de deux classifieurs, un heuristique, l'autre entraîné, on peut choisir de toujours favoriser les règles heuristiques, qui a priori seront toujours correctes contrairement aux sorties des classifieurs entraînés.

3.6 Présenter une recommandation

Comme annoncé plus tôt, cet article se concentre sur l'approche
pour déterminer des commandes avancée et non comment les
présenter. Pour autant, nous discutons brièvement nos choix de
design concernant la présentation d'une recommandation par post-
diction qui ont guidé la réalisation de preuves de concept.

Quoi. Concernant la règle choisie pour l'étape 4, nous avons choisi de présenter uniquement les commandes avec $p(c_x) > \sigma$ où $\sigma \in [0, 1]$ est un palier pour contrôler le taux de faux positifs, c.a.d contrôler qu'il est suffisamment probable que la commande $c^x$ transforme bien l'état $E_{t-x}$ en $E_t$. La commande avancée $c^*$ choisie est alors celle qui a le plus grand $x$, c'est à dire qui supprime le plus grand nombre d'actions:

$$
c^* = \operatorname*{argmax}_x (c_x | p(c_x) > \sigma). \quad (1)
$$

Il faut noter qu’il peut n’y avoir aucune recommandation si $p(c_x) < \sigma$. La valeur de $\sigma$ doit donc être choisie avec attention. Nous recommandons a priori d’utiliser un $\sigma$ relativement élevé pour deux

raisons: premièrement, il a été prouvé que recommander des mau-
vaises recommandations (faux positifs) est préjudiciable pour l'utilisateur
[5], alors que ne pas recommander des actions avancées ne fait que
maintenir un status-quo. Deuxièmement, il y aura d'autres occa-
sions de suggérer la commande avancée "ratée", si ce n'est pas le
cas, ne pas apprendre la commande avancée ne représente pas une
grande perte. D'autre règles de décisions sont possibles; par ex-
emple, on pourrait maximiser le produit $p(c_x) \times x$. On pourrait
aussi considérer, au lieu du nombre d'actions économisées, le temps
gagné; pour ce faire il suffit d'introduire une fonction d'utilité de
chaque commande avancée dans la règle de décision.

Quand. Une recommandation est affichée immédiatement après que la commande avancée ait été identifiée. Ceci a pour avantage de la délivrer dans un contexte d'interaction favorable, c.a.d quand la recommandation est en lien avec la tâche réalisée. Une exception pourrait être si l'utilisateur a ignoré plusieurs fois la recommandation dans la même session : le système pourrait considérer que la recommandation est plus ennuoyante qu'utile pour l'utilisateur.

Comment. Figure 2 illustre différentes représentations. En par-
ticulier, Figure 2-d explique le choix de la recommandation en
affichant l'état de départ et l'état d'arrivée. Figure 2-c met l'accent
sur l'avantage d'utiliser la commande avancée en indiquant le
nombre de commandes économisées. Ces différentes representa-
tions peuvent être combinées, par exemple en affichant le nom
de la commande, son raccourci clavier et le nombre de command-
des économisées. Le choix du type de recommandation peut être
configuré par l'utilisateur.

Où. Par défaut, la recommandation est affichée en haut à droite de l'écran pendant 1s. Mais il est possible de considérer une fenêtre persistante qui affiche les k dernières recommandations.

<figure><img src="image_4.png" /><figcaption>Figure 2: Représentations possibles d'une recommandation. En plus du nom de la commande, le système peut indiquer (a) l'emplacement de la commande dans le menu, (b) le raccourci clavier, (c) le gain en nombre d'actions économisées, (d) l'état de départ et d'arrivée.</figcaption></figure>
# 4 Cas d'étude, Réalisation et Évaluation technique

Nous décrivons trois cas d'étude. L'objectif est d'étudier si la post-diction est possible en pratique et comment elle pourrait être implémentée. La première est une application de type PowerPoint où le widget principal est un canevas avec des formes aux propriétés géométriques (position, taille) connues. Ces cas d'étude propose une première illustration de l'approche à partir d'une représentation d'état simple, et un classifieur à base de règles. La seconde est de type Photoshop, où le canevas est une image. Ici, la représentation de l'état reste simple (tous les pixels), mais de très grande dimension; de plus on introduit un classifieur entraîné. Le dernier est un éditeur de texte dont le widget principal est un champ texte. Pour ce dernier cas, on adopte plusieurs représentations d'état pour le même document; on montre aussi comment combiner deux types de classifieurs différents. Ces cas d'étude décrivent des implémentations possibles de notre approche, mettant en lumière les aspects génériques mais aussi spécifiques aux applications envisagées.

## 4.1 Éditeur de formes : classifieur à base de règles

Nous avons développé un éditeur de forme (Figure 3), une version très simplifiée de Microsoft PowerPoint. Nous avons choisi sept commandes élémentaires (Créer forme par défaut, Déplacer, Redimensionner, Changer la couleur, Copier, Coller, Grouper) que nous avons implémentées ainsi que trois classes de commandes avancées :

* **Alignement des formes** : Aligne les formes en haut, bas, gauche, droite.

* **Copier et Aligner** : duplique une forme et la positionne alignée avec la forme originale

* **Premier Plan / Arrière Plan** : place une forme en arrière plan ou au premier plan.

Ce cas d'étude illustre des fonctionnalités modifiant des attributs géométriques et un classifieur à base de règles.

Représentation de l'état de l'interface (étape 1). Le canevas est représenté par un vecteur de formes. Chaque forme a cinq attributs : position, largeur, hauteur, couleur et type (Carré, Ellipse, Triangle). L'indice des formes dans le vecteur détermine l'ordre d'affichage et donc la profondeur dans le canevas (p.ex., le dernier objet est affiché au premier-plan). Pour cette preuve de concept, un nouvel état est créé à chaque fois que le bouton de la souris est relâché où qu'une commande est exécutée (par le menu ou le raccourci clavier).

Classifieur (Étape 2). Le classifieur prend en entrée deux vecteurs de formes et retourne une commande avancée (ou Null si aucune commande avancée n'a été identifiée). Il s'appuie sur 11 règles (fournies en appendice). Par exemple, si deux formes $f_1$ et $f_2$ ont la même abscisse, $x(f_1) == x(f_2)$, dans l'état courant, mais pas dans un état précédent, le système retourne la commande Aligner à gauche. De la même façon, si deux formes $f_1$ et $f_2$ ont les mêmes attributs forme, couleur et abscisse dans l'état courant, mais que $f_2$ n'existait pas dans l'un des états précédents, le système suggère Copier et Aligner. En pratique, il est possible que l'utilisateur ne

reproduise pas parfaitement les effets des commandes avancées. Par exemple, un alignement d'objets imparfait, alors qu'il serait bénéfique de recommander la commande avancée. Nos règles incluent donc une tolérance $\delta$ pour suggérer une commande avancée, même si l'état courant ne correspond pas tout à fait. Enfin, chaque commande avancée est associée à plusieurs règles qui sont testées dans un ordre particulier$^7$.

Étape 3 et 4. Si toutes les règles associées à une commande avancée sont respectées, celle-ci devient alors candidate pour la recommandation. Pour cette preuve de concept, nous comparons uniquement les deux états de l'interface les plus récents $E_t$ et $E_{t-1}$, ce qui permet de simplifier la postdiction de commandes; en effet cela permet de s'affranchir de la gestion des vecteurs de formes de taille différente à cause d'ajouts/suppression de formes.

<figure><img src="image_5.png" /></figure>

<table><caption>Figure 4: Gauche : Matrice de confusion pour le classifieur à base de règles pour le cas d'étude de l'éditeur de formes. Droite : table de précision, de rappel et de faux positif. *FPR : Taux de faux positif</caption><thead><tr><td>Commande</td><td>Précision</td><td>Rappel</td><td>FPR*</td></tr></thead><tbody><tr><td>AlignBottom</td><td>98.7%</td><td>100%</td><td>0.4%</td></tr><tr><td>AlignLeft</td><td>99.2%</td><td>95.4%</td><td>0.1%</td></tr><tr><td>AlignRight</td><td>99.5%</td><td>100%</td><td>0.1%</td></tr><tr><td>AlignTop</td><td>99.8%</td><td>99.1%</td><td>0.1%</td></tr><tr><td>Put Behind</td><td>53.8%</td><td>54.1%</td><td>5.4%</td></tr><tr><td>Put in Front</td><td>57.2%</td><td>56.9%</td><td>5.4%</td></tr></tbody></table>

Evaluation technique. L'évaluation est réalisée par simulation : un état $E_t$ contenant entre 3 et 8 objets sur le canvas est généré

<footnote>$^7$L'ordre a une importance, car certaines commandes avancées englobent d'autres commandes, comme c'est le cas avec "Copier-Aligner" qui comprend à la fois "Copier-Coller" et "Aligner". Ainsi, une commande "Copier-Aligner" satisfait les règles de la commande "Aligner", ce qui implique que la postdiction de "Copier-Aligner" doit être effectuée avant celle de "Aligner". Nous reconsidérons ce point dans la discussion.</footnote>
<figure><img src="image_6.png" /><figcaption>Figure 3: Éditeur de formes. L'utilisateur déplace à la souris le triangle vert vers le bas. Lorsque sa partie basse est alignée avec celui du carré bleu, le système recommande la commande Aligner Bas.</figcaption></figure>

aléatoirement. Nous appliquons ensuite une commande avancée c pour obtenir $E_{t+1}$. Nous fournissons ensuite $E_t$ et $E_{t+1}$ au classifieur qui restitue, $\hat{c}$. Si $\hat{c} = c$, alors la commande a bien été identifiée. La matrice de confusion Figure 4 indique pour chaque commande exécutée par l'agent les commandes reconnues par le système. Les résultats indiquent un haut niveau de précision (> 99%) et rappel (> 95%) pour toutes les commandes exceptées celles associées au plan. Ces dernières commandes ont des effets assez similaires. Placer une forme A devant une forme B est équivalent à mettre B derrière A. Les distinctions deviennent apparentes lorsqu'il y a au moins trois formes superposées. Une amélioration consisterait à ajouter une règle comptabilisant le nombre total de formes présentes.

*Discussion.* Un classifieur à base d'heuristique (méthode arrière) semble prometteuse pour ce type d'application. Une alternative serait de représenter l'état de l'interface par une image. En théorie, cette approche serait plus généraliste. En pratique, la description du canevas comme un vecteur de formes semble plus frugale dû au nombre limité de formes et d'attributs. Un classifieur à base de règles a ici l'avantage de ne pas nécessiter de base d'apprentissage et de tirer parti du faible nombre d'attributs à analyser. De plus, il est probable que ces règles soient déjà partiellement implémentées dans ce type d'application. Par exemple, Powerpoint propose des aides visuelles pour aligner des formes qui se déclenchent automa-tiquement quand des formes sont proches d'un alignement. Le code pour ces aides (identifier des situations de quasi alignement), pour-rait être exploité dans un classifieur par heuristique comme celui présenté ici.

## 4.2 Éditeur de photos : classifieur entraîné

Pour ce cas d'étude, nous avons augmenté une application existante, Adobe Photoshop, avec un plug-in fait maison. Nous avons consid-éré 8 filtres (Diffuse, Edges, Gaussian, Pinch, Sharpen, Surface et Twirl et Wave) comme commandes avancées. Ces filtres ont tous un effet *global*, c'est à dire qu'ils ont une action sur l'image entière. Leurs effets peuvent être également obtenus par une séquence de

commandes élémentaires comme le montre Figure 5. Par exem-ple, le filtre Blur (une action) est équivalent à appliquer (déplacer manuellement) l'outil Blur sur toute l'image.

*Représentation de l'état de l'interface (étape 1).* L'état de l'interface est représenté par une image bitmap. Le plugin s'exécute simul-tanément avec l'application et capture l'état de la toile (canevas) à intervalles réguliers <fnref n="8" /> grâce à l'API Win32 et l'API COM (Com-ponent Object Model) de Photoshop. En pratique, il y a 4 étapes :

(1) Trouver l'instance de photoshop en cours d'exécution grâce à la fonction "win32gui.FindWindow" de l'API Win32.

(2) Ouvrir une image dans Photoshop grâce à la fonction "Open" de l'API COM.

(3) Appliquer les filtres. Ils sont exécutés à partir d'événements clavier grâce la bibliothèque pyautoguiqui¹⁹.

(4) Enregistrer l'image au format jpg grâce à la fonction "Save" de l'API COM.

La représentation choisie ne prend pas en compte les informations internes à l'application comme les couches ("layers"). Pour réduire le coût d'entraînement du classifieur, les images sont sous-échantillées à une taille de 122x244 pixels.

*Classifieur (étape 2 et 3).* Le classifieur prend en entrée une im-age 244x244 pixels correspondant à la concatenation horizontale de l'image source et de l'image cible. Le classifieur retourne la probabilité pour chaque commande avancée d'avoir transformé l'image source en l'image cible. L'architecture du classifieur con-siste en trois instances d'un modèle Resnet, qui est une architec-ture d'apprentissage profond développée spécifiquement pour la vision par ordinateur. Chaque instance est entraînée sur une base

<footnote n="8">⁸l'intervalle de rafraîchissement peut être ajusté par l'utilisateur en fonction de ses préférences</footnote>

<footnote n="9">⁹Pour cette partie, nous n'avons pas réussi à correctement utiliser les commandes de Photoshop via win32. Nous avons utilisé pyautoguiqui à la place</footnote>
d'apprentissage différente. Le classifieur retourne alors la moyenne
agrégée des probabilités renvoyées par chaque modèle<fnref n="10" />

Choix de la commande (Étape 4). Le classifieur retourne la proba-
bilité pour chaque commande avancée d'avoir transformé l'état de
départ en l'état d'arrivée. Nous avons considéré deux seuils (voir
paragraphe évaluation): un à 0%, c.a.d que la commande avec la
plus grande probabilité est retournée (même si celle-ci est faible) et
un seuil à 95%, c.a.d. que si une commande est retournée, elle a une
probabilité supérieur à 95% d'expliquer le changement d'état.

<figure><img src="image_7.png" /><figcaption>Figure 6: Éditeur d'image. Matrices de confusion du classi-
fieur entraîné. Gauche: seuil de 0% (la commande avec la plus
haute probabilité est retournée). Droite : seuil de 95% (la com-
mande avancée est retournée si sa probabilité est supérieure
à 95%).</figcaption></figure>

Entrainement du classifieur. Les resnet sont d'abord pré-entrainé sur Imagenet [4]<fnref n="11" />. La première phase d'apprentissage s'appuie sur une base d'exemples que nous avons générée automatiquement, en appliquant les 8 filtres à un ensemble de 822 images (total 6576 images). Nous avons conservé les paramètres par défaut de chaque filtre afin d'éviter les valeurs extrêmes qui pourraient être différentes de ce que l'utilisateur peut définir manuellement. Un tiers de ces images générées automatiquement sont utilisées pour entraîner chaque instance de Resnet du classifieur. La seconde phase d'entraînement s'appuie sur une base d'exemples générée manuellement par trois des auteurs. Pour chaque image considérée (sélection aléatoire parmi le jeu d'entraînement), les auteurs devaient essayer de créer un effet similaire aux commandes avancées — les filtres précédemment mentionnées — mais en n'utilisant que des commandes basiques. Sur ces 255 images ainsi générées manuellement, 121 images ont été utilisées pour compléter la base d'apprentissage des classifieurs, les autres 134 ayant servis pour l'évaluation.

Évaluation technique. Le classifieur a été évalué sur les 134 im-
ages générées manuellement restantes. Avec le seuil à 0%, la préc-
sion du classifieur est de 74% et son rappel de 96%. La matrice de
confusion (Figure 6-gauche) révèle que les confusions sont princi-
palement entre les filtres Twirl et Pinch, ou Pinch et Surface. Ces
confusions sont moindres lorsque le seuil est relevé à 95% (Figure 6-
droite). Le nombre de faux positifs diminue de 36 à 19 (-17). La
contre-partie est que le nombre de vrais positifs diminue de 100 à
83 (-17).

Nous avons également comparé notre classifieur à la même ar-
chitecture Resnet entraîné sur une seule instance. Les résultats
sont résumés dans la table 1 et montrent que notre classifieur (en
gras) produit de meilleures performances ce qui montre le bénéfice
d'utiliser 3 modèles Resnet (74%) plutôt qu'un seul (68%).

<table><caption>Table 1: Performance du classifieur avec (Final) et sans (ResNet) combinaisons de modèles.</caption>
  <thead>
    <tr>
      <th>Classifieur</th>
      <th>Architecture</th>
      <th>Précision</th>
      <th>Rappel</th>
      <th>Faux positifs</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Final</td>
      <td>3 x ResNet</td>
      <td>74%</td>
      <td>96%</td>
      <td>27%</td>
    </tr>
    <tr>
      <td>ResNet</td>
      <td>ResNet</td>
      <td>68%</td>
      <td>95%</td>
      <td>43%</td>
    </tr>
  </tbody>
</table>

Discussion. L’élaboration du modèle s’est appuyée sur une ap-
proche itérative jusqu’à obtenir un niveau de précision suffisam-
ment élevé (étape 2 et 3) pour la classification des 8 filtres. Il est
certain que de nombreuses améliorations sont possibles — et néces-
saires — pour traiter une classification avec un plus grand nombre
de filtres. La base d’apprentissage du modèle s’avère aussi critique.
Notre expérience souligne l’importance des données générées sur
la performance des modèles et la nécessité de considérer des don-
nées à la fois simulées et observées. En effet, les données générées
manuellement sont les plus pertinentes (bien que chronophage),
car ce sont celles que le modèle tentera de classifier. Pour ce cas
d’étude, nous avons aussi abordé le choix du seuil (étape 4). Nos
résultats (voir Figure 6) confirment le compromis entre le nombre
de faux positifs et de vrais positifs. Un travail futur devra étudier

<footnote n="10">¹⁰Combiner plusieurs modèles, approche appelée, Apprentissage ensembliste, permet de réduire la variance, le biais et d'améliorer les prédictions [26]. Chaque modèle est entraîné sur 80% des données collectées choisies de manière aléatoire selon la méthode du Bootstrap aggregating (aussi appelé Bagging).</footnote>

<footnote n="11">¹¹version importé depuis pytorch</footnote>
<figure><img src="image_8.png" /><figcaption>Figure 5: Éditeur d'images. Notre plugin Photoshop affichant des recommandations lorsque des filtres avancés peuvent être suggérés.</figcaption></figure>

l'influence de ce seuil sur l'acceptation des recommandations par l'utilisateur.

## 4.3 Éditeur de texte : classifieur combinant règles et apprentissage

Ce troisième cas d'étude est une éditeur de texte "WYSIWYG"<fnref n="12" /> rudimentaire fait maison, implémenté en PyQt. Nous avons considéré trois commandes avancées sur le texte : "Chercher et remplacer", "Copier et coller", "Suppression d'un mot". Nous avons aussi considéré 5 commandes avancées supplémentaires pour la zone de sélection : "Sélection du document", "Sélection fin de ligne", "Sélection début de ligne", "Sélection mot suivant", "Sélection mot précédent" ainsi que 4 commandes avancées pour le déplacement du curseur de saisie : "Mot Suivant", "Mot précédent", "Ligne suivante", "Ligne précédente". Les commande élémentaires auxquels les utilisateurs ont accès dans le logiciel sont la modification d'un caractère (ajout/suppression), ainsi que la manipulation de la zone de sélection et du curseur de saisie, à la souris et au clavier (flèches directionnelles et modifieurs)

Ce cas d'étude illustre deux concepts supplémentaires: premièrement, comment combiner les sorties d'un classifieur heuristique avec celles d'un classifieur entraîné, deuxièmement comment la représentation de l'interface peut-être aussi bien simplifiée (modèle bad of words) qu'augmentée (avec la zone de sélection et le curseur de saisie).

Représentation de l'état de l'interface (étape 1). L'état de l'interface est représenté par une paire : < zone de texte; zone de sélection >. La zone de texte est un vecteur "sac de mots" ("bag of words") [25], c.a.d. une représentation du texte sous forme d'un vecteur numérique contenant le nombre d'occurrence de chaque mots augmenté d'un élément correspondant aux mots non définis et un élément représentant le nombre de caractères total du texte (espaces compris). Cette représentation simplifie nettement l'apprentissage, mais reste adaptée pour identifier les commandes avancées que nous avons sélectionné. La zone de sélection est représentée par deux curseurs de saisie : initial et courant. Ces deux curseurs sont identiques en l'absence de sélection. Un curseur de saisie est représentée par sa position dans le texte via la paire (ligne, colonne). Un nouvel état est créé chaque fois qu'un caractère est modifié ou que le curseur de saisie s'est déplacé (modifiant la zone de sélection ou pas).

Classifieur (étape 2 et 3. Le classifieur combine un réseau de neurones pour la partie zone de texte et un système de règles pour la partie zone de sélection. Ceci s'explique par le fait que la zone de sélection a une représentation simple (géométrique) similaire à l'éditeur de formes. Par contre, la zone de texte est un objet plus complexe où il peut s'avérer utile d'avoir des outils plus généralisables.

Le classifieur vérifie d'abord si le texte a été modifié. Si oui, le réseau de neurones estime la probabilité de chaque commande d'avoir modifié la zone de texte en considérant les 10 derniers états. Le réseau de neurones est un perceptron 4 couches (128-256-128-64 neurones). Si non, la classifieur a base de règles estime si une commande avancée

<footnote n="12">¹²What You See Is What You Get. Un exemple est Microsoft Word.</footnote>
<figure><img src="image_9.png" /><figcaption>Figure 7: Fonctionnement du système de recommandation pour l'éditeur de texte : $E_{n-5}$ (image à gauche) et $E_n$ après 5 actions (image à droite) et la recommandation apparaît à droite en glissant.</figcaption></figure>

aurait permis de modifier la zone de sélection ou la position du curseur de saisie en considérant également les 10 derniers états. Les règles de classification que nous avons implémentées sont simples et données en Annexe. Par exemple, lorsque la valeur de colonne du curseur de saisie passe à 0, la commande suggérée est "sélection début de ligne".

### Entraînement des classifieurs.
Pour entraîner le classifieur, nous avons généré des données d'interaction synthétiques. Nous avons implémenté un agent qui positionne le curseur de saisie aléatoirement dans le texte puis exécute 10 commandes parmi les 4 de modification de texte ainsi qu'une commande "Write character" qui entre du texte (cette dernière est utilisée pour simuler un utilisateur qui écrit). Cette procédure est répétée 40 000 fois. En cas de doublons dans la génération, le doublon est supprimé. 80% des données générées sont réservées pour l'entraînement ; les 20% restants sont utilisées pour l'évaluation. Le classifieur à base de règles n'a pas besoin d'être entraîné.

### Évaluation.
Le classifieur "Zone de texte" est testé sur les 20% des données générées restantes. La matrice de confusion (Figure 8-gauche) est fortement diagonale indiquant une bonne performance. Le taux de précision est supérieur à 96% quelque soit la commande modifiant le texte avec un faible nombre de faux positifs (< 1.2%) (La Figure 8-droite).

Pour le classifieur "Zone de sélection", la procédure est similaire à celle en subsection 4.1. Un jeu de données de test synthétique est créé, où un agent place aléatoirement le curseur puis le déplace aléatoirement 10 fois. Nous étudions alors si le classifieur retourne la commande avancée correspondante. La Figure 9 indique des précisions de 68% à 100%. Une précision inférieure à 100% s'explique par le fait que plusieurs commandes avancées permettent d'atteindre

<figure><img src="image_10.png" /></figure>

<table><caption>Figure 8: Éditeur de texte : Zone de texte (sac de mots). À Gauche la matrice de confusion. À droite, la table de précision, de faux positif et rappel, *FPR : Taux de Faux Positif</caption><thead><tr><td>Commande</td><td>Précision</td><td>Rappel</td><td>FPR*</td></tr></thead><tbody><tr><td>CopyPaste</td><td>99.8%</td><td>99.3%</td><td>0%</td></tr><tr><td>Replace</td><td>99.5%</td><td>95.4%</td><td>0.1%</td></tr><tr><td>DeleteWord</td><td>96.5%</td><td>100%</td><td>1.2%</td></tr><tr><td>Writecharacter</td><td>98.5%</td><td>99.6%</td><td>0.5%</td></tr></tbody></table>
<figure><img src="image_11.png" /></figure>

<table><caption>**Figure 9:** Éditeur de texte : Zone de sélection. À gauche la matrice de confusion. À droite, la table de précision, de faux positif et rappel, \*FPR : Taux de Faux Positif.</caption><thead><tr><td>Commande</td><td>Précision</td><td>Rappel</td><td>FPR*</td></tr></thead><tbody><tr><td>JumpLeftWord</td><td>77.3%</td><td>77.7%</td><td>2.2%</td></tr><tr><td>JumpRightWord</td><td>73%</td><td>92.7%</td><td>4.6%</td></tr><tr><td>MoveToEndOfLine</td><td>82.8%</td><td>82.8%</td><td>2.5%</td></tr><tr><td>MoveToStartOfLine</td><td>68.4%</td><td>93.7%</td><td>5.8%</td></tr><tr><td>SelectAll</td><td>100%</td><td>100%</td><td>0%</td></tr><tr><td>SelectLeftWord</td><td>71.4%</td><td>57.1%</td><td>2.1%</td></tr><tr><td>SelectRightWord</td><td>80.7%</td><td>65.7%</td><td>2%</td></tr><tr><td>SelectToEndOfLine</td><td>100%</td><td>81%</td><td>0%</td></tr><tr><td>SelectToStartOfLine</td><td>89.7%</td><td>69.3%</td><td>1%</td></tr></tbody></table>

le même état courant. Prenons par exemple le mot "day" et considérons que le curseur de saisie soit placé avant le mot. Appliquer la commande "Sélection mot suivant", positionne le curseur de saisie après le "y", ce qui ajoute le mot à la sélection. Ensuite, appliquer "Sélection mot précédent", replace le curseur devant le "d", ce qui restitue le mot de la sélection. Or, dans ce cas, utiliser "Mot précédent" à la place de "Sélection mot précédent" aurait eu le même effet. Ainsi, l'apparente mauvaise performance du classifieur est due au fait que plusieurs commandes peuvent avoir le même effet, et n'est pas forcément négative ici: dans tous les cas, une commande pertinente aurait été suggérée.

**Discussion.** L'analyse du cas d'étude "éditeur de texte" met en évidence plusieurs subtilités qu'il faudra considérer en travail futur. Par exemple, l'espace produit par une "Tabulation" est visuellement similaire à l'entrée de 4 espaces, mais il n'est pas considéré comme un "raccourci" car çe sont des caractères différents. Notre classifieur par apprentissage ne peut donc pas apprendre cette relation et la suggérer à l'utilisateur. Aussi, contrairement aux deux cas d'étude précédents, le choix de la représentation des états est moins évidente. Nous avons choisi une représentation classique en traitement du langage [25], mais il est possible que d'autres représentations soient plus appropriées à notre cas d'usage.

# 5 Discussion Générale

## 5.1 Représenter l'état de l'interface

Une limitation de notre approche est que la représentation de l'état dépend du type de logiciels et des commandes que le designer souhaite couvrir. Il est donc important de réduire l'effort nécessaire pour représenter ces états. Nos cas d'étude mettent en évidence plusieurs critères à prendre en compte comme l'espace mémoire, la qualité de la classification et son efficacité (en terme de calcul). Par exemple, pour l'éditeur d'image, la question de la résolution de l'image était critique pour trouver un compromis entre niveau de détail (qualité) et espace en mémoire. Pour l'éditeur de texte, notre représentation originale s'appuyant sur bag-of-words est particulièrement adaptée (efficacité) à l'identification de certaines commandes, par exemple la commande "trouver et remplacer" est identifiable dans le modèle bag-of-words facilement puisque le compte associé à un mot dans un état devient associé à un mot différent dans un autre état; par contre des commandes d'alignements y seront imperceptibles. Une piste de recherche consiste à déterminer quels sont ces représentations et dans quelle mesure elles peuvent être transposées d'une application à une autre. Une autre piste est d'étudier les avantages et les inconvénients d'un document à posséder de multiples représentations parallèles.

## 5.2 Améliorer la classification

**Classifieur entraîné.** Une difficulté technique de notre approche réside dans l'utilisation de classifieurs entraînés, nécessaires au bon fonctionnement de l'approche. Aboutir à des classifieurs efficaces dans des logiciels avec des milliers de commandes demandera beaucoup de travail. Une première tâche consiste à produire des données d'entraînement en nombre. Dans ce travail, nous avons expliqué comment s'appuyer sur des données synthétisées ou sur des données de vrais utilisateurs. Les données utilisateurs sont intéressantes parce qu'elles correspondent à des tâches directement utiles pour les utilisateurs; toutefois elles posent plusieurs problèmes: (1) la vie-privée, puisque le système nécessite d'enregistrer les états des documents des utilisateurs; pour autant nous pouvons imaginer qu'une version beta soit diffusée auprès d'un groupe restreint d'utilisateurs avertis pour collecter des données avant la publication officielle de l'application (2) il faut qu'un expert labélise les données; autrement dit quelqu'un doit déterminer que le passage d'un état à l'autre pouvait se faire plus efficacement avec une commande avancée bien identifiée.

Une seconde tâche consiste a utiliser des architectures adaptées à chaque représentation d'état, par exemple des transformers pour des représentations textuelles.

**Classifieur à base de règles.** On peut s'interroger sur le coût du développement des classifieurs à bases de règles. D'un côté, il est possible que l'implémentation de certaines règles, même complexes, soient peu coûteuses. Par exemple, nous discutons dans le cas d'étude de l'éditeur de forme que des mécanismes de retour d'information sur l'alignement des formes pourraient être réutilisés pour faire des recommandations et donc diminuer le coût de développement. D'un autre côté, lorsque le nombre de règles est important, il peut être difficile d'articuler précisément les règles entre elles.
*Commandes avec paramètres.* Quel que soit le type de classi-
fieur, nous devons considérer que certaines commandes aient des
paramètres. Certains, comme la position du curseur, peuvent être
encodés directement dans l'état, ne complexifiant pas la réalisation
de notre approche, mais ce n'est pas toujours possible. Par exemple,
les filtres sous Photoshop peuvent avoir plusieurs paramètres, par
exemple le niveau de bruit d'un filtre qui floute l'image. Une solu-
tion est d'avoir des exemples de l'effet de ces filtres pour différent
paramètres dans le jeu de données d'entraînement.

5.3 Prendre en compte le coût d'une séquence de commandes

Le gain d'une commande avancée est estimée par le nombre d'actions évitées. Il peut être intéressant de raisonner en d'autre termes. Par exemple, en estimant le bénéfice temporel (temps gagné) par l'utilisation de commandes avancées car une commande peut (1) être bloquante (requête réseau, algorithme sous-optimal), (2) être difficile d'accès en fonction de la profondeur dans le menu. Enfin (3) la modalité utilisée, menu vs. raccourci clavier, modifie le temps d'exécution. Une amélioration serait de mieux estimer le coût "réel" d'une commande en fonction de sa nature, son accessibilité et des habitudes des utilisateurs. Considérer le coût temporel de la séquence de commandes permet d'introduire naturellement certains cas d'assistance inter-modale : recommander pour une commande une autre modalité d'interaction. Typiquement recommander un raccourci clavier ou gestuel lorsque que la commande est sélectionnée dans un menu car la modalité raccourci clavier/gestuel est plus rapide. Il faut noter que le classifieur pour raccourcis clavier/gestuel serait facile à mettre en œuvre, puisqu'il suffirait de travailler sur une représentation de l'état qui n'inclut que la dernière commande effectuée, combiné à un ensemble de clé-valeur commande-raccourci.

5.4 Recommandation des commandes

Nous avons brièvement abordé la présentation des recommanda-
tions, un problème orthogonal au choix de la commande à recom-
mander [7], mais qui pose de nombreux défis. Outre les questions
génériques à l'interaction avec les systèmes de recommandations,
une question que nos preuves de concept soulèvent est comment
choisir entre deux commandes avancées lorsque toutes deux sem-
blent pertinentes, par exemple parce qu'elles ont le même effet
(voir cas de l'édition de texte). Nous suggérons de considérer des
critères supplémentaires. Par exemple, nous pouvons décider de
ne pas recommander trop souvent de nouvelles commandes pour
ne pas surcharger l'utilisateur; dans ce cas une seule commande
serait présentée, soit arbitrairement, soit selon des règles de pri-
orisation. Ne pas proposer trop souvent de nouvelles commandes
avancées est aussi pertinent du point de vue de l'apprentissage. En
particulier, la règle de décision que nous implémentons Equation 1
pourrait être revue pour proposer la première commande avancée
trouvée. Par exemple, la commande "coller spécial" permet de coller
un contenu avec son formattage. Pour un utilisateur novice qui ré-
entrerait une sélection à la main, il peut être plus adapté de suggérer
d'abord la commande "coller" pour une première familiarisation
avec ce concept, avant de proposer "coller spécial" lors de futures
interactions.

6 Conclusion et travail futur

Nous avons présenté une nouvelle approche pour recommander des commandes à l'utilisateur. Son originalité est de réaliser de la post-diction de commandes en comparant les états passés et présents de l'interface. L'approche a trois atouts majeurs: la commande recommandée (1) est en lien avec la tâche de l'utilisateur, (2) n'a pas été utilisée par l'utilisateur et (3) diminue le nombre d'actions par rapport aux habitudes de l'utilisateur. Nous avons illustré la faisabilité de l'approche à travers trois preuves de concept, chacune considérant un type d'application différent : éditeur de forme, d'image et de texte. Nos premiers résultats sont encourageants. Bien que nous n'ayons considéré qu'un petit sous-ensemble de commandes, nous pouvons retrouver des commandes avancées non-exécutées uniquement à partir d'un historique d'états, et cela avec une précision souvent supérieure à 90%. Nous avons enfin discuté certains défis de notre approche pour dépasser la preuve de concept et réaliser un outil déployable à grande échelle.

Ce travail devra être complété par des études utilisateurs. Ce type d'évaluation est complexe pour deux raisons : (1) de nombreux facteurs rentrent en jeu dans un système de recommandation tant sur l'algorithme pour le choix de la commande, que sur la présentation de la recommandation. Une mauvaise présentation pourrait masquer les avantages de l'approche ou avoir des effets d'interactions subtiles. En effet, des problèmes d'interface pourraient survenir à cause d'une technologie pas suffisamment mature et anéantir les bénéfices de l'approche [11]. (2) la conception d'une étude utilisateur portant sur la **découverte** de commandes est très délicate [15, 16], notamment concernant le choix des participants (niveau d'expertise), des instructions et de la tâche. Enfin, nous envisageons de d'étudier les ressources (CPU/GPU et mémoires) requises pour la pré/post-diction.

7 Remerciements

Cette recherche a été financée par l'Agence nationale de la recherche au titre du projet ANR-22-CE33-0006-01 (NeuroHCI) et ANR-24- CE33-7994-01 (HCIMI). À des fins de libre accès, une licence CC-BY a été appliquée par les auteurs au présent document et le sera à toute version ultérieure jusqu'au manuscrit auteur accepté pour publication résultant de cette soumission.

References

[1] Caroline Appert and Shumin Zhai. 2009. Using Strokes As Command Shortcuts: Cognitive Benefits and Toolkit Support. In *Proceedings of the SIGCHI Conference on Human Factors in Computing Systems* (Boston, MA, USA) (CHI '09). ACM, New York, NY, USA, 2289–2298. doi:10.1145/1518701.1519052

[2] Gilles Bailly and Sylvain Malacria. 2022. Command selection. In *Handbook of Human Computer Interaction*. Springer, 1–35.

[3] Andy Cockburn, Carl Gutwin, Joey Scarr, and Sylvain Malacria. 2014. Supporting novice to expert transitions in user interfaces. *ACM Computing Surveys (CSUR)* 47, 2 (2014), 1–36.

[4] Jia Deng, Wei Dong, Richard Socher, Li-Jia Li, Kai Li, and Li Fei-Fei. 2009. Imagenet: A large-scale hierarchical image database. In *2009 IEEE conference on computer vision and pattern recognition*. Ieee, 248–255.

[5] Hyo Jin Do, Ha-Kyung Kong, Pooja Tetali, Jaewook Lee, and Brian P. Bailey. 2023. To Err is AI: Imperfect Interventions and Repair in a Conversational Agent Facilitating Group Chat Discussions. *Proc. ACM Hum.-Comput. Interact.* 7, CSCW1, Article 99 (apr 2023), 23 pages. doi:10.1145/3579532

[6] Géry Casiez Eva Mackamul and Sylvain Malacria. 2024. Clarifying and differenti-
ating discoverability. *Human-Computer Interaction* 0, 0 (2024), 1–26. doi:10.1080/
07370024.2024.2364606 arXiv:https://doi.org/10.1080/07370024.2024.2364606

[7] Marko Gasparic, Tural Gurbanov, and Francesco Ricci. 2017. Context-aware integrated development environment command recommender systems. In *2017*
[29] Sedighez Holaktaf and Gail C Murphy. 2015. What to learn next: Recommending commands in a feature-rich environment. In *2015 IEEE 14th International Conference on Machine Learning and Applications (ICMLA)*. IEEE, 1038–1044.

[8] Marko Gasparic, Andrea Janes, Francesco Ricci, and Marco Zanellati. 2017. GUI design for IDE command recommendations. In *Proceedings of the 22nd International Conference on Intelligent User Interfaces*. 595–599.

[9] Emmanouil Giannisakis, Gilles Bailly, Sylvain Malacria, and Fanny Chevalier. 2017. IconHK: Using Toolbar Button Icons to Communicate Keyboard Shortcuts. In *Proceedings of the 2017 CHI Conference on Human Factors in Computing Systems (Denver, Colorado, USA) (CHI '17)*. ACM, New York, NY, USA, 4715–4726. doi:10.1145/3025453.3025595

[10] Julien Gori, Mohamed Ali Ben Amara, and Gilles Bailly. 2024. Understanding and generating realistic command distributions. In *Proceedings of the 35th Conference on L'Interaction Humain-Machine*. 1–11.

[11] Saul Greenberg and Bill Buxton. 2008. Usability evaluation considered harmful (some of the time). In *Proceedings of the SIGCHI conference on Human factors in computing systems*. 111–120.

[12] Tovi Grossman, George Fitzmaurice, and Ramtin Attar. 2009. A Survey of Software Learnability: Metrics, Methodologies and Guidelines. In *Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (Boston, MA, USA) (CHI '09)*. Association for Computing Machinery, New York, NY, USA, 649–658. doi:10.1145/1518701.1518803

[13] Wei Li, Justin Matejka, Tovi Grossman, Joseph A. Konstan, and George Fitzmaurice. 2011. Design and evaluation of a command recommendation system for software applications. *ACM Trans. Comput.-Hum. Interact.* 18, 2, Article 6 (July 2011), 35 pages. doi:10.1145/1970378.1970380

[14] Frank Linton, Deborah Joy, Hans-Peter Schaefer, and Andrew Charron. 2000. Owl: A recommender system for organization-wide learning. *Educational Technology & Society* 3, 1 (2000), 62–76.

[15] Eva Mackamul. 2022. Improving the Discoverability of Interactions in Interactive Systems. In *Extended Abstracts of the 2022 CHI Conference on Human Factors in Computing Systems (New Orleans, LA, USA) (CHI EA '22)*. Association for Computing Machinery, New York, NY, USA, Article 57, 5 pages. doi:10.1145/3491101.3503813

[16] Sylvain Malacria. 2023. *Why interaction methods should be exposed and recognizable*. Habilitation à diriger des recherches. Université de Lille. https://inria.hal.science/tel-04273407

[17] Sylvain Malacria, Gilles Bailly, Joel Harrison, Andy Cockburn, and Carl Gutwin. 2013. Promoting Hotkey Use Through Rehearsal with ExposeHK. In *Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (Paris, France) (CHI '13)*. ACM, New York, NY, USA, 573–582. doi:10.1145/2470654.2470735

[18] Carlos Maltzahn. 1995. Community help: discovering tools and locating experts in a dynamic environment. In *Conference Companion on Human Factors in Computing Systems*. 260–261.

[19] Justin Matejka, Tovi Grossman, and George Fitzmaurice. 2013. Patina: Dynamic Heatmaps for Visualizing Application Usage. In *Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (Paris, France) (CHI '13)*. Association for Computing Machinery, New York, NY, USA, 3227–3236. doi:10.1145/2470654.2466442

[20] Justin Matejka, Wei Li, Tovi Grossman, and George Fitzmaurice. 2009. CommunityCommands: Command Recommendations for Software Applications. In *Proceedings of the 22nd Annual ACM Symposium on User Interface Software and Technology (Victoria, BC, Canada) (UIST '09)*. Association for Computing Machinery, New York, NY, USA, 193–202. doi:10.1145/1622176.1622214

[21] Emerson Murphy-Hill, Rahul Jiresal, and Gail C. Murphy. 2012. Improving Software Developers' Fluency by Recommending Development Environment Commands. In *Proceedings of the ACM SIGSOFT 20th International Symposium on the Foundations of Software Engineering (Cary, North Carolina) (FSE '12)*. Association for Computing Machinery, New York, NY, USA, Article 42, 11 pages. doi:10.1145/2393596.2393645

[22] Emerson Murphy-Hill and Gail C Murphy. 2013. Recommendation delivery: Getting the user interface just right. In *Recommendation systems in software engineering*. Springer, 223–242.

[23] Emerson Murphy-Hill, Edward K. Smith, Caitlin Sadowski, Ciera Jaspan, Collin Winter, Matthew Jorde, Andrea Knight, Andrew Trenk, and Steve Gross. 2019. Do Developers Discover New Tools On The Toilet?. In *2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE)*. 465–475. doi:10.1109/ICSE.2019.00059

[24] Jakob Nielsen. 1994. *Usability engineering*. Morgan Kaufmann.

[25] Dan Ofer, Nadav Brandes, and Michal Linial. 2021. The language of proteins: NLP, machine learning & protein sequences. *Computational and Structural Biotechnology Journal* 19 (2021), 1750–1758.

[26] David Opitz and Richard Maclin. 1999. Popular ensemble methods: An empirical study. *Journal of artificial intelligence research* 11 (1999), 169–198.

[27] Andrew Sears and Ben Shneiderman. 1994. Split Menus: Effectively Using Selection Frequency to Organize Menus. *ACM Trans. Comput.-Hum. Interact.* 1, 1 (mar 1994), 27–51. doi:10.1145/174630.174632

[28] Michael B Twidale. 2005. Over the shoulder learning: supporting brief informal learning. *Computer supported cooperative work (CSCW)* 14, 6 (2005), 505–547.

# A Heuristiques utilisées pour le cas d'étude "Éditeur de texte"

## A.1 Alignement gauche, droite, haut, bas

* obtenir la liste *Lo* des objets qui ont changés, en comparant avec les objets d'avant.

* pour chaque L'objet dans *Lo* qui a changé, regarder s'il y a alignement possible avec les autres objets présents dans la liste avec une précision $\delta$ (paramètre).

- Alignement gauche : comparaison des x (abscisse).

- Alignement droit : comparaison des x+w (abscisse + largeur).

- Alignement haut : comparaison des y (ordonnée).

- Alignement bas : comparaison des y+h (ordonnée + hauteur)

## A.2 Copier et Aligner

* Obtenir l'objet d'intérêt *o*

- Si la taille avant et après est la même, récupérer l'objet qui a changé

- Si la taille de la liste a augmenté de 1, récupérer l'objet récemment créé.

* Pour l'objet *o*, regarder s'il y a objet similaire (paramètre $\delta$) présents dans la liste et qui est alignés avec un autre objet.

## A.3 Premier plan et arrière plan

* Si déplacement des objets ou changement dans les propriétés (couleurs, ...) -> retourner Faux

* Calculer la matrice des relations avant et après. Matrice des relations:

Soit $f(i, j) = 1$ si $o_i$ devant $o_j - 1$ si $o_i$ derrière $o_j$ 0 si $o_i = o_j$ ou $o_i$ et $o_j$ ne s'intersecte pas ($=$ pas de relation)

* Prendre que les objets qui ont changé de relations

* Prendre celui avec le plus de changement

Les heuristiques sont comparées dans cet ordre : A2 puis A1 puis A3. Dès qu'une heuristique est reconnu, la commande avancée correspondante est rerounée.

# B Heuristiques utilisées pour le cas d'étude "Éditeur de texte"

Soit Start = c, 1 : début de Sélection à la se situe à colonne c et la ligne l. Soit End = c,l : fin de sélection.

## B.1 Sélection du document

IF Start == 0, AND End == EndDocument -> "Sélection du document";

## B.2 Sélection fin de ligne

IF End.c == NumberOfColumn(End.l) -> "Sélection fin de ligne";

## B.3 Sélection début de ligne

IF End.c == 0 -> "Sélection début de ligne";
## B.4 Sélection mot suivant

Let P0 <- startNextWord( curseur) Let P1 <- EndOfWord( P0 ) IF Start == P0 AND End == P1 -> "Sélection mot suivant";

## B.5 Mot suivant

Let P0 <- startNextWord( curseur) IF Start == P0 -> "Mot suivant";

## B.6 Mot précédent

Let P0 <- startPreviousWord( curseur) IF Curseur == P0 -> "Mot suivant";

## B.7 Ligne suivante

IF Curseur(Et).c == Curseur(Et-x).c AND Curseur(Et).l == Curseur(Et-x).l+1 -> "Ligne Suivante";

## B.8 Ligne précédente

IF Curseur(Et).c == Curseur(Et-x).c AND Curseur(Et).l == Curseur(Et-x).l+1 -> "Ligne Suivante";