Reprogrammer le CDrom Beethoven 9e Symphonie (1989-1991)
Remarques sur la version 0.1 (alpha) de la reprogrammation partielle du CD-ROM de Voyager Co. Beethoven, 9e Symphonie, 1989-1991.
La reprogrammation du CD-ROM édité d’abord en 1989, puis revu en 1991, par The Voyager Company — et considéré comme le premier objet éditorial sur ce support multimédia — participe de nos recherches sur l’archéologie des éditions numériques. Il s’agit d’une maquette de restitution partielle, limitée à un ensemble significatif de fonctions novatrices et non d’une véritable re-publication.
L’enjeu est de permettre un accès différent de l’émulation logicielle de l’OS déjà mise en œuvre avec SheepShaver et détaillée par ailleurs [lien]. L’application native produite avec HyperCard était compatible avec « tous les Macintosh produits après 1986, avec l’OS 6.0.7 ou plus récent… » indiquent les caractéristiques mentionnées sur la notice d’accompagnement. Or, le passage à OS X a rendu l’accès à ce titre hybride impossible, ou au moins imparfait, même avec la version émulée un temps par Apple dite Classic, avant le passage aux processeurs Intel. Pour plus de détails sur les niveaux d’obsolescence, voir le lien suivant.
Le projet consiste à reproduire les comportements identifiés sur le titre original en action sur une machine d’époque, conservée dans nos ateliers, qui sert de témoin. [lien] Nous n’avons pas choisi de décrypter le code source de l’application, bien que cette méthode soit envisageable. [lien] Nous utilisons des captures d’écrans, découpées, et mises en série par un eu d’instructions en html/css/JS. Après une première phase de développement, le site Internet demande un retour critique à plusieurs niveaux. Nous tentons ici de réunir les premières réflexions et les remarques que la réalisation de ce projet suscite et permet.
Nous pouvons rappeler ici les actions relatives à cette expérimentation qui ont déjà été engagées. Au cours de la recherche menée sur une archéologie des éditions numériques, portée par Gilles Rouffineau au sein de l’unité de recherche, plusieurs hypothèses d’attitudes ont été faites. Il s’agit avant tout de permettre l’accès à des artefacts culturels numériques « anciens », utilisant des technologies aujourd’hui obsolètes, rendant l’exécution des programmes difficile voire impossible avec les machines d’aujourd’hui. L’émulation est une solution que nous avons commencé à explorer avec le premier numéro de la série Anarchive sur l’artiste Antonio Muntadas, sous la direction d’Anne-Marie Duguet, datant de 1996. Après avoir réussi à rendre le CD-ROM consultable sur les ordinateurs Mac OS X contemporain [faire un lien sur le post qu’il faut écrire à ce sujet], nous avons réaliser la même opération avec le CD-ROM sur Beethoven [encore un post spécifique à faire]. Suite à cette action, nous avons souhaité faire une première tentative de reprogrammation. Si l’émulation permet de reproduire de la manière la plus fidèle possible un environnement matériel comme logiciel sur des plateformes actuelles, la reprogrammation consiste en la réécriture de l’œuvre logicielle originale dans un environnement contemporain. Nos hypothèses de stratégies entre fortement en parallèle avec celles que le réseau des Médias Variables, fondé par le musée Guggenheim et la fondation Daniel Langlois en 2002/2003. En effet, d’après ce groupe de recherche, les stratégies de conservation et d’activation des œuvres d’art utilisant des technologies obsolètes (et pas uniquement numériques) sont au nombre de quatre : le stockage, la migration, l’émulation et la ré-interprétation. L’émulation et la ré-interprétation sont respectivement résumées ainsi : « faire tourner le logiciel désuet sur de nouvelles plates-formes », et « recréer l’œuvre avec de nouveaux environnements technologiques ». Ce que nous nommons reprogrammation correspond donc à la ré-interprétation. Dans le cas précis du CD-ROM sur Beethoven, nous avons décidé de reproduire le programme avec les technologies du Web, qui se présentent aujourd’hui comme l’un des standards les plus pérenne du paysage globale des technologies de l’interactivité numérique.
D’un de vue méthodologique, nos avons décidé de proposer à un duo designers graphiques spécialisés dans les technologies du Web, PapaScript (Alexandre Dechosal et Maxime Foisseau), de réaliser une première reprogrammation à partir de laquelle la validité de cette démarche pourrait être interrogée. Il était question d’obtenir un objet « concret » à partir duquel une évaluation serait possible. En effet, la critique de l’intention, du projet de reprogrammation, a rapidement trouvé ses limites sans la possibilité de faire l’expérience d’un premier résultat. Afin de faire recherche nous avons donc commander la réalisation de cet objet intermédiaire, dont nous proposons ici un retour critique.
Le choix d’utiliser des effets d’animations très « contemporains » est-il bien adapté ? Est-ce qu’un aspect tout aussi épuré, mais faisant l’économie des effets de transition animés ne serait pas plus discret ? La version actuelle du site fait l’hypothèse suivante : il s’agit de permettre l’accès à l’objet d’origine et de l’augmenter éventuellement de divers contenus (textes, images, vidéos). L’usage de ces animations, en plus d’être superflu, peut sembler en désaccord avec l’idée de reprogrammation en focalisant l’attention sur ses éléments extérieurs. Peut-être faut-il séparer entièrement l’expérience de l’objet reprogrammé et les contenus satellites : lorsqu’on demande à voir les contenus annexes, la reprogrammation disparaît.
La typographie, elle aussi très actuelle (?) convient-elle ?
Problème d’interpolation automatique des images par les navigateurs : on perd l’aspect « noir et blanc » des images à cause d’un effet de filtre qu’il faut désactiver dans le rendu des images:
image-rendering: optimizeSpeed; /* Older versions of FF */
image-rendering: -moz-crisp-edges; /* FF 6.0+ */
image-rendering: -webkit-optimize-contrast; /* Safari */
image-rendering: -o-crisp-edges; /* OS X & Windows Opera (12.02+) */
image-rendering: pixelated; /* Awesome future-browsers */
Les codes CSS ci-dessus ont été testés sur le site (en mode développeur), ils fonctionnent correctement et permettent d’éviter l’interpolation.
UPDATE : Corrigé et testé sous Safari et Chrome.
résultat dans le navigateur sans les CSS image-rendering
résultat dans le navigateur avec les CSS image-rendering
Gros problème de « responsive » : lors du redimensionnement de la fenêtre, toute l’interface de déconstruit. Ce phénomène arrive aussi lorsqu’on change de section via le menu du haut.
Il faut corriger ce bug.
Organisation des menus
– La façon dont les sections sont reparties dans les menus n’est pas suffisamment fonctionnelle.
L’exomenu a perdu de sa raison d’être dans cette version, une confusion s’installe entre ce qu’il est possible de consulter directement depuis l’interface du CD-ROM et ce que ce menu apporte. La meilleure solution semble de l’abandonner et d’intégrer son contenu dans un autre menu. Une liste précise des contenus prévus doit être établie afin de définir leur l’agencement.
– Les zones de contenus de texte et de vidéo, actuellement en colonne de droite, méritent plus de place. Pourquoi ne pas les faire recouvrir la simulation du CD-ROM, quitte à pouvoir revenir à cette dernière via le menu ?
– Tout ceci nous ramène à l’hypothèse d’une séparation entre les contenus satellite et l’objet reprogrammé.
Accès au CD-ROM
– Les champs de texte sélectionnables de l’écran « Index » ne deviennent pas noir au clic, ils le devraient non seulement pour respecter l’aspect et la mécanique des boutons HyperCard d’origine, mais aussi pour donner un retour minimum à l’utilisateur pour valider son action.
– Le CD-ROM n’utilisait pas le roll-over. Cependant, il pourrait être utile de l’utiliser ici pour signifier qu’un bouton est actif ou non. Par ex. pour les boutons qui ne sont pas actifs en bas de l’écran « Le programme », faire en sorte que GLOSSAIRE, ? et HOME se vident de leur contenu (deviennent blancs) pour donner un indice sur ce qu’il est possible de consulter ou non.
– Partir sur des parcours limités mais interactifs autant que possible, entre 3 et 4, pour donner une idée représentative des modalités d’interaction. En l’état, l’ensemble manque de cohérence et apparaît délié.
– Les parcours seraient dans un menu, à gauche, de sorte à pouvoir passer aisément de l’un à l’autre.
– Le menu du haut doit être vidé au maximum (à mon sens -DC)
– Les outils échelle x 2 et masquer la fenêtre OS9 doivent être uniquement dans le menu de gauche, section outil (le + doit rester).
Programme de recherche
Liste des problématiques que cet tentative apporte ou confirme.
Quelles stratégies pour quels accès aux éditions numériques techniquement obsolètes ?
Le parallèle avec les travaux des Médias Variable semble indispensable ici afin de situer nos propres propositions.
Reprogrammation : jusqu’où aller ?
Comment établir la liste des éléments et des étapes minimums à reproduire pour proposer une expérience interactive suffisamment complète de l’objet original ?
Propositions pour une phase 2
La définition d’un cahier des charges plus précis et prenant en compte les remarques que nous faisons ici doit être faite. Il s’agit maintenant d’aboutir à une proposition qui pourrait être rendue publique et serait l’un des résultats de notre recherche. Attention à bien conserver cette première version du site, pour faciliter l’archéologie de notre propre recherche.
La définition de 3 parcours types devrait permettre de stabiliser la proposition d’ensemble. Nous pourrions dire que la différence ntre notre reprogrammation et la ré-interprétation des Médias Variables se trouve dans cette manière de limiter la ré-écriture du programme à certaines parties « significatives » de l’objet d’origine sans le reproduire dans son intégralité. C’est peut-être aussi une différence entre les œuvres d’art interactifs, cibles du projet des Médias Variables, et les éditions numériques, aux contenus parfois encyclopédiques. La manière dont ces parcours sont déterminés doit être documentée et explicitée, car elle peut potentiellement devenir générique pour les œuvres du même type.
La séparation des contenus satellites doit être étudiée, car le cas de l’usage de typographies intégrée aux navigateurs contemporains donne un aspect tout à fait autre de celui d’origine. Permettre la comparaison dynamique entre l’usage des typographies pixélisées, intégrée dans les captures d’écran, et les typographies d’aujourd’hui, beaucoup plus lisses, est une façon d’évoquer la nécessitée de certain choix qui apparaissent dans le travail de reprogrammation. Les éventuels liens entre une reproduction fidèle à l’originale ou non et des stratégies de restaurations archéologiques est un point de recherche qui devrait être abordé indépendant de la réalisation de cette reprogrammation.
Hypothèse d’un convertisseur automatique depuis HyperCard vers HTML5/JS/CSS
Pourquoi y aller ?
– Peut être amusant à faire.
– Permet une adaptation intégrale des titres dans un format que l’on espère pérenne.
– Représente une contribution potentiellement importante dans le monde de l’archéologie des médias.
Pourquoi ne pas y aller ?
– Bien trop chronophage.
– Trop peu de titres importants dans l’histoire des éditions numériques sont concernés.
– Tâche probablement démesurée par rapport à son apport au projet de recherche.
Stack HyperCard vers HTML5 ? Quelques éléments à consulter :
http://www.hyperactivesw.com/mctutorial/rrtutorialtoc.html
http://livecode.com/livecode-to-html5/