Aujourd’hui, la grande majorité des sites est encore conçue et construite par des généralistes de talent, et il n’y a absolument rien de mal à cela. C’est juste que certains des sites les plus importants et les plus complexes requièrent des équipes composites de spécialistes sur un domaine précis. Des experts en catégorisation des informations, en interaction homme-machine ou en conception d’interface. Ils ont également besoin de personnes qui se spécialisent dans des langages de programmation spécifiques, bases de données, sécurité ou architecture des applications. L’histoire de tout progrès humain peut être mesurée par la spécialisation d’individualités au sein d’un groupe, et je vois cela comme une bonne chose.

Nous avons donc ce paradoxe étrange que le terme webdesign puisse être utilisé à la fois pour décrire un novice et un expert, un néophyte et un maître. C’est là que l’effet Dunning-Kruger entre en jeu. Si vous n’êtes pas familier avec ce concept c’est l’observation que les novices souffrent de l’illusion de supériorité et ont tendance à sur-évaluer leurs compétences par rapport à celles des experts parce qu’ils ne comprennent pas pleinement l’ampleur du champ qu’ils doivent maîtriser. Ou pour utiliser un aphorisme souvent cité, «ils savent ce qu’ils savent, mais ils ne savent pas ce qu’ils ne savent pas ». Par comparaison, les experts ont tendance à en savoir plus, mais sont aussi plus conscients de ce qu’ils ne savent pas, ce qui a pour conséquence de les rendre moins sûrs de leur expertise.

NDR :

L’effet Dunning-Kruger décrit un phénomène selon lequel les moins compétents dans un domaine surestiment leur compétence alors que les plus compétents auraient tendance à sous-estimer leur niveau de compétence.

Se référer à l’article wikipedia qui décrit les observations qu’on pu faire David Dunning et Justin Kruger : Effet Dunning Kruger.

En résumé :

1. la personne incompétente tend à surestimer son niveau de compétence,
2. la personne incompétente ne parvient pas à reconnaître la compétence dans ceux qui la possèdent véritablement,
3. la personne incompétente ne parvient pas à se rendre compte de son degré d’incompétence,
4. si un entraînement de ces personnes mène à une amélioration significative de leur compétence, elles pourront alors reconnaître et accepter leurs lacunes antérieures.

La chaîne des prototypes, le contexte d’exécution, l’objet d’activation, le scope, les closures, tout y est expliqué de manière précise et exacte, ce qui est malheureusement assez rare quand il s’agit de JavaScript.

C’est ici : Voyage au coeur de JavaScript.

Et si l’anglais ne vous rebute pas, je vous invite également à lire l’ensemble de la série ECMA-262-3 in detail (autrement dit ECMAScript 3) par Dmitry Soshnikov.

• Bug 13240 – Consider replacing <time> with <data>
• Why no <time>?
• Goodbye datetime, and pubdate. Hello data and value
• Goodbye HTML5 <time>, hello <data>!
• End of <time> Is Not Helping the Case for HTML5

Depuis le compte du client, quand tu cliques sur telle partie, une phrase en hollandais se transforme en norvégien.

(NDR : Se transforme ?)

Quand on clique sur tel bouton, un message d’erreur est censé apparaitre, là il n’apparait pas.

(NDR : quel message ?)

Apparemment il y un problème sur telle page, je pense qu’il doit manquer un morceau de JS [...]

(NDR : « apparemment », « je pense »)

Telle page est cassée sur tous les navigateurs.

Le montant apparaissant sur telle page pour le produit est complètement bidon, le montant total est ok.

(NDR : bidon, hum… »)

Le site est instable sur Internet Explorer, pouvez-vous regardez ? C’est assez problématique.

(NDR : oui, mais encore ?)

Quand on clique sur le carousel, ça donne le tournis, vous pouvez faire quelque chose ?

Laisse tomber, le temps de faire le screenshot, le bug a disparu.

La palme revenant à une remontée d’un bug critique de fonctionnement d’ajout au panier d’un site non identifié (qui s’avèrera être finalement en phase de développement…)

Qu’est-ce qu’il ressort de tous ces exemples ?

