Etirez, réduisez, déplacez et empilez les blocs... >>> Retour page R&D
2 août 2008
[read english abstract below]
Dans le cadre du développement du projet VDN WebViewer j'ai été amené à me retrouver dans la peau d'un développeur d'outils de restitution de contenus web, expérience intéressante s'il en fut puisque du coup je me suis retrouvé confronté aux problématiques des contenus produits par d'autres, ce qui m'a changé de mes questionnements habituels sur ma façon de les produire...
En gros le projet consistait à réaliser un navigateur web capable d'afficher des pages internet dans Second Life avec lesquelles interagir : cliquer, scroller, zoomer, consulter l'historique, enregistrer des favoris, etc... bref, tout ce que permet un navigateur moderne. Je ne vais pas rentrer dans les problèmes techniques - assez fastidieux - ni dans le pourquoi de la chose - il suffit de dire que tel qu'il se présente et avec les fonctionnalités qu'il propose aux utilisateurs c'est rien moins qu'une première mondiale sur Second Life, si si... - mais plutôt évoquer ici les problèmes rencontrés avec les divers sites web qu'il me fallait bien réussir à afficher d'une façon ou d'une autre. Si certains de ces problèmes n'ont pas été simples à résoudre, d'autres ne sont pas encore résolus et ne le seront peut-être jamais, comme par exemple l'impossibilité d'afficher des contenus Flash tout simplement parce que l'interface SL ne reconnaît pas ce langage. Idem pour les interactions Javascript : il ne sera pas simple de les activer, même si Javascript est "lu" par le viewer (voir les animations sur notre page d'accueil).
Dans un sens ça tombait bien puisqu'en définitive, par bien des aspects, consulter des pages web dans SL s'apparente à une expérience d'accessibilité : n'étant pas corrigés par les fonctions "mode Quirks" des navigateurs web (voir l'article du 11 janvier 2008 sur ce "mode Quirks") les sites internet affichés dans SL le sont donc avec leurs propres défauts de conceptions, la plupart du temps liés au non-respect des normes. Si certains sont inutilisables ou presque, c'est parce que leur structuration et/ou leur développement (langages et méthodes utilisés, implémentation ou pas des normes, règles et recommandations W3C-WAI, etc.) ne permettent pas leur utilisation en dehors du cadre étroit des navigateurs "classiques" sur écrans graphiques d'ordinateurs.
Or sur SL on se retrouve dans un environnement de consultation extrêmement particulier : par exemple le simple fait que l'objet (l'écran où s'affiche le site) soit un "objet physique" (quoique virtuel...) fait que quand on croit cliquer sur un lien, on ne fait en réalité que toucher cet objet en un endroit où il se trouve que un lien est justement affiché... or rien dans la structure de cet objet ne vient dire que cet endroit est plus spécial qu'un autre, et donc qu'une action particulière soit à entreprendre ; on se retrouve donc exactement dans la situation d'un utilisateur qui n'aurait ni clavier ni souris : essayez donc pour voir de toucher les liens de cette page sur votre écran, vous n'irez pas bien loin... Ce qui ne va pas sans poser poser un certain nombre de problèmes si le site consulté n'est pas conçu dans le respect des standards d'accessibilité : en effet, dans l'obligation qu'on a sur SL de "dire" le texte du lien via l'outil de tchat pour se faire comprendre du navigateur (et accéder ainsi aux pages suivantes), tout site présentant par exemple des liens sous forme d'images sera définitivement inutilisable, puisqu'en l'occurence aucun texte ne pouvant être lu, aucun texte ne pourra "être dit" ; on ne dépassera donc jamais la page d'accueil... Idem pour les sites présentant des menus ou outils en Flash : inconsultables... Idem pour les sites présentant des menus déroulants (qu'on ne peut du coup jamais dérouler) : inconsultables... Idem pour les sites proposant des liens tous rédigés à l'identique, genre "lire la suite" après chaque extrait de texte : inconsultables (on ne parviendra à n'ouvrir que le premier lien)... Idem pour les sites à pop-up en Javascript qu'on ne pourra pas afficher : inconsultables...
Alors d'un côté on pourrait se dire que voilà une bien pauvre technologie qui n'est même pas capable d'afficher le b-a-ba des sites web modernes. Sauf que si on se plonge dans les critères Wcag (Web Contents Accessibility Guidelines : Guide d'accessibilité des contenus web) du WAI (Web Accessibility Initiative) on peut lire, écrit noir sur blanc, que tout lien doit exister sous une forme textuelle (pour les lecteurs d'écrans), que tout usage de javascript doit être non-obstructif et agir en surcouche sans jamais obérer les scénarios possibles de consultation (pour les ordinateurs où il serait désactivé), que Flash ne doit pas être utilisé comme distributeur de données utiles au bon déroulement de la consultation (pour ceux qui n'auraient pas le plugin installé), que tous les liens doivent être explicites et différenciables quant à leurs intitulés, et enfin qu'aucun contenu non-fenêtré (de type pop-up justement) ne doit être proposé aux internautes.
Il est donc intéressant de constater que pour un webviewer SL, les conditions d'interopérabilité des contenus (la possibilité de les rendre utilisables en dehors de l'outil pour lequel ils sont originellement conçus) sont exactement les mêmes que leurs conditions d'accessibilité. En terme de cube HMS (voir les deux articles consacrés à ce cube), le fait d'être sur SL surajoute à l'accessibilité humaine (H) et à l'intéropérabilité des outils (M) la question de la profondeur du support (S).
En revanche, conséquence logique, plus les sites seront conformes aux standards et normes W3C et mieux leur utilisabilité (en définitive tout se ramène à ça...) sera assurée. Quand sur ce blog je parle sans arrêt d'accessibilité, d'interopérabilité, de convergence de contenus je ne pense pas spécialement - ou pas seulement - aux publics à handicap mais plutôt à ce genre de nouvelles formes de consultation/utilisation des contenus web. (...avec les suites d'outils que nous développons - le Webviewer en fait partie - vous pouvez par exemple filmer avec votre téléphone mobile un prototype fraîchement sorti de votre labo de recherche, l'envoyer illico sur le web et le projeter instantanément sur SL devant un panel de 30 avatars ; question réactivité, instantanéïté et interopérabilité, ça le fait assez bien...)
Donc les problèmes n'ont pas été simples à résoudre. J'ai notamment compris in situ - et dans la douleur - ce que voulait dire ce fameux "mode Quirks". Par exemple, la norme W3C (comme toutes les normes industrielles elle n'est pas là pour contraindre - ça c'est le rôle du législateur - mais pour garantir par son application une reproductibilité de résultats qualitatifs ...) prévoit que les valeurs des attributs d'une balise doivent impérativement être mises entre guillemets (par exemple [img width="300"] qui signifie que 300 [la valeur en pixels] est la largeur [l'attribut] de l'image [la balise]). Il suffit donc de récupérer par une regex PHP (un genre de script de filtrage informatique) tout ce qui se trouve entre guillemets pour pouvoir le réutiliser au bon moment selon les besoins. C'est notamment le cas de la balise+attribut form action="(valeur)" qui précise quoi faire lors de la soumission d'un formulaire : lorsque vous faites une recherche dans Google et que vous cliquez pour appeler la page des résultats, en fait vous envoyez simplement votre demande à la "valeur" que prendra l'attribut "action" de la balise "form" ("search" en l'occurence)...
Donc on écrit le script et la bonne regex, on ouvre Google sur le WebViewer dans SL pour tester, on envoie le code idoine pour afficher la page web de résultats et... et il ne se passe rien ! Ah. On ouvre alors le code source de Google et on s'aperçoit que pour le jeu d'instruction "form action=" ils n'ont pas mis la valeur correspondante entre guillemets. Et donc, à cause de ça, de cette microscopique erreur, plus rien ne marche. En ne respectant pas la norme W3C ils n'ont pas garanti la reproductibilité de résultats qualitatifs. La meilleure preuve, c'est que ça n'a pas marché... Mais si en revanche ça marche sur votre navigateur, dites-vous bien que c'est uniquement parce qu'une équipe de développeurs a pris le temps d'écrire un bout de code "Quirks" pour rattraper cette erreur incompréhensible des ingénieurs de Google - pourtant ils sont assez nombreux et leur boîte a les moyens de leur payer quelques caisses de guillemets, non ? -, erreur que je n'avais évidemment jamais remarquée parce que mon navigateur se charge à chaque fois de la corriger tout seul. Mais dans SL, pas de correction sans intervention. Résultat pour moi : quelques lignes de code et une heure de boulot en plus. Du pur "Quirks" donc.
Idem pour certains de leurs liens : quand j'ai terminé de construire la regex PHP pour "lister" tous les liens d'une page afin de pouvoir les retraiter "à la voix" dans SL et que testé sur leur site le script n'a pas marché non plus, je suis retourné voir dans les codes et y ai découvert que pour certains liens (pas tous... pourquoi ?) ils n'avaient pas tenu compte des recommandations W3C pour les écrire proprement. Ça a donc fait encore des lignes et des heures de codage "Quirks" en plus...
Au bout du compte je crois bien avoir passé plus de temps à développer des solutions de "rattrapage" d'erreurs qui n'ont pas lieu d'être que de temps à concevoir et développer les scripts de base. Si donc d'aventure en utilisant le WebViewer vous tombez sur des sites inutilisables, dites-vous bien que la faute n'en revient pas nécessairement à son auteur mais à des développeurs de sites internet qui se f... des normes, de l'accessibilité, de l'interopérabilité et de la convergence des contenus comme de leur première page Html. Horrifié j'ai du coup essayé d'anticiper toutes sortes d'erreurs possibles mais la profondeur des aberrations qu'on peut rencontrer çà et là est insondable ; à un point tel que si je m'en étais tenu aux standards et normes, toute requête dans Google comme tout click dans un certain nombre d'autres sites aurait systématiquement échoué... Qu'auriez-vous alors pensé de cet outil "même pas capable de marcher correctement" ? Hé bien c'est exactement ce qui guette Microsoft et son IE8 (lire l'article "Jusqu'à ce que..." du 1er avril 2008). Il me paraît aujourd'hui plus qu'évident que les surcoûts - en temps, en énergie, en budget - que représentent ces sur-développements "Quirks" vont amener leur disparition rapide. Ce jour-là ça va être chaud pour vos sites respectifs. (Je peux vous confirmer que c'est déjà très certainement le cas sur SL où ils ont de fortes chances de ne pas être intégralement consultables, mais rassurez-vous, pour le moment pas d'inquiétude, ça ne représente au mieux que 0,00001% de vos visiteurs. Sauf que demain, c'est dans pas longtemps.)
Lors un échange avec Philippe Schoen sur son blog en février dernier concernant l'iPhone (et tout le bien que j'en pense...) s'est posée la question du rapport entre normativité et innovation. (La relation avec cet article c'est que les problématiques de migration des contenus web que ce soit vers SL ou vers un mobile sont très proches : elles posent les mêmes questions et appellent les mêmes solutions... Si les solutions devaient être différenciées, alors chaque outil émergent appelerait d'autres solutions, ce qui n'est ni techniquement ni économiquement viable.) De mon point de vue donc, et cette expérience de wiever vient le confirmer, concernant la stricte question de la restitution des contenus web et pour les raisons exposées ci-dessus il n'y a pas d'innovation possible sans un appui robuste sur les normes W3C. Pour Philippe au contraire, la norme est ce qui nuit à l'innovation : s'excluant l'une l'autre, la seconde ne peut venir au mieux qu'en validation a posteriori de la première.
Quelques extraits de l'échange :
[AB] Deux solutions, soit ignorer iPhone et ses utilisateurs qui n'auront qu'à se débrouiller avec ce qu'ils ont, soit reprendre chaque site manuellement un par un... Au moment où on se bat pour la pérennité des contenus et l'industrialisation des process, dans les deux cas c'est un pas en arrière. C'est dommage. Suite au Barcamp5 d'hier je continue à poser la question de la pertinence d'une innovation menée pour elle-même (produit marketé) indépendamment des grands enjeux concernant les contenus, les outils et les utilisateurs.
[PS] Tu parles constamment de la norme : l'innovation casse les normes pour imposer la sienne jusqu'à devenir une norme qu'une nouvelle innovation va casser. Dans cette perspective, la vitesse et l'ampleur de la diffusion de l'innovation devient un indicateur pertinent : ça veut dire que si une invention ne respecte pas la norme et s'impose auprès des utilisateurs, c'est ce produit qui est l'innovation.
[AB] La question de la norme ne se pose pas ici en terme de frein qui viendrait brider une démarche innovante, c'est là une vision un peu trop romantique à mon goût. L'explosion des contenus numériques et celle des outils en charge de les afficher - en gros ce qui dessine notre futur technologique proche - nécessite une ouverture à la fois des langages, des outils et des esprits, mais cette ouverture ne peut s'appuyer que sur un socle commun à partir duquel échanger (le mot-clé : échanger des contenus, échanger des savoirs, échanger des informations, échanger des univers potentiels, échanger des expériences utilisateurs, échanger des productions, des rêves ou des réalités même virtuelles, etc.) Or de quel socle disposons-nous aujourd'hui ? Quelle langue pouvons-nous parler pour nous comprendre ? Sur quel background commun minimal contraindre nos outils à communiquer intelligemment entre eux ?
Bien sûr c'était un débat un peu biaisé dès le départ puisque la question portait de mon point de vue sur les (in)aptitudes concrètes de l'iPhone à restituer convenablement des contenus web (ce en quoi il n'innove en rien, au contraire... que par ailleurs il innove dans d'autres domaines - l'ergonomie sur petits écrans par exemple et en devienne du coup séduisant au point de s'imposer peut-être comme "modèle normatif" - est une toute autre question) et que Philippe s'interrogeait lui sur ce qu'est, dans l'absolu, une innovation (sur le fond je suis d'accord : dans le monde social par exemple les normes freinent probablement plus qu'elles ne boostent, quoiqu'au prix d'une certaine stabilité...) mais il ressort au final à la fois de cet échange et de cette expérience de développement d'un webviewer pour SL que toute cette théorie que je tente de construire pas à pas et qui me semble parfois "litanique" tant je la trouve répétée, ressassée, expliquée et réexpliquée, trouve de temps en temps son application immédiate et pratique : une sorte de moment de fusion entre un événement pratique (constater que sur SL seuls les contenus normés sont pleinement utilisables) et la théorie sous-jacente qui vient à la fois expliquer pourquoi et valider en retour toute la démarche initiale. Au-delà, cela témoigne que l'argumentaire traditionnellement opposé aux standards du web (10% des internautes profitent de 90% des innovations et 90% n'en utilisent que 10%, et donc permettre l'accessibilité aux contenus "démocratise" le web mais sans le faire avancer...) n'est pas pertinent : avec ce WebViewer j'espère au contraire avoir démontré que seule l'application stricte de langages normés à des contenus web valides et sémantiquement structurés est capable de produire de l'interopérabilité, de l'accessibilté, de la convergence, et donc potentiellement une certaine forme d'innovation.
Que zoomer à la voix des contenus web mixés à des objets multimédias produits par des mobiles sur une plateforme de metavers 3D ne soit pas très innovant, certes, mais additionné aux démarches complémentaires que sont aujourd'hui l'interopérabilité entre metavers 3D (SL vers Opensim, voir les news SL récentes), l'intégration de contenus web ou la consultation d'univers 3D sur terminaux mobiles ou navigateurs web "classiques" (voir par ex. les travaux de Katharine Berry : AjaxLife) cela commence lentement à ressembler à un nouvel outil dont on sait pas encore dessiner les contours (web3D ?) mais qui s'annonce probablement comme l'une des innovations technologiques majeures du tout début du XXIème siècle. Quitter le schéma paradigmatique traditionnel "un contenu/un média" (dont le modèle est de plus en plus mis à mal, que ce soit sous sa forme "un article/un journal" ou "une chanson/un CD" ou "un reportage/un poste TV" ou "un film/une salle de cinéma" ou encore "un site web/un navigateur" ...) pour aller vers un contenu unique utilisable par des utilisateurs (tous) différents sur des outils multiples en est l'une des manifestations. Je garde mon idée que l'iPhone a de ce point de vue une génération de retard et que c'est dommage. Produit marketé, oui, et même très bien, mais produit innovant, sûrement pas.
Avec l'aide de Marc Moana (AIRE), grand explorateur d'univers "alternatifs", la migration du VDN WebViewer va être tentée sur Opensim (Francogrid) dans les semaines qui viennent. Si ça marche (doigts en X...) ce sera la première installation d'un webviewer sur une grid open-source :-) C'est pas rien quand même... Vive l'interopérabilité et la convergence des contenus web !!!
"Un idiome commun serait l¹unique moyen d¹établir une correspondance qui s¹étendît à toutes les parties du genre humain [...]. Supposé cet idiome admis et fixé, aussitôt les notions deviennent permanentes ; la distance des temps disparaît ; les lieux se touchent ; il se forme des liaisons entre tous les points habités de l¹espace et de la durée, et tous les êtres vivants et pensants s¹entretiennent." Diderot, L'Encyclopédie.
Pour découvrir le VDN WebViewer, consultez les pages qui lui sont dédiées.
During the developpment of this project I've been confrontated to several problems, and the biggest of them all was the lot of errors met in webpages code wrote by developpers. W3C-unvalidated pages avoid scripts to work correctly (for exemple missing quotes in attribute's value of a tag or bad coding the a href links...). Looking for a "W3C normated" code, PHP-regex (kind of filters) scripts fail to detect expected tags. A precise example : to use the r/ code properly (request to forms) I had to fisrt detect the destination (action) of the link, i.e. form action="search.php". So the page called "search", wrote in PHP langage, is the destination to reach to obtain the result we're waiting for. But absent quotes (form action=search instead, like in the main Google page - think they got enough money to buy a full truck of quotes, no ?) cause failures : nothing happens on SL first tests... For making the script working perfectly I had to develop some special script-lines able to recognize real codes to find, even if they're wrong (unvalidated). These additionnal scripts are called "Quirks"... meaning that unvalidated or un-normated contents may work as well as normated, as in "normal" web browsers as FF or IE. Awfull and unusefull work, but hardly required : without these additionnal scripts, requests on Google won't work and your thoughts will probably be "hey, that's a joke, that webviewer doesn't work !"... I do think I've spent more time trying to "repare" these errors than in developpment of the project itself.
Another big problem (but there's nothing I can do about this...) was the unability of contents to be displayed or used InWorld on SL because their non-accessibility : pop-up wrote in Javascript, undiffenciated links (i.e. "read more" after each text abstract, causing scripts to always open the first one - no way to go further), Flash menus you can't use, images-links instead of text-links (how to "chat the link content" without any link content ?), ... all gadgets web-developpers shoudn't use.
My conclusion is that the more accessible, interoperable and convergent are your web contents, the more able they'll be to fit to new ways of internet-uses for tomorrow morning. This WebViewer proves that a well-formed content is always more usable than any other one, and proves that respecting WAI-Wcag (Web Accessibility Initiative - Web Contents Accessibility Guidelines) recommandations is the better way to make you sure they'll stay operable in the future, on SL, on a mobile or on any future web consultation tool. Long life to W3C and long life to well-used web langage norms!!! As this VDN WebViewer project aims to prove it, they don't "kill innovation" but hardly help to "produce innovation" ;-)
Back to VDN WebViewer page