nota-bene.org > Sur le web > Questions sur l’avenir du Web : ma réponse

Questions sur l’avenir du Web : ma réponse

À propos de cet article

Un article de Stéphane

Publié le 11 juillet 2007

URL courte : http://nota-bene.org/183

7 commentaires

Tristan ayant fermé les commentaires sur son article, je vais continuer la discussion ici.

Je vous invite, pour lire ce qui suit, à commencer par lire l’article de Tristan Nitot, intelligent comme toujours, Questions sur l’avenir du Web.

Il s’y mélange un certain nombre de concepts, et comme j’ai les mains dedans ces temps-ci, je me permets d’y répondre et de clarifier certaines choses.

La vidéo en ligne

Débarrassons-nous tout de suite d’un serpent de mer avant de reparler du reste.

Le commentaire de Lanza indique que <object type="application/ogg" data="ma-video.ogg"></object> permettrait (permet ?) de dispenser simplement de la vidéo via HTML.

Certes, mais le besoin de nouveaux éléments HTML comme <video> ou <audio> montre bien que <object> ne tient pas ses promesses.

Ce serait méconnaître l’histoire que de ne pas savoir que c’est à cause des lourdeurs d’implémentation (demander à un seul tag de tout faire) qu’en son temps l’élément <img> a été introduit.

Si les incarnations les plus visibles de la vidéo sur internet ont délaissé Real et QuickTime au profit de Flash et de son format FLV, c’est avant tout pour des questions de simplicité. Qui n’a pas passé des nuits à encoder dans tous ces formats me jette la première pierre.

Je suis pour les standards, qui sont une des raisons pour lesquelles je fais ce métier (sans l’ouverture du web, jamais je n’aurais pu l’apprendre), mais object n’a pas tenu ses promesses.

Ce serait un peu comme de dire que pour la 3D on a VRML et que c’est bien suffisant, j’ai l’impression.

La carte séduction

Tristan a absolument raison quand il dit :

Microsoft et Adobe jouent les cartes habituelles des éditeurs de plateformes propriétaires : ils investissent massivement pour séduire une clientèle qui va devenir captive à terme, car pris dans la nasse.

Je suis d’accord, et j’en constate les effets quand je vois les yeux qui brillent des décideurs avec qui je suis en contact.

Maintenant, c’est le jeu du commerce. Agiter des épouvantails ne séduit pas une entreprise. Faire des machins qui donnent l’impression de tourner tout seuls en faisant des arbres de Noël, ça, ça séduit les décideurs.

Nous allons devoir, pour convaincre que Flex ou Silverlight ne sont pas la panacée, montrer que les standards sont ce qui rend le web pérenne (on est encore d’accord), et notamment ce qui garantit son interopérabilité.

Quid, par exemple, de Silverlight et de Flex sur les téléphones portables, le nouvel eldorado des décideurs de prestations liées au web ?

Des cibles différentes

Là où mon point de vue diverge avec Tristan c’est là-dessus :

A l’inverse, quand on investit dans le Web, on a une pérennité du contenu qui est sans commune mesure, car personne ne contrôle le Web ouvert.

Oui mais là Tristan tu te trompes de cible [1]. Investir dans Flex ou Silverlight, ce n’est pas toujours avec une vocation de pérennité.

Je travaille en ce moment presque exclusivement sur les applications riches (Flex et Ajax en particulier). Oublions un instant Ajax, qui du point de vue de ma chapelle (l’accessibilité), a bien du retard sur Flex.

Les arguments des décideurs pour choisir Flex plutôt que de faire des pages en HTML sont les suivants :

  • les allers-retours client-serveur se voient moins, c’est bien agréable (plus fluide en termes d’expérience utilisateur)
  • ça bouge puisque c’est du Flash, c’est sexy
  • ça se développe assez facilement puisqu’on s’appuie sur des compétences qu’on a déjà (Action Script, Java/JSP, XML pas trop difficile à écrire, débogage et intégration dans éclipse)

