Travail dirigé de Martin Sévigny, ©1996 Section précédente | Section suivante | Page d'accueil |

9. Évaluation de l'interface et améliorations suggérées

9.1 Introduction

L’approche méthodologique utilisée, soit la conception centrée sur l’usager, nécessite une interaction constante entre les concepteurs d’un logiciel et les usagers potentiels. Cette interaction doit avoir lieu tout au long des phases de développement du logiciel, des premiers prototypes aux versions "alpha" et "bêta".

Afin de bien appliquer cette méthodologie pour la conception d'ERIS, nous avons fait appel aux usagers potentiels en une seule occasion, soit à la toute fin. Cette seule interaction s’explique par le fait qu’il s’agit en fait d’un premier prototype. Normalement, la poursuite du développement du logiciel exigerait de nouvelles expériences avec les usagers.

Les objectifs reliés aux tests effectués avec les usagers sont les suivants:

Pour cette première rencontre avec des usagers potentiels, nous n'avons pas mis l'accent sur la mesure précise de l'efficacité de l'interface. Nous voulons plutôt recueillir des informations sous forme d'impressions.

Nous devons également mentionner que les modifications suggérées par les évaluateurs, de même que les idées qui sont issues de cette évaluation n’ont pas été appliquées dans le cadre de ce projet de recherche. Leur intérêt du point de vue de la recherche ne s’en trouve pas diminué pour autant, et ces idées et suggestions seront certainement appliquées dans les phases subséquentes du projet.

9.2 Méthodologie

La recherche d'information dans une base de documents structurés constitue une activité peu fréquente pour la plupart des gens, surtout lorsqu'il s'agit d'exploiter la structure afin d’améliorer la qualité des recherches. De plus, ERIS étant conçu à des fins de recherche, il n'existe pas de public cible auquel serait destiné le logiciel dans son état actuel. Ces deux particularités ont été déterminantes sur le choix de la méthodologie utilisée pour les tests avec usagers.

Un premier aspect méthodologique important pour l'évaluation avec usagers concerne le protocole d'évaluation à utiliser, c'est-à-dire l'ensemble des informations fournies et des activités demandées aux usagers. En effet, nous devons nous assurer que les usagers possèdent suffisamment d'information pour bien comprendre les activités demandées. D'un autre côté, il est nécessaire de prévoir des activités qui permettront l'évaluation la plus précise possible en fonction des objectifs visés.

Un deuxième aspect important constitue le choix des usagers. Idéalement, ceux-ci devraient faire partie du public cible du logiciel, et être suffisamment représentatifs de l'ensemble de ce public cible. Un grand nombre d'usagers facilitera l'atteinte de cette représentativité, au détriment toutefois des coûts associés à l'évaluation.

Afin de respecter ces contraintes, nous avons choisi d'utiliser un faible nombre d’usagers connaissant bien les principes du repérage de l'information et relativement bien ceux des documents structurés. Nous avons toutefois cru bon de commencer les séances d'évaluation par une introduction théorique sur les documents structurés, SGML et le repérage d'information.

Quatre évaluateurs furent invités à participer (individuellement) et ils ont tous accepté. Ces quatre individus sont tous étudiants ou finissants de la maîtrise en bibliothéconomie et sciences de l'information de l'Université de Montréal. Ainsi, ils connaissent très bien les problèmes reliés au repérage de l'information et ont déjà utilisé plusieurs systèmes différents. De plus, ces usagers furent choisis en fonction de trois critères supplémentaires:

Les quatre évaluateurs avaient une connaissance pratique de HTML ("Hypertext Markup Language", une DTD de SGML). De plus, trois des quatre connaissaient déjà les principaux concepts propres à SGML (éléments, attributs, hiérarchie, modèle de contenu, etc.). Quant au quatrième, les explications fournies pendant la partie théorique de l'évaluation furent suffisantes. Mentionnons également que la connaissance de l'environnement Windows des quatre usagers s'est avérée amplement satisfaisante.

Pour une première évaluation où l'objectif est de recueillir les impressions des évaluateurs, nous avons choisi de récolter les "résultats" par la méthode de la verbalisation. Ainsi, pendant toute la durée de l'évaluation, les usagers étaient invités à exprimer verbalement ce qu'ils pensaient, ce qu'ils ressentaient, l'état de leurs réflexions, etc. L'enregistrement sur cassette audio des évaluations a permis de conserver l'intégralité des résultats.

Le protocole complet des évaluations est présenté à l'annexe D (page 153). Il comprend deux grandes parties: une partie théorique, afin de fournir aux évaluateurs certaines notions de base sur le contexte de l'évaluation, ainsi qu'un partie pratique, où les évaluateurs pouvaient utiliser le prototype et commenter leur expérience.

La partie théorique avait une durée d'environ 25 minutes, et se déroulait dans un local avec la seule présence du concepteur du prototype et de l'évaluateur; cette partie ne fut pas enregistrée sur cassette. On y abordait les sujets suivants:

La deuxième partie voyait l'évaluateur utiliser le prototype sous la supervision du concepteur, avec des activités libres et des activités dirigées. On rappelait constamment à l'évaluateur de verbaliser ses pensées et les 35 minutes que duraient cette partie furent enregistrées sur cassette.

En premier lieu, l'évaluateur était invité à parcourir les différents éléments de l'interface, pendant environ cinq minutes. La seule consigne était de tenter de faire le tour des fonctionnalités d'ERIS, et le concepteur s'assurait que l'usager ne mettait pas en route de longues tâches qui auraient perturbé le déroulement de l'activité.

Pendant le reste de l'activité, soit environ 25 minutes, l'évaluateur était invité à effectuer un certain nombre de tâches qui lui étaient demandées par le concepteur. Ces tâches avaient été soigneusement préparées et permettaient de toucher à tous les concepts importants présents dans l'interface.

9.3 Résultats

9.3.1 Retour sur la méthodologie

Le déroulement des évaluations avec les usagers laisse supposer qu’en général, les choix méthodologiques étaient appropriés. Les explications données pendant la partie théorique se sont avérées utiles et les évaluateurs ont bien compris ces notions. De plus, la période d’exploration libre de l’interface a permis à chaque évaluateur d’en faire un tour presque complet, et dans bien des cas à maîtriser déjà l’environnement de recherche.

Les principaux problèmes sont survenus pendant la période d’activités dirigées. En effet, certaines questions ont dû être formulées de différentes façons avant d’être bien comprises. La terminologie utilisée n’était peut-être pas assez familière aux évaluateurs, d’autant plus qu’à plusieurs occasions ils n’ont pas compris certaines informations présentées à l’écran, faute d’une terminologie adéquate.

Par conséquent, les questions furent répétées de différentes façons, jusqu’à ce que l’évaluateur comprenne la tâche à exécuter. Parfois, des pistes furent données pour l’aider dans sa démarche et pour s’assurer que toutes les étapes étaient franchies, car l’objectif était de leur faire voir l’interface et ils devaient réussir toutes les tâches pour y arriver.

Les prochaines sections contiennent les résultats obtenus de l'évaluation des usagers. Ces résultats ne sont pas présentés en fonction de chaque tâche exécutée, mais plutôt regroupés selon deux grandes parties du prototype, soit l'environnement de recherche, incluant la présentation des résultats, et l'aide à la recherche. De plus, nous avons inclus une description de chaque tâche et son "corrigé" dans la section qui lui convient le mieux, afin d'aider le lecteur à bien situer les commentaires.

9.3.2 L'environnement de recherche et la présentation des résultats

Cette grande partie d'ERIS regroupe les fonctions associées aux bordereaux de recheche, à l'historique des recherches ainsi qu'à la fenêtre de présentation des résultats. Les tâches 6, 7, 9, 10 et 11 demandaient aux usagers d'utiliser l'une ou l'autre de ces fonctions.

Sixième tâche: rechercher les avertissements qui contiennent le mot "sauvegarde".

Solution:

Pour effectuer cette recherche, il faut appeler le bordereau de recherche simple (menu "Recherche") et choisir l’identificateur générique "Avertissement" dans la zone "Rechercher". Par la suite, il faut entrer le terme "sauvegarde" dans la zone "Contenant:" et lancer la recherche.

Septième tâche: restreindre la recherche précédente en sélectionnant seulement les avertissements qui contiennent également le mot "migration".

Solution:

Il faut consulter l’historique des recherches, sélectionner la recherche précédente et activer le bouton "Modifier la requête". Ceci nous amène au bordereau de recherche où il faut ajouter un deuxième terme de recherche, soit "migration", et choisir le bon opérateur, soit "ET".

Neuvième tâche: vérifier s'il existe une astuce au sujet des "services d'impression".

Solution:

Pour réaliser cette tâche, il faut essentiellement effectuer une recherche (bordereau simple) dans les identificateurs génériques "Astuce", et rechercher les deux mots "services" et "impression" reliés par un opérateur de proximité, soit "1MMO" (1 mot de distance, dans le même ordre). Préalablement, il faut savoir que les astuces sont identifiées par un élément "Astuce", ce qu'on peut découvrir en consultant la description des identificateurs, ou simplement en choisissant un identificateur dans le bordereau, puisque la correspondance entre l'identificateur générique "Astuce" et sa signification est facile à deviner.

Dixième tâche: supprimer la première requête effectuée lors de cette session.

Solution:

Pour supprimer une requête, il faut ouvrir l'historique des recherches, sélectionner la bonne requête, et activer le bouton "Supprimer la requête".

Onzième tâche: consulter les résultats obtenus avec la deuxième requête effectuée lors de cette session.

Solution:

Pour consulter des résultats déjà obtenus, il existe deux méthodes. On peut choisir la requête correspondante dans l'historique des recherches et activer le bouton "Voir les résultats". Ou encore, on peut activier la fenêtre de présentation des résultats et choisir le nom de la requête correspondante dans la liste déroulante en haut de la fenêtre. Les résultats seront automatiquement affichés.

