- l'assistance dans la gestion des informations sur Internet et la stéréo-présentation portable-

A partir de 1994 j’ai étudié l’Internet avec assiduité. D’abord, je l’ai analysé comme univers documentaire utile pour des recherches en éducation. J’en ai fait une synthèse en y travaillant quelques mois pour découvrir à la fin sur Internet une synthèse analogue déjà faite! Puis, j’ai constaté que mon travail devenait caduc rapidement. Je me suis sensibilisé au problème du dépistage des informations, une étape préalable à la consultation. Le "phénomène Internet" mettait en évidence l’importance de plus en plus grande de la documentation par rapport à l’instruction dans un contexte informationnel explosif. J’ai déjà montré dans un autre chapitre que, dans une entreprise, il fallait trouver une explication au moment où on en a besoin, sans qu’il soit toujours nécessaire de la mémoriser. L’explication hors- instruction se rencontre de plus en plus dans des situations comme " l’aide en ligne ", "le support aux clients ", "l’assistance des utilisateurs", "le guichet de référence", "le groupe de coopération ".

Les dialogues avec mon épouse, qui a fait entre 1994 et 1996 des études en "Bibliothéconomie et Sciences de l’information ", m’ont permis de suivre de près la problématique de la documentation. Nous avons observé Internet comme un instrument de recherche des informations (la télé- documentation) continuant la tradition des bases d’informations distribuées. En consultant la littérature qui décrivait l’activité des bibliothécaires de références et les problèmes posés par leur conversion dans des guides documentaires pour Internet, j’ai compris que c’était un terrain fertile d’application pour mes études sur le mixage de l’assistance synchrone et asynchrone. L’Internet m’est apparu comme une énorme structure explicative potentielle, dont l’exploitation efficace réclame des formes variées d’assistance. Le bibliothécaire de référence sur Internet devrait pouvoir coopérer à distance, de manière synchrone et asynchrone avec ses clients, en leur expliquant comment trouver les informations utiles, de façon analogue à l’assistance offerte dans une bibliothèque.

Mon intérêt pour l’organisation des espaces informationnels et pour l’assistance de leur exploration ont toujours secondé celui pour la présentation discursive et dialogale. L’essai C3 (sur la physiologie) de l’explication présente la " sérialisation  du  parallélisme " (le discours expliquant des structures) et "la parallélisation de la sérialité " (la décomposition expliquant des processus) comme des phénomènes explicatifs de base. L’organisation des bases d’informations représente un geste explicatif complémentaire à l'acte discursif. Une structure informationnelle a un potentiel explicatif, qu’une exploration matérialise. Réciproquement, un environnement de découverte permet la décomposition structurée d’un discours. La recherche des informations est un discours interrogatif , alternant avec le monologue de la lecture, pour composer le phénomène explicatif de l’exploration.

J’ai observé avec attention les opérations informationnelles qu’on peut exécuter sur Internet: la navigation à la recherche des informations, l’interrogation des bases de données à distance, la gestion locale des informations trouvées, la mise au point et l’utilisation des grands moteurs de recherche et des grands répertoires, l’abonnement aux sources pertinentes, le filtrage des informations, les systèmes de recommandation, la communication bilatérale et collective, la composition des sites WEB, l’assistance et l’éducation à distance, etc. J’ai composé un curriculum et des cours et j’ai donné des leçons à quelques occasions plutôt informelles. Je voulais sentir le spécifique des procédures sur Internet comme sujets des explications. Une autre direction de mon attention est allé vers l’utilisation d’Internet comme instrument pour l’explication à distance. L’application qui me paressait la plus intéressante était l’explication des opérations sur Internet par Internet!

Un des aspects que j’ai trouvés remarquable a été la corrélation entre le succès fulgurant du WEB et la simplicité et l’universalité de l’interface HTML. La préférence des utilisateurs pour une interface unique et familière, au lieu de la multitude d’interfaces des applications client- serveur existantes exprimait à mon opinion un besoin naturel d’économie et de cohérence. Ceux qui composent des explications doivent chercher la simplicité ergonomique et la consistance sémiotique. Expliquer, c’est simplifier la compréhension, surtout pour les sujets compliqués. Les solutions sophistiquées doivent être adoptées seulement en dernier recours.

