VP-SE Research Group
(C)
Il en a résulté des environnements à base de fenêtres, d'icônes et de menus, évitant à l'utilisateur de devoir apprendre un langage de commandes pour pouvoir piloter ces applications. De plus, l'adoption de directives régissant l'apparence et le comportement de l'interface avec l'utilisateur ("look and feel" en terminolgie anglo-saxonne) des applications a permis de réduire la courbe d'apprentissage de l'utilisation de nouvelles applications en profittant des connaissances opératoires acquises par l'utilisateur lors de l'utilisation d'autres applications.
A cela s'ajoute généralement la rédaction d'une documentation (guide de l'utilisateur, manuel d'initiation, manuel de référence) et éventuellement le développement d'un tutoriel d'initiation à l'utilisation du produit. Ce tutoriel est parfois fourni (voire vendu) séparément du logiciel, mais il est de plus en plus commun qu'il soit accessible directement depuis l'application même. Cette combinaison n'est toutefois que superficielle, car le tutoriel ne prend pas en considération les activités passées de l'utilisateur.
Une autre approche visant à aider l'utilisateur débutant consiste à intégrer un mécanisme d'aide en-ligne, que l'utilisateur peut invoquer à tout moment, généralement lorsqu'il éprouve des difficultés. Les simples arborescences de pages d'explications, ou parfois des hypertextes, à travers lesquels l'utilisateur peut naviguer, commencent maintenant à être remplacés par des aides contextuelles qui prennent en compte les dernières actions effectuées. L'utilisateur peut ainsi obtenir des explications complémentaires sur l'erreur qu'il a commise ainsi que des suggestions de "remédiations" [1][5][9]. Encore faut-il, pour que cette information soit pertinente, que l'utilisateur ait utilisé la bonne commande. Un tel mécanisme ne sera, en effet, pas d'une très grande utilité si l'utilisateur ne sait pas ce dont il a besoin ou ne connaît pas le concept qui pourrait lui être utile dans la situation où il se trouve.
Il ne faut pas oublier qu'il y a presque toujours un modèle sous-jascent à toute application informatique. Ce modèle était généralement déjà présent à l'esprit des développeurs lorsqu'ils ont commencé le développement de l'application et la compréhension de ce modèle, qui est rarement explicite, facilitera grandement l'utilisation de l'application.
Par exemple, pour une application de courrier électronique, le modèle sous-jascent inclus les notions de pseudonyme, de classeur pour l'archivage, d'adresses électroniques (locales ou à distance), de recherche sélective dans les archives, de composition de messages, de réponse à des messages reçus, de retransmission d'un message reçu à une autre personne, etc. Ces notions sont liées entre elles: peut-on répondre à un message archivé? Peut-on utiliser une adresse électronique présente dans un message pour définir un pseudonyme?
Pour qu'une aide à l'utilisateur soit efficace, il est bon d'aller au-delà de la simple explication des commandes opératoires du système. L'enseignement, par exemple par le biais d'un tutoriel, du modèle sur lequel est basée l'application devrait être à même de considérablement augmenter/ améliorer la compréhension que l'utilisateur a du système qu'il utilise.
Il est toutefois rare qu'un utilisateur ait la patience de s'installer face à un tutoriel pour apprendre tous les aspects d'un logiciel, aspects dont il ne perçoit pas toujours l'utilité. De plus, certains concepts "avancés" ne seront probablement pas d'une grande utilité pour un débutant, mais le-dit débutant n'est pas forcément capable de s'en rendre compte par lui-même. Il n'est donc pas aisé de réduire la charge cognitive de l'apprentissage de l'application à son strict minimum lors de l'utilisation d'un tutoriel indépendamment du logiciel dont il est sensé enseigner l'usage.
Appliquée aux logiciels, cette approche consiste à se préoccuper, tout au long du développement d'un logiciel, des différentes catégories d'utilisateurs et d'inclure dans le logiciel tout ce qui est nécessaire pour que les utilisateurs puissent, quels que soient leur bagage et leurs connaissances préalables, utiliser et, le cas échéant, apprendre à utiliser efficacement ce logiciel et les concepts qui le sous-tendent. Le logiciel prend alors un rôle actif: l'utilisateur garde le contrôle du déroulement du programme, mais le logiciel peut prendre des initiatives et faire des suggestions que l'utilisateur peut choisir d'ignorer ou de suivre. L'ordinateur n'est plus maître ou esclave; il devient un collaborateur.
Cette approche a un intérêt pédagogique indéniable puisqu'elle permet de fournir des explications ou d'introduire de nouveaux concepts "in situ", c'est-à-dire dans une situation où ils ont un sens, au moment où ils sont le plus utiles et, par conséquent, le plus à même d'être compris et assimilés. Elle permet aussi de proposer à l'utilisateur d'essayer une simulation avant d'utiliser pour la première fois une primitive dont le mauvais usage pourrait mettre l'utilisateur dans l'embarras. Cela nécessite de collecter, pour chaque utilisateur, des informations tout au long de l'utilisation du produit afin de déterminer le "profil" de cet utilisateur et d'adapter en conséquence le dialogue homme-machine. Le facteur temps constitue un aspect à prendre aussi en considération car, même lors d'une utilisation fréquente, l'uusage de certaines fonctions rarement utilisées peut comporter des difficultés. On peut ainsi imaginer que les savoirs acquis par un utilisateur se périment s'ils ne sont pas mis en oeuvre pendant un certain laps de temps.
Cette notion de profil de l'utilisateur permet aussi de concevoir une interface adaptative qui évolue en fonction de l'évolution de l'utilisateur, au fur et à mesure que celui-ci acquiert de l'expérience dans l'utilisation du logiciel. On peut, par exemple, envisager d'afficher des menus très explicites pour un utilisateur débutant, puis rendre ces menus de plus en plus concis au fur et à mesure que l'utilisateur se sera habitué à les utiliser. Nous manquons toutefois d'expérience pratique sur ce plan et la question reste ouverte de savoir si une telle interface "évolutive" constitue réellement une amélioration. Il conviendra, en effet, de vérifier si cette technique n'a pas un effet psychologique déstabilisant allant à l'encontre du but visé. Cette notion d'interface adaptative n'est pas nécessairement liée au concept de logiciel auto-éducatif, mais l'infrastructure nécessaire pour développer ces derniers permet de facilement mettre en place cette adaptativité.
Notre approche va quelque peu à l'encontre de la tendance actuelle en matière de développement d'interfaces utilisateur qui est reflétée par l'utilisation de plus en plus répandue de générateurs d'interfaces graphiques. La tendance générale est, en effet, de clairement dissocier la spécification et l'implantation de cette interface de la spécification et de l'implantation des fonctions opératoires que cette interface doit activer. Cette dichotomie franche a pour intérêt de faciliter le développement de l'application ainsi que la standardisation de l'interface de toute une série d'applications partageant alors la même apparence ("look and feel") et permettant ainsi à l'utilisateur de réutiliser, pour de nouvelles applications, certaines connaissances opératoires qu'il aurait acquises précédemment lors de l'utilisation d'autres applications.
A l'opposé, notre approche repose sur une étroite dépendance entre la spécification de l'interface utilisateur et celle les fonctions opératoires et des concepts de l'application. Nous devons donc, pour cela, utiliser une méthodologie de développement différente qui soit mieux appropriée à ce contexte, les méthodologies et outils classiques de développement d'interfaces n'étant pas adaptés aux considérations d'ordre pédagogique.
Tout utilisateur de courrier électronique, qu'il soit novice ou professionnel, voudra commencer à recevoir et à envoyer des messages aussi rapidement que possible. Bien d'autres fonctions sont disponibles, mais elles sont secondaires en regard de ces deux premières. La question par laquelle nous avons commencé consistait donc à déterminer de quelle façon il était possible de combiner l'apprentissage de l'envoi et de la réception de messages avec l'utilisation de ces mêmes fonctions. Dans notre cas, par exemple, le système prend l'initiative de déposer un message de bienvenu dans la boite aux lettres vide d'un utilisateur qui n'aurait pas encore de correspondant. D'une manière similaire, le système est à même de proposer l'adresse d'un correspondant local qui se serait porté volontaire pour aider ou conseiller des débutants. Le système est aussi capable de proposer l'adresse d'un correspondant fictif auquel l'utilisateur pourrait envoyer un message pour s'exercer.
D'une façon générale, nous avons essayé de concevoir l'interface-utilisateur de sorte qu'un concept ne soit abordé que lorsque le besoin s'en faisait sentir. Par exemple, la notion de classement des messages dans des "classeurs" ("folders" en anglais) n'est abordée par le logiciel qu'à partir du moment où l'utilisateur a suffisamment de messages pour qu'un classement se justifie. Il va de soi que l'utilisateur peut invoquer la fonction de classement à tout moment, même si le logiciel ne l'a pas encore considéré comme nécessaire. Tout cela fait partie de notre conception du logiciel comme un assistant "intelligent", c'est-à-dire obéissant, mais pas nécessairement passif pour autant.
Comme cela a été mentionné précédemment, le logiciel doit maintenir un "profil" de l'utilisateur afin de pouvoir déterminer s'il y a lieu d'activer certaines parties didactiques du programme. Dans le cas de la messagerie, les informations conservées dans ce profil comprennent des éléments tels que:
un message a été lu, un message a été envoyé, connait une adresse locale, connait une adresse à distance, nombre de fois que cet utilisateur a utilisé le système, liste de comandes d'édition utilisées, a selectionné des messages dans un classeur, nombre de fois qu'un message d'origine a été inclus dans une réponse, liste des commandes utilisées avec succès, etc.
Un prototype de ce système est en cours d'achèvement. Sa spécification ainsi que sa réalisation ont été faites à l'aide d'un environnement de développement de didacticiels faisant aussi l'objet de nos activités de recherche [6][7][8][4]. Nous développons en parallèle deux versions: l'une pour station de travail Sun utilisant le système de messagerie EAN et l'autre pour Vax/VMS utilisant Vax-Mail. La réalisation en parallèle de deux implantations nous permet d'assurer un haut niveau de portabilité de l'application ainsi produite.