6.3 Evaluation et application
6.3.1 Evaluation sur des exemples construits
6.3.1.1 Protocole expérimental
Avant de passer à l’échelle, nous avons évalué le comportement de l’algorithme de regroupement perceptuel sur des exemples simples construits11. Dans ce but, nous avons utilisé l’outil DOM-Filter pour construire un ensemble de configurations d’éléments à regrouper.
Nous étudions deux types de configurations (voir Table 21 pour des exemples) :
- Cas de figure 1 : les éléments affichés à l’écran sont disposés régulièrement sur le plan ;
- Cas de figure 2 : les éléments affichés à l’écran sont disposés de manière aléatoire ; Nous supposons que les performances de l’algorithme se dégradent en cas de disposition aléatoire des composants. Par contre, nous nous attendons à obtenir de meilleurs résultats sur une disposition d’éléments qui présentent des régularités dans leur organisation, comme c’est le cas dans une interface graphique.
Pour chacun de ces cas de figure, nous testons l’algorithme sur un nombre faible (4) et moyen (12) d’éléments affichés. Pour chaque cas de figure, nous donnons :
- Le nombre d’agrégations totales réalisées (T) ;
- Le nombre d’agrégations incorrectes : ce sont des agrégations qui ont été faites à tort, car un être humain aurait ajouté ou supprimé des éléments pour que cette agrégation soit correcte (I) ;
- Le nombre d’agrégations manquées : ce sont les agrégations qu’un être humain aurait effectuées mais que l’algorithme a manquées (M).
6.3.1.2 Résultats
La Table 20 présente les résultats obtenus pour les différentes configurations d’éléments. La Table 21 illustre quelques configurations de composants et le résultat de l’application de l’algorithme.
11
Un cas construit est une configuration définie de manière artificielle et non forcément rencontrée dans la nature ; le terme est utilisé ici par analogie avec la notion de phrase construite en linguistique.
Nombre d’éléments 4 12 T I M T I M Organisation régulière 3 1 0 4 1 0 Organisation aléatoire 1 1 1 3 2 2
Table 20 : résultats de l’algorithme sur différents exemples. L’algorithme d’agrégation a utilisé un seuil
de proximité fondé sur la plus grande différence de deux éléments consécutifs dans la liste des paires d’éléments triés calculée par l’algorithme. (T): nombre total de regroupements effectués, (I) : nombre de regroupements incorrectement effectués, (M) : nombre de regroupements manqués.
Table 21 : exemples de résultats sur quelques configurations construites de composants : la colonne de
gauche présente des organisations régulières et la colonne de droite des organisations irrégulières. Les rectangles rouges figurent les agrégations réalisées par l’algorithme.
6.3.1.3 Discussion
Le comportement de l’algorithme s’avère être satisfaisant sur l’ensemble des cas testés : l’application de celui-ci permet de regrouper des éléments selon leur proximité, créant ainsi des groupes d’éléments qui semblent cohérents à l’œil humain.
6.3 - Evaluation et application
Dans le cas d’une organisation des composants aléatoires sur la surface considérée, les performances de l’algorithme se dégradent sérieusement. A l’inverse, quand une régularité dans la structure existe, comme c’est le cas d’une interface graphique, les résultats sont meilleurs. C’est un résultat conforme à nos attentes et ceci nous permet d’envisager de tester son comportement sur des interfaces graphiques réelles.
Toutefois, des limitations sont à prendre en compte :
- Les regroupements hiérarchiques ne sont pas pris en compte dans l’algorithme : c’est une caractéristique importante des IHM qui peut introduire des regroupements faux dans les résultats ;
- Lorsque le nombre d’éléments pris en compte est faible, le paramétrage de l’algorithme est important. En particulier, le choix du seuil de proximité (le nombre de paires de Widgets dont la distance est considérée comme significative) peut influencer assez fortement la qualité des regroupements effectués. Par exemple, le fait d’ajouter une paire supplémentaire, dans le cas de la disposition aléatoire de taille moyenne, permet d’effectuer un regroupement correct. Le choix de cette mesure devra donc être étudié sur les exemples réels.
- L’algorithme ne prend pas en compte les mesures de similarité qui peuvent exister entre les composants. Dans le cas précis des exemples construits où aucune sémantique n’est attachée aux éléments qu’on cherche à regrouper, ce manque n’a pas d’influence sur le résultat. Toutefois, dans le cadre d’une interface graphique réelle, il sera nécessaire de le prendre en compte et de définir une mesure de similarité entre les composants.
- Enfin, l’algorithme a réduit les composants à leur centre pour effectuer les calculs de distance. Cette simplification n’a pas d’impact dans les exemples construits en raison de la régularité de la taille et de la forme des éléments pris en compte. Toutefois, cette simplification risque d’avoir une influence lors de l’application de l’algorithme à de vraies interfaces graphiques. Il sera donc nécessaire de prendre aussi cette information en compte.
6.3.2 Application sur un site exemple : Google
6.3.2.1 But
On se donne une application écrite en HTML. On connaît le problème à identifier : les agrégations d’éléments et l’inadéquation des groupements issus du code par rapport aux regroupements que peut faire un utilisateur. La question qui se pose alors est : peut-on, en partant d’indices perceptuels objectifs, aboutir à un regroupement plus conforme à une vision utilisateur ?
6.3.2.2 Présentation du site
Au chapitre 3, nous avons pris l’exemple d’un site très simple, construit par nous-même. Nous allons maintenant étudier un site réel. Nous allons nous servir d’un site simple et connu : la page d’accueil de Google (Figure 3333).
Figure 33 : capture d’écran de l’outil DOM-Filter affichant la page d’accueil de Google. A ce stade, tous
les nœuds de la page originelle ont été traités et intégrés dans l’espace de travail de DOM-Filter et leurs propriétés visuelles ont été extraites automatiquement.
6.3.2.3 Architecture générale du site
Malgré sa simplicité, la page d’accueil de Google comporte un nombre important d’éléments. Nous allons brièvement passer en revue ce qui compose cette page. D’une manière structurelle, la page Web utilise deux éléments distincts :
- Un fichier HTML ;
- Un fichier de définition de feuilles de style CSS.
De manière classique, ce site obéit à une règle de bonne programmation en usage dans le monde de l’ingénierie Web, à savoir la séparation entre structure et mise en forme. Ainsi, la page HTML se contente de décrire les différents éléments présents ; c’est le fichier CSS qui s’occupe de la mise en forme.
En ce qui concerne la partie fonctionnalités du site, on la négligera : il s’agit pour l’essentiel de faire appel au moteur de recherche en lui-même. Ce qui va nous préoccuper, dans la continuité du chapitre précédent, concerne l’interprétation d’une interface graphique et du modèle qui peut en être fait.
6.3 - Evaluation et application
6.3.2.4 Structure et analyse du site
Le format HTML utilisé dans cette page est un format de type XML, à base de balises. L’ensemble des balises forme une structure arborescente. Les balises possèdent une représentation en mémoire : le DOM.
On distinguera deux types de nœuds : les Widgets et les containers. Widget et container sont des termes issus des librairies de composants graphiques classiques.
- Dans cet exemple, les Widgets désigneront toutes les balises qui ont une représentation graphique à l’écran, donc qui sont visibles.
- Les containers désigneront toutes les balises servant à regrouper d’autres balises. Ce regroupement peut être explicite (par exemple, une cellule ou une ligne de tableau) ou implicite (aucun affichage n’est visible). Par exemple, à l’écran, si seule une liste de liens <a href> est visible, dans le code, ces liens sont regroupés dans une balise <div>).
Pour appuyer cette distinction, on soulignera que le langage CSS prévoit deux types d’affichage pour toutes les balises d’une page HTML : inline ou block. Cette distinction permet de préciser que l’élément suivant dans le flot de traitement sera placé à la suite de la balise traitée sur la même ligne (inline), ou bien placé sur la ligne suivante (block). De façon classique, les balises de type block seront des containers, tandis que les balises de type inline seront des Widgets.
La Table 22 récapitule l’ensemble des éléments quantitatifs de la page d’index du site
www.google.fr.
Catégorie des nœuds pris en compte Compte
Nombre de nœuds 175
Nombre d’éléments visible à l’écran 32
Nombre de containers 17
Nombre de Widgets 117
Profondeur de l’arbre DOM 11
Table 22 : résultats de l’analyse quantitative de la page d’accueil de Google effectuée
automatiquement par l’outil DOM-filter.
6.3.3 Méthodologie
L’expérience consiste à comparer des regroupements de Widgets effectués de différentes manières. Le but est d’obtenir une représentation qui soit la plus proche possible d’une organisation pertinente pour un utilisateur.
Afin de mesurer l’efficacité de l’algorithme et son comportement sur la page Web, on introduit plusieurs éléments de comparaison.
- On obtient d’un côté un ensemble de regroupements témoins (appelés les agrégats
témoins). Ces agrégats constituent une référence apportée de manière manuelle par un
expert du domaine. En utilisant la plate-forme, cet expert va sélectionner, en les entourant manuellement à la souris, les ensembles de composants d’intérêt.
- De l’autre côté, on obtient des agrégats de composants obtenus de manière automatique (appelés les agrégats tests) par les méthodes décrites ci-après. On peut comparer, en extension, les agrégats tests avec les agrégats témoins.
En prenant les agrégats témoins comme référence, on peut se trouver en présence de plusieurs situations :
- « Hit » : l’agrégat témoin et l’agrégat test considérés coïncident (ils ont exactement les mêmes éléments) ;
- « Split » : un agrégat témoin est scindé sur plusieurs agrégats tests. L’exemple de la page de recherche du site de la SNCF est une illustration caractéristique d’une telle situation ;
Les situations de ce type sont particulièrement problématiques pour la synthèse d’un modèle pour l’assistance car elles sont significatives de la divergence des points de vue entre l’usager et l’application. Les structures employées par l’application ont été choisies pour permettre un certain rendu graphique en dépit de la sémantique de ces structures.
- « Overlap » : un agrégat test est inclus à l’intérieur d’un agrégat témoin ;
- « Gap » : inverse de la situation overlap, c’est l’agrégat test qui englobe l’agrégat témoin ;
Ces deux dernières situations sont représentatives d’une situation classique, rencontrée avec le langage HTML : un ensemble important de nœuds intermédiaires peut être utilisé avant d’arriver aux éléments affichés. Il existe donc une quantité importante de regroupements implicitement effectués dans le code source qui englobent une grande partie des éléments graphiques, sans que cela soit explicite, i.e., visible à l’écran. En l’absence d’informations sur les balises HTML employées, il n’est pas possible pour l’Agent Modeleur de décider quels regroupements sont importants et pertinents et quels regroupements ne le sont pas.
- « Miss » : un agrégat témoin ne se retrouve pas dans la liste des agrégats tests, synthétisés par la méthode considérée.
A l’instar des situations de split, les situations où un agrégat est identifié par un utilisateur mais pour lesquels il est impossible d’en trouver une contrepartie dans le code source sont les plus importantes pour l’assistance. Elles sont au cœur du fossé cognitif et des situations de références manquantes que nous avons évoquées dans le chapitre 3 et le chapitre 4 et qui sont dues à l’activité cognitive active de l’utilisateur.