1. La description du bug est floue et imprécise.
2. Le rapport a été fait dans la précipitation.
3. Le demandeur ne s’est pas attardé sur le sujet et la plupart du temps se fait le relais du client sans plus d’analyse.
4. Les étapes pour reproduire le bug ne sont pas indiquées.
5. Sur quelle plateforme ? Quel navigateur ? Quelle version ? Où ? Comment ? La plupart du temps on n’en sait rien. Pour le dernier exemple on ne sait pas quel site est concerné.

Les conséquences pour l’intégrateur ou le développeur sont claires : en plus de devoir corriger le bug, il devra la plupart du temps faire un premier travail d’enquête, essayer de comprendre la syntaxe approximative des rédacteurs et s’assurer de la reproductibilité ou de la réalité du bug. Combien d’échanges du type :

• Non moi j’ai rien, tout fonctionne correctement
• Bah, chez moi j’ai toujours le problème
• T’es sur ? c’est quelle version de navigateur ?
• etc.

Comment éviter tout ça ?

Simplement en suivant quelques règles :

1. Vider le cache du navigateur avant toute chose.
2. S’assurer de la réalité du bug.
3. Prendre 10 à 30 minutes pour faire un raport de bugs correct.
4. Soigner la rédaction. Inutile d’utiliser du pseudo-langage technique ou marketing qui la plupart du temps n’est compris que du demandeur.
   Mettez vous d’accord sur un glossaire qui facilitera les échanges. Doit on dire select, droplist, dop-down pour une liste déroulante ?
5. Rester factuel : « j’ai constaté… » action/réaction.
6. Si vous devez travailler avec des développeurs et/ou intégrateurs, vous devez avoir un minimum de connaissances : html, css, php, ça doit vous
   parler un minimum. Rien ne vous empêche d’être curieux ou de discuter avec le technicien qui se fera un plaisir de vous expliquer.
7. Reproduire le bug et en décrire toutes les étapes avec précision ainsi que sa fréquence.
8. Indiquez toutes les informations qui seront utiles pour le constat du bug : version du navigateur, plateforme, lien pour accéder de la page concernée, screenshot si nécessaire.
9. Indiquer la sévérité du bug, inutile de mettre tout en urgent, ce ne sera pas traité plus rapidement et vous risquez de voir des bugs mineurs,
   résolus avant des bugs bloquant des fonctionnalités plus importantes sur le site.
10. Relire le rapport avant de l’envoyer (soigner l’orthographe et la rédaction).

Il n’est pas interdit également de se déplacer et de faire une démonstration en direct du problème ce qui peut s’avérer quelques fois plus rapide que des échanges interminables de mails ou de commentaires. Vous pouvez aussi faire une petite vidéo des actions provoquant le bug, certains logiciels comme CamStudio (au hasard) permettent de capturer les mouvements effectués sur votre écran d’ordinateur.

Quelques articles sur le sujet :

Apprendre à rapporter un bogue
Les bugs mystiques
Comment signaler efficacement un bug

Comme le nom l’indique, il y sera question de traiter de la qualité web, selon plusieurs points de vue : webdesign, accessibilité, développement front-end, suivi de qualité web, etc.

Pour commencer, plusieurs intervenants tentent de définir ce qu’est la qualité web, et c’est déjà pas mal !

À suivre ici : http://w3qualite.net/

(enfin, dès qu’un flux RSS sera disponible ;-)

Grossièrement il s’agit d’un langage objet « classique », qui à première vue ressemble beaucoup à Java : des classes, un typage statique (optionnel), et d’autres choses intéressantes. Je vous laisse découvrir ses fonctionnalités plus en détail sur la page de présentation du langage. Sa conception a été orientée vers les performances, la sécurité, et les outils de développement. Il disposera d’une machine virtuelle qui sera intégrée dans les navigateurs qui voudront le supporter (et pourquoi pas ailleurs, comme sur le serveur), et d’un compilateur vers JavaScript pour la compatibilité (un peu comme CoffeScript).

Il y a environ un mois, un mail interne datant de novembre 2010 avait été publié sur le web. Je vous en cite quelques extraits (il s’appelait alors Dash), puisque ces prises de position n’apparaissent pas sur le site du nouveau langage (les emphases sont de moi).