Et ça on ne peut pas le nier. Pour eux, ces arguments, à court terme (facilité d’implémentation, aspect sexy) comme à long terme (réutilisation de compétences déjà implantées chez tous les grands comptes), sont de taille.

Va promettre ça en HTML, c’est impossible. Un truc à base d’Ajax, accessibilité mise à part ? L’équipe spécialisée en RIA avec qui je travaille pouffe dès qu’on lui parle d’animations, qui mettent très vite à genoux les navigateurs à cause de leurs grosses demandes de ressources. Flash est fait pour ça, qu’on le veuille ou non : l’animation c’est son travail.

La pérennité du contenu ? oui, mais les applications Flex s’en foutent : elles ne sont là que comme incentives. C’est sexy et ça donne au visiteur une impression plaisante, impression qui peut assez facilement se traduire en taux de conversion important.

La pérennité du contenu ? oui, mais un site de vente, lui aussi, s’en fout : comme vous le savez je travaille chez un fournisseur de téléphonie, combien de temps restent en vente les téléphones portables avant d’être supplantés par les nouvelles gammes ?

Ce ne sont, simplement, pas les mêmes cibles qui sont visées. D’un côté du sexy animé (court terme et marketing), d’un autre de la stabilité et de la pérennité (« contenus » au sens noble).

Je ne parviens pas à être inquiet par les effets d’annonce des géants Microsoft et Adobe : Flash existe depuis des années, et pourtant le web reste composé majoritairement de sites de contenu, pour qui le HTML reste le fondement ; le format WMV existe depuis des années aussi, et pourtant il n’est pas majoritaire sur internet alors que Microsoft est très largement leader des plateformes bureautiques autant que des navigateurs et qu’on aurait pu craindre une évolution en adéquation avec leurs parts de marché.

Conclusion

C’est là que nous nous rejoignons :

Par contre dans une perspective où c’est le Web tout entier contre deux plateformes propriétaires, alors les dés ne sont pas jetés, et le bien du public peut encore l’emporter.

Exactement. Les animations Flash/Flex auront leur utilité (exposer une carte géographique avec une progression des frontières au fil des âges, sélectionner des critères de choix dans une boutique pour filtrer les produits, simplifier la gestion du glisser-déposer pour se rapprocher du modèle ergonomique des postes de travail [2], etc.), Silverlight est un outsider et je ne sais pas quoi en penser, mais au final le web tout entier est toujours, à ma connaissance, un truc basé sur HTML.

Peut-être que je suis un grand naïf, mais j’ai quand même l’impression que notre culture est encore très basée sur l’écrit.

Au final, on est quand même d’accord [3].


Notes