L’universalité de l’Internet promettait aussi une évasion au piège des technologies disparates, périssables et coûteuses qui diminue actuellement les bénéfices des efforts de composition. Cet espoir m’a déterminé de transposer mon groupe de problèmes sur Internet: la combinaison des modalités, la présentation pluri-pistes, le mixage synchrone- asynchrone, la modification labile du mode de coopération, le triple–contrôle. Je voulais des solutions "distribuées" - fonctionnant dans un réseau d’ordinateurs coopérants -, "portables"- indépendantes du type d’ordinateur- et "transparentes " - ne demandant aux acteurs de se concentrer que sur la logique de l’explication, sans avoir besoin de savoir tous les détails techniques. Cette tentative m’a valu la prolongation de mon étude de deux ans...

Je me suis proposé d’intégrer une gamme de nouveaux instruments explicatifs, basés sur la coopération à triple contrôle, dans des systèmes complets d’assistance pour les utilisateurs d’Internet. J’ai nommé finalement ce projet "TaxiNet " .

Le point de départ de ce projet était l'observation que l'orientation des voyageurs dans le labyrinthe informationnel Internet est un problème de plus en plus critique. Une fois arrivé sur un site ils peuvent utiliser les moyens conçus pour l'assistance des utilisateurs. Mais le problème que je posais était: qui et comment peut offrir de l'aide aux navigateurs qui ne sont pas encore arrivés à l'adresse la plus opportune et qui ont besoin d'assistance pour la trouver ? Ils peuvent parvenir sur un site en navigant, en partant d'une recommandation trouvée quelque part, en utilisant un répertoire comme Yahoo ou un moteur de recherche comme AltaVista . Ils peuvent aussi utiliser les menus que certains fournisseurs de services Internet (AOL, etc) offrent à leur clients. Ces outils sont nécessaires mais pas suffisants. Il existe un public qui n'est pas bien servi par les instrumentes actuels d'orientation et qui, en conséquence, utilise l'Internet difficilement et inefficacement. Les voyageurs non–experts s'orientent avec difficulté sur la carte énorme et changeante du l'hyperespace , ne sont pas avisés sur les instruments et les techniques qu'il pourraient utiliser , ne sont pas en mesure de décider quelles adresses sont les plus pertinentes et dignes de confiance, ne savent pas comment filtrer les informations obtenues avec les moteurs de recherche etc. La compréhension de ces problèmes impose des nouvelles formules d'assistance , qui combinent la documentation à adresse générale avec l'aide personnalisé offert par un assistant humain, de manière synchrone ou asynchrone. Voilà donc l'objectif du TaxiNet.

Les centrales TaxiNet devaient permettre d’abord la mise en contact ( immédiate ou programmée pour plus tard ) des guides et des clients, qui annonçaient leurs demandes et leurs offres. Puis, elle devait permettre la navigation coopérative synchrone et la coopération asynchrone par une navigation annotée. Elles devaient aussi soutenir plusieurs autres opérations dont la gestion des informations, la composition WEB, les abonnements, la communication etc. Enfin, un système de suivi, de rétroaction et de paiement était aussi nécessaire.

Je voyais plusieurs contextes d'application:

- Un fournisseur d'accès Internet pourrait utiliser une centrale TaxiNet pour améliorer la qualité des services offertes à ces clients.

- Une entreprise pourrait équiper son réseau local avec une centrale TaxiNet pour offrir à ses employés la possibilité d'exploitation coopérative de Internet, ou l'assistance d'un documentaliste spécialisé

- Un centre virtuel d'information pourrait utiliser TaxiNet comme site WEB, exploitée par la coopération libre entre les utilisateurs ou par l'intervention des guides spécialisés et payés.

- Un centre publique TaxiNet serait utilisable par des personnes qui n'ont pas d'accès Internet, ou ne veulent pas perdre trop du temps avec la recherche et préfèrent des services Internet "à la carte ", avec tout l’encadrement nécessaire, comme dans un restaurant.

En fabriquant des "TaxiNet ", je voulais pousser plus loin l’étude comportementale et en même temps tester mes idées destinées à inspirer la fabrication de nouveaux instruments. Pour un projet si vaste, j’avais besoin de partenaires. Un vieil ami, homme d’affaires à Washington, voulait lancer en Roumanie une entreprise de design WEB et cherchait quelqu’un pour former l’équipe de développement. D’autre part, l’Institut Polytechnique de Iasi (où j’avais fait mes études en Télécommunications) était une pépinière d’étudiants en informatique, qui permettaient la sélection d’une équipe forte. J’ai profité de cette double opportunité. Le plan initial a été d’organiser le stage des futurs "développeurs WEB" autour du projet TaxiNet. J’espérais parvenir dans un an à un premier prototype fonctionnel, avec lequel on aurait pu équiper l’Institut Polytechnique, qui avait besoin d’optimiser l’utilisation de l’Internet pour la documentation et la recherche. En septembre 1997, je me suis déplacé vers la Roumanie dans le laboratoire de Iasi où j’ai travaillé plus d'un an comme chef de projet et d’équipe.