L’environnement de recherche, soit les bordereaux et la fenêtre de l’historique furent très bien assimilés par les évaluateurs. En effet, la plupart ont maîtrisé ces éléments pendant la période d’activités libres et les tâches relatives à cet environnement furent faciles à exécuter.

La facilité des évaluateurs à utiliser la fenêtre de l’historique pour modifier leurs requêtes ou revoir les résultats peut s’expliquer par leur expérience préalable avec des logiciels d’interrogation. En effet, notre interface n’apportait rien de bien particulier pour l’historique, si ce n’est un souci pour l’intégration des fonctions. Même chose pour le bordereau de recherche simple, qui permettait des requêtes faciles à comprendre et dont le fonctionnement n’a pas semblé perturber les évaluateurs.

Ce qu’il faut retenir, c’est l’hésitation des usagers à utiliser les fonctions reliées à l’identification des requêtes (et des résultats), soit les champs "noms" et "description". En fait, aucun n’a remarqué ces informations lors de sa première utilisation du bordereau; tous ont immédiatement voulu entrer la requête. Leur premier contact avec le nom de la requête fut lorsqu’ils consultèrent les résultats. Même à la suite d’explications de la part du concepteur sur le rôle du nom et de la description, une seule fois un évaluateur a utilisé ces possibilités; il a ultérieurement nommé une requête, c'est-à-dire entré de l'information dans le champs "Nom:".

Le nom et la description des requêtes seront particulièrement utiles lorsqu’un usager utilisera l’interface pendant une longue période où il effectuera un grand nombre de requêtes. Ceci explique peut-être le fait que les évaluateurs n’aient pas senti le besoin d’en faire l’usage. Toutefois, il faut noter que tous ont fait remarquer que le nom d’une requête modifiée ne changeait pas, même si son numéro changeait. Cette particularité semble agacer et causer de la confusion; il faudrait donc revoir cette approche.

Le module de présentation des résultats de l’interface est relativement simple et on ne peut y effectuer beaucoup d’opérations. Toutefois, certaines remarques s’imposent suite à l’évaluation par les usagers.

Tout d’abord, la présentation générale des résultats semble fonctionnelle. Les usagers savaient rapidement combien de résultats ils obtenaient, de quel type il s’agissait, et quel était leur contenu. On a de plus apprécié la possibilité de pouvoir rapidement consulter d’autres résultats à l’aide d’une liste déroulante. Notons également les bons commentaires reçus quant à la présentation visuelle de la fenêtre.

En plus de la possibilité de consulter d’autres résultats, deux fonctions sont accessibles depuis la fenêtre des résultats: obtenir la description d’un élément retourné en résultat et passer en mode navigation. Les évaluateurs ont tout de suite remarqué les liens hypertextuels et ont voulu les essayer. Ils ont bien compris la description et ont pu remarquer qu’il était facile de retourner dans les documents pour voir le contexte autour d’un résultat.

9.3.3 L’aide à la recherche

L’environnement d’aide à la recherche est celui qui, de loin, a causé le plus de problèmes aux usagers. Comme il s’agit des fonctions qui sont le plus reliées à la recherche d’information dans les documents structurés, cette constatation peut sembler normale. Toutefois, les remarques faites par les évaluateurs sont très intéressantes.

9.3.3.1 Index

Les usagers devaient consulter un index lors des tâches 1, 2 et 5, qui sont reprises ici.

Première tâche: consulter l'index des préfaces.

Solution:

Il fallait choisir l’item de menu "Index des mots de la base..." du menu "Informations". Ensuite, dans la fenêtre de dialogue présentée, il fallait choisir l’option "Un des éléments suivants:", et sélectionner l’élément "Préface".

Deuxième tâche: certaines parties de la base de documents sont identifiées afin d'attirer l'attention du lecteur sur des commandes dangereuses, des opérations à éviter, etc. Consulter le vocabulaire contenu dans les éléments de ce type.

Solution:

Encore une fois il s’agissait de consulter l’index associé à un identificateur générique particulier mais cette fois on ne fournissait pas le nom de l’identificateur en question, mais plutôt sa description. Par conséquent, les usagers devaient d’abord consulter la description des identificateurs, trouver l'identificateur approprié (Avertissement) et enfin consulter son index, ce qui est possible depuis la fenêtre de description des identificateurs.

Cinquième tâche: consulter les valeurs possibles de l'attribut "Alignement vertical".

Solution:

Il existe plusieurs façons d’obtenir cette information, soit l’index associé au nom d’attribut "Alignement vertical". On peut obtenir l’index à partir du menu "Informations", et choisir "Un des attributs suivants" dans la fenêtre de dialogue. On peut également "double-cliquer" sur ce nom d’attribut dans le guide sommaire de la structure, ou encore consulter la description de ce nom d’attribut et ensuite activer le bouton "Index".

