| Travail dirigé de Martin Sévigny, ©1996 | Section précédente | Section suivante | Page d'accueil | |
Cette annexe contient une transcription du protocole d’expérimentation avec les usagers. Pour les premières parties (jusqu’à l’expérimentation), il s’agit du texte tel qu’il fut présenté aux usagers, ce qui explique son style personnel et "oral". La partie expérimentale est plus descriptive.
Ce protocole contient les informations qui étaient considérées essentielles à la bonne marche des expérimentations. Les usagers ayant plus de difficultés avec certaines notions avaient droit à plus d’explications. L’important était de s’assurer qu’ils comprennent la notions théoriques requises de même que les tâches à exécuter.
De plus, le concepteur du prototype jouait le rôle de l’aide en ligne, c’est-à-dire qu’il donnait les informations sur l’interface lorsque les usagers posaient des questions. Ces informations ne sont pas transcrites ici.
Je termine dans quelques semaines ma maîtrise en bibliothéconomie et sciences de l’information à l’EBSI. Dans le cadre de cette maîtrise, j’ai effectué un travail dirigé de 12 crédits, pour lequel j’ai conçu un prototype de logiciel d’interrogation pour une base de données de document structurés. L’objectif principal de la recherche était d’étudier les éléments d’interface nécessaires pour l’interrogation de tels documents.
Cette recherche se situe dans un cadre plus global, puisqu’elle s’insère dans un projet de recherche de trois ans qui consiste à définir un modèle de documents structurés et de repérage dans ces documents, ainsi qu’un prototype pour tester le modèle. Ce projet de recherche est piloté par le professeur Yves Marcoux de l’EBSI. Le modèle est encore en construction, mais on a tout de même pu fabriquer le prototype, du moins une partie importante.
Pour réaliser le prototype, nous avons appliqué la méthode de conception centrée sur l’usager, qui nécessite une interaction soutenue entre les concepteurs et des usagers potentiels. Habituellement, les usagers interviennent dès les premiers prototypes et jusqu’à la fin du projet; dans notre cas, nous avons aujourd’hui le premier prototype et c’est pourquoi nous demandons votre présence.
Les commentaires émis par les usagers sont très importants, et normalement ils devraient être suivis de recommandations pour l’évolution du logiciel. Dans notre cas, le travail dirigé se termine sur ces rencontres et les modifications ne seront pas apportées. Toutefois, ces rencontres font partie intégrante de la recherche et les résultats se trouveront dans le rapport et toute publication. Votre contribution est très importante.
Toutefois, soyez assurés de la confidentialité de votre participation. Aucun indice ne vous permettra de vous identifier dans les publications, et la présentation des résultats demeurera suffisamment générale pour éviter d'associer un évaluateur à quelque caractéristique que ce soit. De plus, vous serez enregistrés, mais l’enregistrement sonore de la session pratique ne sera utilisé que pour la compilation des résultats et leur analyse. Ils ne seront diffusés sous aucune forme et ne feront pas partie du rapport de recherche.
La rencontre d’aujourd’hui se déroulera en deux grandes parties. Tout d’abord, on vous présentera la théorie qui soutient ce projet de recherche, soit les documents structurés, le modèle en développement, SGML, la base de documents utilisée, ainsi que le repérage d’information dans les documents structurés.
Dans la deuxième partie vous serez amené à utiliser le logiciel. Dans un premier temps, vous pourrez explorer à votre guise (ou presque) les différentes fonctionnalités, puis dans un deuxième temps on vous demandera d’effectuer certaines tâches précises.
Nous nous intéressons donc aux documents structurés. Qu'est-ce qu'un document structuré? Il s'agit d'un document électronique conservé selon un format structuré, et un format structuré permet un balisage logique des documents. Le concept important est donc celui du balisage logique, par lequel des balises sont utilisées pour décrire la structure logique d'un document. Et la structure logique d'un document correspond à sa division en unités comme des chapitres, des sections, etc. Ou encore en l’identification de la signification de certaines parties du texte, comme un titre d'une oeuvre, une chanson, etc.
En récapitulant, un document structuré sera donc un document électronique qui contient de l'information sur sa structure logique, sous forme de balises. Veuillez noter que cette définition est extraite de l'article de Yves Marcoux publié dans ICO Québec, volume 6, numéros 1-2, printemps 1994, et intitulé "les formats normalisés de documents électroniques".
Ces documents structurés doivent être perçus comme une hiérarchie complexe d'éléments logiques. J'utilise le terme de hiérarchie complexe car la plupart du temps on aura affaire à une hiérarchie classique, mais de façon générale on doit parler de réseau entre les éléments. Les relations possibles entre les éléments sont habituellement rigoureusement définies pour une application donnée.
Le plus souvent, chaque élément découle d'un élément parent, et possède zéro, un ou plusieurs enfants; un bout de texte sera considéré comme un élément. Mais d'une façon plus générale, nous pouvons retrouver des structures telles celles-ci:
Pour quelle raison définit-on des éléments, et comment le fait-on? Nous savons que les documents structurés contiennent de l'information sur leur structure logique, c'est-à-dire le rôle que jouent les différentes parties du document. Prenons comme exemple le fragment de texte suivant:
L'auteur québécois Michel Tremblay est célèbre dans le monde entier, notamment pour ses pièces de théâtre comme "Les belles-soeurs" ou encore ses romans comme "La grosse femme d'à côté est enceinte".
On peut définir plusieurs éléments de structure logique à l'intérieur de ce petit bout de texte:
Un document structuré va permettre d'exprimer ce contenu logique, selon les demandes de l'auteur. Une fois exprimée la structure logique, on peut faire ce que l'on veut du document: publication électronique, recherche, impression, synthèse de la parole à partir du texte, etc. Cela est rendu possible parce que l'on a enlevé les caractéristiques de formatage propres à chaque type d'application pour se concentrer sur la signification réelle des différentes parties de texte.
Le modèle de documents structurés présentement en construction permettra à la fois de définir des documents structurés, mais également d'effectuer des recherches très poussées dans ces documents. Il ne se base sur aucune norme existante, mais elles seront compatibles avec ce modèle, qui sera donc plus général. Ce modèle est présentement développé par le professeur Yves Marcoux de l'EBSI.
Une des particularités du modèle est qu'il permet de regrouper les éléments en deux grandes catégories: les éléments qui sont positionnels et ceux qui ne le sont pas. Les éléments positionnels sont ceux dont l'ordre a une importance par rapport à ses voisins. Par exemple, deux paragraphes sont habituellement rédigés de manière à être interprétés dans un certain ordre. Les éléments non positionnels sont bien entendus ceux dont l'ordre a peu d'importance. Par exemple, un élément décrivant l'auteur du document est important, mais son endroit exact l'est beaucoup moins.
Le logiciel que vous allez essayer fut construit avec comme toile de fond ce modèle. Toutefois, comme le modèle n'est pas complété et qu'il n'existe pas de corpus documentaire respectant ce futur modèle, les documents utilisés par le logiciel sont en format SGML.
SGML, pour Standard Generalized Markup Language, est une norme ISO (8879) qui permet de définir des langages de définition pour tous les types de documents. SGML n'est pas un langage en soi, mais plutôt un métalangage, car il permet de définir des langages. Ces langages, ou Document Type Definitions (DTD), s'appliquent normalement à un type de documents, même si ce concept est relativement large, et on dira qu'un document est en "format SGML" s'il respecte une DTD qui elle-même est conforme à la norme ISO.
Bien entendu, SGML permet de définir des documents structurés, et en ce sens il constitue un cas particulier du modèle en construction. Son utilisation étant de plus en plus répandue, nous avons décidé d'utiliser des documents SGML afin d'explorer les possibilités de recherche du modèle en construction.
SGML est un cas particulier car il ne permet que des hiérarchies strictes, c'est-à-dire où tous les éléments n'ont qu'un seul parent (sauf l'élément hiérarchique supérieur qui n'en a pas). On peut tout de même obtenir des liens hypertextuels en associant des actions à certains éléments. Ceci permet d'obtenir un peu l'équivalent de hiérarchies complexes. De plus, les éléments non positionnels portent un nom particulier dans SGML: ce sont des attributs. Nous avons donc des éléments et des attributs.
Le logiciel que vous allez utiliser peut consulter et interroger une seule base de données, que nous appellerons "base de documents". Cette base comprend huit des douze livres qui constituent le manuel d'utilisation de Netware 4.02, le logiciel d'exploitation de réseaux de Novell Inc. Il s'agit donc de documents qui traitent d'informatique. Novell nous a généreusement permis d'utiliser les sources SGML de ces livres pour les fins de cette recherche.
La base de documents comprend environ deux millions de caractères, soit autour de mille pages. Elle utilise une DTD appelée "Docbook", développée spécialement pour les manuels de logiciels. Elle puise de cette DTD une soixantaine d'identificateurs génériques différents de même qu'un trentaine de noms d'attribut différents. Sa structure logique est très riche, et elle contient près de deux mille liens hypertextuels.
Le logiciel que vous allez utiliser n'en est pas vraiment un, puisqu'il s'agit d'un prototype seulement. Ainsi, il n'est pas complet et peu performant. D'ailleurs, il faut tout de suite noter qu'aucune de ces qualités ou fonctionnalités ne fut recherchée:
De plus, le logiciel n'est pas complet: il n'a pas de module de consultation des documents permettant la navigation hypertextuelle, mais vous pourrez tout de même voir les résultats de vos recherches. De plus, le langage de recherche n'est pas encore implanté (ni totalement défini), et vous ne pourrez effectuer que des recherches relativement simples.
Toutefois, l'environnement de recherche est bien présent, et ce sont les qualités et défauts de cet environnement que nous voulons vérifier avec des usagers potentiels.
Après la présentation des objectifs et des concepts théoriques, l'usager est prié de s'installer devant l'ordinateur où est installé le prototype. À ce moment, le prototype est démarré, mais aucune fenêtre n'est affichée. Pendant le reste de la séance, l'usager est invité à commenter constamment ce qu'il voit, ce qu'il pense, ce qu'il ressent, etc. Ces commentaires sont enregistrés sur bande magnétique et serviront à l'analyse des résultats. Au besoin, un rappel fréquent est fait afin de s'assurer que l'usager donne constamment ses impressions oralement.
La première partie de l'expérience consiste à laisser l'usager explorer le logiciel sans lui demander de tâches précises, afin de vérifier s'il se sent à l'aise avec les menus, la terminologie, l'enchaînement des actions, etc. La consigne donnée est la suivante:
Pendant cinq minutes, vous pouvez explorer le prototype à votre guise. Dans la mesure du possible, tentez d'en constater toutes les facettes et surtout, n'oubliez pas de verbaliser vos commentaires.
Pendant cette période, le concepteur s'assure que l'usager ne démarrera pas de tâches qui prendront trop de temps avant d'être complétées.
À la suite des activités libres, l'usager est invité à effectuer une série de tâches qui ont pour objectif de vérifier si le logiciel peut répondre à certains besoins d'information d'un usager ne le connaissant pas.
L'évaluateur est remercié pour sa précieuse collaboration, et fortement invité à venir voir la présentation publique de la recherche qui aura lieu à l'EBSI à l'automne.
| Travail dirigé de Martin Sévigny, ©1996 | Section précédente | Section suivante | Page d'accueil | |