Sur le plan de la consolidation de l’équipe de design WEB et du lancement de l’entreprise EASE, les résultats ont été positifs. On a tous gagné beaucoup d’expérience. Certaines parties du projet ont été développées jusqu’au stade de prototypes fonctionnels. Mais le TaxiNet n’a pas été finalisé... Ce n’est pas la place pour décrire ici la multitude des obstacles auxquels je me suis heurté et qui m’ont obligé à percevoir la différence entre la recherche et le développement. Si j’en signale quelques-uns, c’est pour expliquer ce que j’ai compris sur la position difficile d’un acteur du système complet de l’explication: l’ingénieur fabricant.

Un multitude d’aspects collatéraux et imprévus m’ont obligé à négliger ou ont perturbé l’axe principal de ma recherche: l’expérience initiale réduite des étudiants dans le développement WEB, les fonds et les moyens restreints par rapport à l’ampleur du projet, le temps impressionnant réclamé pour l’organisation du réseau des ordinateurs et la méthodologie de développement, le besoin s'orienter continuellement dans l’univers hystérique des technologies et des informations, etc. Le temps passait impitoyablement; les solutions intéressantes se dévalorisaient le lendemain de leur apparition; la technologie évoluait plus vite que notre capacité de la suivre! Le fait de travailler dans le laboratoire jusqu’à 44 heures sur 48... n’a changé que peu de chose. L’importance cruciale du capital pour le succès de l’entreprise de fabrication était d’une frustrante évidence...

En réalisant que le projet initial était trop ample pour le contexte du terrain, j’ai décidé de le diviser en plusieurs sous-projets que j’ai proposés à des équipes plus petites. Je les ai conduits parallèlement.

La gestion de la mise en contact des assistants et des assistés a été traitée dans plusieurs projets:

"Assistance synchrone" (développé en ISAPI C++ par C. Mironeanu et S. Mihaila), préparait le contact immédiat, sollicitée par un " Internaute " en difficulté; le système cherchait un assistant approprié et disponible, utilisant un algorithme de type " queue d’attente ".

" Assistance asynchrone " (développé en ISAPI C++ par S. Mihalche si N. Archip) permettait, à l'aide d'une structure de définition de l'expertise, la programmation de celui qui avait besoin d’aide sur la liste d’un guide disponible ultérieurement.

J’ai exploré des techniques de gestion du processus de type "demande et offre " (" matching systems ") dans les projets- étude: " Jobs " (développé en PowerBuilder par S. Kovacs); " Real Estate " (développé en CGI VisualBasic par I. Sova); " Personals " (développé en ColdFusion par C. Mitocaru); " Cars " (développé en ASP et VBscript par I. Macovei); " News " (développé en C++ par D. Papaghiuc). A part les éléments classiques (la gestion des informations, les comptes des clients, la sécurité, la performance du serveur, l’interface ergonomique, etc.) j’ai étudié dans ces projets des comportements qui visaient le fonctionnement des TaxiNet : les robots de corrélation entre la base des offres et celle des demandes, la transformation d'une recherche vers une des bases dans une inscription dans l’autre, la répétition automatique des requêtes et l'avis par émail en cas de réussite etc.

Les problèmes du suivi , de la personnalisation des comptes, du commerce et de paiement électronique, nécessaires pour la gestion des TaxiNet ont été aussi abordés dans une série de projets (conduits par B. Ghidireac et développés avec ASP, SSL, CyberCash, SiteServer).

J’ai scruté dans les projets "Collective memory" (développé en CGI Perl et JavaScript par M. Feraru et A. Dumitrascu ) et "Cooperative Active Bookmarks " (développé en C++ et ASP par S. Mihalache) la problématique de la gestion coopérative des onglets de référence sur Internet et intranet. Dans les spécifications des protocoles de coopération, j’ai suivi le cas de la collaboration documentaire dans une équipe d’experts ayants différents rôles dans une entreprise et d’autre part, le cas la collaboration entre un client et le bibliothécaire de référence qui l'aide dans la recherche des informations.

