La table ronde qui clôturait l’édition Paris Web 2011 réunissait une fois encore différents intervenants impliqués dans le développement des principaux navigateur du marché. Ils y faisaient part de leurs travaux, de leurs collaborations respectives, et des évolutions à venir au sein de nos navigateurs.
Effet #sharethelove ajouté, ils s’embrassaient même !
Photo par Jean-François Renauld
En plus de cela et depuis maintenant plus de deux ans, je reviens de Paris Web avec (entre autres choses) la conviction qu’un dialogue se met doucement en place entre les intégrateurs, très demandeurs de nouvelles fonctionnalités ; et les implémenteurs, très demandeurs d’une priorisation de leurs tâches.
Aujourd’hui, la réponse est unanime : « Notre bugtracker est là, nous attendons vos retours d’expériences ».
Dans les faits c’est souvent beaucoup plus empirique : certains râlent dans leur coin, d’autres échangent sur des réseaux sociaux, et quelques (rares ?) courageux passent effectivement par les systèmes de suivi des bugs (j’y suis passé, c’est franchement pénible et peu adapté à nos profils).
Tout ça sans parler des disparités entre bugtrackers : certains ne proposent aucun suivi ; d’autres exigent une authentification complète ; certains sont extrêmement bien cachés…
J’ai réalisé qu’il manquait peut-être une plateforme d’échange plus simple entre ces deux communautés. Et que cette plateforme devait rassembler les idées en un seul et même endroit, quelque soit le navigateur. Après tout, cette « nouvelle fonctionnalité incroyable », nous souhaitons l’avoir partout, pas seulement dans notre navigateur favori.
Ne souhaitant pas non plus reproduire le travail déjà réalisé par chacun, je me mets à imaginer une interface :
- qui proposerait à toute personne du métier d’exprimer une idée facilement ;
- qui permettrait à la communauté d’approuver par un vote chaque idée soumise, et de trier ainsi les demandes les plus populaires ;
- qui laisserait ensuite chaque représentant navigateur formuler une réponse courte en précisant si c’est inenvisageable, à étudier, en cours ou même déjà en place.
Amis intégrateurs, respectables implémenteurs, les commentaires sont là pour recueillir vos avis sur cette idée.
8 commentaires ↓
Me gusta
quelques aspects:
un bug tracker universel pour le Web pourrait surement exister mais serait difficile à maintenir (pas impossible mais il faudrait envisager comment cela peut fonctionner, il y a de nombreux enjeux)
la langue de cet outil ? anglais ?
Théoriquement, les spécifications en brouillon du W3C sont faites pour cela pour avoir un retour de feedback avec la liste de discussion associée.
Les développements qui sont réalisés par les navigateurs sont également en partie la source de discussions avec les développeurs Web dans leurs agences et les tendances du marché. Nous regardons les forums également comme StackOverflow.
Questions
Quels sont les éléments difficiles, les propositions de fonctionnalités à améliorer dans les bugs trackers. En partant de l’existant c’est plus facile.
Pour la question de Karl sur les bug trackers: ce sont des outils orienté implémentation. Pas le lieu pour une discussion sur les contours de fonctionnalités ou même la définition de priorités (celles des développeurs web, pas celles des éditeurs).
Bien sûr il y a des améliorations possibles des bug trackers. Le bugzilla de Mozilla est devenu un peu plus lisible et moins pénible à utiliser récemment, c’est déjà ça de pris. Le bug tracker d’Opera pourrait être public pour toute la partie «spec deviation» avec ponctuellement des bugs masqués (sécurité ou enjeux commerciaux). Les développeurs web ont déjà tendance à ignorer Opera, si en plus les rapports de bug tombent dans une boite noire…
Pour les discussions sur les fonctionnalités, mon impression est qu’avant de s’y aventurer il faut avoir les idées très claires sur ce qu’on veut proposer. Personnellement je ne me sens pas autorisé à y penser tout haut, et du coup je dois avoir cinq ou six brouillons de courriels à envoyer au WHATWG et au CSS WG. Autre impression: en tant que développeur web ne représentant que lui-même, mes suggestions auront très peu de poids (et comme je suis quelqu’un de profondément vain, ça m’emballe moyen.)
Enfin, des fois on aimerait discuter de nos lettres au Père Noël et cahiers de doléances avec d’autres personnes qui ont des profils similaires et des expériences proches mais différentes. Cette idée que j’avais en tête, qu’est-ce que les confrères en pensent? C’est juste un délire perso ou bien ça intéresse tout le monde?
Moi je verrais bien un espace de discussion sur l’évolution des standards web pour les développeurs/designers. Ça pourrait être un espace de discussion libre, avec pourquoi pas un système de propositions et de votes, mais pour que ça soit vraiment intéressant il faudrait un aspect éditorial en plus:
Voilà, en gros.
(En passant, j’ai peut-être bien quelques semaines de temps à donner au cours des prochains mois. Moi je dis ça, je dis rien…)
Ah oui, mais non, soyons bien clairs, ici on parlerai plutôt d’un « feature tracker », ce n’est pas tout à fait la même chose. C’est plutôt dans l’optique d’une plateforme de feedback (et éventuellement de discussion) avec des designers/développeurs Web qui expriment ce qu’ils souhaitent et les fabricants qui disent ce qu’ils en pensent. Pour les détails d’implémentation ou de planning, là, c’est assez normal que ça se passe sur les plateformes respectives de chaque constructeur.
Ça, il y a des chance. Ceci dit, on peut imaginer un principe de traduction communautaire ou tout le monde peut proposer dans sa langue et que ceux qui en on les compétences traduisent pour que ce soit accessible/visible par tous (avec des trucs comme la possibilité de voter pour une fonctionnalité que si elle a été traduite en anglais… Bref, il y a moyen de trouver des solutions pour faire participer même les personnes allergiques à l’anglais.
Oui, alors ça, c’est la théorie hein. Pour faire partie de ces Dev. Web qui mettent les pied au W3C, je n’ai pas peur de dire que le W3C n’est pas très « author friendly ». Le W3C est avant tout une instance faite pour les constructeurs, un arène ou ils se battent assez férocement. Quand un Dev. Web arrive là bas, il faut quand même qu’il s’accroche un peu. Entre les processus interne, les informations cachés aux non membres, etc. C’est pas super encourageant quand on vient juste pour dire « Hey, j’ai pensé à ça, ce serait cool, non ? ». À titre d’exemple, c’est assez intéressant de voir comment les différentes propositionS pour un sélecteur de parent en CSS se font accueillir sur la liste de diffusion publique du CSS WG (en clair, pas très gentiment pour rester poli).
Au delà de ce coté un peu rugueux du W3C pour les Dev. Web (on peut effectivement très bien passer cet écueil sans trop de dommages si on sait faire preuve d’un peu de patience), quand on en est à l’étape brouillon de spec, c’est qu’on est déjà après le cap de « j’ai une idée trop cool » et déjà dans la logique d’implémentation/faisabilité. Il s’agit donc de quelque chose qui, encore une fois, est plus destiné aux fabricants.
Le W3C pourrait sans doute effectivement faire quelque chose ici, mais dans ce cas, il s’agirait sans doute de mettre en place un nouveau process/point d’entrée plus adapté au Designer et Dev. Web. A ce titre, les « Community Group » sont une bonne initiative mais peuvent encore être largement améliorés et simplifiés de ce point de vue.
Tout à fait d’accord. Ceci dit, cela reste un processus ou c’est encore le fabriquant qui est à l’initiative des nouveautés. Avoir un avis en amont des Designer et Dev. Web permettrait peut être de nouer une forme de dialogue un peu différent ou ce seraient les utilisateurs qui exprimeraient leur besoins propres.
\o/ ai-je envie de dire
En ce qui me concerne, du coté d’Opera c’est l’absence de feedback et de suivi qui est gênante. Ça désengage la personne qui remonte le bug et ne l’incite pas à s’investir. C’est une des raisons qui fait que j’ouvre aussi peu de bug chez Opera, la motivation est très faible pour celui qui rapporte le bug : Pas de visibilité sur la résolution, pas d’information sur la criticité du bug, s’il a déjà été signalé, etc. Pour les « feature request », c’est encore pire… pourquoi demander si on nous donne le sentiment de ne pas être écouté, autant utiliser un autre navigateur dans ce cas.
Du coté des utilisateurs de Bugzilla (Mozilla et Chrome+Webkit), le premier problème, c’est l’interface. C’est un truc immonde pensé pour des asociaux (et je pèse mes mots). La courbe d’apprentissage est assez longue surtout quand il s’agit de chercher des bugs. Le deuxième problème de Bugzilla, c’est la classification des bugs. Pour faire simple : C’est le bordel. Il est donc extrêmement difficile d’y trouver ce que l’on cherche si personne ne vous dit ou chercher. Cela créer un barrière à l’entrée et rebute les nouveaux entrant. J’ai beaucoup apprécié le système de remonté d’avis/bugs que Mozilla a mis en place lors de la beta de Firefox 4. C’était beaucoup plus simple et intégré à l’interface du navigateur. Le seul défaut de ce système c’était l’absence de dialogue possible.
Enfin, dans les cas particulier de Apple et Microsoft, il faut au choix un identifiant iMachin ou un compte Windows Live. Clairement : ça ne va pas être possible là !
Voila, my 2 cent
Ah les voilà les commentaires que j’espérais ! Merci à vous trois.
Jérémie à très bien exprimé ce que je souhaitais dire, pas la peine de paraphraser.
Je rajouterais seulement que le look and feel d’une interface est extrêmement important pour voir ses utilisateurs passer à l’action et jouer le jeu du site. Les outils actuels, les spécifications, les listes de discutions, les wikis… Tout ça est super sur bien des aspects, mais pas sur ce point.
Florent : la grande force d’un tel outil, c’est qu’il permettrait de mettre en avant les features qui font consensus. Le système de vote me semble parfait pour cela.
Pourquoi ne pas ajouter à cela un petit aspect communautaire en effet, même si pour moi il ne s’agirait pas là de la fonctionnalité principale. Mais c’est à creuser !
Une boîte à idées mondiale se remplirait très vite, je ne suis pas persuadé qu’elle permettrait au web d’avancer plus vite mais elle aurait le mérite de faire remonter des besoins. Je ne pense pas qu’il y ait plus de dialogue qu’avant entre les fabricants qui font maintenant la course à l’implémentation des APIs d’HTML5 et à l’intégration continue. Du coup ils sont sans cesse en demande de retours pour chasser les défauts. L’exemple d’Opera illustre parfaitement cet état de fait.
Mais il ne faut pas se leurrer, c’est juste parce qu’ils se battent pour des parts de marchés. C’est la guerre à qui sera le meilleur et c’est tant mieux pour le web.
Les enjeux sont tellement importants que des boîtes comme Google, Microsoft ou Adobe n’hésitent pas à mettre la main à la poche pour « soutenir » le W3C. On retrouve d’ailleurs les noms des employés de ces entreprises sur la plupart des specifications publiées par l’organisme de standardisation. Et ce n’est pas un hasard, ces entreprises ont des intérêts directement liés à ces documents.
Je n’ai rien contre un monde où les ouvriers dicteraient leurs demandes aux industriels mais j’ai pris la très mauvaise habitude de l’inverse.
C’est peut-être en train de changer.
Il y a eu dans le passé de nombreuses initiatives de collection de feedback faite par des organismes divers et variés, temporaires ou sur le long terme. L’enjeu le plus souvent c’est que ces organisations ajoutent une couche d’indirection, de coordination, et donc de bruit. La dernière tentative, c’est le truc lancé par quelques personnes de JQuery. Je ne pense pas qu’il y ait malheureusement de solutions miracles.
L’enjeu est souvent que la réaction d’un meilleur canal de feedback part toujours d’une bonne intention sans en comprendre les véritables enjeux. Une technologie entre les premières idées et le déploiement (potentiel) prend plusieurs années, parfois plus de dix ans. Avoir une initiative de collecte de besoins et de la pousser, de la soutenir demande de l’implication sur le long terme, sur quelques années. La réalité du quotidien revient souvent à la charge et les gens abandonnent ces initiatives.
Ce qu’il faut comprendre c’est qu’une feature ne rentre pas dans une spécification à cause d’un vote.
Le vote pourrait montrer sa popularité mais ne veut pas dire qu’elle est facilement réalisable. Jérémie donne l’example du sélecteur parent qui est quelque chose de très complexe et qui revient très régulièrement.
Je vois un autre enjeu dans cette négociation, celle de la documentation sur le long terme des idées qui n’ont pas été adoptées pour une raison X ou Y. À noter que les listes de discussions documentent déjà beaucoup de choses.
Oui, c’est hardu. Oui cela pourrait être surement plus user-friendly. Mais surtout cela demande beaucoup de pratiques, de patience et d’investissement personnel. Et c’est sur ce dernier aspect que le bât blesse.
Tout cela non pas pour décourager mais pour voir comment on peut envisager des mécanismes réalistes qui vivront sur des années voir dizaines d’années.
J’ai l’impression que cette plateforme existe déjà. Des discussions où des WebDev et des implémenteurs discutent, ça arrive déjà depuis 2004 dans les mailing-lists WHATWG (www.whatwg.org).
Lesquels ? Qui a dit ça spécifiquement ? Je passe suffisamment de temps avec des gens de Mozilla pour savoir qu’ils n’attendent pas de priorisation des tâches. Pareil pour Webkit et Chrome spécifiquement. Opera, Microsoft et Apple font des trucs dans leur coin. Microsoft attend que les specs W3C sortent ou qu’il y ai consensus entre les autres navigateurs. C’est comme ça qu’ils priorisent. Concernant l’ajout de fonctionnalité, la priorisation, c’est de faire d’abord ce qui tape à l’oeil (WebGL, CSS3 animation, etc.). Pour HTML, pas grand chose à dire à part que le support de base est présent partout, mais que ce qui n’est pas tape-à-l’oeil (input types, quelques attributs, etc.) arrive au compte-goutte. Pour le DOM, y’a des réformes en cours menées par les navigateurs. Ca arrive doucement. Pour JavaScript, c’est le comité ECMA TC-39 qui fait avancer les choses avec un bon concensus et une bonne participation de tous les navigateurs. Les navigateurs ne demandent de priorisation à personne à ma connaissance. Ils décident. Un jour, il est même arrivé que je dise que j’avais voté pour un bug sur bugzilla et qu’on me réponde que tout le monde se tapait des votes. A prendre avec des pincettes.
Je crois qu’on prend le problème à l’envers. Il n’y a pas de « représentant navigateur ». Il y a des navigateurs qui font des specs ensemble après s’être réuni au WHATWG. Les navigateurs n’ajoutent pas de fonctionnalités à tire-la-rigot. Ca suit souvent le processus qu’on peut trouver à http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F Bien sûr, je ne connais pas de cas où la demande de base ne venait pas d’un navigateur.
Laisser un commentaire