Travail dirigé de Martin Sévigny, ©1996 | Section précédente | Section suivante | Page d'accueil | |
Lapproche méthodologique utilisée, soit la conception centrée sur lusager, nécessite une interaction constante entre les concepteurs dun 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 sexplique par le fait quil sagit en fait dun 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 nont pas été appliquées dans le cadre de ce projet de recherche. Leur intérêt du point de vue de la recherche ne sen trouve pas diminué pour autant, et ces idées et suggestions seront certainement appliquées dans les phases subséquentes du projet.
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 damé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 dusagers 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.
Le déroulement des évaluations avec les usagers laisse supposer quen 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 dexploration libre de linterface a permis à chaque évaluateur den faire un tour presque complet, et dans bien des cas à maîtriser déjà lenvironnement de recherche.
Les principaux problèmes sont survenus pendant la période dactivité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, dautant plus quà plusieurs occasions ils nont pas compris certaines informations présentées à lécran, faute dune 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 laider dans sa démarche et pour sassurer que toutes les étapes étaient franchies, car lobjectif était de leur faire voir linterface 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.
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 lidentificateur 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 lhistorique 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.
Lenvironnement de recherche, soit les bordereaux et la fenêtre de lhistorique furent très bien assimilés par les évaluateurs. En effet, la plupart ont maîtrisé ces éléments pendant la période dactivités libres et les tâches relatives à cet environnement furent faciles à exécuter.
La facilité des évaluateurs à utiliser la fenêtre de lhistorique pour modifier leurs requêtes ou revoir les résultats peut sexpliquer par leur expérience préalable avec des logiciels dinterrogation. En effet, notre interface napportait rien de bien particulier pour lhistorique, si ce nest un souci pour lintégration des fonctions. Même chose pour le bordereau de recherche simple, qui permettait des requêtes faciles à comprendre et dont le fonctionnement na pas semblé perturber les évaluateurs.
Ce quil faut retenir, cest lhésitation des usagers à utiliser les fonctions reliées à lidentification des requêtes (et des résultats), soit les champs "noms" et "description". En fait, aucun na 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 lorsquils consultèrent les résultats. Même à la suite dexplications 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 lorsquun usager utilisera linterface pendant une longue période où il effectuera un grand nombre de requêtes. Ceci explique peut-être le fait que les évaluateurs naient pas senti le besoin den faire lusage. Toutefois, il faut noter que tous ont fait remarquer que le nom dune 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 linterface est relativement simple et on ne peut y effectuer beaucoup dopérations. Toutefois, certaines remarques simposent suite à lévaluation par les usagers.
Tout dabord, 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 sagissait, et quel était leur contenu. On a de plus apprécié la possibilité de pouvoir rapidement consulter dautres résultats à laide dune 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 dautres résultats, deux fonctions sont accessibles depuis la fenêtre des résultats: obtenir la description dun é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 quil était facile de retourner dans les documents pour voir le contexte autour dun résultat.
Lenvironnement daide à la recherche est celui qui, de loin, a causé le plus de problèmes aux usagers. Comme il sagit des fonctions qui sont le plus reliées à la recherche dinformation dans les documents structurés, cette constatation peut sembler normale. Toutefois, les remarques faites par les évaluateurs sont très intéressantes.
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 litem de menu "Index des mots de la base..." du menu "Informations". Ensuite, dans la fenêtre de dialogue présentée, il fallait choisir loption "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 sagissait de consulter lindex associé à un identificateur générique particulier mais cette fois on ne fournissait pas le nom de lidentificateur en question, mais plutôt sa description. Par conséquent, les usagers devaient dabord 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 dobtenir cette information, soit lindex associé au nom dattribut "Alignement vertical". On peut obtenir lindex à partir du menu "Informations", et choisir "Un des attributs suivants" dans la fenêtre de dialogue. On peut également "double-cliquer" sur ce nom dattribut dans le guide sommaire de la structure, ou encore consulter la description de ce nom dattribut et ensuite activer le bouton "Index".
Dès les premières évaluations, nous avons senti que litem de menu "Index des mots de la base..." a causé beaucoup de confusion. En effet, puisquil sagissait à chaque fois de consulter un index particulier, cest-à-dire correspondant à un sous-ensemble de la base, lexpression "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 lajout de notions de structure à la base de documents, et donc à la recherche, semble nuire à la bonne compréhension des termes familiers en recherche dinformation. En effet, les évaluateurs, qui possédaient tous une bonne expérience en interrogation de bases de données, nont pas toujours compris que les tâches se résumaient à consulter un index. Peut-être que la surcharge dinformation disponible sur la base de documents cause cette confusion. Dailleurs, 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 lindex était finalement présenté, les évaluateurs ont vite compris quil sagissait dune liste de mots et de leur fréquence. Certains ont vu quils pourraient insérer directement un terme dans une requête. Toutefois, personne na tenté de faire une recherche dans les mots de lindex. On ne le demandait pas spécifiquement, mais les activités libres ou la curiosité auraient pu les mener à essayer cette fonctionnalité.
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 sagissait de consulter lindex associé à un identificateur générique particulier mais cette fois on ne fournissait pas le nom de lidentificateur en question, mais plutôt sa description. Par conséquent, les usagers devaient dabord 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 dactivités libres. Les usagers ont vu quils 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 lidentificateur 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, cest loubli de consulter ces descriptions lorsque nécessaire. En effet, la tâche 2 demandait de vérifier un index, mais sans quon leur donne le nom de lidentificateur 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 ny a pensé du premier coup.
Dun autre côté, lorsquil était temps dobtenir de linformation sur la structure, comme la tâche 3 où lon demandait de vérifier si une section de niveau 4 pouvait contenir un titre, on a pensé à aller voir la description de lidentificateur "Section4". On peut comprendre ce réflexe par lutilisation du terme "description", qui laisse supposer que lon y trouvera ce genre dinformation.
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 dinformation sur la structure de la base, le guide sommaire de la structure est très efficace. On louvre et ensuite on choisit lidentificateur 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, cest le guide sommaire de la structure qui donne la réponse la plus rapide. On na quà sélectionner lidentificateur générique "Figure", puis linformation 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 dactivités libres. Deux problèmes importants sont survenus par rapport à cette fenêtre.
Tout dabord, aucun évaluateur na 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 narrivaient 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é.
Lautre problème est relié à la terminologie utilisée. Les concepts de parents et denfants 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 dancê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 lutilisation dune 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, cest-à-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 dexplications de la part du concepteur, son utilisation est devenue un jeu denfant. 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 dune aide rapide. Elle semble parfaitement remplir son rôle, même si de toute évidence des améliorations pourraient être apportées.
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 dabord, mentionnons quil manque un élément dintroduction à cette fenêtre. En effet, lorsquon 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 à lusager où il pourrait savoir ce quil fait et déterminer ce quil 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 lorsquil est au-dessus dun ensemble, pour bien montrer que lon peut activer une fonction en cliquant dessus, donner des informations sur ce quest 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 linterface (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, nest pas aussi intuitive quon aurait pu le croire. Lespace requis à lécran est toutefois beaucoup plus grand si on nutilise 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 lemploi de certains termes et la façon daccéder à ce module.
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.
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.
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.
Lors de la conception d'ERIS, il nous est toujours apparu évident que non seulement tout système dinterrogation de bases de données devrait permettre un accès aux informations sur la base, mais que cela était encore plus important lors de linterrogation de documents structurés. En effet, plus les informations sur la base sont nombreuses, plus il est intéressant et important pour lusager de les connaître, dy avoir accès facilement et rapidement. Pour y arriver, le logiciel dinterrogation 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é quil manquait deux éléments essentiels pour optimiser lutilité de ces informations: un mécanisme de recherche ainsi quun point d'accès unique.
Ce point d'accès (ou guichet unique) devrait permettre à lusager (en particulier sil sagit dun usager occasionnel) de se guider dans les informations sur la base. Ces dernières étant nombreuses, un guichet unique ayant pour but daider lusager à faire un bon choix serait profitable. Ce guichet pourrait être constitué dune fenêtre permettant datteindre les différents mécanismes dinformation, 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 à lusager 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 nest pas très performante lorsque lusager ne connaît pas lidentificateur à 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 daccè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 dinformation 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 dinformations, plus il peut y avoir de confusion quant à leur utilisation. Cest pourquoi nous proposons un guichet unique pour bien guider lusager. Mais nous avons également réalisé quil 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: lorsquon 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. Sil 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 dinterface, 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, quil 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.
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 | |