Les techniques impliquées dans les projets (les serveurs WEB, les bases de données, les langages de programmation) ont été très variées au début parce que nous avons voulu comparer leur potentiel pour comprendre les tendances de la technologie et établir des formules "portables " (dépendant le moins possible d’un outil spécifique). On devait aussi préparer l’équipe pour une gamme encore imprécise de contrats potentiels. Cette ambition a retardé l’avancement du TaxiNet. Ce n’est qu’en 1998 que nous nous sommes arrêtés sur une technologie: BackOffice (NT 4.0, MIIS, SQL 6.5) VisualStudio (InterDev, ASP, VBasic, C++, J++) DHTML, JavaScript, ActiveX, JavaApplets, Flash).

Tout cela avait de quoi décourager un auteur qui osait se lancer dans la fabrication "de bas niveau ", parce qu’il était mécontent des outils de composition que les informaticiens lui offraient...

Le problème principal pour ma recherche, qui était aussi l’axe des TaxiNet, a été le mécanisme de coopération tri- polaire expert- ordinateur- novice. Cette étude a été concentrée dans le projet "Cooperative browsing " (développé avec C++ et DCOM par S. Mihaila et O. Groza). L’évolution tortueuse des spécifications de ce projet a commencé avec ce plan initial :

Deux ordinateurs liés en réseau partagent une démonstration. Les fenêtres principales contiennent une application quelconque devenue bi- contrôlable par un mécanisme extérieur. Leur corrélation se base sur une " fenêtre de glace " (transparente) superposée sur la fenêtre de l’application, qui ainsi complétée avec une couche démonstrative, constitue la piste principale de la démonstration. Quand un des partenaires tente une action vers l’application, son geste est intercepté par le filtre de glace, qui possède des instructions concernant la réaction. L’interprétation correcte du geste au niveau du filtre superposé suppose que celui-ci suive les transformations de la fenêtre qu’il couvre (scroll, refresh, etc) et que l’auteur de la démonstration prépare des réactions explicites et cohérentes. Sur le "filtre de glace " l’auteur et les partenaires peuvent faire des annotations: des signaux, des explications, etc. Le même filtre doit transmettre les gestes au partenaire à distance. De l’autre coté, le "filtre jumeau" doit faire les adaptations nécessaires, mixer les télé-commandes avec les ordres de l’utilisateur local, pour contrôler en conséquence l’application qu'il a au- dessous. Ils existent aussi des pistes supplémentaires de communication. Dans le cas asynchrone, l'utilisateur qui navigue seul peut faire des annotations que son partenaire pourra revoir à l'occasion de la reprise de la navigation enregistrée.

Ce projet s’est avéré très difficile. Je décris plus bas quelques problèmes techniques rencontrés pour illustrer la position du fabricant dans l’univers des instruments primaires qu’il utilise pour produire les instruments secondaires nécessaires au concepteur de l’explication. On saisira ainsi la différence entre ces deux mondes et la raison pour laquelle il n’est pas facile de trouver un langage (dénominateur) commun pour leur dialogue...

L’Internet n’offre pas encore des conditions pour une coopération en temps réel et ne garantit pas l’explication synchrone. Le protocole IP et ceux basés sur lui utilisent la transmission par paquets, sans maintenir une connexion permanente (comme le font les centrales téléphoniques), ce qui a apporté économie et flexibilité; en même temps il n’assure pas le passage immédiat d’une commande d’un ordinateur à l’autre. Quand le réseau est congestionné, un acteur peut recevoir la réaction de son partenaire avec un retard inacceptable. Ajoutons à cette restriction la bande de transmission limitée et fluctuante qui ne garantit pas le passage des signaux multimédia dans le volume et le rythme nécessaire. En dépit des efforts pour garantir la bande d’accès (compression des informations, techniques de " streaming " comme " RealAudio " et " RealVideo ", méthodologies de négociation de la "qualité du service " etc.), la transmission synchrone multimédia sur Internet reste problématique. Cet aspect dérange surtout quand le principe sur lequel se fonde la réplication de l’application à distance est le " bitmap sharing " (la copie d’un écran pour le refaire sur l’autre).