The goal of the Dash effort is ultimately to replace JavaScript as the lingua franca of web development on the open web platform. We will proactively evangelize Dash with web developers and all other browser vendors and actively push for its standardization and adoption across the board. This will be a difficult effort requiring finesse and determination, but we are committed to doing everything possible to help it succeed.

Au cas où un doute subsisterait, le contexte est posé : le but est clairement de remplacer JavaScript.

Why are you circumventing the standards process? We fully intend to cooperate fully with standards processes–the problem is that the current standard processes are limited to Javascript, which is not viable in the long term. Any effort with the historic baggage that Javascript has will be extremely limited. We need to make a clean break, make progress, and then engage the community.

Google ne croit pas à « l’innovation ouverte ». Ils préfèrent concevoir en secret, puis commencer à discuter avec la communauté pour en faire un standard lorsque le langage est terminé.

What will Google developers be using? We will strongly encourage Google developers start off targeting Chrome-only whenever possible as this gives us the best end user experience. However, for some apps this will not make sense, so we are building a compiler for Dash that targets Javascript (ES3). We intend for existing Google teams using GWT and JSCompiler to eventually migrate to the Dash compiler.

Nous le savions déjà, mais les services de Google seront de plus en plus rapides et avancés dans Chrome, car il y aura des optimisations spécifiques pour ce navigateur. Chrome interprètera donc du Dart dans les futurs services de Google, tandis que les navigateurs qui ne supportent pas le langage auront du Dart compilé en JavaScript.

Le remplacement de JavaScript n’est pas ce qui me gène le plus dans cette histoire. Cette nécessité est certes discutable, car JavaScript est en train d’évoluer très rapidement avec le projet Harmony, mais toutes les nouvelles idées sont bonnes à prendre.

Ce qui est très dérangeant en revanche, c’est cette tendance de plus en plus présente chez Google à faire les choses de son côté, et à bénéficier de fait d’un avantage technologique sur ses concurrents.

Brendan Eich, concepteur du langage JavaScript et travaillant actuellement sur le projet Harmony (le futur de JavaScript), est évidemment fortement hostile à ces méthodes de conception. Si vous souhaitez connaître son avis sur le sujet, je vous invite à lire ce fil de discussion sur Hacker News, dans lequel il y explique son point de vue. Selon lui, les concepteurs du langage Dart n’ont pas connaissance des évolutions futures de JavaScript, puisqu’aucun n’a participé à Harmony.

Pour terminer, il ne faut jamais perdre de vue que les standards du web ne gagneront jamais définitivement : c’est un combat qu’il faut mener en permanence pour maintenir l’équilibre entre innovation et standardisation.

En voici quelques-unes que je vous recommande, toutes sont hebdomadaires :

• JavaScript Weekly
• HTML5 Weekly
• Web Design Weekly
• Hacker Newsletter (sélection de posts Hacker News)

Si vous en connaissez d’autres, n’hésitez pas à les indiquer dans les commentaires !

Cette histoire vous rappellera peut-être celle de _why, qui est très similaire. Et comme pour _why, des miroirs ont tout de suite été mis en place pour que ses travaux restent accessibles à tous.

Une partie du compte GitHub : https://github.com/diveintomark
Dive Into HTML5 : http://diveintohtml5.ep.io/
Dive Into Python 3 : http://diveintopython3.ep.io/

L’outil de création ultime, le « Flash du web », n’est pas arrivé, et tous les regards se tournent évidemment vers Adobe. À la différence d’un outil dédié au Flash Player, la création d’un outil pour le web est beaucoup plus complexe, car il s’agit d’un « environnement ouvert ». Les technologies permettant l’animation sur le web sont nombreuses et très différentes.

HTML

Il est bien sûr possible d’animer les éléments HTML en JavaScript, comme cela se fait depuis des années. On définit un timer, et on modifie des propriétés CSS au fil du temps. Il est aujourd’hui possible de profiter des optimisations que le navigateur peut proposer, avec la méthode window.requestAnimationFrame.

CSS peut également être directement utilisé pour animer les éléments d’une page, et il n’est pas rare de combiner plusieurs modules :

• Pour l’apparence, l’ensemble des propriétés CSS, ainsi que CSS 2D Transforms et CSS 3D Transforms.
• Pour les animations elles-mêmes, CSS Transitions et CSS Animations.
• …et les shaders arrivent. Devinez qui a fait cette proposition et l’a implémentée ? Adobe bien sûr !