[1je prends des risques à contrarier Tristan, qui rappelait à Paris Web 2006 que quand les mecs de 120 kilos parlent, ceux de 60 ferment leur gueule clin d'œil

[2Vous allez m’objecter que les bibliothèques les plus connues en Javascript gèrent le glisser-déposer, et vous aurez raison. Mais vous ne pourrez jamais garantir que c’est facile à implémenter, ni que c’est fiable/stable sur tous les navigateurs : le travail d’un plugin est de garantir la fiabilité des résultats à l’intérieur de ce plugin.

[3Et je viens donc de m’éviter une baffe monumentale du Géant des Carpathes sourire


Commentaires

    • 11 juillet 2007

    Quelle audace ! clin d'œil

    Sérieux, je suis tout à fait d’accord avec toi. Il ne faut pas être dogmatique, chaque problématique a une solution, et surtout, différentes problématiques peuvent rarement avoir la même solution.

    Pour ce qui est de ton aversion apparente pour Ajax, ça se soigne, je t’assure qu’il est possible de faire des choses légères et qui fonctionnent.

    Répondre à Nicolas Hoizey

    • 11 juillet 2007

    Si <object> est compliqué à implémenter, c’est à mon avis parce que son usage a été détourné dans le passé.

    <object> sert normalement à inclure du contenu dans un format quelconque à l’interieur d’un document HTML. Face à cela le comportement du navigateur peut être triple :
    * Je sais restituer le format, je le fait.
    * Je ne sais pas restituer le format, mais un plugin que je connais peut le faire, je lui délègue donc la restitution.
    * Je ne sais pas restituer ce format, mes plugins non plus, j’affiche le contenu de l’élément object.

    Au lieu de cela, nos navigateurs se sont servis d’<object> pour faire un appel explicite à un plugin donné. Le résultat en ce qui concerne la vidéo par exemple est catastrophique.
    * Si le plugin n’est pas disponible, rien n’est affiché.
    * Si le plugin est disponible, mais n’est pas capable de restituer le format de vidéo passé en paramètre (il manque un codec) le résultat est aléatoire et dépend du plugin en question (demande d’upgrade du plugin, affichage d’une fenêtre noire, etc, etc.), ce qui amène à des situations cauchemardesque du point de vue de l’utilisateur.
    Et ce alors même qu’un autre plugin présent sur la même configuration est peut-être capable de restituer le contenu.

    Alors peut-être que le passé est trop lourd et qu’il faut briser ce modèle pour ne pas faire ressembler nos navigateurs à des usines à gaz, mais c’est un pas de plus vers un HTML interface plutôt qu’un HTML transporteur de contenu, qui risque de subir de plein fouet la concurrence des autres formats d’interface comme Flash ou Silverlight. Alors qu’il aurait pu et dû fournir le contenu à ces formats.

    Répondre à Lanza

  • Je crois très fort à Ajax (en particulier à Hijax, en fait). Et quand on embarquera ARIA nativement, je prônerai son usage haut et fort sourire

    Donc non, pas d’aversion. C’est juste que pour le moment, on ne peut pas vraiment considérer que c’est aussi solide que les RIA comme Flex, même si je le déplore.

    Répondre à Stéphane

    • 17 juillet 2007
    « [...] le besoin de nouveaux éléments HTML comme <video> ou <audio> montre bien que <object> ne tient pas ses promesses. »

    Essentiellement parce que les navigateurs n’ont pratiquement jamais appliqué à la lettre les spécifications de la balise <object>. Macrodobia continue bien à promulguer l’usage du <embed>.

    Ceci dit, je ne suis pas contre l’introduction de balises spécifiques pour la vidéo et l’audio.

    Quelques liens intéressants à ce sujet :

    Répondre à Michaël Guitton

    • 20 juillet 2007

    Attention, long commentaire (enfin, je pense)

    la balise object

    en son temps l’élément a été introduit.

    Peux-tu préciser à cause de quelle lourdeur d’implémentation l’élément IMG a-t-il été introduit ?

    La balise object existe justement pour permettre un moyen générique d’insérer n’importe quel type de contenu. Si elle n’a pas percé, c’est parce que IE, encore lui, ne l’implémente pas correctement.

    Si on te suivait, il faudrait une balise par type de contenu à afficher : image, video, audio, mais aussi, doc, 3d, anim... désolé, mais selon moi, c’est pas praticable... Il faut factoriser. Et l’utilisation de type MIME pour cela, c’est plutôt bien, car c’est quelque chose d’extensible.

    Finalement, on retrouve la même chose que pour les balises "input" des formulaires. Ne me dis pas que tu n’aurais pas préféré la balise textarea sous la forme < input type=’textarea’/> !

    et sur les mobiles ?

    Quid, par exemple, de Silverlight et de Flex sur les téléphones portables, le nouvel eldorado des décideurs de prestations liées au web ?

    Crois moi, MS et Adobe sont au courant.

    Adobe implémente petit à petit les fonctions de Flash sur portable, ils en sont à Flash 6 ou 7, donc tu vois qu’on arrive bientôt à 9...

    Et, (je ne sais pas trop si j’ai le droit de le dire, mais passons), Silverlight Mobile est prévu pour la fin de l’année. Voilà.

    pérennite du contenu


    combien de temps restent en vente les téléphones portables avant d’être supplantés par les nouvelles gammes ?

    C’est un peu un mauvais exemple : on va essayer justement d’externaliser au maximum cette information, pour pouvoir la changer le plus facilement possible. Finalement, on va tenter de pérenniser uniquement la partie affichage pure... Et c’est bien là que Flex se débrouille.

    Disclaimer clin d'œil

    Attention, je ne fais que relever des problèmes dans tes réponses ; dans l’ensemble je suis évidemment d’accord...

    Répondre à Julien Wajsberg

    • 25 juillet 2007

    Tout à fait d’accord (je ne suis pas sûr d’être objectif). Je ne connais pas trop Flex mais je sais que faire de jolis effets avec de belles bibliothèques js (dites web 2.0) ce n’est pas simple et ça prend des ressources. Le fait que les différents navigateurs actuels ne gèrent pas le css au même niveau c’est très gênant. Et je ne parle pas des navigateurs plus anciens.

    Je refuse d’installer un script tant qu’il n’est pas entièrement valide et je fait mon possible pour qu’il soit au maximum accessible ce qui fait que j’installe très peu de script.

    Flash est indispensable pour les vidéos je ne connais pas de moyen plus simple (ça ne veux pas dire qu’il n’en existe pas).

    Je n’étais pas tout à fait d’accord sur la balise <object> mais c’est vrai qu’une balise <video> serais finalement plus utile qu’une balise <object> qui sert aussi bien pour un jeux, des formules mathématiques, des dessins vectoriels ou pleins d’autres choses. Elle est forcement utile pour le reste (il y aura toujours de nouveaux média à insérer).

    Hier mon chef m’a dit :
    « J’ai regardé le site depuis un point internet, et je ne voyais pas les vidéos. Il y avait un carré blanc à la place. »
    Je lui ai répondu que le “player de Flash

    Répondre à ryuran

  • La balise object existe justement pour permettre un moyen générique d’insérer n’importe quel type de contenu.

    [...]

    Ne me dis pas que tu n’aurais pas préféré la balise textarea sous la forme < input type=’textarea’/> !

    Moi je ne dis rien : je constate que dans les faits ça n’a pas marché, et que Marc Andreessen et son équipe ont préféré créer img plutôt que d’attendre dix ans que object marche.

    Bien sûr que je préférerais un objet protéiforme. Je suis comme tout le monde bien fatigué des insertions empilées de object et embed, voire de scripts d’insertion de Flash tous plus abscons les uns que les autres.

    En conclusion, peut-être que l’approche la plus pragmatique est d’inventer des tags indiquant des types d’objets (image, vidéo, audio, etc), quitte à ce que le navigateur se repose sur son système interne d’objets si c’est comme ça qu’il est conçu. Le tout, évidemment, se mettant aussi du côté du mec chez lui qui fait son petit site dans son coin (argument fort des gens de HTML 5 : où est la place des gens dont ce n’est pas le métier, si on leur donne des contraintes trop fortes qui impliquent trop d’apprentissage avant de pouvoir publier leur première page ?).

    Tout ça pour dire que dans le meilleur des mondes je dirais comme vous. Dans la pratique je sais que c’est plus compliqué. Ce qu’on reproche à Microsoft aujourd’hui (implémentation incorrecte), on le reprochait à Netscape hier (introduction d’une nouvelle balise).

    Répondre à Stéphane

Qui êtes-vous ?
Votre message
  • Pour créer des paragraphes, laissez simplement des lignes vides. Tous les liens sortants comporteront un attribut rel="nofollow". Merci de ne pas spammer.

Ceci est la version Bureau Afficher la version Mobile