Si on utilise le principe des " replicated architectures " (deux applications distinctes mais synchronisées par des ordres qui passent entre les deux ordinateurs) les nécessités de bande passante sont plus modestes. Mais la synchronisation est empêchée par l’absence d’une transmission immédiate, si on n’utilise pas de nouvelles technologies de commutation (comme ATM, qui ne se généralise pas au rythme que j’espérais en 1997). Ainsi, j’ai dû faire des compromis dans la quête des comportements désirés: fabriquer l’instrument de partage seulement pour la navigation coopérative dans les réseaux locaux (intranet) et mettre au point pour Internet des solutions partielles.

Une difficulté redoutable était de rendre portables les objets explicatifs partageables, ce que le contexte Internet promettait.... Mon espoir était de lier deux ordinateurs avec des configurations différentes (hardware, systèmes d’opération, variables d’état). Mais cela s’est avéré un vœu pieux à cause des restrictions des couches technologiques qui ne m’ont pas permis la "transparence " au niveau de la couche de communication. Les systèmes d’opération existants (Microsoft Windows, MacOS, XWindows) gèrent différemment les interfaces de leurs applications, empêchant l’interception des actions adressées par l’utilisateur vers l’application A1, pour l’injecter vers l’application A2. Cette manœuvre est difficile même si les systèmes d’opération sont identiques. Quand l’interception se fait à l’intérieur de l’application A1, on peut transmettre un ordre vers A2 seulement si le système d’opération de l’ordinateur permet la manipulation d’une application par ordre extérieur, à la place des gestes sur l’interface de l’utilisateur local. Dans le système Windows de Microsoft nous n’avions pas retrouvé les facilités de commande extérieure (par " script ") offerte par AppleScript aux applications MacIntosh que pour quelques applications conçues les dernières années (par exemple le " scripting " VBA pour la gamme Microsoft Office). Microsoft a introduit récemment des techniques comme COM, DCOM OLE Automation sur la base desquelles on peut construire des applications contrôlables à distance par scripts. L’informatique est en train de faire de grands pas dans la direction des applications distribuées et du contrôle à distance. Le modèle virtuel de comportement que j’ai décrit à la fin de ce chapitre sera probablement bientôt une réalité. Mais aujourd’hui encore, un auteur d’objets collaboratifs- explicatifs distribués ne dispose pas d’instruments de composition appropriés.

Même quand on peut intercepter des ordres en A1 pour les injecter en A2, on doit résoudre des problèmes supplémentaires. Par exemple, nous devons concilier les ordres à distance avec les ordres locaux ("floor control") et réaliser un " awareness " qui donne aux partenaires la possibilité de s’observer adéquatement. Nous devons aussi résoudre les problèmes posés par les différences entre les contextes des deux applications liées. Les moniteurs peuvent avoir des dimensions différentes ou être réglés sur d’autres résolutions. Les processus peuvent se dérouler avec des temps différents d’exécution. Les fenêtres des applications peuvent être placées et dimensionnées différemment. Les variables de système inscrites dans les registres des ordinateurs peuvent aussi différer. Ainsi la transposition d’un geste, d’un contexte vers l’autre, peut réclamer une adaptation ou une réduction des libertés de manœuvre.

La réalisation d’une "application partagée" sur deux plates-formes identiques par la programmation explicite des deux répliques corrélées est complexe mais pourtant faisable. Pour faciliter la composition des démonstrations de type " shared work ", le mieux serait de disposer d’un unique outil " d’authoring ", applicable sur toute application destinée à l’explication à distance. En passant de la démonstration d’une application à la démonstration d'une autre, l’auteur utiliserait les mêmes mécanismes de composition. Il s’occuperait seulement de la physiologie démonstrative superposée sur la couche des applications, sans être obligé de modifier leur code, auquel d’ailleurs il n’a généralement pas accès. Les mécanismes de partage devraient être englobés dans la méta- application démonstrative et non pas infusés dans l’application démontrée. Mais comment intercepter, interpréter, retransmettre et traiter les actions de l’utilisateur sur la fenêtre de l’application, sans entrer dans son programme? . L’essai d’agrandir la reproductibilité de la solution se heurte à de grandes difficultés à cause de la manière de contrôler les applications utilisées par les systèmes d’opération actuels.

