Archives mensuelles : novembre 2009

SMIL-animated SVG for accessible textbooks

Dyspraxia is a serious learning disability for 250.000 children in elementary schools in France. Not that French children are particularly disadvantaged. It just happens that it seems to be a very wide spread kind of disability and the proportion of dyspraxic children should roughly be the same from country to country. In order to overcome this obstacle, the nonprofit organization I currently work for is leading the way toward adapting the ergonomy of existing paper textbooks and helping textbook editors creating the accessible (and digital) textbook of the future. Maybe you’ve heard of any similar initiatives ?

Their first attemps were made using a French e-learning authoring tool called Didapages. Up to version 1.1 it was free for non-commerciale uses. Version 2 is much more commercially oriented. And closed-source. And only runs on Windows. And despite its ease of use for educators and non-IT specialists, it has several drawbacks and limitations, partly due to the technology it uses, Flash, and partly because its developer does not think he can build a sustainable business model using free software licensing. Too bad. I am looking for an alternative solution, as some part of its user community does.

Free software packages such as Xerte, eXe, Scenari, Docebo and others look attractive. But none is the ideal solution : either they are also based on Flash, or their community is almost non-existant and their development may have stopped some time ago. Educators are not developers. And the crowd of educators might be missing a critical mass of developers in order for a very striving free software community to have developped around any elearning authoring tool. The bells and whistles of proprietary products have much more appeal to the average teacher.

From a technology perspective, I had a look at open standards for acessible, animated and interactive contents. W3C, please show me the way. The relevant standards seem to be :

  • HTML 5 for content, with its Javascript-animated « canvas » element for sprite-based animations (for bitmaps graphics) ;
  • SMIL for animated documents and for limited interactivity, possibly also combined/extended with Ecmascript for more interactivity ;
  • CSS for styling, possibly some day with Webkit-like CSS animation but this option does not excite me much ; CSS animation may require Javascript or SMIL
  • SVG for graphics : there is such a thing as SVG Animation, and Ecmascript can be embedded in a SVG file in order to provide more interactivity and to overcome some current interactivity limitation of SMIL ; SVG is for vector graphics but could also embed (and animate) bitmap graphics (used as sprites).

The advantage of SMIL and SMIL-animated SVG over Flash seems to be that SMIL is a declarative technology. This « document » model allows less dependency on scripting and more flexibility through earlier or further transformations (with templating, XSLT or content management engines). This allows the animation and, to a lesser extent, interactivity aspects of educational content to be a native part of the content itself and not to be an afterthought. It facilitate later and looser coupling with further technologies. It allows more ReSTfullness (restafari !). It does not cause cancer. Well, I don’t know. It tastes good. (note to myself : consider discarding this whole paragraph) :)

Flash applets, on the other hand, can be made somewhat accessible but this may not be an easy task for the average Flash developer, and SMIL sounds like a much more accessibility-friendly technology. There even is a DAISY profile for SMIL documents. I should have a deeper look into these profiles.

But interactivity with specific application logic seems to require a bit of scripting anyway, doesn’t it ? Here comes Ecmascript with SMIL, which should probably be limited to a minimum. Can you always provide accessibility-safe fallback mechanisms for a SMIL document if you introduce scripting for interactivity ? I am not sure. I will have to figure this out. Maybe the DAISY SMIL profile tells me more about this.

After a first glance at these standards and being an non-expert in animated contents, it seems to me that there ARE available and mature open standards which cover most of the accessible and digital textbook related concerns. There should be no need to develop any addiction for Flash authoring systems.

But the problem is that these standards are still « emerging ». They were proposed several years ago, are slowly maturing and their support in modern web browsers only starts to become a reality. The most advanced support for SMIL-animated SVG comes with Opera. And is said to be available in Firefox 3.6 as far as I understood. I’ll test this stuff with Opera until Firefox 3.6 comes to ubuntu. The lack of consistent support for SMIL and SVG animation can be overcome with the use of free software SDK or Javascript libraries which take SMIL elements as input and generate equivalent Javascript instructions as output. For instance, the RaphaelJS Javascript library allows browsers to support animated SVG even if such a support is not built-in for them. As far as I understand, the Ample SDK allows SMIL animations to be supported by non SMILable browsers, too.

