Karl, tu as rejoint le projet Web compat chez Mozilla, est-ce que tu peux nous expliquer le but de ce projet ?
Le projet Web Compatibility à Mozilla a été démarré fin 2012. Le lancement de Firefox sur les appareils Android et puis de Firefox OS a révélé de nombreux problèmes de compatibilité Web. La détection de la chaîne de caractères identifiant les navigateurs (User Agent string) est souvent fautive. Elle se traduit par deux symptômes : la réception du site pour « desktop » lorsque les autres reçoivent la version « mobile » et des chemins de code erronés dans les scripts en JavaScript du site Web. Nous réalisons donc :
- des sondages automatiques du Web pour détecter les sites fautifs ;
- du triage des tickets d’erreurs rapportés par sondage ou par les utilisateurs ;
- des analyses des erreurs ;
- des propositions de solutions ;
- des contacts vers les sites Web présentant des erreurs.
Nous avons une section dédiée de Bugzilla pour ceux-ci. À noter que cet effort de compatibilité Web a eu un ancêtre à Mozilla pendant le temps héroïque de la domination d’Internet Explorer sur le Web. De nombreux sites étaient incompatibles avec Firefox, il fallait alors contacter les sites pour les inciter à être compatibles avec tous les navigateurs.
Et dans cette mission, quel est ton rôle ?
Nous avons tous les participants au projet Compatibilité Web une mission avec un contour fluide. C’est important afin de ne pas tomber dans une tâche répétitive qui serait préjudiciable au projet. Dans les rôles actuels sur une semaine :
- Triage de bugs avec une reclassification si un bug n’a pas été caractérisé correctement. Il est parfois nécessaire de tester de nouveau afin d’obtenir une confirmation.
- Analyse du bug. Certains bugs de sites Web demandent une analyse plus profonde afin de bien comprendre l’enjeu. Les CSS et le JavaScript posent généralement le plus de problème. La minimisation des scripts n’aide pas toujours à la bonne compréhension du script. Il y a des cas de figures répétitifs, une sorte de top 10 des problèmes de compatibilité Web.
- Contacter les entreprises et les propriétaires de sites afin de les encourager à rendre leurs sites Web plus compatibles. Il y a quelques obstacles le long du parcours tels que trouver les personnes susceptibles de répondre au contact ou de nous envoyer vers la bonne personne au sein de l’entreprise. Malheureusement, les points de contact traditionnels tels que les formulaires client ou les comptes Twitter officiels de l’entreprise ne permettent pas un contact intéressant. Les personnes chargées de trier ces bugs n’ont souvent pas assez de compétences techniques pour comprendre l’enjeu.
- Une fois que l’entreprise est contactée, faire le suivi au long cours et réessayer de multiples fois. C’est la partie monastique du rôle. Beaucoup de chances de ne pas avoir de réponse positive si ce n’est de réponse du tout.
- Nous développons également un projet Web Compatibilité qui est pour tous les navigateurs. Je réalise donc un peu de programmation Python sur le projet surtout pour tout ce qui concerne les interactions HTTP entre client et serveur.
- Et puis bien sûr les petites tâches administratives hebdomadaires, comme la mise en forme de nos compte-rendus de meetings, la gestion des contacts particuliers avec les grands comptes comme Yahoo !, Google, pour les enjeux de compatibilité Web.
- Le soutien à la communauté. Le travail de compatibilité Web ne serait pas possible sans la participation de toute la communauté. Nous tentons souvent de nous décharger des responsabilités face au bug afin de rendre autonomes certaines personnes dans chaque région géographique avec les bugs de compatibilité Web. Il y a des centaines de bugs enregistrés, nous ne pourrions pas humainement tout faire. Il est donc important que ces tâches soient vraiment partagées entre tous.
La notion de « compatibilité web » est tellement importante qu’elle est devenue le nom de ce projet. Est-ce que ça veut dire que Webcompat est amené à rapporter des problèmes de compatibilité quel que soit le navigateur, ou votre mission est-elle centrée sur les produits Mozilla ?
Hmm peut-être ai-je été confus dans mon propos initial. Il y a :
- Tech Evangelism (Mozilla only)
Desktop : https://bugzilla.mozilla.org/buglis...
Mobile : https://bugzilla.mozilla.org/buglis... - Webcompat.com (any browser)
http://webcompat.com/
Tech Evangelism (que Mozilla a renommé Web Compatibility il y a quelques années) est un projet géré pour régler les problèmes de compatibilité Web subis par les navigateurs de Mozilla.
L’équipe qui travaille sur le projet (en dehors des contributeurs) est principalement issue d’anciens membres de l’équipe Open The Web à Opera. Lorsque nous travaillions à Opera, nous n’étions pas satisfaits que le gestionnaire de bugs soit privé. Nous avons l’ouverture avec Bugzilla, mais dans notre travail, nous remarquons souvent que les bugs ne se limitent pas seulement à un seul navigateur. Demander la correction pour un seul navigateur semble contre-productif. Il est préférable d’encourager à élargir l’horizon de la correction lorsque nous contactons ou analysons. En 2012, Microsoft, Mozilla et Opera avaient conjointement organisé une clinique des navigateurs, lors d’un atelier Paris Web. Un des participants pendant l’atelier nous avait fait remarquer combien il était décourageant d’avoir à reporter les bugs de navigateur sur chacun des sites de rapport de bugs. Il semblait naturel d’avoir un site qui puisse répondre aux problèmes courants que les utilisateurs, les développeurs de site ainsi que les développeurs de navigateurs rencontrent. Ce n’est bien sûr pas l’unique raison mais cela fait partie des raisons de l’existence de https://webcompat.com/.
Donc pour revenir à la question, le cœur de la mission est de permettre :
A person should be able to use the Web whatever the device and the browser they are using.
Qu’est-ce qu’on peut faire pour faire avancer la cause ? En particulier, comment expliquerais-tu les choses pour un profane ?
La compatibilité Web n’est pas une science exacte. Il n’y a pas de recette miracle. Cependant, maximiser l’accès d’un site Web aux utilisateurs est bénéfique pour tous. Voici quelques idées, certaines essentiellement évidentes mais toujours bonnes à rappeler.
En amont
- Plus le site Web est complexe, plus le site sera difficile à réaliser, tester et maintenir dans le temps. Plus cela représente un coût autant pour le client (argent et réputation) que pour l’agence Web (réputation).
- Plus nous utilisons des technologies avancées ou pas encore tout à fait matures et plus nous prenons le risque de devoir gérer des problèmes de compatibilité Web.
- Plus le site Web dépend de bibliothèques de code externe, plus il y a de chances que ce site sera un problème dans le futur.
- Il y a bien sûr la règle opposée, plus une bibliothèque externe est connue, plus elle a de chances d’être plus à jour que les développements internes.
- Testez au maximum votre site Web. Automatisez le plus possible vos tests quand c’est possible, il y a de nombreuses bibliothèques pour réaliser des tests fonctionnels. Par exemple The intern. Attention cependant les tests automatiques sont aussi dépendants du moteur de rendu que vous utilisez pour le test. Cela s’est beaucoup amélioré ces dernières années avec la disponibilité de PhantomJS (WebKit) et SlimerJS (Gecko), les deux peuvent être pilotés avec CasperJS.
- 80% des problèmes sont créés par des détections erronées de la chaîne « User-Agent » du côté serveur ou du côté client. Un autre 15% par des problèmes de CSS. Les 5% restants sont des problèmes complexes de JS, de fallback, etc.
Pendant l’exploitation du site
- Mesurez les performances du site, non seulement la vélocité, mais la complétion des tâches. Cf. Spotting bugs using statistical methods
- Si vous observez un taux de rebond pour certains navigateurs plus important que pour d’autres, il est probable que ce site fonctionne mal pour ces navigateurs.
- Si un navigateur est totalement absent de vos statistiques, il est probable que votre site est inutilisable par ce navigateur.
- Vérifiez les rapports de bugs des navigateurs Web et n’hésitez pas à consulter webcompat.com pour chercher le nom de domaine du site que vous développez. Cela vous permettra d’identifier les enjeux que rencontrent vos utilisateurs.
- Lorsque vous développez un site Web, permettez aux utilisateurs et aux spécialistes de la compatibilité Web d’avoir un contact efficace. Bien trop souvent, les formulaires de contact des sites Web, les comptes Twitter des compagnies, etc. sont des trous noirs sans aucune réponse. Il s’agit là de gérer une demande technique et pas seulement une relation client commerciale. (Cet aspect précis pourrait faire l’objet d’un article en entier sur les bonnes pratiques.)
En aval
- Si vous êtes le développeur d’un site Web et que vous ne comprenez un bug sur votre propre site, n’hésitez pas à le rapporter sur webcompat.com. Les problèmes de compatibilité Web demandent parfois une certaine expertise. Et c’est une bonne façon d’apprendre.
- Si vous êtes un utilisateur, n’hésitez pas à faire un rapport de bug sur webcompat.com. Donnez la description de toutes les étapes pour reproduire le problème. Plus les détails sont nombreux et plus il est facile de comprendre ce qui se passe.
- Soyez poli en toutes circonstances. Il est très frustrant de rencontrer des problèmes sur les sites Web, mais généralement la colère ou les insultes crispent la relation entre vous et la personne qui est probablement capable de corriger le problème. N’oubliez pas que cette personne a probablement aussi un supérieur hiérarchique et qu’elle ne maîtrise pas toutes les décisions exécutives.
- Si vous êtes un moine, nous aider à trouver les bugs, les analyser et contacter les sites Web. Plus nous sommes à faire ce travail, plus le Web sera utilisable.
Pour faire avancer la cause :
- Rapporter les bugs
- Ouvrir des communications positives
- Travailler ensemble à la résolution des enjeux
Un mot de la fin pour nos lecteurs ?
La majorité des problèmes de compatibilité Web est due à un manque de prise en compte de la possibilité d’une erreur. Actuellement de nombreux sites décident pour l’utilisateur ce qui est bon pour l’utilisateur. Ce n’est pas très agréable, personne n’aime s’entendre dire « vous n’avez pas le bon profil, vous ne pouvez pas entrer ici ».
Il est pourtant intéressant de rendre le site accessible à un grand nombre de personnes en planifiant l’échec en ayant toujours un « fallback » générique. Si A alors blahA, si B alors blahB, sinon blahFallback. Trop souvent blahFallback est complètement absent ou bien un système empêchant l’accès.
Le choix des utilisateurs de leur produit est très important pour les utilisateurs, mais également pour votre marque. Un utilisateur refusé est un client perdu.
Vos commentaires
# Karl Dubost Le 23 février 2015 à 07:31
En relisant, je remarque que j’ai oublié de mentionner les contributeurs actifs du développement du site Web webcompat.com. C’est important car sans eux, le site ne serait pas là où il en est aujourd’hui.
* Alexa Roman @calexity
* Daniel Davis @ourmaninjapan
* Guillaume Demesy @magsout
On les retrouve dans http://webcompat.com/humans.txt
# Nicolas Hoffmann Le 23 février 2015 à 10:51
Moi moi moi, j’ai une question Karl ! :)
Tu invites à chercher le « nom de domaine du site que vous développez », ce qui est une bonne chose (et que je me suis empressé de faire d’ailleurs ;) ).
Ma demande serait un poil différente : serait-il possible - d’une manière ou d’une autre - que moi, en tant que responsable de sites que je gère, je puisse « m’abonner » ou du moins « déclarer » que tout ce qui passe sur « tel nom de domaine » sur Webcompat m’intéresse ? (même avant que des problèmes ne surviennent, du coup, je suis automatiquement prévenu qu’on a reporté un problème sur un site qui m’intéresse)
Je me dis que ça pourrait être un plus, autant pour le client que pour le prestataire. J’ai surfé sur le site, mais je n’ai pas vu d’options dans ce sens, est-ce que cela serait possible ? (d’ores et déjà, ou dans un futur proche)
# Karl Dubost Le 23 février 2015 à 22:52
Oui, Nicolas c’est une excellente idée qui est déjà dans la liste des features demandées.
* Register contact for sites, to get feedback #60
Il faut juste le développer ;)
# QuentinC Le 24 février 2015 à 18:45
Bonjour,
Je suis un utilisateur de lecteur d’écran. Je trouve qu’il faudrait le même genre d’initiative mais pour l’accessibilité. Ca inciterait peut-être des gros sites et/ou des bibliothèques js connues à se bouger pour s’améliorer aussi dans ce domaine.
Pour nous autres, les problèmes d’accessibilité ou d’utilisabilité sont aussi énervants que les problèmes de compatibilité, voire même plus.
Ou alors Est-ce que les problèmes d’accessibilité sont aussi abilités à être rapportés sur votre plate-forme ? Ou alors ça ne servirait de toute façon à rien parce que c’est trop spécifique ? Et question subsidiaires, qu’en est-il des problèmes des navigateurs eux-mêmes ? Je n’ai peut-être, àprès tout, rien compris et suis complètement à côté de la plaque
Merci.
# Stéphane Deschamps Le 24 février 2015 à 18:52
Bonjour QuentinC,
Ton message arrive juste après celui de Nicolas qui réfléchissait dans la même direction, c’est très réjouissant :) [sourire]
Il y a aussi en ce moment une réflexion de fond qui vient d’être lancée sur le blog de Temesis qui mérite d’être lue.
# karl Le 25 février 2015 à 02:36
OK ma première réponse n’est pas passée. Ou j’ai peut-être oublié de pousser le bouton.
Je reprends donc ^_^ désolé pour le retard.
Nicolas :
Oui, c’est une des options que nous voulons développer (ou si quelqu’un veut s’y mettre). Il y a un ensemble d’issues ouvertes pour cela. Mais celle sur la notion de contact semble la plus proche.
QuentinC :
Oui tout à fait. L’accessibilité à sa place. D’autant plus que l’on peut considérer qu’un site qui fonctionnerait dans un cas et pas dans un autre est un problème de compatibilité Web. Là où il faut être prudent dans les rapports de bug est de décrire le problème, de l’analyser, de suggérer une solution si possible pour améliorer, mais de ne pas trop se lancer dans une leçon de morale à propos du site. Les personnes avec qui nous établissons des contacts pour corriger les sites ont probablement leur propre contrainte. Il s’agit ici de s’entraider et non de rendre honteux. Souvent la colère et la moquerie crispent la relation et rendent beaucoup plus difficile la recherche d’une solution.
QuentinC :
Pour les navigateurs. Parfois l’analyse du site révèle que le site ne fonctionne pas à cause d’un bug réel dans le navigateur ou d’une feature non implémentée. Dans ce cas, il y a plusieurs chemins possibles. Il est toujours possible de contacter le site pour signaler le problème et suggérer comment gérer l’incompatibilité. Il est également possible de lier vers le bug du navigateur s’il existe ou encore le créer si cela n’a jamais été fait. Les problèmes de Web Compatibilité nous entraîne parfois à prendre des décisions sur les navigateurs qui ne sont pas réjouissantes mais nécessaires pour le confort des utilisateurs comme l’implémentation d’une feature qui n’est pas standard.
# Karl Dubost Le 25 février 2015 à 03:48
OK ma première réponse n’est pas passée. Ou j’ai peut-être oublié de pousser le bouton.
Je reprends donc ^_^ désolé pour le retard.
Nicolas :
Oui, c’est une des options que nous voulons développer (ou si quelqu’un veut s’y mettre). Il y a un ensemble d’issues ouvertes pour cela. Mais celle sur la notion de contact semble la plus proche.
QuentinC :
Oui tout à fait. L’accessibilité à sa place. D’autant plus que l’on peut considérer qu’un site qui fonctionnerait dans un cas et pas dans un autre est un problème de compatibilité Web. Là où il faut être prudent dans les rapports de bug est de décrire le problème, de l’analyser, de suggérer une solution si possible pour améliorer, mais de ne pas trop se lancer dans une leçon de morale à propos du site. Les personnes avec qui nous établissons des contacts pour corriger les sites ont probablement leur propre contrainte. Il s’agit ici de s’entraider et non de rendre honteux. Souvent la colère et la moquerie crispent la relation et rendent beaucoup plus difficile la recherche d’une solution.
QuentinC :
Pour les navigateurs. Parfois l’analyse du site révèle que le site ne fonctionne pas à cause d’un bug réel dans le navigateur ou d’une feature non implémentée. Dans ce cas, il y a plusieurs chemins possibles. Il est toujours possible de contacter le site pour signaler le problème et suggérer comment gérer l’incompatibilité. Il est également possible de lier vers le bug du navigateur s’il existe ou encore le créer si cela n’a jamais été fait. Les problèmes de Web Compatibilité nous entraîne parfois à prendre des décisions sur les navigateurs qui ne sont pas réjouissantes mais nécessaires pour le confort des utilisateurs comme l’implémentation d’une feature qui n’est pas standard.
Vos commentaires
Suivre les commentaires :
|
