Re: Images Actives, libres+libres

[Joachim Dornbusch <joachim.dornbusch AT crdp.ac-versailles.fr>]

Bonjour Georges,

il est intéressant de croiser nos approches car parallèlement j'ai aussi avancé sur Images Actives en prenant en compte tes recommandations qui m'ont beaucoup apporté.
J'ai aussi commencé à implémenter les spécifications de la version 1.0 issue des remontées d'expériences des professeurs :
http://joachim-dornbusch.ac-versailles.fr/images_actives_1.0/tests

Tu peux peut-être répercuter ma réponse sur educ AT april.org sinon les abonnées de cette liste auront le sentiment que je ne te réponds pas.
Voici quelques résultat de mes cogitations :

1° l'essentiel est de définir le format de données qui sera au coeur d'Images Actives, pas le "modus operandi" pour l'utilisateur. En amont se trouve un générateur, destiné à l'utilisateur primaire (le créateur de l'image) : celui qui permet de mettre les données dans le format en question. En aval se trouve l'animation, destinée à l'utilisateur secondaire (qui visionne, manipule le résultat).

2° Le générateur peut être  un logiciel dédié (C++, Python, Java), un plugin de logiciel libre existant, ou n'importe quoi d'autre (par exemple, une application web, implantée sur serveur).
L'actuel logiciel Images actives est un ancêtre de ce générateur.

3° En aval, l'animation, peut, elle aussi, être implémentée dans n'importe quelle technologie : html5, flash, processingjs, silverlight, applet ou autre, ou même une technologie non web. Le tout  est qu'elle accepte, comme données entrantes, le format de données Images Actives, dont elle effectuera le rendu de son mieux.

4° Quel est ce format de données ?
Pour faire coïncider au mieux "l'univers du problème et celui de la solution", j'ai pris pour point de départ ces énoncés :
Une image active est une image : cela définit une relation d'héritage à partir d'un format d'image.
Une image active a des options (disposition, comportement) : cela définit une relation de composition et suggère l'ajout d'un autre fichier.

C'est pourquoi le fichier de contenu (images et légendes) me semble devoir être un fichier svg éventuellement enrichi (héritage). Le format svg s'y prête bien puisque les métadonnées qu'il contient permettent d'accueillir les éléments textuels de l'image active.
Le fichier d'options doit être un second fichier (xml), avec ses propres spécifications. Le fichier "images actives" peut-être une archive de ces deux fichiers et de leurs dépendances (les bitmaps liés au svg, les sons pointés par le xml).

5° Comment spécifier le format de données ?
Le format du fichier d'options (xml) est le point critique de l'affaire. Ce format doit rester évolutif.
A un instant t, une certaine version d'Images Actives propose :
- un choix de dispositions
actuellement nous en avons conçu quatre : accordéon, légendes numérotées en haut et en bas, légendes recouvrant l'image, légendes audio.
- un choix de comportements
nous en avons prévu deux : découverte de l'image, quizz (pas encore implémenté)

Mais cette liste ne doit pas être close, et le format du fichier d'options doit être conçu pour permettre l'ajout par nous ou par d'autres de nouveaux comportements et de nouvelles dispositions. Cela peut être fait en utilisant la pluralité des espaces de nommage xml.
Cette structure devra se refléter dans la programmation des animations (même si ce n'est qu'une simple recommandation) : "encapsulate what changes". Quel que soit le langage utilisé, les dispositions et les comportement doivent être encapsulées (notamment selon le pattern "Strategie" ou un autre pattern de délégation)
Par exemple, l'interface "comportement" propose la méthode afficherLegende() : cette méthode sera implémentée tantôt sous forme de l'ouverture d'un panneau d'accordéon, tantôt sous forme de l'émission un son, ou sous d'autres formes que nous n'avons pas encore prévu (par exemple, un module de synthèse vocale).
Ainsi, à l'avenir, nous pourrons définir de nouvelles dispositions, de nouveaux comportements,  ce qui conduira à ajouter des champs au fichier xml d'options, et nous définirons le contenu de ces champs dans de nouveaux espaces de nommage.

voici le fichier svg utilisé dans les tests :
http://joachim-dornbusch.ac-versailles.fr/images_actives_1.0/tests/content.svg

Tu remarques que tous les contenus textuels pourraient être modifiés avec, par exemple, les rubriques "propriétés de l'objet" et "métadonnées" d'Inkscape. D'autre part l'utilisateur peut introduire ses détails aussi bien comme des paths svg que comme des bitmaps détourés sous Gimp ou autre.

voici un example de fichier xml d'options utilisé dans les tests :
http://joachim-dornbusch.ac-versailles.fr/images_actives_1.0/tests/options_example.xml

Tu remarques que la disposition particulière ("accordion") et le comportement particulier ("simple_discovery") sont définis dans leurs propres espaces de nommages. C'est ce qui permet à notre format de rester extensible.

A noter, ces deux fichiers étant des fichiers xml, je pense que le code html pourrait être généré "d'un seul coup" par une transformation XSLT qui reste à écrire. Quant au code _javascript_ de cette animation, nous aurions intérêt à ce qu'il partage le diagramme de classe de la version flash/actionscript. Les deux langages et la structure des animations sont très proches et cela n'a pas de sens de développer deux architectures divergentes.

Il va sans doute falloir que nous nous concertions un peu plus si nous voulons que nos travaux convergent !

Amitiés,
Joachim




 



Le 05/05/2011 00:02, Georges Khaznadar a écrit :

Bonjour,

Je viens de finir une première version qui fonctionne pour des images
actives qui utilisera des logiciels libres pendant la conception, et
reposera sur des logiciels libres pour la diffusion.

Le parti pris est le suivant :

nous pourrions réaliser un superbe logiciel, capable d'une part de
détourer les images à la perfection, riche d'outils divers permettant
des détourages automatiques (par exemple des outils de seuillage comme
pour l'analyse des radiographies), et capable d'autre part d'éditer les
textes explicatifs à la perfection, avec un vérificateur d'orthographe,
un système de recherche en plein texte, des facilités pour compléter la
frappe à la volée, etc.

Mais plus nous nous approcherions de la perfection, et plus l'outil
ressemblerait à un logiciel standard de traitement d'image, comme
Photofiltre ou The Gimp, et à un traitement de texte, comme Word ou
LibreOffice.

Dans ce cas, ce serait contre-productif de persuader les auteurs
d'images actives d'apprendre *encore un autre* logiciel servant en fait
à réaliser ce qu'ils savent déjà faire par ailleurs, avec des outils
standards.

J'ai donc pris le contre-pied de cette démarche : je m'appuie sur le
savoir-faire déjà existant des utilisateurs, et j'ajoute juste le grain
de sel qui permet de faire de l'image active.

À l'arrivée, il reste un trio de programmes :

1- un plugin pour Gimp
2- un programme qui s'appuie sur OpenOffice/LibreOffice
3- un convertisseur de fichier pai -> xhtml qui travaille dans l'ombre

Comment fait un auteur ? Le mode d'emploi est le suivant :

A- choisir une image ordinaire et l'ouvrir avec The Gimp. Créer des 
   chemins fermés pour chaque zone à détourer. Gimp est très fort à ce
   jeu-là, car il a plusieurs outils qui permettent de réaliser des
   sélections fines, et l'outil des chemins, s'il permet de définir un
   chemin à la souris directement, permet aussi de transformer n'importe
   quelle forme sélectionnée en chemin fermé (et réciproquement). Avec
   Gimp, détourer le plan du métro ne poserait pas de problème. J'ai
   fait un exemple avec le reticulum endoplasmique d'une cellule (20
   minutes de travail), voir à
   http://georges.khaznadar.fr/docs/images-actives/cellule.xhtml

   Nommer les chemins : c'est important, ça définit les titres.

   Utiliser la Plugin : Images Actives -> Enregistrer une image PAI...

B- lancer le programme "oopai" ; celui-ci reprend le fichier issu de Gimp
   et fabrique à la volée un tableau dans l'application de traitement de
   texte. Colonne de gauche : les formes détourées dans l'image. Colonne
   de droite : les textes détaillés pour commenter les parties de
   l'image. Après le travail, on ferme le traitement de texte ; alors
   oopai reprend la main, utilise la dernière version enregistrée par le
   traitement de texte, extrait exclusivement les cases de la deuxième
   colonne et s'en sert pour mettre à jour le fichier PAI. Au passage,
   il invoque le générateur de fichier XHTML et le résultat est alors
   accessible dans un navigateur, l'image est active.

A'- l'utilisateur peut réitérer un passage dans The Gimp et utiliser le
    plugin par Images Actives -> Lire une image PAI... pour peaufiner les
    formes, refaire les titres, ajouter ou supprimer des formes, etc.

B'- l'utilisateur peut réitérer un passage dans oopai et bricoler dans
    le traitmeent de texte, et ainsi de suite.

On pourrait imaginer un programme graphique qui enrobe les étapes A, B,
A', B', A", B" etc. Je ne l'ai pas fait.

Voyez à http://georges.khaznadar.fr/docs/images-actives/,
http://georges.khaznadar.fr/docs/images-actives/sources.html

Amitiés,			Georges.