The main problem is not in web browser support, though. The main problem is that there is almost no (free software) authoring tools for such animation and interactivity technologies. Limsee2 is a code editor/development environment for SMIL (does it support SVG animation ?) but its INRIA authors stopped working on it some time ago. And there seems to be no real community behind it. Limsee3 is not a further version of Limsee 2 (despite the name). It is a WYSIWYG SMIL authoring tool but it does not seem to support SVG animation (does it ?). And it may also probably stop being developed as soon as the governmental subsidies behind the corresponding research project end. Yet another research package soon to be dying on the labs shelves ?

This sends me back to my above observation about the non-existence of a sufficiently-big or proficient-enough community of educators who can use AND develop such advanced authoring tools with accessibility in mind. Too bad…

Madswatter and Ajax animator are very early prototypes for animation authoring environments. There are other free software attempts currently aiming at proposing a proper animation editor: clash/geesas (which is a fork of pencil) and moing… Maybe you’ve heard of other projects ? Inkscape has some plan for introducing SMIL authoring capabilities. There even is a mockup of the user interface for the timeline-based authoring of animations. This is work in progress. Well, maybe this is more than just a work on blueprints : the Inkscape roadmap mentions simple and limited animation authoring as a feature for their next release (version 0.48) ! The 0.49 version should focus on much more support for animated SVG. Exciting ! This topic is hot right now. Itches are starting to be scratched a lot !

That being said, I realize I already have a tool for authoring animations. It’s Open Office Impress. And the Impress wiki tells me that its animation are based on SMIL ! When I have a look at the xml file saved by Impress (inside its ODP zipped archive), I can indeed see SMIL element names and attribute names mixed with Open Office specific elements and attributes, even though the resulting document may not be SMIL compliant, strictly speaking. A limited effort (XLST or a custom extension) may allow to produce real SMIL documents.

Instead of using elearning-specific authoring tools (think Xerte, eXe, …), what if futur editing software for educational contents were tools I (or any educator) already have on my desk : Inkscape for the creation of bits of animated graphics and/or Open Office Impress for the layout and animation of the overall animated document? In Inkscape, the « properties » window of any object even reveals some event fields for Ecmascript/Javascript instructions (onclick, onmouseover, etc.). Too bad Impress can’t properly import SVG content. But maybe this is not required. In the end, e-learning specific tools would be required anyway for the packaging of the resulting animated and interactive content into Learning Management Systems such as Moodle. Such content packages would need to be made SCORM or AICC compatible so that they expose their navigational and educational structure to these platforms via a standard API. I read the SCORM is not ideal as such an API from an accessibility perspective because it heavily relies on Javascript (it is a Javascript API). But does the use of a scripting language always prevent accessibility ? I don’t know. SCORM may be nice for portability from LMS to LMS. But so nice for accessibility.

At the moment, I feel like the ideal authoring chain of tools for educational content / textbooks would be as follows :

  1. Inkscape in order to create the graphism, layout and animation of individual educational « applets » : cross words, coloring books, simulations, geometry tools, … the result being saved as an animated (and partial SMIL-interactivity) SVG file with event-hooks being defined so that we can go to the next step
  2. an ECMAscript code editor (I am not into this emacs thing… Eclipse anyone ?) in order to transform this animated SVG file into an animated AND interactive SVG piece of content
  3. Open Office Impress in order to create the layout, structure and general content of your course/manual/textbook chapter/whatever, inserting the SVG file and adding further animations as well as individual multimedia items (sound clips, videos, hyperlinks), the result being saved as a SMIL/HTML document
  4. More scripting edition of this document if needed (but would it be needed at this stage ? I can’t tell)
  5. CSS styling would be made ready for the document at this stage or earlier (can Open Office make any use of existing CSS stylesheets or would it always mix them into its own content format ?)
  6. a SCORM packager such as Reload Editor would import this content and allow the author to specify the SCORM relevant bits of information, the result being saved as a Moodle-ready package
  7. Your favority Moodle-like LMS platform would serve the content to users, possibly running on their laptop in an offline fashion

This whole chain of tools would probably benefit from being powered by a web content management system (Plone ? Drupal ?) so that the assembly line is smoother and allows widespread collaboration, with workflows, access control and so on. No need to get stuck back to the Dreamweaver era of the I-am-waiting-for-the-Dreamweaver-guy-to-update-my-textbook.

Now it’s your turn. What do you think ?

La téléconférence du geek