SVG

Pour animer du SVG, il y a également plusieurs possibilités : du simple JavaScript, comme pour les éléments HTML (les éléments SVG sont intégrés de manière transparente au document HTML). Ensuite, l’ensemble des technologies CSS citées pour le HTML peuvent (ou pourront) également être utilisées pour le SVG. Enfin, SVG peut utiliser une technologie d’animation spécifique, SMIL.

Rappelons qu’Adobe a misé sur cette technologie autrefois, mais ils ont arrêté le développement de leur plugin SVG après le rachat de Macromedia ; peut-être préparent-ils leur grand retour sur cette technologie ?

Canvas

Canvas (2D) est une zone de pixels qui peut être directement dessinée en JavaScript, on ne manipule plus de document comme en HTML ou SVG. Les animations se font donc directement avec JavaScript, mais là aussi, il est possible d’utiliser window.requestAnimationFrame pour optimiser ces animations.

WebGL

WebGL, ou Canvas 3D, c’est le roi. Cette technologie permet de dialoguer directement avec la carte graphique, à l’aide d’une API OpenGL simplifiée (WebGL donc). C’est toujours l’élément canvas qui est utilisé, nous avons donc une zone de pixels qui n’attendent plus qu’à être dessinés !

Les outils

Vous le voyez, il existe beaucoup de technologies très différentes, et elles peuvent interagir les unes avec les autres. C’est toute la puissance du web ! Mais cette puissance est difficile à maîtriser, et il est nécessaire de revoir la plupart des concepts proposés (notamment par Flash) ces dernières années pour l’exploiter efficacement. Un seul outil ne peut pas se charger de tout, et il faudra certainement passer d’un outil spécialisé à un autre selon les technologies utilisées.

Chez Adobe, pour l’instant, nous avons une pré-version du logiciel Edge, en cours de développement, qui permet d’animer des éléments (CSS transitions) et même d’ajouter des actions (fonctions JavaScript), mais il y a encore beaucoup de travail pour passer d’un petit outil d’animation simple à quelque chose de beaucoup plus riche, comme la partie animation de Flash. Toujours dans les labs d’Adobe, nous avons également Muse, qui permet de créer des pages web sans écrire une ligne de code. Pas de gestion des animations, et la version actuelle déçoit un peu, en passant complètement à côté de la sémantique.

Sencha (ExtJS, Sencha Touch) vient de sortir la version finale de son outil d’animation CSS, Sencha Animator. Les démonstrations me semblent très prometteuses, mais l’outil se positionne sur le mobile, et se limite volontairement au support de Webkit pour cette raison, dommage.

Animatable semble également très intéressant, mais la sortie du soft (qui sera disponible sous la forme d’une application web) commence à se faire attendre.

Pas grand chose à ma connaissance pour créer de manière graphique du Canvas 2D ou du WebGL. Ces technologies sont très différentes de HTML et SVG puisqu’elles ne reposent pas sur la manipulation de documents. Je les vois beaucoup plus s’orienter vers un outil complet de type IDE, ou vers des environnements dédiés à certaines librairies (et là je rêve d’un IDE basé sur three.js).

Je n’ai pas mentionné les librairies JavaScript dédiées à l’animation, évidemment nombreuses, mais certaines offrent des approches intéressantes qui pourraient servir de base pour la création d’outils. J’ai notamment été bluffé par d3.js, qui s’affranchit (presque, puisque l’outil tourne essentiellement autour de la manipulation d’attributs et d’éléments) de la technologie de rendu utilisée pour permettre d’exploiter des données dans le cadre de visualisations. Il est ainsi très facile de passer de SVG à HTML/CSS, puisque l’outil fournit l’animation, les états, les manipulations de données, mais ne se préoccupe pas de la manière dont les changements de style vont être appliqués pendant l’animation. Il est tout de même possible d’utiliser un ensemble d’aides pour manipuler le SVG, mais c’est totalement optionnel.

Voilà, un peu en vrac, ce que j’avais en tête sur le sujet. N’hésitez pas à indiquer d’autres outils dans les commentaires (j’en ai certainement oublié un paquet !), et à partager vos idées sur les évolutions récentes et à venir de nos outils.