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).

En mettant à jour les guidelines pour les campagnes d'e-mailing ce matin et en vérifiant la partie ressources qui listent les liens à consulter, je suis tombé sur le sujet La genèse du SPAM, sur le site mailperformance. Je dois avouer - à ma grand honte - que je ne m’étais jamais posé la question de l’origine du mot SPAM. Voilà ce qui y est dit :

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 :

Je suis un webdesigner ! La preuve :

Chrome 7 est sorti, mais vu la quantité impressionnante de nouveautés, ils auraient mieux fait de sauter la version 7 pour l’appeler directement Chrome 8 ! Je prends le risque de publier la liste en entier, prévoyez une bonne heure de lecture :

• Des corrections de bugs
• Le parseur HTML5 mis à jour
• File API
• Possibilité d’uploader un répertoire avec <input type="file" directory>

Je suis taquin, mais l’arrivée du parseur HTML5 dans Webkit est une très bonne nouvelle pour l’interopérabilité : on a exactement le même sur Firefox ! En effet, contrairement aux précédentes versions, HTML5 définit également l’algorithme à utiliser pour construire l’arbre du document à partir de la source HTML. C’est très intéressant, car même les erreurs dans le code seront interprétées de la même manière sur tous les navigateurs !

Dans Trois couleurs le magazine d'actu des cinémas MK2, il y a une rubrique qui se nomme Le net en moins flou tenue par un certain Étienne Rouillon. Lu dans le numéro d'octobre :