Une grande SSII a enfin signé avec l’une des associations qui bénéficie du wecena. Le communiqué de presse est prêt. L’appel au volontariat destiné aux 4000 salarié est prêt à être envoyé. Il ne me manquait plus qu’une chose pour faire nickel : avoir une solution de téléconférence gratuite pour accueillir les volontaires à distance, répondre aux questions des personnes intéressées (managers, volontaires en puissance, etc.). J’ai donc dû mettre au point un système de téléconférence spécial geek dont j’espère bientôt faire la démo. Voici mes notes de travail, prenez-en soin !

Sous ubuntu 9.04, j’ai installé webcamstudio, téléchargeable via, installable depuis un dépôt ou bien depuis les sources, facile à compiler avec NetBeans sous Ubuntu (installer le paquet NetBeans). Webcamstudio est un logiciel en Java qui permet de créer une webcam virtuelle qui peut capture l’image de votre bureau, des animations, du texte, un canal IRC, une vidéo Youtube, le flux video d’une vraie webcam branchée sur le PC…
Mettre la sortie en 320×240 pour éviter tout risque d’incompatibilité avec le site qui va diffuser la vidéo ( par exemple).
WCS créé un device « Video loopback » de type « Video 4 Linux » (et pas Video 4 Linux 2).
Lancer l’utilitaire gstreamer-properties pour vérifier que ubuntu arrive à lire cette webcam et informe ubuntu de la webcam par défaut. Video / entrée / Video for linux 1, device = Video Loopback 1. Faire un test pour vérifier que ubuntu détecte bien la webcam virtuelle créée par webcamstudio.
Aller sur et y créer son compte utilisateur.
Sur le site de webcamstudio, il y a une explication pour savoir comment faire en sorte que flashplayer accepte d’utiliser comme il se doit la webcam virtuelle : fait aller sur un site pour y régler les paramètres de sécurité du flashplayer de votre navigateur : « toujours autoriser, » (et aussi quantserve. com ?).
Puis se logger dans ustream et aller dans l’interface de broadcast. Y sélectionner son périphérique vidéo (video loopback) et son périphérique audio (« linux microphone »).
Ensuite, il y a un certain nombre de réglages à faire pour avoir du son diffusé. On lance donc l’utilitaire « pavucontrol » de pulseaudio sur ubuntu (à partir de la 9.04). Cet utilitaire permet de :

  • régler chaque périphérique audio d’entrée (les sources) et de sortie (les sinks)
  • régler aussi les « moniteurs » qui sont des genres de périphériques virtuels créés par pulseaudio ; notamment, pulseaudio créée un « moniteur » associé à votre périphérique de sortie son (vos hauts-parleurs) ; ce moniteur se comporte comme une sorte de microphone virtuel qui serait branché sur vos hauts-parleurs et vous permet de capturer tout son émis par votre PC pour pouvoir l’enregistrer à nouveau ou le diffuser en streaming par exemple,
  • relier chaque logiciel qui produit du son (lecture) ou en capture (enregistrement) à un périphérique de sortie son de son choix, y compris aux « moniteurs » ; en l’occurence avec une seule carte son en sortie (pas de casque audio USB), vous n’avez qu’un seul choix pour les logiciels de lecture. Par contre, pour les logiciels de capture, vous pouvez choisir de capturer ce qui entre dans le microphone ou bien ce qui entre dans le moniteur de la sortie de votre carte son, à savoir ce qui sort de la carte son… Vous suivez ? J’explique…

En pratique, le périphérique de sortie par défaut, c’est la sortie carte son (un casque dans mon cas). Et le périphérique d’entrée par défaut, c’est mon microphone du casque audio. Je mets en sourdine le microphone de ma webcam.
De plus, le site qui diffuse votre video et votre son est utilisé via votre navigateur web, firefox dans mon cas. Firefox apparaît donc dans pavucontrol de 2 manières :

  1. en tant que logiciel de lecture (c’est le son joué par firefox), je le relie à la sortie de ma carte son mais je le mets en sourdine le temps de mon broadcast (sinon, ça pourrait faire de l’écho).
  2. mais aussi et surtout en tant que logiciel d’enregistrement (c’est l’applet flash de qui capture mon son) que je relie au moniteur pulseaudio de ma carte son de manière à enregistrer tout le son qui sort de ma carte et pas seulement ma voix captée par mon microphone mais aussi les MP3 joués en local, les conversations téléphoniques via un softphone, etc.