Dès les premières évaluations, nous avons senti que l’item de menu "Index des mots de la base..." a causé beaucoup de confusion. En effet, puisqu’il s’agissait à chaque fois de consulter un index particulier, c’est-à-dire correspondant à un sous-ensemble de la base, l’expression "mots de la base" semblait inappropriée. Une terminologie plus générale pourrait être utilisée, par exemple en utilisant seulement "Index...".

Ensuite, il faut souligner que l’ajout de notions de structure à la base de documents, et donc à la recherche, semble nuire à la bonne compréhension des termes familiers en recherche d’information. En effet, les évaluateurs, qui possédaient tous une bonne expérience en interrogation de bases de données, n’ont pas toujours compris que les tâches se résumaient à consulter un index. Peut-être que la surcharge d’information disponible sur la base de documents cause cette confusion. D’ailleurs, certains ont eu comme premier réflexe de chercher dans le "Guide détaillé de la structure" pour réaliser ces tâches. Par contre, une fois le concept bien compris, la répétition de ce type d'opérations (par exemple avec la tâche 5) était facile et rapide.

Enfin, mentionnons que lorsque l’index était finalement présenté, les évaluateurs ont vite compris qu’il s’agissait d’une liste de mots et de leur fréquence. Certains ont vu qu’ils pourraient insérer directement un terme dans une requête. Toutefois, personne n’a tenté de faire une recherche dans les mots de l’index. On ne le demandait pas spécifiquement, mais les activités libres ou la curiosité auraient pu les mener à essayer cette fonctionnalité.

9.3.4.2 Description des identificateurs

Une fenêtre d'ERIS permet de présenter à l'usager la description détaillée des identificateurs génériques ou des noms d'attribut. Les usagers devaient absolument utiliser cette fonctionnalité pour la réalisation de la deuxième tâche.

Deuxième tâche: certaines parties de la base de documents sont identifiées afin d'attirer l'attention du lecteur sur des commandes dangereuses, des opérations à éviter, etc. Consulter le vocabulaire contenu dans les éléments de ce type.

Solution:

Il s’agissait de consulter l’index associé à un identificateur générique particulier mais cette fois on ne fournissait pas le nom de l’identificateur en question, mais plutôt sa description. Par conséquent, les usagers devaient d’abord consulter la description des identificateurs, trouver l'identificateur approprié (Avertissement) et enfin consulter son index, ce qui est possible depuis la fenêtre de description des identificateurs (avec un bouton de commande).

La fenêtre de description des identificateurs fut en général explorée pendant la séance d’activités libres. Les usagers ont vu qu’ils obtenaient ainsi une description des éléments et attributs de la base. Certains détails de présentation de cette fenêtre seraient à revoir, en particulier mettre en évidence le nom de l’identificateur et revoir le contrôle du défilement des identificateurs, en général mal compris par les usagers. De plus, les intitulés des boutons de commandes permettant de consulter la description des autres identificateurs portaient à confusion semble-t-il.

Ce qui a surtout frappé par la suite, c’est l’oubli de consulter ces descriptions lorsque nécessaire. En effet, la tâche 2 demandait de vérifier un index, mais sans qu’on leur donne le nom de l’identificateur générique en question. La façon simple était de consulter la description des éléments pour y trouver la définition désirée. Personne n’y a pensé du premier coup.

D’un autre côté, lorsqu’il était temps d’obtenir de l’information sur la structure, comme la tâche 3 où l’on demandait de vérifier si une section de niveau 4 pouvait contenir un titre, on a pensé à aller voir la description de l’identificateur "Section4". On peut comprendre ce réflexe par l’utilisation du terme "description", qui laisse supposer que l’on y trouvera ce genre d’information.

9.3.4.3 Guide sommaire de la structure

La guide sommaire de la structure devait être consulté pour les tâches 3 et 4 de l'évaluation.

Troisième tâche: vérifier si une section de niveau 4 peut contenir un titre.

Solution:

Pour obtenir cet élément d’information sur la structure de la base, le guide sommaire de la structure est très efficace. On l’ouvre et ensuite on choisit l’identificateur générique "Section4", ce qui nous donne immédiatement la réponse dans la zone "Enfants".

Quatrième tâche: vérifier quels attributs sont associés à l'élément "Figure".

Solution:

Encore une fois, c’est le guide sommaire de la structure qui donne la réponse la plus rapide. On n’a qu’à sélectionner l’identificateur générique "Figure", puis l’information désirée est dans la zone "Attributs".

Le guide sommaire de la structure fut exploré par tous les évaluateurs sauf un pendant la séance d’activités libres. Deux problèmes importants sont survenus par rapport à cette fenêtre.

