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.

• 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

Ce service n’est actuellement disponible que sur invitation (merci Guillaume ;-), mais relativement facile à se procurer (contrairement à Ffffound) et n’est accessible que si vous avez un compte Facebook ou Twitter (d’ailleurs ce côté fermé de nouvelles applis ou nouveaux sites commence à me gonfler : Facebook Connect a-t-il déjà bouffé OpenID ? (La question a été posée il y a deux ans déjà : Facebook Connect vs. OpenID: Who Will Emerge Victorious?)

A chaud et rapido, je dirais que ça me parait pas mal et me semble compléter plutôt bien Twitter pour faire de la veille ou lancer un débat (qui a dit troll ?)

Quelques blogs qui se sont penchés sur le sujet :

• 10 astuces pour bien débuter avec Quora
• Tout savoir sur Quora
• Quora, un réseau social condamné à rester confidentiel ?
• Pourquoi Quora plait-il aux blogueurs ?
• Les dilemmes de Quora

Au cours de l’année 2010, le magazine Designers Interactifs a mené une enquête en ligne auprès des professionnels du web à laquelle ont participé 1449 personnes. En tant que participant, j’ai reçu la synthèse de ce sondage en fin de semaine dernière.

Les métiers représentés dans ce document sont :

Architecte de l’information, chef de projet, designer d’interaction, designer et développeur flash, développeur front-office, développeur web, directeur artistique, directeur de création, ergonome web, motion designer, webdesigner, webmaster, designer sonore.

Ce qu’il faut retenir de cette synthèse, c’est que :

• plus de la moitié des «designers interactifs» (sous cette dénomination, on retrouve tous les métier énumérés plus haut) ont moins de 30 ans.
• l’activité est concentrée à 59% dans la capitale.
• le turn-over est élevé : 59% des personnes sont dans leur poste depuis moins de 3 ans.
• le métier se féminise : 34% en 2010 contre moins de 30% en 2008 et 2009.
• environ 30% exercent leur métier en tant que freelance.
• l’activité est concentrée dans des petites structures (39% travaillent dans des sociétés de 1 à 5 collaborateurs).

Les tendances qui se dégagent : émergence d’html5 et des technologies mobiles, nécessaire polyvalence des designers, manque de reconnaissance du design et manque de maturité des entreprises.

Pour la question des salaires. Un intégrateur ou développeur front office gagne en moyenne entre 29 et 39 keuros par an selon son degré d’expertise. La journée en freelance se monnaie entre 350 et 400 euros.

Tous les détails et graphiques de cette synthèse sont disponibles sur le site des designers interactifs. (Il faut être membre pour y avoir accès. Un slideshow permet de voir les 11 premières pages).

Le mot SPAM trouve son origine dans un sketch des Monty Python dans lequel le même mot, désignant un jambon en boîte de basse qualité, envahit la conversation et le menu d’un petit restaurant. SPAM est l’acronyme de Shoulder of Pork and hAM (épaule de porc et jambon), ou Spiced Pork and hAM (porc épicé et jambon), Spiced Pork And Meat, SPiced hAM. Le sketch parodiait une publicité radiophonique pour le SPAM, pendant laquelle le terme était répété inlassablement au point de perturber la conversation des autres acteurs.

Damned ! les Monty Python(s) ! Comment ai-je pu y échapper ? Est-ce qu’alzheimer me guette ? Et aurais-je enfouis ce sketch et cette information dans les tréfonds de ma mémoire ? Toujours est-il que ce sketch est tout simplement hilarant et que je ne peux m’empêcher de le partager avec vous aujourd’hui :

Le credo de «A book apart» est d’éditer de courts ouvrages sur un sujet précis destiné aux personnes qui font des sites web. Le premier de cette série est intitulé «html5 pour les web designers» et comme son nom ne l’indique pas – relançons le débat une fois de plus – est plutôt destiné aux personnes qui font du code et donc plutôt les intégrateurs html ou développeurs client.

En moins de 100 pages l’essentiel est abordé. Si vous aviez besoin d’une mise à jour rapide sur le sujet, voilà le livre qu’il vous faut. C’est également le livre que vous pouvez laisser traîner négligemment sur votre bureau ou prêter à vos amis qui ne sont pas «web designer», – franchement 89 pages ça se lit vite.

L’ouvrage passe rapidement sur les débuts du html – au passage, merci de noter qu’html 1.0 n’a jamais existé – pour s’intéresser aux différences de balisage entre html5 (attention html5 et pas html 5) et ses versions précédentes (html 4.01, xhtml 1.0), les medias riches, les webforms et la sémantique, sans oublier le dernier paragraphe qui pose (répond à) la question qui est pas mal revenue ces derniers temps : peut-on utiliser html5 dès aujourd’hui et si oui comment ?

J’ajouterai que le plus grand soin a été apporté à la conception et la mise en page de cet ouvrage qui en font un objet très agréable à consulter. A un prix aussi dérisoire on aurait tort de s’en priver !

Chaque fois que vous créez un site web, vous contribuez à l’héritage culturel commun à tous les êtres humains. En choisissant l’HTML5, vous contribuez aussi au futur.

Si vous ne vous sentez pas investi d’une mission digne d’un super-héros après ça !

En vente dans toutes les bonnes librairies.

Auteur : Jeremy Keith
Editeur : Eyrolles
Collection : A Book Apart
Traduction de : Html5 for webdesigners
Nombre de pages : 98 pages (mais en fait 89)
Date de parution : 30/09/2010
Prix : 12 euros

Il existe de nombreuses guidelines publiques comme par exemple les guidelines d’accessibilités du W3C (WCAG), mais les guidelines du site internet d’une entreprise restent en général interne à l’ entreprise et sont estampillés «document confidentiel» et donc à ne pas divulguer.

Aujourd’hui je me suis penché sur les guidelines de la BBC qui sont complètement accessibles à tout le monde sur leur site internet http://www.bbc.co.uk/guidelines/.

Vous pourriez vous poser la question «pourquoi ?» si vous n’aviez pas été devancé par l’introduction de la page d’accueil qui indique :

Cette page vous donne accès aux méthodes, standards et guidelines de la BBC et est destinée principalement à ceux qui entreprennent ou qui souhaitent entreprendre des travaux pour la BBC en tant que fournisseur.

(This page links you to BBC policies, standards and guidelines, and is intended primarily for those undertaking or wishing to undertake work for the BBC as a supplier.)

3 types de guidelines : Editoriales, Qualité, Développement Web. Nous allons nous intéresser aux dernières.

On y retrouve par ordre :

1. Les guidelines d’accessibilité versionnées et indiquant clairement le degré d’obligation d’appliquer ces recommandations : MUST, MUST NOT, SHOULD, en majuscule et gras, difficile de faire plus clair.

On y retrouve la plupart des thématiques nécessaires pour faire un site approchant d’un degré d’accessibilité satisfaisant (ceux qui s’y sont déjà essayé savent qu’il est très dur voire quasi impossible de faire un site complètement accessible).

2. Les guidelines éditoriales et graphiques : Le premier lien renvoie vers le site GEL (Global Language Experience) où vous trouverez tout ce qui concerne le design, la typo, la construction des pages. Difficile de faire plus complet.

Le fichier pdf de la charte est téléchargeable : http://www.bbc.co.uk/guidelines/gel/downloads/GEL_styleguide.pdf (pdf – 272ko). Si vous n’avez pas compris l’utilité ou le fonctionnement d’une grille pour structurer vos pages, ce document est pour vous. Tout est très bien expliqué et documenté.
Je vous recommande vivement de jeter un coup d’œil ensuite sur le document : Mobile Design Guidelines v1.1 (pdf – 5,5mo), vraiment très instructif, qui explique comment concevoir l’interface de la version mobile d’un site.

3. Je passe rapidement sur Infrastructure, Policy et Red buttons (au passage le fichier est endommagé…), pour me concentrer sur la partie Technical. Vous y trouverez toutes les préconisations pour l’optimisation et le poids des pages, les règles à suivre pour les emails, le support des navigateurs, etc..

Bref je vous conseille d’aller faire un tour sur ce site qui est vraiment une source d’inspiration pour la rédaction des guidelines à suivre pour votre site internet.

J’en profite pour ajouter quelques exemples de guidelines que j’ai pu trouver en cherchant un peu :

- Oquast best practices
- YSlow User Guide
- Centre d’aide de Google pour les webmasters
- UI Guidelines for mobile and tablet web app design
- Guidelines pour designer sur téléphone mobile
- Email design guidelines de Campaign monitor

Toutefois mes préférées restent quand même les Christopher Doyle Guidelines (pdf – 1mo)…

La preuve :