Le problème, c’est que ma voix qui entre dans le microphone ne ressort pas dans la sortie de ma carte son. Sinon, ça me ferait de l’écho dans les oreilles. Donc ma voix n’est plus capturée par l’applet flash de firefox/ustream puisque celle-ci est maintenant associée au moniteur de la sortie son.
Pour contourner ce problème, on créé une loopback audio grâce à 2 utilitaires de pulseaudio. Ouvrez une fenêtre de terminal et tapez-y parec | pacat.
parec apparaît dans pavucontrol en tant que logiciel de capture son à qui on demande de capter l’entrée son du microphone. Il envoie ce son (ma voix) vers pacat via un pipe. pacat, lui, apparaît dans pavucontrol comme logiciel de lecture. Et il envoie forcément sa sortie (ma voix) vers la carte son. Donc ya de l’écho. Tant pis, on diminue le son dans le casque (physiquement), si ça gêne.
Mais on obtient le résultat recherché : à savoir permettre à firefox/ustream de capturer non seulement ma voix mais également tout ce qui sort des logiciels audio du PC.
Maintenant, l’audioconférence. Pour cela, j’utilise un softphone, en l’occurence Twinkle (ou parfois Ekiga). J’ai un compte SIP chez un opérateur de voix sur IP. Je recommande, c’est gratuit. offre (gratuitement via SIP) des salles d’audioconférence. J’appelle donc avec twinkle cette salle d’audioconférence. Twinkle apparaît dans pavucontrol à la fois comme logiciel de lecture et comme logiciel d’enregistrement. En tant que logiciel d’enregistrement, je lui demande simplement d’enregistrer ma voix. En tant que logiciel de lecture, je lui demande juste de faire son travail, c’est-à-dire d’envoyer le son produit par les interlocuteurs de l’audioconférence vers la sortie de ma carte son, de manière à ce qu’il puisse être capté, comme ma voix à travers le moniteur pulseaudio de cette sortie, sur lequel est branché la capture audio de firefox/ustream.
Et voila.
Les inconvénients actuels :

  • ça bouffe un max de CPU tout ça : twinkle, webcamstudio, firefox avec l’applet flash de ustream, pulseaudio en plus. C’est tout juste tenable sur mon laptop dual core 2×1,2 GHz. On peut rendre les choses vivables grâce à un ajustement des priorités via « sudo htop ». pulseaudio tourne d’office à haute priorité (-11). Je mets manuellement twinkle à -2 (prioritaire). Et firefox à -1 et on laisse webcamstudio à 0. Toutes les applis non prioritaires (applets Gnome par exemple) peuvent être passées à 1 (non prioritaires). Faute de ce type de réglages, l’audioconférence peut être ingérable ou la capture sur ustream de trop mauvaise qualité (y compris des pertes de trames entraînant une désynchronisation de la voix et de l’image si on demande à ustream d’enregistrer le broadcast pour la postérité). Autre possibilité de contournement : faire tourner le tout sur un PC plus puissant. Autre possibilité de contournement, faire une conférence main libre avec un téléphone normal. On évite ainsi le softphone mais le son capté le sera via un microphone près du téléphone.
  • j’entends de l’écho quand je parle (à cause de parec|pacat). Possibilités de contournement : est-ce qu’utiliser le module-loopback de pulseaudio règlerait ce problème (pacmd load-module module-loopback) ? a priori non. Autre possibilité de contournement : le téléphone main libre à côté du PC. Autre possibilité : baisser le son du casque quand je parle et le remonter quand j’ai fini de parler. Autre possibilité : trouver un moyen pour dire à pulseaudio qu’un logiciel de capture devrait combiner 2 périphériques d’entrées au lieu d’un seul : le microphone qui capte ma voix et le moniteur de la sortie son qui ne capterait plus ma voix (on se passerait de parec|pacat).
  • ma webcam est une caméra sur batterie, il faut que je pense à la brancher sur secteur sinon… elle se vide.
  • il faudrait voir si on ne peut pas diffuser une meilleure qualité d’image (640×480) et ce que ça implique en terme de CPU.

Au final, je me dis qu’il faut que je remette la main sur mon téléphone SIP matériel (Gigaset de Siemens) et ça simplifera mon problème de CPU. Mais ça ne donne pas une solution « portable »…