pour l’enregistrement multimédia de cours
Stéphane Nicoll
1—Véronique Pirot
—Olivier Bonaventure
2Institut d’Informatique
Facultés Universitaires Notre-Dame de la Paix Rue Grandgagnage 21,B-5000 Namur (Belgique)
[email protected], [email protected], [email protected]
RÉSUMÉ. Nous présentons d’abord une solution pragmatique de télé-apprentissage que nous avons utilisée pour enregistrer et diffuser plusieurs centaines d’heures de cours sur internet.
Notre méthode permet d’enregistrer facilement des cours ex cathedra si le contenu visuel du cours est accessible sur le web et si le professeur utilise un micro sans fil. Nous montrons les avantages d’une telle méthode. Les résultats de son évaluation par les étudiants et les profes- seurs sont exposés. La deuxième partie de l’article est consacrée à eConf et WebReplay. Ces deux logiciels, permettent l’enregistrement et la diffusion automatique de cours. eConf est un superbe outil pour enregistrer une session web complète synchronisée avec la voix du profes- seur. L’information multimédia est contenue dans un fichier de type SMIL. L’applet WebReplay permet de rejouer la session enregistrée sur tout navigateur compatible Java.
ABSTRACT. We first present a pragmatic solution that we used to record and distribute several hundred hours of courses over the internet. Our method allows easily recording of classroom lectures when course’s content is available on the web and professor uses a wireless micro- phone. We show the advantages of such a method. Evaluation by students and teachers is discussed. The second part of this article is devoted to eConf and WebReplay. These software tools have been developed in order to allow easily and automatic recording and playback of lectures. eConf is a great tool to record a complete web session synchronized with the presen- ter’s voice. The multimedia information is contained in a SMIL- like file. The WebReplay applet allows the recorded session to be played on any Java enabled web browser.
MOTS-CLÉS :internet, enregistrement, diffusion de cours, serveur de flux, Java, télé-apprentissage, multimédia, SMIL, faible bande passante.
KEYWORDS:internet, recording, lecture broadcasting, streaming, Java, e-learning, multimedia, SMIL, low bandwidth.
½. S. Nicoll travaille maintenant pour Kiala, Bruxelles, Belgique.
¾. O. Bonaventure est maintenant à l’Université catholique de Louvain (UCL), Belgique.
1. Introduction
La croissance récente de l’internet a entraîné le développement rapide du télé- apprentissage via le web. Le plus grand avantage de l’apprentissage via internet est que les étudiants peuvent suivre les cours à leur propre rythme à partir de n’importe quel ordinateur connecté à internet. De nombreuses universités et entreprises ont dé- veloppé leurs propres solutions de télé-apprentissage pour améliorer l’accès des étu- diants aux cours. Mais nous n’avons pas trouvé, sur le marché, une solution répondant aux contraintes auxquelles nous étions confrontés. C’est pourquoi nous avons déve- loppé nos propres outils pour supporter le télé-apprentissage et nous avons offert à nos étudiants des cours via internet en complément aux cours traditionnels ex cathe- dra. C’est ainsi que l’institut d’informatique des FUNDP a diffusé plusieurs centaines d’heures de cours d’informatique via internet depuis octobre 1999.
Nous décrivons, dans cet article, à la fois les leçons apprises de cette expérience à large échelle et les outils que nous avons développés. Ces outils sont librement dis- ponibles et nous espérons qu’ils serviront à d’autres institutions pour diffuser leurs cours.
L’article est divisé en deux parties. Nous décrivons d’abord le premier prototype qui nous a permis de produire du contenu multimédia de télé-apprentissage et les résultats de son utilisation pendant deux ans. La deuxième partie est consacrée au logiciel eConf qui fût développé dans un deuxième temps et qui a répondu à toutes les contraintes initiales.
2. Un premier prototype
La première étape de tout projet de télé-apprentissage est d’identifier les contraintes.
Notre objectif était d’aider des étudiants adultes inscrits à une licence en informatique à horaire décalé. La plupart de ces étudiants ont un emploi du temps surchargé et il leur est difficile d’être présents aux cours, donnés à raison de deux soirées par se- maine et du samedi matin. internet nous a semblé tout indiqué pour leur permettre de suivre les cours à leur propre rythme. Du point de vue de l’étudiant, la solution de télé-apprentissage choisie doit être utilisable pour le plus de cours possibles, sans né- cessiter d’investissement matériel ni logiciel. Mais du point de vue de l’université, l’in- vestissement pour la diffusion des cours doit rester limité. Cela signifie que la solution choisie doit être utilisable pour de nombreux cours sans nécessiter d’investissements spécifiques ni de main-d’œuvre et sans imposer non plus de trop grands changements aux professeurs. Cet argument d’accessibilité, à la fois pour les étudiants et pour les professeurs, est primordial, sachant qu’une petite université peut organiser plusieurs centaines de cours différents par année.
Face à ces contraintes, nous avons évalué plusieurs solutions de télé-apprentissage existantes. Celles-ci peuvent être regroupées en deux types. La première solution est de filmer le professeur donnant son cours avec des transparents ou écrivant au tableau et de diffuser le cours dans son entièreté (Tsichritzis 1999). Cette solution est simi-
laire aux « TV broadcasts » de l’université de Stanford aux Etats-Unis ou de l’Open University au Royaume-Uni. Comme avantage de cette solution, citons le fait que le professeur ne doive en rien modifier sa manière de donner cours. Cette solution a été utilisée bien avant l’invention de l’internet. Grâce aux progrès effectués dans le domaine de l’équipement audio et vidéo (Balaouras et al. 2000; Real 2002; Cisco 2002), elle peut également être utilisée dans l’internet. Ce type de solution présente de nombreux inconvénients. Premièrement, un enregistrement de qualité nécessite une caméra de bonne qualité et la présence d’un opérateur compétent, particulièrement si le professeur utilise des transparents ou un tableau qui doit être lisible par les étudiants distants. Ceci implique un coût récurrent non négligeable pour l’université. Deuxiè- mement, l’étudiant doit impérativement être connecté à l’internet par une connexion haut débit pour pouvoir suivre les leçons, alors qu’à l’époque du début de notre projet, la majorité des étudiants étaient encore connectés à l’internet via un modem télépho- nique.
Un deuxième type de solution de télé-apprentissage est de demander au professeur de développer un site web complet pour chacun de ses cours. Il existe de nombreux outils pour produire de tels sites. Cette solution est souvent encouragée mais elle pré- sente un inconvénient majeur : le professeur doit réécrire entièrement tous ses cours, ce qui lui demande énormément de temps. D’un point de vue financier, certaines études ont chiffré le coût élevé de ces solutions en termes de main d’œuvre (Bodain et al.
2000). L’expérience de certains de nos collègues confirme ces études. Du point de vue estudiantin, la solution ne nécessite pas de connexion à large bande mais elle implique un apprentissage personnel.
Les inconvénients des méthodes existantes nous ont poussés à développer nos propres outils. La majorité des professeurs utilisent déjà des transparents, rédigés sur ordinateur, pour présenter leur cours. Le message de leurs cours est donc principale- ment délivré par deux médias : leur voix et les transparents. Pour enregistrer et diffuser ces deux médias, nous avons demandé aux professeurs de stocker leurs transparents sous format HTML sur le web et leur avons fourni un micro sans fil. Le format HTML a été choisi pour deux raisons. D’abord, le contenu web est beaucoup plus ouvert qu’une solution propriétaire. Ensuite, la plupart des outils de présentation ou des édi- teurs de texte peuvent facilement produire du contenu HTML.
Pour enregistrer et diffuser les cours, nous avons installé un ordinateur, un projec- teur et un micro sans fil dans chaque salle de classe. Le professeur utilise un navigateur pour présenter ses transparents via le vidéo-projecteur aux étudiants présents dans la salle de cours (figure 1). Toutes les requêtes web de l’ordinateur du professeur se font via WebConf (Liao 1999). WebConf est un proxy web écrit en Java qui capture le trafic http et envoie les pages HTML aux étudiants distants qui suivent le cours en direct. Un outil audio commercial (Real 2002) enregistre la voix du professeur, l’envoie aux étu- diants distants via un serveur relais et la stocke localement sous un format compressé.
Pour l’étudiant distant, écouter un cours est aussi simple que se connecter à l’internet.
Leur ordinateur doit juste être équipé d’un lecteur de contenu de flux audio (strea- ming) leur permettant d’écouter le signal sonore et d’un navigateur compatible Java
pour visualiser les documents reçus. La fenêtre ouverte dans le navigateur de l’étu- diant est mise à jour dès réception d’un nouveau document. A tout moment, donc, l’étudiant distant voit le même transparent et entend la même chose que les étudiants présents physiquement au cours.
Après le cours, les fichiers sont synchronisés automatiquement grâce au langage SMIL (Synchronized Multimedia Integration Language) et à des scripts PERL. Le fichier SMIL est créé à l’aide d’un simple éditeur de texte. Il permet l’intégration de plusieurs objets multimédias indépendants pour en faire une présentation multimédia synchronisée. Le fichier SMIL et les différents signaux sont placés sur un serveur de flux (streaming server). Des pages web donnant accès au cours sont également créées automatiquement. Chaque transparent vu par le professeur est accessible séparément via un lien hypertexte. Quand l’étudiant choisit un lien dans une des pages web ainsi créées, le navigateur web requière le fichier SMIL du serveur de flux. La réponse de ce dernier entraîne l’ouverture du lecteur de contenu par le navigateur. Le lecteur requière alors le fichier SMIL du serveur de flux en utilisant RTSP. L’information contenue dans le fichier SMIL permet alors au lecteur de contenu de demander et de recevoir les clips de flux multimédia. Les étudiants peuvent contrôler la présentation par l’utilisation de boutons pause, stop, play . . .
Professor’s PC with web browser
Student
Student HTTP Requests
HTTP Responses
Web proxy and audio capture Audio
Audio HTTP refreshes
HTTP refreshes
Web server
HTTP Responses HTTP Requests
Figure 1. Fonctionnement du premier prototype
2.1. Evolution du prototype
Nous pensions au début du projet que les étudiants seraient surtout intéressés par la diffusion en direct des cours. Cette diffusion en direct leur permet en effet d’éviter les navettes vers l’université trois fois par semaine. Après quelques mois de diffusion, nous nous sommes rendus compte que les étudiants n’utilisaient la diffusion en direct
que rarement (d’Udekem Gevers et al. 2002). Nous nous sommes donc alors concen- trés sur le développement du stockage des cours sur serveur de flux. Mais écouter les cours via un serveur de flux entraîne un coût proportionnel à la durée de la connexion.
C’est pourquoi nous avons ensuite décidé de compresser chaque cours en une archive que les étudiants peuvent télécharger facilement. Nous avons également gravé des cé- déroms. Une fois téléchargé, le cours peut alors facilement être écouté sans connexion au réseau. Dans le prototype, les archives étaient produites par des scripts PERL avec quelques interventions manuelles pour chaque cours.
2.2. Evaluation du prototype
Une évaluation des outils offerts à été effectuée auprès des étudiants et des pro- fesseurs concernés (d’Udekem Gevers et al. 2002). Les étudiants sont satisfaits des solutions offertes. Ils les utilisent pour écouter les cours auxquels ils n’ont pas assisté, pour écouter les parties ardues des cours et pour compléter leurs notes. Ils sont moins stressés et apprécient les flexibilités spatiale et temporelle offertes. La comparaison des trois outils (diffusion en direct, en différé et le cédérom) montre clairement que la diffusion en direct n’intéresse pas les étudiants. Deux tiers d’entre eux déclarent par contre utiliser la diffusion en différé (streaming) pour suivre des parties de cours ou pour préparer leur examen. L’inconvénient majeur de la diffusion en différé via strea- ming est éliminé par le recours au cédérom. Finalement, tous les étudiants estiment que les outils offerts complètent les cours ex cathedra très utilement.
Les professeurs évalués considèrent que leur manière de donner cours n’est pas changée de façon significative par l’enregistrement. La plupart des professeurs uti- lisaient déjà des transparents. Quelques modifications ont dû y être apportées. Par exemple, il est recommandé d’utiliser plutôt un fond blanc qu’un fond dégradé afin de réduire le temps de transmission des pages web. Un professeur a également expliqué que ses transparents devaient être plus complets pour l’enregistrement (par exemple en numérotant les lignes d’un programme) afin de pouvoir commenter explicitement les différentes parties du transparent pour les étudiants distants.
3. eConf et WebReplay
L’évolution positive par les étudiants des outils offerts montre clairement l’uti- lité de notre solution pragmatique. Le prototype développé présente néanmoins des lacunes car il nécessite l’utilisation de deux outils différents et l’intervention d’une personne compétente à différents stades de la production de la version enregistrée.
Nous avons donc décidé de développer le logiciel eConf (Nicoll 2002b) pour automa- tiser les enregistrements des cours. Pour des raisons de portabilité, nous avons choisi de développer le logiciel en Java. Les différences majeures entre le premier prototype et eConf sont les suivantes. Premièrement, eConf contient à la fois le proxy web et l’outil d’enregistrement audio. Il peut donc capturer les pages web requises par le na- vigateur du professeur tout en enregistrant sa voix. Il n’y a donc pas de problème de
synchronisation. Deuxièmement, eConf est capable de produire automatiquement, à la fin du cours, une archive zip qui contient les pages web vues par le professeur, sa voix enregistrée dans un format compressé et l’applet WebReplay Java qui permet de re- jouer toute la session web sur n’importe quel navigateur. Le fichier zip peut être stocké localement ou être automatiquement transféré sur un serveur web. Aucune interven- tion humaine n’est nécessaire entre le moment où le professeur démarre la session et le moment où le cours est disponible sur internet.
3.1. Architecture d’eConf
L’architecture du logiciel eConf est divisée en trois sections : la gestion du contenu web, l’enregistrement de l’audio et la production de la session (i.e. du cours). Les fonctionnalités de chaque section, ainsi que leurs interactions, sont décrites ci-dessous.
Pour permettre au professeur d’accéder au contenu à partir de n’importe quel ser- veur web, nous avons choisi de coupler eConf au proxy web JigSaw (W3C 2002).
JigSaw est un proxy web très puissant, open-source, écrit en Java et développé par le consortium W3C. L’interaction de JigSaw avec eConf permet au professeur de surfer sur le web et accéder à n’importe quel type de contenu. Il n’est plus limité, comme avec le premier prototype, aux pages HTML simples. La gestion du contenu web com- prend essentiellement deux fonctionnalités : l’interaction avec le proxy et la gestion du contenu.
L’interaction proxy définit l’architecture permettant à eConf d’interagir avec un proxy. Elle définit une interface permettant de recevoir, de manière asynchrone, les événements générés par le proxy et la structure de ces événements. eConf fournit une implémentation de référence pour le proxy JigSaw mais il reste ouvert et il est possible de définir une implémentation pour un autre proxy. Le plus grand avantage de JigSaw est qu’il permet aux développeurs d’implémenter un filtre qui est appelé deux fois à chaque requête. Nous nous appuyons sur cette particularité dans eConf de la manière suivante. D’abord, la méthode ingoingFilter() est appelée quand une requête est envoyée par le navigateur. Ensuite, la méthode outgoingFilter() est appelée quand la réponse est renvoyée par le réseau. eConf implémente un filtre proxy qui est compatible avec ce modèle. Ce filtre permet à eConf de recevoir des événements tels que : le timestamp de la requête http, le code de la réponse HTTP, le type MIME et, bien sûr, le contenu du fichier requis.
La gestion du contenu permet de centraliser toute l’information (URL, descrip- tion du fichier et informations temporelles) relative au contenu visualisé pendant la session web. Pour ce faire, eConf contient un référentiel contenant tous les fichiers demandés par le navigateur du professeur via le proxy. En fait, le référentiel contient les relations entre le contenu web et un fichier local. Ces informations sont récupérées lorsque le proxy génère des événements tels que décrit ci-dessus. Plus précisément, le référentiel reçoit un événement chaque fois qu’une réponse est reçue du réseau. Lors de la réception d’un tel événement, le fichier correspondant est copié dans un cache
local et ajouté au référentiel. Les relations entre les URLs et les fichiers dans le cache sont primordiales pour la mise à jour des parties des pages HTML, notamment pour préserver les liens entre fichiers.
!
"#!
"$%! "$%!
&%'!
"!(#)$ )*$ "!
)!
+ , #*$ "$,-*,#**,!"$$ !
% "$ #*$
"$,-").///#*$0#* *, !"$ $ !
)!
&%'!
"#!
Figure 2. Une page HTML simple
Pour illustrer la nécessité de mettre à jour les fichiers HTML stockés, considérons une page telle que celle de la figure 2. Quand le navigateur web va demander cette page HTML, il va l’étudier et requérir les deux images référencées dans le code HTML. Ces deux requêtes http vont être interceptées par le proxy et stockées dans le référentiel.
Cet exemple montre les différences qui existent entre les fichiers appelés dans eConf les fichiers dépendants d’une part et les fichiers racine d’autre part. La première re- quête concerne un fichier racine (c’est-à-dire un fichier demandé par le professeur) tandis que celles demandant les images concernent des fichiers dépendants. Comme le navigateur peut requérir n’importe quel type de média et que http est un protocole sans état, il n’existe pas de méthode parfaite pour faire la distinction entre un fichier racine et un fichier dépendant. Actuellement, eConf dépend de quelques heuristiques pour déterminer si une ressource doit être considérée comme fichier racine ou pas.
La distinction entre les fichiers racine et dépendants est cruciale pour la réécoute de la session car eConf doit savoir quelles sont les pages consultées par le professeur (et montrées aux étudiants) et pendant quelle durée elles furent montrées. Cette infor- mation lui permettra de montrer les pages vues pendant une durée correcte lors de la réécoute.
eConf gère également le second média utilisé pour l’enregistrement des cours : le son, c’est-à-dire, la voix du professeur. Pendant la session web, la voix du professeur est enregistrée et stockée sur le disque local. eConf s’occupe non seulement d’enregis- trer la voix mais également de la comprimer immédiatement sous différents formats.
Le type de format audio à utiliser pour un cours donné dépend de la taille acceptable du fichier audio et de la qualité audio demandée. L’implémentation de référence de eConf repose sur le Java Media Framework de SUN (Sun 2002) et supporte donc les mêmes codecs audio que JMF. Néanmoins, eConf permet d’ajouter facilement d’autres codecs
audio si nécessaire, de la même manière que d’autres proxy peuvent être connectés à eConf.
eConf est paramétré principalement via deux fichiers de configuration XML. Le premier contient des données de configuration générale, telles que celles concernant l’enregistrement audio, les paramètres du proxy et la définition des intégrateurs. Le deuxième contient la/les session(s) qu’eConf doit produire à la fin du cours. La fi- gure 3 montre un exemple d’un tel fichier. Il détermine les différents formats audio qui seront utilisés pour une session donnée (exemple : MP3, GSM) et leurs paramètres correspondants (taux d’échantillonage . . .) et l’intégrateur à appliquer. eConf peut en- registrer une session dans différents formats. Par exemple, il peut enregistrer en même temps une session de haute qualité avec le codec MP3 et une session de basse qualité avec le codec GSM. Nous utilisons souvent le format GSM car il produit des fichiers très comprimés de qualité acceptable. La taille d’une archive zip basée sur le format GSM est approximativement de 4 Mbytes par heure de cours. En comparaison, la taille d’une archive zip basée sur le format MP3 de bien meilleure qualité est d’environ 11 Mbytes par heure. Chaque session produite peut être stockée localement dans un réper- toire déterminé ou être automatiquement envoyée via ftp vers un serveur de fichiers.
Cette dernière fonctionnalité est très utile lors de l’utilisation fréquente d’eConf. Le fichier de configuration d’eConf peut être utilisé pour définir un intégrateur par ses- sion. Il est donc possible de produire en même temps par exemple à la fois une session audio de haute qualité qui sera rejouée avec webreplay et une session de basse qualité adaptée à une écoute avec realone, pour autant que les intégrateurs appropriés aient été implémentés et définis dans le fichier global de configuration d’eConf.
12# 3$- $0%*-(44561!
$!
#$ 7"-(8)"$ 0 0)'*"-9: (8)"$ 0 ;; !
$ ')$-,,$ #$-"*"<=7'!
7% ,#-#) ,#$$-;;5 #)$>$-? 0"$-!
0"3$ ')$-,)
7-,).#'*0#07$ *-*7$ )/%-"*$$ !
$* %-/$&$)'!
$!
$ ')$-,,$ #$-/<=7'!
7% ,#-*# ,#$$-4 #)$>$-? 0"$-!
0"3$ ')$-0 )"-0.@$#) !
$* %-/$&$)'!
$!
$!
Figure 3. Exemple de fichier de configuration d’eConf
A la fin du cours, eConf dispose donc d’un fichier audio contenant la voix du professeur et d’un référentiel des fichiers vus. L’étape finale est donc de construire l’archive. Ce mécanisme de construction est expliqué dans le paragraphe suivant.
3.2. Production du contenu grâce à eConf
Avec l’audio et les pages web collectées pendant la session, eConf est maintenant capable de produire une archive contenant le cours en entier. La production est faite en deux étapes. D’abord, un basic producer assemble toutes les pages web dans une archive. Pendant la préparation de l’archive, tous les fichiers HTML du référentiel sont analysés pour résoudre les références externes et les liens. Sur la toile actuellement, de plus en plus de sites contiennent des liens faisant référence à des sites externes. Ces liens doivent être correctement résolus.
Quand un fichier racine est analysé, eConf vérifie la source de tous les liens pour voir si le lien en question est relatif au site web (par exemple :
<img src= ”/images/img.gif”> ou absolu, c’est-à-dire un URL complet. Dans le pre- mier cas, il construit d’abord l’URL complet, basé sur l’information du lien et de- mande au référentiel de vérifier si l’URL a été enregistré. Si oui, le lien est changé vers un lien local car eConf connaît la position du fichier grâce au référentiel.
Quand l’archive brute est construite, eConf peut appliquer un intégrateur sur l’ar- chive pour la finaliser. Cette étape permet, par exemple, d’ajouter un fichier audio, de construire et d’ajouter un fichier de synchronisation ou encore d’ajouter un lecteur permettant de rejouer le cours. Actuellement, eConf ne fournit qu’une implémenta- tion de référence de ce processus, appelé WebreplayIntegrator. Cet intégrateur produit une archive zip contenant : tous les fichiers montrés pendant la session, un fichier au- dio compressé conformément aux exigences de l’utilisateur, un fichier pseudo-SMIL contenant l’information de synchronisation entre l’audio et les pages web et, enfin, l’applet WebReplay configurée pour la session. Une telle archive peut être utilisée di- rectement par l’utilisateur final. Comme pour l’audio ou les pages web, eConf n’est pas condamné à n’interagir qu’avec WebReplay. L’interface Integrator peut être adap- tée par tout développeur pour produire une archive zip basée sur ses propres besoins.
Il pourrait être possible, par exemple, d’adjoindre à eConf la possibilité de produire du contenu dans un format acceptable pour un lecteur compatible SMIL.
Le fichier SMIL produit par eConf est basé sur une variante de SMIL 1.0 (W3C 2002). WebReplay considère qu’un cours est composé de deux types de médias joués simultanément. Le premier média est la voix enregistrée qui doit être jouée pendant toute la présentation. Le deuxième type de média est composé des pages HTML vues par le professeur. Ces pages sont spécifiées par la balise img dans laquelle la durée de chaque page est indiquée. Un exemple de fichier SMIL produit par eConf est montré dans la figure 4.
3.3. WebReplay
Pour avoir une solution de télé-apprentissage complète, la seule chose qu’il nous restait à développer était un lecteur pour rejouer les sessions produites par eConf. Ce lecteur doit répondre à trois contraintes. Premièrement, Il doit être facile à configurer.
#!
"$%!
('0"> ,$ *$$$% &' $, !
#$ #$-7" 0$-($)"$ 0 !
#$ #$-0)'*" 0$-9: ( 0A ;; !
'7!
'7!
$* %-# ,-,!
'7!
"$%!
&%'!
)!
7% 0-7%%$##)!
#* 0-&B"# $*-# %7-C6# !
#* 0-%$#///,$,7%)0 &$ +D %$ 2" #
$*-# %7-4;6# !
#* 0-%$#///,$,7%)0 &$ +D % $" #
$*-# %7-;?5C# !
)!
&%'!
#!
Figure 4. Un exemple de fichier SMIL produit par eConf
Ceci est important car ce lecteur doit pouvoir être utilisé pour d’autres applications que l’écoute de cours. Deuxièmement, le lecteur doit être capable de reproduire n’importe quel type de contenu vu pendant le cours. Comme le cours est vu dans un navigateur web, il paraît évident d’utiliser cet environnement pour rejouer les sessions. Troisiè- mement, le lecteur doit être léger et doit fonctionner sur n’importe quel système.
Ces contraintes nous ont conduit à créer notre propre applet Java, très légère, We- bReplay (Nicoll 2002a). WebReplay contient environ 2.000 lignes de code et la taille de la version compilée et de seulement 31 kbytes. Comparée à d’autres solutions, une applet a l’avantage de supporter automatiquement la majorité des caractéristiques de Java. De plus, notre applet ne requière pas de privilèges spéciaux et ne devrait donc pas générer de problème de sécurité. La troisième contrainte est donc rencontrée. La deuxième contrainte est assez facile à satisfaire. En effet, toute applet a la capacité, par son environnement, de montrer des pages web complexes à condition que leur syntaxe locale ait été optimisée. Ce qui est le cas ici car eConf gère les liens externes et internes des pages web.
L’unique fonctionnalité de WebReplay est de rejouer une session web synchroni- sée à un fichier audio. Cette synchronisation est définie dans un fichier qui est compa- tible avec une variante de SMIL. Un tel fichier peut être produit par le WebReplayInte- grator lors de l’intégration d’une session eConf. Cette ouverture, du côté client, permet WebReplay d’être utilisé par n’importe quel autre composant, en utilisant un fichier de configuration adapté.
Figure 5. L’interface utilisateur de WebReplay
Quand l’applet WebReplay démarre, la fenêtre du navigateur est divisée en deux parties. La partie supérieure de la fenêtre est utilisée par les boutons de WebReplay (figure 5), en laissant la plus grande partie de la fenêtre disponible pour montrer les pages web enregistrées pendant la session. Nos expériences avec le premier proto- type ont montré l’importance de l’interface utilisateur pour les étudiants. WebReplay permet de suivre un cours dans sa totalité bien sûr, mais offre également d’autres fonc- tionnalités. Les étudiants nous ont signalé que rendre l’accès possible à des parties de cours précises est aussi important. WebReplay dispose de plusieurs options pour sa- tisfaire cette demande. Premièrement, la première page de WebReplay contient une table des matières avec des liens indépendants vers chaque page web (et l’audio as- socié) vues pendant le cours. Deuxièmement, les boutons de l’interface utilisateur permettent à l’étudiant de naviguer d’une page web à l’autre à l’intérieur d’une ses- sion. Troisièmement, une case de défilement permet à l’étudiant de débuter la session là où il veut.
4. Comparaison avec d’autres méthodes de télé-apprentissage
Différentes solutions ont été développées pour enregistrer et diffuser des cours.
Nous en comparons certaines avec nos outils. Les membres de la communauté de recherche sur les réseaux ont développé des outils (UCL 2002) pour diffuser des pré- sentations sur internet en se basant sur IP multicast (Macedonia et al. 1994). Ces outils furent écrits initialement pour envisager d’utiliser internet pour diffuser des présenta- tions en direct. Certains de ces outils permettent de diffuser de l’audio, d’autres de la vidéo et d’autres encore se sont spécialisés dans la diffusion de transparents, encodés en fichiers PostScript ou en simples pages web (Liao 1999). Ces outils peuvent être utilisés séparément ou dans un environnement intégré plus convivial. Dans ces outils, l’objectif a été la diffusion de contenu en direct. Même si certains prototypes sont en mesure de stocker et de rejouer de telles présentations, ils ne sont pas souvent utilisés en pratique. De plus, ces outils nécessitent l’accessibilité à des connections à l’internet à haut débit. A l’opposé, notre solution est basée sur une production optimale de la session enregistrée et sur son encodage sous forme compacte pour faciliter le stockage ou le télé-chargement.
Différents outils (Gehne et al. 2000; RealNetworks 2001) permettent d’associer des commentaires audio à une présentation. Ces outils sont en général associés à un seul outil de présentation et ne sont pas facilement portables. L’utilisation d’un tel outil oblige le professeur à utiliser le logiciel de présentation lié à l’outil. A l’opposé, la
seule obligation liée à notre outil est de placer le contenu visuel du cours sur un serveur web. Ceci donne une grande flexibilité au professeur qui peut utiliser n’importe quelle ressource web pour ses cours.
L’inconvénient de notre solution est le fait que l’information écrite manuellement par le professeur sur le tableau ne soit ni enregistrée ni diffusée. Des discussions avec nos collègues nous ont indiqué que ce problème était majeur pour les cours basés sur les mathématiques. Pendant ces cours en effet, les professeurs préfèrent écrire les démonstrations et les exercices sur un tableau. Nous avons fait quelques expériences avec des appareils spéciaux tels que ceux décrits dans (Caton 1999), qui permettent de digitaliser, enregistrer et diffuser le contenu d’un tableau. Mais ces appareils sont destinés à être utilisés sur des tableaux de petite dimension tels qu’on en trouve dans les salles de réunion et pas sur les larges tableaux des salles de cours. L’utilisation de tels appareils oblige le professeur à écrire en tous petits caractères sur le tableau, ce qui n’est pas acceptable pour les étudiants présents en classe.
5. Conclusion
Dans la première partie de cet article, nous avons présenté une solution de télé- apprentissage pour enregistrer et diffuser des cours via internet. Notre méthode per- met d’enregistrer facilement des cours ex cathedra, à condition que le contenu visuel du cours soit accessible sur le web et que le professeur utilise un micro sans fil. Nous avons utilisé cette méthode pour enregistrer et diffuser plusieurs centaines d’heures de cours. L’évaluation de ce prototype a montré l’utilité d’une telle approche prag- matique. L’évaluation a également mis en évidence différents points applicables à d’autres applications multimédias d’enseignement à distance. Premièrement, le signal audio et le texte ou les images sont suffisants et la vidéo n’est pas un média incontour- nable pour suivre un cours. Deuxièmement, les solutions utilisant le streaming sont moins utiles pour les étudiants que les solutions permettant de télécharger des cours complets. Troisièmement, les cours enregistrés peuvent très bien être diffusés par un simple lecteur SMIL.
Dans la deuxième partie de cet article, nous avons décrit deux applications, ac- cessibles gratuitement, que nous avons développées sur base des leçons apprises lors du développement et de l’utilisation du premier prototype. eConf est une application Java qui permet d’enregistrer facilement des cours et qui est capable de produire une archive contenant la voix du professeur combinée aux pages web montrées pendant la session. WebReplay est une applet Java simple qui peut être utilisée pour rejouer les sessions enregistrées par eConf. Le logiciel eConf est basé sur une version non standard de SMIL supportée par WebReplay mais il pourrait facilement être amélioré pour produire des archives compatibles avec les autres lecteurs SMIL.
Remerciements
Le premier prototype a été développé avec l’aide d’Emmanuel Hêne et de Aimé Kassa. Marie Gevers nous a aidés en interrogeant les étudiants afin de mieux détermi-
ner leurs besoins. Enfin, nous aimerions remercier les étudiants et les autres profes- seurs pour leur participation active à cette expérience.
6. Bibliographie
P. Balaouras, I. Stavrakakis, and L. Merakos. Potential and limitations of a teleteaching envi- ronment based on H.323 audio-visual communication systems. Computer Networks, pages 945–958, 2000.
I. Bodain and J. Robert. Investigating distance learning over the internet. In INET2000, Global Internet Summit, July 2000.
M. Caton. ebeam advances evolution of whiteboards. PC Week Labs, eWeek, December 1999.
Cisco. IP/TV. http ://www.cisco.com/go/iptv, 2002.
M. d’Udekem Gevers, V. Pirot, E. Hene, and B. Charlier. Une expérience de télé-présence pour des étudiants de licence en informatique à horaire décalé. Educational Media International, 2002.
R. Gehne and C. Jesshope. Tools for the production of small-footprint, low-bandwidth, strea- ming multi-media for distance education. In Lifelong Learning Conference, pages 240–244, Central University of Queensland, Australia, 2000.
T. Liao. Webconf reference manual. INRIA document, available from http ://webca- nal.inria.fr/doc/man/webconf.html, 1999.
Michael R. Macedonia and Donald P. Brutzman. MBone provides audio and video across the internet. IEEE Computer, 27(4) :30–36, 1994.
UCL Network and Multimedia Research Group. Mbone conferencing applications.
http ://www-mice.cs.ucl.ac.uk/multimedia/software/, 2002.
S. Nicoll. Webreplay. available from http ://www.infonet.fundp.ac.be/soft/webreplay/, March 2002a.
Stephane Nicoll. econf. http ://econf.sourceforge.net, March 2002b.
Real. Real audio. http ://www.realnetworks.com/products/, 2002.
RealNetworks. Realpresenter plus.
available from http ://www.realnetworks.com/products/presenter/, 2001.
Sun. Java Media Framework. http ://java.sun.com/products/java-media/jmf/, 2002.
D. Tsichritzis. Reengineering the university. Communications of the ACM, 42(6), June 1999.
W3C. JigSaw. http ://www.w3c.org, 2002.
W3C. SMIL. http ://www.w3c.org/AudioVideo, 2002.