Nous avons essayé de réaliser la "fenêtre de glace " B1, superposée sur l’application A1 qui devait intercepter les gestes pour les transmettre vers la fenêtre- sœur B2 qui couvrait A2. Ici on injectait les ordres reçus dans la "queue d’attente " que le système d’opération Windows utilisait pour satisfaire les commandes de l’utilisateur local. Cette technique devait respecter le mode de gestion des interfaces, supporter les changements dynamiques des fenêtres, dépasser la difficulté du mixage des gestes locaux et répliqués, permettre " l’awareness ", soutenir les commentaires et les annotations. Mais le fait de préparer les réactions démonstratives "au dessus " de la couche de l’application nous isolait des mécanismes d’interprétation des gestes à l'intérieur de l'application . L’auteur était obligé ainsi à un effort important d’interprétation supplémentaire, difficile à synchroniser avec celle de l’application, surtout si on permettait la modification des fenêtres (dimension, scroll, résolution, couleurs, etc.). Les spécifications de la carcasse démonstrative universelle se sont avérées en conséquence trop ambitieuses. Nous sommes arrivés à la conclusion que, jusqu’à l’arrivée des ordinateurs spéciaux, utilisant une couche intermédiaire comme filtre contrôlable entre les actions et les applications, nous devions nous contenter de solutions plus modestes.

On a pu faire des compromis en réduisant l’espace des opérations, en utilisant des plates-formes identiques et des applications dédiées. Notre prototype réalise déjà la navigation à double commande avec deux navigateurs Microsoft Explorer modifiés pour permettre la coopération, les annotations et la communication entre les deux pilotes. Il s’inscrit dans une vague de préoccupations similaires. Des exemples de plus en plus intéressants montrent l’intérêt actuel du sujet: le " Cooperative Browsing " avec Netscape Conference, le mode " Application Sharing " de Microsoft NetMeeting etc. Nous assistons à une explosion des applications de type " Remote Control " et " Shared Applications ", ayant l’origine dans le " groupware " ou les " vidéoconférences ", basées sur les technologies de l’informatique distribuée (DCOM, Corba etc) et préparant le passage vers le "network computer" .

Mais même pour le cas particulier de la navigation coopérative, il y a encore beaucoup de problèmes difficiles. Prenons seulement l’exemple du rapport en triangle entre deux navigateurs et un serveur qu’ils essayent de visiter en coopération La symétrie désirée n’était plus possible: les deux ordinateurs avaient des IP différents; leurs possesseurs avaient des paroles et des droits différents par rapport à l’application qui roulait sur le serveur, qui leur allouait deux sessions différentes; les conditions des réseaux pouvaient introduire des différences importantes entre les réponses que les deux clients recevaient pour des requêtes similaires! Pour dépasser cette impasse (qui apparaît dans la réplication de toutes les applications de type client–serveur) nous avons dû permettre l’accès réel au serveur pour un seul navigateur, qui mixait les commandes des deux utilisateurs et leur distribuait les répliques reçues du serveur.

Toutes ces complications ont retardé l’apparition du démonstrateur WEB à triple commande et des TaxiNet qui en dépendaient, au-delà du terme que j’avais à ma disposition pour terminer mon doctorat. J’ai du quitter

le laboratoire de Iasi et revenir à Montréal pour terminer ma thèse, tout en continuant de surveiller à distance l’avancement des travaux (expérience que je n’ai pas assez d’espace pour décrire ici). Ma tentative n’a donc pas réussi dans le délai disponible. Pourtant, je considère l’expérience comme fort intéressante. J’en suis sorti enrichi sur le plan de l’observation de la production des outils informatiques, ce qui complétait mon incursion phénoménologique.

D’autre part, l’équipe de Iasi s’est soudée et a gagné une expérience importante dans la combinaison des techniques variés pour bâtir une application de mise en contact, de documentation, de transaction. Pour ma part, j’ai pu valoriser cette expérience dans un projet de coopération avec l’Université de Montréal. Pendant l’automne 1998, nous avons contribué à un cours de développement WEB (IFT 3220), présenté par le professeur Jan Gecsei, par des suggestions concernant le curriculum et le laboratoire et par un tutoriel qui7 permettait aux étudiants la comparaison de plusieurs technologies de design WEB.

Dans ce projet, appelé "StereoTutor" (développé avec C. Mitocaru, L. Vornicu, S. Savin, A. Dumitrascu) je n’avais pas pu encore intégrer la triple commande pour des raisons exposées plus haut. Ce perfectionnement devait prendre encore un certain temps car ils dépendait de la finalisation du projet de coopération avec "fenêtre de glace ". Ce que j’ai pu introduire dans "StereoTutor " était le principe de la stéréo- démonstration, transposé dans les conditions du WWW. La réalisation a été simplifiée par rapport au cas de l’HyperCard, à cause du caractère labile du HTML. D’autre part, les instruments de travail interactif au niveau du navigateur (JavaScript, Java applets , ActiveX controls, Netscape plug-ins, Shockwave et Flash) ne permettaient pas la réalisation facile d’un stéréo- démonstrateur multi- contrôlable (simulation avec aspect graphique garanti, couches d’annotation, awareness, floor control , etc).

