Travail dirigé de Martin Sévigny, ©1996 | Section précédente | Section suivante | Page d'accueil | |
L'évaluation par des usagers, présentée dans la partie précédente, nous a permis de réfléchir à des améliorations que nous pourrions apporter à ERIS. Bien entendu, la réalisation de ce projet de recherche nous a également permis de mener une réflexion générale sur l'interrogation de documents structurés et sur les outils nécessaires pour y arriver.
Dans les pages qui suivent, nous présentons les éléments de cette réflexion, qui pourrait en quelque sorte guider les futurs concepteurs de bases de documents structurés et d'outils de recherche appropriés.
Les commentaires émis par les évaluateurs nous ont amené à pousser plus loin (et à modifier quelque peu) la réflexion que nous avions menée en début de projet (étape 3 de la méthodologie) sur l'utilisation de la structure en recherche.
Toute information stockée dans une base de données acquière (en plus de celle qu'elle possède déjà) une certaine structure. Là où les documents structurés se distinguent, c'est dans l'importance que prend cette structure et dans sa complexité potentielle. Dans la plupart des systèmes de gestion de bases de données textuelles, les usagers interrogent les documents à laide de certains champs ou index, pour lesquels ils spécifient des critères de recherche textuels, cest-à-dire relatifs au contenu des champs. De plus, il peuvent habituellement relier les critères dun même champ ou de différents champs à laide dopérateurs, booléens la plupart du temps. Par conséquent, tout ce que lusager a besoin de connaître, ce sont les champs ou index disponibles et leur signification. Bien entendu, plus il en connaît sur la méta-information (dictionnaire de données), plus ses recherche pourront être fructueuses.
Dans le cas des documents structurés, lusager doit aussi connaître les champs (éléments de structure logique) et leur signification, mais en plus, il risque dy avoir un grand nombre de types déléments, et il existe des relations entre ces éléments. À l'opposé, dans une base de données de type fichier plat, il existe une seule relation: les champs se situent sous les documents, dun point de vue hiérarchique. On pourrait ajouter que les documents se retrouvent sous la base, mais on ne peut aller plus loin.
Selon nous, même si les usagers connaissent les implications de linterrogation de documents structurés, cest-à-dire même s'ils savent quils peuvent non seulement interroger le contenu mais également la structure des documents, il demeure nécessaire d'avoir recours à des outils spécialisés.
Les réactions des évaluateurs nous ont fait constater qu'à l'heure actuelle, les usagers ne connaissent pas vraiment les implications de l'interrogation de documents structurés. Il semble que les documents structurés que lon peut interroger en exploitant leur structure sont trop rares pour que les usagers potentiels soient familiers avec ces concepts. Il est donc certain que la plupart des usagers ne seront pas habitués à utiliser de tels outils, même spécialisés. Il est même probable que les notions de relations entre les éléments portent à confusion chez certains.
Si un jour nous voulons en arriver à de meilleurs environnements dinterrogation qui répondront encore mieux aux besoins des usagers et si, pour y arriver, nous utilisons des documents structurés, il ne faudra pas oublier que dans une première phase, les usagers seront des novices dans lexploitation de la structure et même dans la compréhension de cette notion. Ceci demande, encore une fois, non seulement des outils adaptés aux documents structurés, mais en plus adaptés à des novices en la matière. Il y aura toute une terminologie à construire, des conventions à établir, etc.
Nous avons observé chez les évaluateurs une certaine confusion lorsquils sont confrontés à des éléments de structure des documents. Malgré les explications théoriques, la mise en pratique nétait pas facile. Bien entendu, il sagissait de leur premier contact avec linterrogation de documents structurés, mais ils avaient tout de même une certaine familiarité avec les documents structurés eux-mêmes et avec linterrogation de bases de données en général.
Concevoir une interface qui va permettre de réduire ou même supprimer cette confusion constitue un défi important, en partie seulement relevé dans le cadre de ce projet. Toutefois, un peu plus loin nous présenterons certaines pistes à explorer pour faire un autre bout de chemin vers cet objectif ambitieux.
Dans ERIS, la fenêtre de présentation des résultats et le guide détaillé de la structure ont un caractère commun: chacun constitue un sous-ensemble de la base de documents. La fenêtre des résultats présente un sous-ensemble dans le but de faciliter la navigation dans les résultats de recherche. Le guide détaillé de la structure, de son côté, présente un sous-ensemble de la base afin daider lusager à mieux connaître la structure.
Lutilisation de sous-ensembles, que nous appellerons portes dentrée car ils permettent de voir une partie des documents sous un certain angle, constitue une idée dinterface à exploiter davantage. Lusager pourrait tirer profit de ces portes dentrée, car elles simplifient la compréhension de la base de documents et lui permettent de se construire des petites bases personnelles, à partir de certaines parties de la ou des grandes bases.
Nous avons déjà expliqué que la fenêtre de présentation des résultats doit utiliser les mêmes éléments dinterface que le module de consultation des documents, et cest pourquoi il semblait naturel de les présenter en mode de navigation hypertextuelle. En y ajoutant des éléments tels que des signets ou lhistorique des éléments visités, lusager pourra facilement se construire son petit univers personnel dans la base.
Le guide détaillé de la structure, présenté en mode graphique, possède un potentiel très peu exploité dans le cadre de ce projet. En effet, sa présentation a séduit les usagers et lapproche en arbre inversé semble être efficace afin de présenter des éléments hiérarchiques.
Ce module pourrait devenir lembryon dune interface où les éléments graphiques sont plus présents. Par exemple, les résultats de recherche pourraient également être présentés de cette façon. De plus, une telle représentation pourrait servir de navigateur lors de la consultation des documents. Enfin, elle pourrait même servir de base à une formulation graphique des requêtes, ce qui fera lobjet dune piste de recherche présentée un peu plus loin. Une chose est sûre, cet élément dinterface pourrait être exploré plus à fond.
Pour réaliser ce projet de recherche, nous avons effectué presque toutes les étapes qui permettent de publier de linformation sous forme électronique, et qui permettent aux usagers deffectuer des recherches dans cette information. Nous allons maintenant voir quelles sont les particularités de cette démarche dans le contexte dune base de documents structurés. Pour y arriver, nous allons séparer la démarche en quatre parties, représentées par les rôles joués par lauteur, léditeur, le concepteur du logiciel et lusager.
Lauteur est celui qui crée les documents, linformation. Son rôle est primordial et en principe, cette information devrait être indépendante du processus dédition qui suit. Toutefois, cette situation idéale nest pas toujours possible ou réalisée. Pour y arriver, lauteur devrait fournir son information sous la forme dun ou de plusieurs documents structurés, soit un document électronique contenant de linformation sur la structure logique.
Il est intéressant de noter que lêtre humain conçoit des documents (du moins ceux destinés à diffuser de linformation) en fonction dune structure logique quil possède très bien. Nous sommes habitués à travailler avec des plans, des chapitres, des sections, etc. Créer un document structuré ne devrait pas causer de problèmes.
Toutefois, la disponibilité grandissante et la facilité dutilisation des logiciels de traitement de textes et de publication assistée par ordinateur viennent modifier cette approche. En effet, même si lauteur pense en fonction dune structure logique, il va rédiger son document et les balises qui laccompagnent en fonction de lapparence du document. Ainsi, il va insérer des codes de formatage plutôt que des éléments de structure logique. Il va donc à lencontre de sa façon de penser.
Demander à un auteur de fournir des documents structurés exige donc un certain effort, car il ny sera pas habitué. De plus, cela demande habituellement une certaine rigueur, puisquon doit respecter une grammaire (DTD) bien définie. Cet effort peut sembler contraignant si on le compare à lédition à laide dun traitement de textes. Toutefois, il sagit dune structure moins complexe que dentrer des informations dans une base de données par exemple, où les règles à suivre sont souvent plus strictes que pour les documents structurés. De plus, il sagit dun "retour au naturel", puisque lêtre humain réfléchit de cette façon, avec une approche structurée.
Par conséquent, nous considérons que lauteur devrait fournir ses documents dans un format structuré, en tentant dinclure le plus dinformation possible sur la structure logique. De plus en plus d'outils (éditeurs structurés) existent pour accomplir cette tâche et il n'est pas utopique de croire que plusieurs auteurs seraient prêts à les utiliser. Si l'auteur ne peut y arriver, léditeur devra le faire, ce qui risque de diminuer la qualité du processus puisquen général il nest pas aussi bien placé que lauteur pour déterminer la structure logique dun texte.
Pour les fins de cette discussion, nous allons considérer léditeur comme celui qui prend la décision de publier les documents structurés fournis par lauteur. Les éditeurs seront souvent ceux qui rassemblent linformation pour en faire des ensembles cohérents, font des choix parmi de nombreux documents pour sélectionner les meilleurs, etc. Cette définition ne diffère pas de celle donnée depuis longtemps aux éditeurs, mais leur rôle et leur façon de travailler pourraient être modifiés par la diffusion de bases de documents structurés.
Une fois que léditeur a arrêté son choix sur les documents structurés, il devra fournir un certain nombre d'informations au concepteur du logiciel, afin que ce dernier puisse les compiler et permettre ainsi la consultation et la recherche dans les documents. Nous allons explorer en détail ces informations, car cest à ce niveau que la diffusion de documents structurés amène le plus de changements. Si l'éditeur distribue son information à l'aide de plusieurs logiciels différents, il devra adapter ces informations pour chaque logiciel.
Une des conclusions tirées à la suite de cette recherche concerne limportance de présenter un maximum dinformations sur la base à lusager, importance encore plus grande lorsquil sagit dune base de documents structurés. C'est ce que nous avons appelée la "méta-information sur la base de documents" (ou plus simplement "méta-information") à la page 47, cette méta-information étant constituée de ce qu'on retrouve habituellement dans le dictionnaire de données d'une base de données et de certaines autres informations. Léditeur devra être responsable de consigner cette méta-information et de la fournir au concepteur du logiciel.
La méta-information sur une base de documents devrait inclure ces parties:
Définition formelle des documents
Les documents structurés doivent respecter une certaine définition formelle, ou grammaire. Dans le contexte SGML, il sagit de la DTD. Léditeur est responsable de fournir cette définition, puisquelle est absolument nécessaire au logiciel. À noter qu'il doit aussi la fournir à l'auteur, lorsque ce dernier doit la respecter.
Description de la base
Un ensemble de documents structurés doit avoir son rôle, sa raison dêtre. Léditeur doit fournir ces informations afin quelles soient rendues disponibles par le logiciel. On pense notamment à lobjectif de la base, sa portée, sa fréquence de mise à jour, et toute autre information générale pertinente.
Description des identificateurs génériques et des noms d'attribut
Chaque identificateur générique ou nom d'attribut utilisé dans la base a une signification précise et un rôle important à jouer. Léditeur doit fournir ces informations, quil puisera dans les commentaires de la DTD ou dans un guide laccompagnant si on se situe dans un contexte SGML. Il est important de noter que seules les descriptions des identificateurs génériques et noms d'attributs utilisés dans la base doivent être présentes. Cela correspond à la notion de structure réalisée, telle que discutée à la page 48.
Règles et styles de présentation
La présentation des résultats obtenus en recherche dinformation structurée diffère selon le type déléments retournés. Léditeur doit donc fournir les informations nécessaires, soit les identificateurs génériques qui seront affichés en entier, ceux qui seront représentés par un descripteur. Dans ce cas, il doit aussi spécifier quel sera ce descripteur.
Un document électronique est plus agréable à consulter sil utilise différents styles, soit un texte "riche". Afin de permettre cette présentation, léditeur devrait fournir une feuille de style, qui définit ainsi toutes les instructions de formatage nécessaires pour une présentation agréable des documents.
Règles dindexation
Comme pour toute base de données, lindexation peut prendre différentes formes en fonction des différents "champs". Léditeur devrait fournir des renseignements sur les éléments à indexer et de quelle façon.
Bordereaux de saisie de requêtes
Lutilisation de bordereaux pour effectuer des requêtes peut savérer fort efficace dans bien des situations. Dautant plus si les bordereaux sont bien adaptés aux besoins de recherche des usagers, et en particulier les besoins les plus fréquents. Deux intervenants sont les mieux placés pour définir de tels bordereaux: les usagers eux-mêmes et léditeur. Ce dernier connaît bien linformation dans sa base, de même que sa structure, et devrait être en mesure de fournir des bordereaux utiles au concepteur du logiciel, et donc aux usagers.
Règles de fonctionnement
Si jamais certains éléments des documents doivent engendrer des actions particulières, léditeur doit fournir ces informations. Dans un contexte SGML, cest le cas avec les liens hypertextuels, qui ne font pas partie de la norme, mais doivent être interprétés à partir de la présence de certains éléments.
Le concepteur du logiciel dinterrogation de documents structurés doit permettre à des usagers de consulter et interroger des documents rédigés par un auteur et diffusés par un éditeur. Pour y arriver, il doit concevoir un environnement constitué dun système de compilation des documents, dun moteur de recherche et dune interface.
Le système de compilation des documents doit permettre de traiter toute linformation fournie par lauteur et léditeur, soit les documents et la méta-information sur la base de documents, pour les rendre compatibles avec linterface. Cela inclut la représentation interne des données et lindexation. Ce système doit être suffisamment souple pour permettre de traiter tout type de documents et de sadapter aux prescriptions sur les styles de présentation, les règles de présentation des résultats et dindexation, les bordereaux à définir, etc.
Linterface doit être adaptée à linterrogation de documents structurés, et respecter en particulier les recommandations formulées dans ce rapport. Les critères habituels dutilisabilité doivent également être respectés. Finalement, le moteur de recherche doit permettre toutes les opérations définies par un langage de recherche pour les documents structurés.
Les deux aspects les plus importants du rôle du concepteur du logiciel dinterrogation sont la qualité de linterface et la souplesse de lenvironnement. En effet, nous avons montré que la conception dune interface-utilisateurs pour linterrogation de documents structurés nécessitait beaucoup de soins. De plus, si le logiciel doit être utilisé avec de nombreuses bases de documents qui varient énormément dans leur structure, il devra être suffisamment souple afin déviter de le reprogrammer pour chaque base. Nous considérons que ces deux qualités ne sont pas faciles à atteindre.
Finalement, nous voulons souligner que lusager a aussi un rôle à jouer dans la démarche. Lusager est dabord responsable dadapter son environnement de recherche à ses besoins généraux. Le logiciel devrait notamment permettre à lusager de déterminer ses "préférences" et ce dernier doit en tirer profit. Ces préférences sont habituellement reliées au fonctionnement général de linterface.
Ensuite, on devrait permettre à lusager de définir ses propres feuilles de style pour la présentation des documents. Cela devrait se faire selon un mécanisme simple mais puissant. Le logiciel doit donc permettre cette fonction, ce qui est du ressort du concepteur au moment de construire son interface. Lusager devrait également pouvoir définir ses propres bordereaux de recherche. Ajoutés à ceux définis par léditeur, ceci lui permettra deffectuer certains types de requêtes fréquentes avec une grande facilité.
Lusager sera aussi responsable de gérer ses stratégies de recherche, que ce soit lhistorique des requêtes ou encore les noeuds visités en mode hypertextuel.
En situation réelle, les rôles des différents intervenants ne sont souvent pas définis aussi clairement que dans les sections précédentes. Dailleurs, il faut bien noter que la classification utilisée ne fait pas référence à des individus ou des institutions, mais bien à des rôles. Les différents rôles pourraient, dans certaines situations, être tous tenus par la même personne, même sil ne sagit pas nécessairement de la solution la plus efficace.
Dailleurs, plusieurs tâches déditeur pourraient être effectuées par lauteur des documents, sil connaît bien les enjeux et les conséquences de ses actions. De la même façon, le concepteur du logiciel pourrait prendre des décisions laissées habituellement à léditeur, même si en général cette méthode nest pas à conseiller.
Limportant est de retenir que la méta-information doit accompagner les documents, et que cette méta-information doit être complète. Dans ce cas, on augmente les probabilités que lensemble de la démarche soit un succès.
Le deuxième objectif de ce travail de recherche était de réfléchir au rôle que peut jouer le spécialiste de linformation dans la conception doutils de recherche. Après un an de travail sur un projet de la sorte, certaines réflexions en sont effectivement issues. Pour bien comprendre ces réflexions, nous allons séparer la conception de linterface et la réalisation du logiciel.
Afin de bien situer les enjeux de la conception dune interface humains-ordinateurs, nous allons nous inspirer de Preece (1993) et mentionner les connaissances de base que doit posséder le concepteur dune interface:
Si le concepteur arrive à bien connaître ces informations, il pourra utiliser ses connaissances (nécessaires) sur lergonomie et en particulier les interfaces pour réaliser la conception dune interface qui respecte tous les critères dutilisabilité. Par la suite, il faut réaliser le logiciel comme tel, cest-à-dire coder linterface et la coupler au "système" sous-jacent.
Il y a deux façons de parvenir à concevoir le logiciel (y compris linterface) que nous allons considérer optimales, car elles devraient résulter en une excellente interface.
La première façon est de faire travailler en équipe un ou des spécialistes de chaque domaine. Ainsi, associer des gens qui connaissent bien les usagers, leurs besoins et les tâches quils voudront accomplir, lenvironnement où le système sera utilisé et les limites techniques. Il ne faut pas oublier dajouter les gens qui vont réaliser le logiciel, que nous appellerons les programmeurs. Cette approche sera optimale en autant que tous arrivent à travailler en symbiose, ce qui nest pas facile et en constitue la faiblesse.
La deuxième approche consiste à trouver une seule personne qui soit spécialiste de tous les domaines mentionnés. En principe, elle devrait arriver à un résultat très intéressant avec un effort minimal. Toutefois, la grande faiblesse vient du fait que trouver une telle personne est une tâche très difficile et pour bien des domaines, il nen existe probablement pas.
Les limites des deux approches nous amènent à trouver des solutions de compromis, et cest à ce moment que le spécialiste de linformation peut jouer un rôle important. Par sa formation, il est déjà un spécialiste des trois premiers éléments mentionnés par Preece, soit les usagers, les besoins et tâches ainsi que lenvironnement. De plus en plus, les spécialistes de linformation sont bien au courant des possibilités et limites offertes par linformatique, soit le quatrième point.
Si certains spécialistes de linformation pouvaient aller chercher des connaissances approfondies dans le domaine des interfaces humains-ordinateurs, le seul autre domaine manquant serait la programmation. Mais même sans cette connaissance nous serions en présence dune situation qui se rapproche du deuxième scénario optimal, puisquil y aurait seulement deux groupes dintervenants, soit les spécialistes de linformation et les programmeurs.
Réduire de cette façon le nombre dintervenants peut avoir des conséquences heureuses. En effet, les spécialistes de domaines différents ont souvent des méthodes de travail ainsi qu'un langage particuliers, ce qui rend les échanges interdisciplinaires plus difficiles. Dans le scénario de compromis que nous proposons, les échanges interdisciplinaires seraient limités à ceux entre les programmeurs et les spécialistes de linformation. Ces derniers possédant de plus en plus de bonnes connaissances informatiques, le dialogue devrait être plus facile et les échanges plus fructueux.
Ce travail de recherche a été réalisé par un étudiant en bibliothéconomie et sciences de linformation possédant des connaissances à la fois dans le domaine des interactions humains-ordinateurs et en programmation. De plus, le directeur de recherche était un informaticien de formation mais travaillant maintenant dans le domaine du repérage de linformation dans un département associé aux sciences de linformation et non à linformatique. Il sagit dun cas particulier se rapprochant encore plus de la deuxième solution optimale, mais nous considérons que la collaboration avec des programmeurs pourrait aussi savérer très fructueuse.
Afin de mettre en relief le caractère concret de ce projet de recherche et de ses conclusions, nous voulons les résumer en présentant cinq recommandations pour la conception dinterfaces destinées à linterrogation de documents structurés. Ces recommandations napportent rien de nouveau par rapport aux points de discussion précédents, mais en sont plutôt une synthèse.
Il faudrait donc sassurer de guider les usagers, de leur offrir une interface qui leur présente toute linformation désirée, et qui peut composer avec leurs erreurs.
Les documents peuvent être associés à un réseau, et souvent à une hiérarchie. Pour lêtre humain, ces concepts sexpriment et sexpliquent de façon optimale en utilisant des représentations graphiques plutôt que des listes ou du texte.
En principe, cette recommandation devrait être suivie par tous les concepteurs de logiciels dinterrogation de bases de données. Toutefois, elle prend encore plus dimportance dans un contexte de documents structurés, où les informations sont très nombreuses et importantes. Linterface devrait entre autres permettre la recherche dans la méta-information.
Ces portes dentrée sont essentielles pour permettre à lusager de se construire des visions personnelles des informations contenues dans les documents. Elles contribuent également à diminuer la complexité apparente des documents structurés.
Même si ces éléments restent à concevoir, ils semblent promis à un avenir intéressant puisquils reposent sur des concepts naturels pour lêtre humain.
Si ces recommandations sont suivies, de même que les recommandations générales pour la conception dinterfaces, on devrait obtenir une interface qui présente un haut niveau dutilisabilité.
Travail dirigé de Martin Sévigny, ©1996 | Section précédente | Section suivante | Page d'accueil | |