HTML 5 - acronyme.
(Abréviation de l'anglais Hypertext Markup Langage (sic), langage informatique permettant de traduire des données sous forme de page web) 1. Développée par l'organisme W3C, la dernière version du HTML permet notamment d'afficher des informations numériques malgré une syntaxe impropre ou incompréhensible. « Le nouveau internet Explorer 9 intègre le HTML5 pour une navigation plus riche. » 2. Par extension, discours à la logique incompréhensible. « Je ne sais pas toi, mais quand Brice parle de CD-Roms, pour moi c'est du HTML5.»

Hum..., c'est qui ce Étienne Rouillon ?

Revoyons un peu l'intitulé des boutons de validation des formulaires... Par manque de place, l'action est souvent résumé à un simple ok ou go, ce qui peut se comprendre dans la mesure où un attribut title est présent pour préciser l'action. En revanche, lorsque la place le permet pourquoi ne pas préciser l'action lancée lors du clic sur le bouton ? Rechercher un produit pour un moteur de recherche, Mettre à jour mon profil sur la partie personnelle de votre compte sur un site, Publier l'article pour publier un article actuellement en mode brouillon dans un CMS, bref quelque chose de plus significatif que envoyer ou valider qui rendront l'interface de votre site beaucoup plus parlante pour vos utilisateurs.

Par pitié, Saint W3C, donnez-nous des sélecteurs de parents en CSS ! Cette question a été soulevée de nombreuses fois, mais pour de supposés problèmes de performances, aucune solution n’a encore vu le jour. Shaun Inman avait proposé en 2008 les « qualified selectors », qui permettent de changer le « sujet » d’un sélecteur CSS, par exemple :

a< img { background: none; }

Merveilleux, n’est-il pas ? Malheureusement, dans l’un des commentaires, Dave Hyatt (responsable du développement de Webkit, éditeur de la spécification HTML5) avait immédiatement pointé les problèmes de performances que cette solution pouvait poser. Il en profite d’ailleurs pour signaler que la majorité des sélecteurs CSS3 ne devraient pas être utilisés du tout, si l’on se préoccupe réellement des performances de nos pages. Ahem. Aujourd’hui, Remy Sharp vient de proposer une nouvelle solution, en essayant de prendre en compte les différents problèmes de performances pointés par les implémenteurs. En partant du principe que les sélecteurs sont évalués de la droite vers la gauche, il s’agit d’utiliser un pseudo sélecteur :parent sur un élément, pour indiquer qu’il faut remonter sur l’élément parent. Ce qui donnerait :

a img:parent { background: none; }

Évidemment, cette solution est plus limitée que la précédente, et peut-être un peu moins claire. Mais on s’en contenterait, non ? Pour ma part, je pense qu’avec les progrès fantastiques effectués ces dernières années en termes de performances par l’ensemble des navigateurs, nous devrions pouvoir implémenter ce genre de solutions sans pour autant plomber complètement la vitesse d’affichage d’une page. N’oublions pas que l’auteur d’une page est également responsable de la bonne utilisation des technologies qu’il utilise : il est très simple de bloquer un navigateur en JavaScript par exemple. Finalement, le problème vient peut-être du fait que CSS n’étant pas un langage de développement, le W3C à tendance à partir du principe qu’un utilisateur de CSS n’a pas à se préoccuper des performances des sélecteurs qu’il va utiliser, ce qui est complètement illusoire. Allez, je retourne mettre ma petite classe « img-link » en attendant CSS4.

Ce qui est terrible quand on est intégrateur, développeur client ou graphiste, c'est de se voir imposer une application (html+css) en entreprise dont tous les défauts vous sautent cruellement aux yeux et auront le don de vous agacer à chaque fois que vous l'utiliserez :

• design insipide et maladroit,
• images compressées à mort,
• ergonomie inexistante,
• navigation incohérente,
• montage full tableau (en 2010 !),
• double déclaration de doctype (une fois en XHTML transitional, une fois en HTML - loose.dtd, au cas où...),
• etc.

La liste est trop longue pour que je puisse énumérer chacun des points, mais tout est vrai (si si). Alors un mot à l'attention des décideurs :

1. Prenez des pros, pour réaliser vos applications,
2. Prenez conseil auprès des personnes dont c'est le métier, qui sauront vous conseiller les meilleurs choix,
3. Pensez à l'utilisabilité et l'accessibilité, une application doit être facile à utiliser, logique et utilisable par tous,
4. N'oubliez pas que vous avez les compétences en interne.

Aujourd'hui, je suis tombé par hasard sur un article qui m'a interpelé et qui m'a amené à faire deux trois recherches sur ce mécanisme appelé en anglais link prefetching. Ce système permet d'indiquer au navigateur de télécharger des images ou des documents et de les mettre en cache une fois la page chargée. L'utilisateur peut alors avoir rapidement accès à ces documents qui ont été mis en cache par le navigateur. D'après les lectures que j'ai pu faire le link prefetching en html5 serait actuellement possible uniquement avec Firefox. On imagine aisément toutes les utilisations qui pourraient en être faites... Le navigateur active ce mécanisme lorsqu'il trouve une balise HTML link ou un lien http: header avec un type de relation next ou prefetch. Exemples : <link rel="prefetch" href="/images/monimage.jpeg"> Link: </images/big.jpeg>; rel=prefetch Plus d'informations sur le sujet :

• http://davidwalsh.name/html5-prefetch
• http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-prefetch
• https://developer.mozilla.org/en/Link_prefetching_FAQ
• http://blog.whatwg.org/the-road-to-html-5-link-relations#rel-prefetch
• http://www.cloudspace.com/blog/2010/06/03/html5-link-prefetching-or-the-most-dangerous-tag/

Mozilla Labs vient de sortir un nouveau bébé, et il s’appelle Zaphod. Il s’agit d’une extension permettant, pour simplifier, de remplacer à la demande le moteur JavaScript de Firefox par un autre, Narcissus. L’originalité de ce moteur ne tient ni à ses performances, ni à ses fonctionnalités, tous les deux en-deçà de ce que propose le moteur JavaScript de Firefox. Non, son véritable atout vient du fait qu’il est écrit en… JavaScript, et sa conception se veut la plus simple possible. Ces deux éléments rendent le projet très accessible (toute proportion gardée bien entendu), et il devrait grandement faciliter les diverses expérimentations des hackers du monde entier. Vous avez toujours rêvé d’un GOTO en JavaScript ? C’est le moment de l’implémenter ! Les petits liens :

• L’annonce de l’extension Zaphod
• Le projet Narcissus
• Le code (mais si c’est simple, allons allons)