Notre tutoriel (accessible à l’adresse www.easeweb.com/umontreal) met en évidence l’intérêt du principe de la stéréo- démonstration pour les présentations multi- facettes et comparatives. Son but est l’initiation dans le design au niveau du client WEB et du serveur WEB. La méthode d’explication consiste dans la présentation commentée du traitement d’un même problème (un magasin virtuel simple) dans 6 technologies différentes. Les utilisateurs peuvent comparer les sources commentées et les schémas de design et disposent aussi des méta-commentaires des "développeurs" (C. Mitocaru, A. Dumitrascu, S. Mihalache, M. Iftime, S. Breban).

De coté du serveur sont comparés les: ASP- VBscript, ColdFusion, Java Servlets, ISAPI C++, CGI Perl , JavaScript- LiveWire et l’accès aux données par ODBC, JDBC, ADO, Access, SQL 6.5, miniSQL, fichiers plats. Du coté du client (browser) l’interactivité et la gestion des données ont été résolues avec JavaScript, VBscript, Cookies, ActiveX , DHTML Datasources, applets Java.

Les observations et l’explication qui suivent seraient plus utiles si elles accompagnent la visite du site.

La piste principale de la démonstration ("application ") présente un magasin virtuel simple mais fonctionnel qui se comporte identiquement dans les 6 alternatives techniques. Pour passer de la démonstration d’une technologie à une autre, cette piste aurait dû contenir vraiment la technique commentée dans les autres fenêtres démonstratives. Mais l’emplacement de la démonstration à un seul fournisseur Internet, qui ne dispose pas de tous les serveurs et services que les 6 technologies utilisent (serveurs MIIS, Netscape et Apache, extension ASP et Cold Fusion etc), rend ce fonctionnement impossible. Profitant du comportement identique des versions, on a équipé la démonstration avec une seule implémentation, utilisée pour illustrer le fonctionnement de l’application. Ceux qui seraient intrigué par ce truc, peuvent visiter les applications réelles, installées dans le réseau local de Iasi.

La deuxième piste ("sources") relève les sources (les programmes) qui réalisent le comportement de l’application. Elles sont enrichies par trois niveaux de commentaires (concernant une ligne, un module ou toute la page source), conçus et mis en évidence de façon consistante. Le fait important est que, pareillement à un "meta-debugger", la piste "sources " contient à tout moment exactement les modules qui sont intervenus pour réaliser la dernière opération. Ces modules sont extraits des pages sources globales, qui peuvent être consultées pour saisir la position du module courant. Si l’utilisateur change de technique, la fenêtre se met à jour, en lui permettant de comparer les sources qui réalisent des fonctions analogues.

La troisième piste ("cartes ") contient les schémas de l’application en deux versions : un schéma simple (utilisable dans le dialogue client-analyste pour l’extraction des spécifications) et un schéma complexe avec les détails d’implémentation , basé sur la modélisation UML (utilisable pour le dialogue analyste-"devéloppeur"). Le schéma général est commun pour les 6 applications. Par contre, les schémas UML différents, mettent en évidence les différences d’approche entre les techniques. Comme pour le cas de la piste source, on peut choisir le schéma voulu à tout moment. L’utilisation de la technique "flash " pour la réalisation de ces cartes offre à l’utilisateur de bonnes possibilités d’investigation , permettant d'agrandir les détails, de déplacer la fenêtre d’observation, de percevoir les modules actifs mis en évidence par les couleurs et l’animation et d'appuyer sur les blocs dont on veut obtenir des informations supplémentaires dans les autres fenêtres.

La quatrième piste ("commentaires ") est dédiée aux observations sur la réalisation de chaque pas de l’application, que les concepteurs partagent avec leur public. Elle utilise des métaphores graphiques qui mettent en évidence le processus de coopération entre le serveur et le browser dans l’interprétation et l’exécution des sources. Elle contient aussi des explications textuelles, commentant les schémas graphiques ou révélant divers aspects constatés par les "développeurs". C’est ici qu’est mis en valeur le mixage de la communication textuelle- sérielle et graphique- parallèle, si efficace pour expliquer les processus complexes.