Tout d’abord, aucun évaluateur n’a pu trouver par lui-même la signification exacte des différents éléments de cette fenêtre. Le principal problème vient de la disposition des éléments à l’écran: les usagers n’arrivaient pas à voir le point central de cette fenêtre, soit l’élément décrit. Ainsi, ils ne savaient pas à quoi étaient reliés les ancêtres, les parents, etc. Nous avions tenté de mettre en évidence le nom de l’élément (couleur et taille de caractères différentes) mais cela ne semble pas avoir fonctionné.

L’autre problème est relié à la terminologie utilisée. Les concepts de parents et d’enfants ne semblaient pas avoir été compris suffisamment pour être correctement et rapidement interprétés dans cette fenêtre. De plus, la généralisation aux concepts d’ancêtres et de descendants ne fut évidente pour aucun usager.

Différentes suggestions ont été faites par les évaluateurs afin de rendre cette fenêtre plus facile à comprendre. Mentionnons l’utilisation d’une présentation graphique, plus adaptée à des hiérarchies, et la mise en évidence plus prononcée de l’élément décrit. De plus, on a suggéré de rendre la présentation dynamique, c’est-à-dire de "voir" les relations se construire, par exemple avec une présentation graphique où les éléments pourraient se placer un par un. Ces aspects feront partie de la discussion à venir.

Il y a toutefois un point très positif à noter. En effet, une fois que les évaluateurs avaient bien compris le rôle et le fonctionnement de la fenêtre, à la suite d’explications de la part du concepteur, son utilisation est devenue un jeu d’enfant. Les tâches 3 et 4 furent en effet effectuées sans aucun problème et rapidement. Ce point est très important parce que le rôle exact de cette fenêtre est de fournir des informations rapidement sur certains éléments de structure, notamment au moment de saisir des requêtes de recherche. Ainsi, elle est surtout destinée aux usagers habitués qui connaissent relativement bien le logiciel et qui ont besoin d’une aide rapide. Elle semble parfaitement remplir son rôle, même si de toute évidence des améliorations pourraient être apportées.

9.3.4.4 Guide détaillé de la structure

Le guide détaillé de la structure, un peu plus lourd à utiliser, n'était exploré que pour exécuter la tâche 8 de l'évaluation.

Huitième tâche: les ensembles de message présentent une structure très complexe qui s'étend sur plusieurs niveaux. Vérifier cette affirmation.

Solution:

Pour apprécier la complexité de la structure hiérarchique, on doit utiliser le guide détaillé de la structure. À ce moment, on peut créer une nouvelle hiérarchie (à l'aide du menu "Structure") à partir de l'identificateur générique "Ensemble de messages".

Tout d’abord, mentionnons qu’il manque un élément d’introduction à cette fenêtre. En effet, lorsqu’on la démarre, on se retrouve avec un ensemble "base de documents" dans le haut de la fenêtre, sans jamais avoir rien demandé. Il serait préférable de présenter une fenêtre de dialogue à l’usager où il pourrait savoir ce qu’il fait et déterminer ce qu’il veut comme début de hiérarchie. Pour pallier ce manque, le concepteur a fourni les explications nécessaires, notamment sur la possibilité de construire de nouvelles hiérarchies.

La présentation générale de cette fenêtre fut appréciée par les évaluateurs. On a particulièrement apprécié de se retrouver "en mode graphique". Certaines modifications pourraient toutefois être apportées, comme changer le curseur lorsqu’il est au-dessus d’un ensemble, pour bien montrer que l’on peut activer une fonction en cliquant dessus, donner des informations sur ce qu’est au juste un ensemble, puisque certains usagers ont éprouvé des problèmes avec ce concept.

Le principal problème relié à ce module est la définition des "ensembles". En effet, ce terme est absent des autres parties de l’interface (et des explications fournies pendant la partie théorique de l’évaluation) et sa présence a semé des doutes chez les évaluateurs. Ainsi, même après des explications, la visualisation du début de la hiérarchie des ensembles de message (tâche 8) en a laissé plusieurs perplexes sur la provenance des 219 ensembles de message et surtout de leurs 219 enfants (entrées de messages).

Il semble donc que cette vision de la base de documents, soit le regroupement par identificateurs génériques, n’est pas aussi intuitive qu’on aurait pu le croire. L’espace requis à l’écran est toutefois beaucoup plus grand si on n’utilise pas de regroupements.

En conclusion, mentionnons que cette fenêtre présente certains éléments qui ont plu aux évaluateurs, notamment la présentation graphique, mais que certains autres sont à améliorer, y compris l’emploi de certains termes et la façon d’accéder à ce module.

9.4 Bilan de l'évaluation par des usagers

Dans cette section, nous voulons tracer un bilan d'ERIS suite à l'évaluation par des usagers, et ce bilan se concentre sur les modifications mineures (terminologie, disposition à l'écran, etc.) ainsi que sur les modifications à la structure du prototype qui ne changent pas radicalement la philosophie sous-jacente. Dans la prochaine partie (page 100), nous allons discuter de l'ensemble du projet de recherche, et formuler des recommandations plus importantes pour l'avenir.

9.4.1 Modifications mineures

De nombreuses modifications mineures pourraient être apportées à ERIS. Ces modifications seraient relativement faciles à implanter, et ne changeraient pas son fonctionnement général.

Il est intéressant de noter que ce type de modifications est tout à fait normal dans la démarche de conception d'un logiciel selon l'approche ergonomique. En effet, l'interaction avec les usagers sert notamment à identifier les détails d'interface qui sont mal interprétés par les usagers et qui doivent être corrigés avant la sortie officielle du produit. ERIS ne fait pas exception à la règle, et l'évaluation sommaire par quelque usagers a tout de même permis d'atteindre cet objectif.

Problème: La terminologie de l'item de menu "Index des mots de la base..." du menu "Informations".

Solution:

On pourrait tout simplement renommer cet item "Index..." ou "Index des mots...". De cette façon, l'usager devrait comprendre qu'il s'agit de la fonction qui affiche un index, et les "..." suggèrent la présence d'une fenêtre de dialogue permettant une interaction avec l'usager, par exemple pour choisir l'index en question. De plus, cette expression est déjà utilisée pour les boutons de commande activant l'index que l'on retrouve sur certaines fenêtres.

Problème: Lorsqu'un usager modifie une requête existante, le nom de la requête est conservé, mais pas le numéro.

Solution:

On doit nécessairement attribuer un nouveau numéro, alors il faudrait également attribuer un nouveau nom. Celui-ci pourrait être le même nom auquel on rajouter l'expression "(modifiée)".

Problème: Les usagers ne semblent pas remarquer que la fenêtre de présentation des index (voir Figure 11: fenêtre de présentation des index, page 166) permet de faire une recherche dans l'index présenté.

Solution:

Il faudrait mettre en évidence la zone de saisie du mot à chercher, en la séparant de la zone des mots de l'index et de leur fréquence. Ceci permettrait aux usagers de mieux voir cette fonctionnalité qui peut être très utile lorsque l'index présenté est très volumineux.

Problème: Dans la fenêtre de description des identificateurs (voir Figure 10: fenêtre de description des identificateurs, page 165), le nom de l'identificateur n'est pas assez visible par rapport aux autres informations.

Solution:

Dans ce cas, il faut revoir la présentation visuelle de la fenêtre. Une taille de police plus grande pour le nom pourrait être envisagée, ou encore l'utilisation d'une couleur différente.

Problème: Dans la fenêtre de description des identificateurs (voir Figure 10: fenêtre de description des identificateurs, page 165), le contrôle permettant le défilement des identificateurs n'est pas bien compris par les usagers.

Solution:

Le type de contrôle employé dans cette fenêtre est destiné à la navigation dans une base de données, d'un enregistrement à l'autre, ce qui est justement notre but. Toutefois, ce type de contrôle est peu fréquent dans les logiciels "grand public" et cela explique pourquoi les usagers le connaissent peu. Il serait peut-être plus approprié d'utiliser des boutons de commandes intitulés "Description précédente" et "Description suivante" pour arriver aux mêmes résultats. L'ajout de flèches à ces boutons pourrait également fournir des indices visuels intéressants.

Problème: Dans la fenêtre de description des identificateurs (voir Figure 10: fenêtre de description des identificateurs, page 165), les boutons "Autres attributs" ou "Autres éléments", ainsi que le bouton "Attributs" ou "Éléments" portent à confusion.

Solution:

On pourrait remplacer les deux boutons par un seul, soit "Autre description...". Ce bouton activerait une fenêtre de dialogue permettant de choisir un identificateur générique ou un nom d'attribut, qui serait par la suite décrit dans la fenêtre.

Problème: Dans la fenêtre de description des identificateurs (voir Figure 10: fenêtre de description des identificateurs, page 165), la barre de titre n'est pas mise à jour lorsqu'un nouvel identificateur générique ou nom d'attribut est présenté.

Solution:

Il s'agit d'une simple erreur de programmation oubliée et qui devrait être corrigée dans une version ultérieure d'ERIS.

Problème: Dans la fenêtre du guide détaillé de la structure (voir Figure 5: fenêtre du guide détaillé de la structure, page 163), il n'est pas évident pour l'usager qu'il peut agir directement (à l'aide du dispositif de pointage) sur les ensembles présentés à l'écran.

Solution:

Il faudrait changer le curseur lorsqu'il se trouve "au-dessus" de la représentation graphique d'un ensemble. Il faut toutefois prendre en considération que présentement, deux opérations distinctes sont possibles: sélectionner l'ensemble (en cliquant sur sa représentation) ou encore "étendre" l'ensemble (à l'aide d'un double-clique). Deux curseurs seraient peut-être nécessaires: un lors du survol d'un ensemble non sélectionné, et un autre lors du survol d'un ensemble sélectionné. Dans ce dernier cas, l'utilisation d'un curseur particulier éviterait d'avoir recours au double-clique pour étendre l'ensemble, puisque le changement de curseur pourrait suggérer une telle opération.

Problème: Dans la fenêtre du guide sommaire de la structure (voir Figure 4: fenêtre du guide sommaire de la structure, page 162), les termes "Ancêtres", "Parents", "Enfants" et "Descendants" ne sont pas bien compris.

Solution:

Ces termes sont ceux qui, à notre avis, représentent le mieux ces concepts. Ils sont fréquemment utilisés dans la littérature sur les documents structurés et pour les hiérarchies en général. Par conséquent, nous croyons qu'ils devraient tout de même se retrouver dans l'interface. La solution à ce problème passe probablement par une réorganisation majeure de cette fenêtre, qui sera discutée dans la section suivante.

Problème: Lorsque la fenêtre du guide détaillé de la structure est visible à l'écran, un nouveau menu s'ajoute à la barre de menu ("Structure"). Toutefois, les usagers n'ont pas remarqué ce menu, et n'ont donc pas exploré les fonctions qui s'y trouvent.

Solution:

Il semble que l'ajout d'un menu à la barre de menu constitue un changement trop mineur pour être remarqué. Nous pourrions avertir l'usager lorsque la barre de menu change, mais cette pratique devient lourde pour l'usager régulier. Une meilleure solution serait d'offrir ces fonctions non pas dans un menu, mais plutôt dans une barre d'outils disposée en haut de la fenêtre du guide détaillé de la structure, où elles seraient beaucoup plus visibles.

Problème: Le bordereau simple (voir Figure 13: fenêtre présentant le bordereau de recherche simple, page 167) permet à l'usager de chercher deux mots dans un élément d'identificateur générique particulier. Les champs du bordereau sont donc identifiés par "Rechercher:" et "Contenant:" mais ce dernier terme est peu élégant.

Solution:

On pourrait remplacer "Contenant:" par "Qui contient:", ce qui serait déjà mieux.

Problème: Le bordereau simple (voir Figure 13: fenêtre présentant le bordereau de recherche simple, page 167) utilise les termes "MMO" et "MNQ" pour les opérateurs de proximité. Ils sont toutefois très peu significatifs.

Solution:

On pourrait remplacer "MMO" par "DMO", signifiant "Distance même ordre" et "MNQ" par "DNQ" signifiant "Distance n'importe quel ordre". Toutefois, même si ces termes sont un peu plus intuitifs, les usagers devront probablement consulter la définition exacte lors de leur première utilisation.

9.4.2 Changements à la structure d'ERIS

L'évaluation par des usagers permet non seulement d'identifier des éléments mineurs à modifier dans l'interface, mais également de réajuster notre tir sur certaines approches utilisées dans la structure même du prototype. Ce sont ces aspects que nous présentons dans cette section.

9.4.2.1 Guichet unique pour l'utilisation d'ERIS

Lors de la conception d'ERIS, il nous est toujours apparu évident que non seulement tout système d’interrogation de bases de données devrait permettre un accès aux informations sur la base, mais que cela était encore plus important lors de l’interrogation de documents structurés. En effet, plus les informations sur la base sont nombreuses, plus il est intéressant et important pour l’usager de les connaître, d’y avoir accès facilement et rapidement. Pour y arriver, le logiciel d’interrogation doit offrir des outils particuliers.

Notre interface offrait plusieurs accès à ces informations: nous avions les deux guides de la structure, la description des identificateurs, de même que les index. Toutefois, nous avons constaté qu’il manquait deux éléments essentiels pour optimiser l’utilité de ces informations: un mécanisme de recherche ainsi qu’un point d'accès unique.

Ce point d'accès (ou guichet unique) devrait permettre à l’usager (en particulier s’il s’agit d’un usager occasionnel) de se guider dans les informations sur la base. Ces dernières étant nombreuses, un guichet unique ayant pour but d’aider l’usager à faire un bon choix serait profitable. Ce guichet pourrait être constitué d’une fenêtre permettant d’atteindre les différents mécanismes d’information, tout en donnant une courte explication à propos des objectifs de chaque mécanisme.

On pourrait par exemple avoir un bouton "Description des éléments", suivi d'une explication telle "Pour connaître la signification et le rôle d'un identificateur générique ou d'un nom d'attribut". Il faudrait ajouter des boutons et des explications pour le guide sommaire de la structure, le guide détaillé de la structure, les index, etc.

Ces dernières fonctions existent déjà dans ERIS, et le guichet unique ne servirait qu'à guider les usagers vers les bonnes sources d'information. D'autres fonctions qui n'existent pas présentement devraient également s'y retrouver. On pense notamment à une fonction permettant d'obtenir de l'aide sur les différents concepts utilisés dans ERIS: ensembles, identificateurs, éléments, attributs, etc, ou encore fournir des exemples de requêtes utilisant ces concepts.

De plus, ce guichet unique devrait permettre de faire des recherches dans les informations sur la base. Par exemple, notre interface proposait à l’usager la description de chaque identificateur générique ou nom d'attribut de la base. Pour les consulter, il devait choisir un identificateur et lire sa description. Toutefois, cette approche n’est pas très performante lorsque l’usager ne connaît pas l’identificateur à utiliser (par exemple pour la deuxième tâche); il doit les passer un par un, en espérant que leur nombre ne soit pas trop élevé. Si un mécanisme de recherche était disponible, cette tâche serait grandement simplifiée. Ce mécanisme de recherche devrait être implanté au niveau du point d’accès unique pour les informations de la base, tel que défini au paragraphe précédent.

L'idée de présenter à l'usager toutes les informations sur la base de documents à l'aide d'un guichet unique est intéressante parce qu'on peut à la fois donner accès à la fonction (bouton de commande) et donner des explications sur ce qu'on peut y faire (explications de la fonction). Présentement, ERIS dispose principalement ces fonctions dans le menus "Informations", ce qui ne permet pas de donner des explications sur les fonctions, à cause de l'espace restreint qu'offre un menu.

On peut logiquement supposer que les usagers familiers avec ERIS utiliseront de moins en moins le panneau d'information, puisqu'ils connaîtront bien le rôle des différentes fonctions. C'est pourquoi il est important de conserver le menu "Informations" et même d'y ajouter les nouvelles fonctions proposées (recherche dans les informations, définition des concepts utilisés).

Enfin, le guichet unique sera pour les usagers non familiers un point de départ ainsi qu'un point de repère important. C'est pourquoi on pourrait penser y ajouter également les fonctions de recherche et de consultation des documents (non implantée), ce qui donne un guichet unique non seulement vers les informations sur la base de documents, mais bien pour toutes les fonctions d'ERIS. Toutefois, une telle approche demanderait une bonne réflexion sur la conception du guichet, pour éviter une surcharge d'information qui pourrait semer de la confusion chez les usagers.

Fournir un maximum d’information sur la base peut sembler évident et constituer un objectif facile à atteindre. Toutefois, les évaluateurs nous ont fait réaliser que plus il y a d’informations, plus il peut y avoir de confusion quant à leur utilisation. C’est pourquoi nous proposons un guichet unique pour bien guider l’usager. Mais nous avons également réalisé qu’il pourrait y avoir une autre possibilité de confusion qui nous avait échappée: confondre le contenu des documents et leur structure (ou les informations sur leur structure).

Cette confusion fut exprimée par un réflexe rencontré en quelques occasions: lorsqu’on demande aux usagers de vérifier une information sur la structure (par exemple la tâche 2, où l'usager devait d'abord trouver quel identificateur générique identifiait les avertissements dans la base de documents), ils pensent immédiatement à faire une recherche. Notre prototype proposait une seule méthode de recherche, soit un bordereau simple pour rechercher des mots dans un élément. S’il avait proposé plusieurs méthodes et si en plus il avait permis la recherche dans les informations sur la base, la confusion aurait peut-être été plus grande.

Par conséquent, trouver les éléments d’interface, et en particulier la terminologie, qui feront en sorte que cet environnement soit à la fois complet, utile, facile à utiliser et à apprendre pose un défi très intéressant, qu’il nous fut impossible de relever dans le cadre de ce projet. Mais nous croyons que les changements proposés dans cette partie, et en particulier ceux concernant le guichet unique, nous permettraient de nous rapprocher de cet objectif.

9.4.2.2 Le guide sommaire de la structure

L'évaluation faite par des usagers nous laisse perplexe face au guide sommaire de la structure. En effet, cet élément d'interface semble jouer un rôle important, soit celui de donner des indications rapides et concises sur la structure de la base de documents, informations qui peuvent être utiles pendant la saisie des requêtes de recherche par exemple. D'ailleurs, nous l'avons conçu à cette fin. D'un autre côté, tous les usagers ont eu des problèmes à bien comprendre le fonctionnement et la signification de cet élément.

Nous sommes donc en face d'un dilemme: doit-on modifier la présentation de ce guide, afin de le rendre plus simple à comprendre pour les usagers novices, mais peut-être au détriment de sa souplesse d'utilisation? Nous croyons qu'il serait effectivement bon de garder cet élément dans sa forme actuelle, mais il faudrait également ajouter une autre forme de présentation, plus graphique.

Cette nouvelle présentation permettrait de visualiser les mêmes informations, soit les ancêtres, parents, attributs, enfants et descendants d'un identificateur générique, mais cette fois-ci en utilisant des éléments graphiques pour représenter ces entités de même que les relation entre elles. Les détails précis de la présentation visuelle sont encore à définir, mais nous croyons que cette approche pourrait plaire aux usagers occasionnels d'ERIS.

De plus, en conservant la possibilité d'utiliser la présentation tabulaire actuelle, les utilisateurs plus familiers (ou qui préfèrent tout simplement cette présentation) pourront obtenir leur information rapidement, avec probablement une consommation réduite d'espace écran par rapport à la présentation graphique.


Travail dirigé de Martin Sévigny, ©1996 Section précédente | Section suivante | Page d'accueil |