La cinquième piste ("aide ") contient l’aide contextuelle classique - c’est-à-dire un index des connaissances nécessaires pour la réalisation de chaque module. Il fait des renvois vers des pages pertinentes extraites de la documentation technique. Ici on a utilisé comme modalité l’exploration hypertextuelle, collatérale, mais synchronisée avec l’évolution de la navigation.

Les cinq pistes peuvent être parcourues séparément. Cela peut intéresser au début, pour ce familiariser, ou plus tard, quand on veut analyser une seule piste et on ne veut pas partager l’écran avec les autres. Mais le mode d’exploitation le plus intéressant est le mode "stéréo "; les pistes sont visibles simultanément, chacune dans sa propre fenêtre. Une des pistes ("maître ") sera l’axe de navigation. C’est ici que l’élève agit pour explorer la démonstration en profitant du fait que les autres pistes ("esclave ") sont automatiquement mises à jour (synchronisées) pour compléter les informations de la piste "maître ". Par exemple, quand la piste "application " est la piste "maître " de la démonstration, l’utilisateur avance dans le magasin virtuel comme un client habituel. Mais regardant dans les fenêtres "esclave " il peut voir, après chaque opération, les parties responsables des sources, les blocs impliqués sur le schéma, les commentaires sur le modèle métaphorique et l’aide contextuel approprié.

Si la piste "cartes " ou "sources " devient "maître ", l’appui d’un bloc quelconque devrait mettre à jour les autres fenêtres, incluant la piste de l’application devenue " esclave ". Cette chose est plus difficile à réaliser, car l’avancement dans l’application est un processus à états, qui ne peut pas être géré dans un ordre arbitraire! Si tu n’as rien mis dans la corbeille, tu ne peux pas exercer le paiement à la caisse... Si l’administrateur n’a rien mis dans le catalogue des produits, on ne peut pas démontrer la manière de le consulter. Pour permettre à l’explorateur qui veut observer le fonctionnement d’un bloc ou d’un module source de se jeter au milieu d’une application, il faut préparer spécialement le contexte dans lequel il sera placé. Une autre solution qui apporte de la cohérence est d’interdire toute activité sur les pistes "esclave " utilisées seulement comme panneau d’affichage. Dans ce cas, la fenêtre "application " contiendra le "film" des événements démontrés.

Même si les pistes "esclave " ont seulement une fonction d’affichage, elles demandent l’interactivité nécessaire pour leur exploration commode. À cause de la dimension limitée de l’écran, la dialectique détail-ensemble est un problème épineux qui réclame des facilités de type scroll, dilatation, etc. Si à un certain moment ces instruments ne suffisent pas pour l’observation des fenêtres secondaires trop petites, on peut agrandir celles-ci en les commutant avec la fenêtre principale de la démonstration. L’application "maître " est conçue de la manière à pouvoir être manipulée dans une fenêtre plus petite.

La dernière fenêtre visible sert au contrôle du système multi-piste. C’est ici que l’utilisateur peut demander, à l’aide d’un bouton, que l’information présentée dans une fenêtre auxiliaire apparaisse dans la fenêtre principale. C’est toujours ici qu’il pourra imposer, avec un autre bouton, l’axe principal de la démonstration. Il pourra choisir les modes : " application driven ", " source driven ", " map driven " ou " comments driven " (cette partie est encore en développement). Un autre bouton permet la commutation des commentaires d’une technologie à une autre, en assurant la mise à jour de toutes les fenêtres. Il y a aussi un bouton pour changer le type du schéma utilisé sur la piste "cartes ". Ce panneau de configuration dynamique pourrait être considérée comme une sixième piste ("contrôle "). Je prévois l’enrichissement significatif de cette piste de négociation quand la démonstration passera au mode de travail mixte synchrone- asynchrone. Des pistes supplémentaires de communication deviendront probablement nécessaires et la gestion du faisceau discursif se compliquera.

Une fois raffiné le contenu pédagogique et la physiologie de cette application encore à améliorer, j’ai l’intention d’aborder la construction d’un instrument générique de présentation coopérative WEB. Il sera ajouté, dans un futur imprévisible, aux autres outils qui équiperont mon TaxiNet...

Mais dans le cadre de cette thèse, mon voyage au bout... du laboratoire se termine, avec des conclusions présentées dans le chapitre suivant.