Illustration issue du site de Gonglue Jiang (jianggonglue.com)

Pour la faire courte, un jeune designer devait “designer” un humidificateur d’air et à fini par en faire un pot de fleur avec une fausse plante dedans qui semble se faner au fur et à mesure que l’humidificateur se vide. Quand la fleur est totalement fanée, ça veut dire qu’il faut remettre de l’eau dedans. Simple, clair, efficace, intuitif et même… émotionnel…

Voilà, c’est ça un vrai design produit.

Regardez un peu toutes les étapes du processus et dites-moi à quel moment le mec s’est contenté de dire “ça serait trop fun d’en faire un faux pot de fleur !”…

MAIS ! Je ne parts pas sans une petite compensation…

Voilà un tutoriel Adobe qui explique comment éviter que les pixels de vos créations Illustrator exportées en bitmap ne “bavent”. En gros sous Illustrator CS4 c’est très chiant et sous CS5 il y a une fonction magique pour ça…

La société où je travaille, Profideo, a pour site grand public principal un comparateur d’assurance-vie.

Comme c’est un site grand public, notre principale source de trafic vient du référencement dans les moteurs de recherche (et donc en très grande majorité de Google). Du coup nous portons une grande attention à cet aspect et essayons constamment d’optimiser nos pages pour que leur classement monte dans les moteurs (on appelle ça du SEO, “Search Engine Optimisation”). Je m’occupe de l’optimisation des pages et mon collègue, Matthieu, s’occupe de l’aspect “back-linking” et partenariats.

C’est une jolie victoire que je souhaite partager avec vous aujourd’hui, car nous sommes passés en première page des recherches sur le mot clé “assurance vie” ! Pour l’anecdote, certaines sociétés de conseil en référencement (dont je tairais le nom…) nous avaient annoncé que c’était impossible d’apparaître en première page sur un mot-clé aussi concurrentiel.

Comme quoi, rien n’est impossible

PS : En fait je viens de voir qu’on se balade en fonction de l’heure entre le bas de la première page et le haut de la deuxième… Mais on est encore loin d’avoir épuisé toutes nos cartes !

Page d'accueil du comparateur d'assurance-vie

Mise à jour – 28 avril 2010 :

Depuis la rédaction de cet article, le site comparateur d’assurance-vie est monté en 5 place sur la recherche “assurance vie”…

Par ailleurs, les comparateurs des autres gammes que nous sommes en train de lancer sont tous soit déjà positionnés en première page, soit en passe de le devenir, sur leurs principaux mots-clés respéctif :

• “assurance vie”
  => 1ère page (5ème place)
  => http://assurance-vie.lesdossiers.com/
• “madelin”
  =>  1ère page
  => http://comparateur-retraite-loi-madelin.lesdossiers.com/
• “compte titres”
  => 1ère page
  => http://comparateur-compte-titres.lesdossiers.com/

Jeudi dernier la société Globalis organisait un petit déjeuner intitulé “Contexte et enjeux de l’optimisation FrontEnd” auquel j’ai participé.

L’optimisation FrontEnd est ici comprise essentiellement comme un moyen d’accélérer la vitesse de chargement d’une page Web, d’un point de vue technique (temps de chargement global), mais aussi du point de vue de la vitesse ressentie par l’utilisateur (attente avant début d’affichage des premiers éléments par exemple).

Je vous propose un petit résumé de cette conférence agrémenté de quelques remarques personnelles.

Les gens de Globalis ont eu la sympathie de m’envoyer le fichier PDF de leur présentation et m’ont autorisé à le publier sur ce blog : Présentation Globalis : Contexte et enjeux de l’optimisation FrontEnd

Présentation du contexte

La société Globalis :

• 13 ans d’expérience
• Spécialiste PHP
• 25 experts
• Créateur de PHPIndex

Pourquoi optimiser la vitesse des pages ?

• Améliorer l’agrément et la qualité perçus par l’utilisateur
• Le temps d’affichage des pages est pris en compte par Google pour le référencement
• L’aspect Green IT

Remarque : c’est bien la première fois que j’entend parler du Green IT comme argument pour optimiser la vitesse d’affichage des pages. Perso, je pense qu’on est très très loin de voir des entreprises se soucier de l’environnement dans la mise en œuvre d’un site Web !

Remarque 2 : JP vient de me faire remarquer un article de Search Engine Land qui confirme et détail la prise en compte de la vitesse des pages dans le rankink de Google. Vous pouvez aussi voir la déclaration officielle sur le blog de Google.

Où l’effort doit-il porter ?

• Si les pages d’un site ne s’affichent pas assez vite, il est tentant pour certains décideurs de se contenter de “mettre de plus gros serveurs”. Plus concrètement, essayer d’optimiser les ressources hardware qui, par nature, sont très facilement interchangeables.
• Concrètement ce n’est pas forcément la meilleure solution pour un site. Surtout que les problèmes de lenteur proviennent plus souvent aujourd’hui du client (ordinateur, connexion et navigateur de l’internaute) que du serveur (le serveur n’envoi pas immédiatement les données car ils prend du temps à les calculer ou à les récupérer dans une base…)
• Il est donc souvent plus efficace de revenir sur la conception d’un site que d’essayer de gagner quelques millisecondes sur le temps de réponse du serveur.

Remarque : je suis assez d’accord avec ce constat, même si ça n’empêche pas certaines applications Web d’être mal développées côté serveur et de répondre plus lentement qu’elle ne devraient (code qui n’optimise pas ses requêtes SQL par exemple). On ne parle pas non plus, bien entendu, des sites sous-dimensionnés (trop de visiteurs simultanés) victimes de leur succès…

Quelques chiffres éloquents

Les pages sont en moyenne 10 fois plus lourdes aujourd’hui qu’il y a 15 ans !

• 1995 : 25 ko / 5 ressources appelées dans la pages (images, feuilles de styles…)
• 2010 : 250 ko / 42 ressources

79% des internautes considèrent qu’une page est trop lente si elle prend plus de 2 secondes à charger.

Google Maps a amélioré sa vitesse d’affichage de 30% en passant de 100 ko à 70 ko.

On considère qu’on a un gain significatif à partir de 100ms. C’est le temps minimum de chargement de chaque requête faite par le navigateur, quelque soit le type et le poids de la ressource chargée ! Il est facile de comprendre alors que le premier conseil d’optimisation est de diminuer au maximum le nombre de requêtes…

Conseils d’optimisation

3 grands axes d’optimisations :

• Diminuer le nombre de requêtes
• Alléger le poids des ressources
• Améliorer la vitesse ressentie par l’utilisateur

Diminuer le nombre de requêtes

• Paramétrer le cache des ressources statiques pour qu’elle ne soit pas rechargées par le navigateur inutilement
• Utiliser la technique des sprites en CSS pour factoriser les images
• Packager les ressources => regrouper les fichiers CSS en un et les fichiers JS en un. Il y a des outils pour automatiser ça

Alléger le poids des ressources

• Utiliser la compression GZip (via un module Apache ou un paramétrage PHP) peut réduire jusqu’à 80% la taille d’une ressource statique
• Utiliser le format adapté pour les images (plutôt JPG pour les photos, PNG pour les graphismes avec des aplats…)
• Packager les ressources => les outils de packging permettent aussi de “minifier” (ou compacter) les fichiers pour en réduire la taille (la librairie javascript jQuery passe de 155 ko à 25 ko en version packagée…)
• Diminuer la taille des cookies (je suis très dubitatif là-dessus)
• Eviter d’utiliser des cookies pour les ressources statiques (une solution pour cela est d’utiliser un sous-domaine spécifique qui n’utilise pas de cookies pour appeler ces ressources)

Améliorer la vitesse ressentie par l’utilisateur

En gros, ça revient à démarrer l’affichage de la page le plus vite possible.

• Afficher la page dès le début du parsing HTML (peut de gens s’en souviennent, mais c’était une des raisons “pratiques” de ne pas utiliser les tableaux HTML pour la mise en forme d’une page, car certains navigateurs n’affichent pas un tableau tant que son contenu n’a pas été chargé complètement…)
• Charger les scripts en bas de page (au lieu de la balise head…) (perso je ne trouve pas ça très propre et je préfère les solutions telle que l’injection DOM qui permettent de paralléliser les chargement JS sans affecter celui de la page)
• Ne pas utiliser de “filtres” tels que les fichiers HTC pour Internet Explorer (ils en existe pour gérer les PGN avec couche de transparence alpha par exemple), car ils ralentissent beaucoup l’interface (ils sont notamment recalculés lors d’un simple scroll…)
• Précharger les ressources quand c’est possible (la page d’accueil Google contient par exemple une image utilisée avec la technique des sprites pour des éléments graphiques qui ne sont utilisés que dans les pages de résultats)
• Technique de “post-load” (j’ai pas trop creusé le sujet, il a des plugins pour ça…)
• Paralléliser les téléchargement (notamment pour les images, IE6 par exemple ne sait charger que 2 images à la fois sur un même domaine. Une solution complexe à mettre en œuvre consiste à utiliser 2 ou 3 sous domaines différents pour les images…)

Conclusion

Les deux “experts” qui ont fait l’essentiel de la présentation lors du petit déjeuner semblaient assez jeunes (ce qui n’est pas un défaut en soit ! :p) et étaient très enthousiastes vis à vis de ces techniques d’optimisation…

Ils avaient bien raison, car dans le fond leur propos est juste et le panel de techniques d’optimisation évoqué semble correspondre à l’état l’art aujourd’hui.

Néanmoins je relève qu’ils ont très peut parlé des problèmes de mise en œuvre de ces techniques dans des contextes réel.

Grossièrement, pour avoir une bonne checklist de toutes ces techniques, il suffit d’utiliser le plugin YSlow de Yahoo! (se prononce “Why slow ?”). Il s’agit d’un plugin pour Firebug qui est lui-même un plugin Firefox (véritable “must have” pour les Webdesigner). YSlow analyse la page et lui donne une note basée sur la prise en compte des techniques d’optimisation Frontend recommandés par Yahoo. Ces techniques recoupent en majeur parties celles évoquées lors du petit déjeuner de Globalis.

Le problème aujourd’hui n’est donc pas tellement de savoir quoi optimiser, mais plutôt de savoir le faire efficacement et dans la durée.

Je pense que j’ai pas mal soulé nos hôtes ce matin là en insistant beaucoup par exemple sur la technique des sprites CSS qui est effectivement idéal pour un site dont les images ne bougent pas trop, mais ça devient une autre paire de manche de l’utiliser sur un site mis à jour fréquemment… J’ai eu l’expérience par exemple d’un site où toutes les images au départ étaient des sprites, mais par la suite on s’est mis a ajouter des images petit à petit (un bouton par ci, un visuel par là…). Et comme le travail se fait souvent dans l’urgence, on n’a pas toujours pris la peine d’incorporer la nouvelle image (ou l’image mise à jour) dans la composition de sprite globale. On tend donc à perdre les bonnes habitudes et, en l’occurrence, à augmenter petit à petit le nombre de requêtes par page…

J’en retiens donc qu’il faut bien se pencher sur les techniques automatisables (comme le packaging des fichiers), mais qu’on manque un peu de maturité pour les autres techniques, comme les sprites ou le chargement des images via des sous-domaines distincts.

Et vous ? Utilisez-vous des techniques d’optimisation Frontend ? Si oui lesquelles ? Rencontrez-vous des difficultés ? Connaissez-vous d’autres techniques ?

N’hésitez pas à participer avec vos commentaires !

On me pose souvent des questions sur certaines bonnes-pratiques javascript assez récurrentes en partant de l’utilisation d’une librairie telle que jQuery. C’est pourquoi je profite d’une de ces questions posée récemment (merci Gilles) pour faire un article sur le sujet.

Donc voici les différentes étapes assez systématiques par lesquelles je passe quand je dois entamer un développement javascript dans une page.

1. Charger jQuery

Je passe rapidement sur cette étape, vous pouvez directement l’appeler depuis le serveur de jquery.com ou le copier dans le répertoire local du site.

<script type="text/javascript"
  src="http://code.jquery.com/jquery-latest.pack.js"></script>

2. Créer un fichier javascript et le charger dans la page

On ne le redira jamais assez : ne mettez pas de balises <script> dans vos pages ! Préférez un fichier à part du genre monScript.js cela vous permettra de bien séparer les choses. Ici je pars du principe que vous avez un dossier js à la racine du site dans lequel vous mettez ce genre de fichier.

<script type="text/javascript" src="/js/monScript.js"></script>

3. Préparer le fichier javascript

A la longue, mes fichiers javascripts finissent par avoir toujours la même structure… En l’occurence, je commence toujours par écrire les quelques lignes suivantes

(function($){

  $(document).ready(function(){
    // Méthodes exécutées au chargement du DOM
  });

})(jQuery);

a. Englober tout le code dans une fonction anonyme

Ce morceau de code peut déjà sembler complexe à certains, mais une fois décortiqué il se comprend très bien. Dans un premier temps, on crée ce que l’on appelle une fonction anonyme, c’est à dire une fonction qui n’a pas de nom :

function(){ /* contenu de monScript.js */ }

Le but va être de “ranger” tout le code du fichier à l’intérieur de cette fonction. L’avantage est énorme, car grâce au principe de champ d’application des variables et des objets en javascript, tout ce que nous allons faire dans cette fonction ne pourra pas venir perturber d’autres scripts éventuels chargés dans la même page. Par exemple, fini les fonctions avec des noms à rallonge pour être sûr qu’aucune autre n’aura le même nom.

Le problème à ce stade, c’est qu’une fonction (anonyme ou pas) ne s’exécute pas d’elle-même, pour l’exécuter, il faut qu’elle soit appelée. Ainsi, dans le code suivant, la première ligne sert à déclarer la fonction, la deuxième à l’appeler :

var toto = function() { alert("toto") };
// => Pour l'instant rien ne se passe...

toto();
// => Là ma page affiche l'alerte, car la fonction toto est exécutée

La subtilité avec une fonction anonyme c’est justement qu’elle n’a pas de nom ! Mais ce n’est en fait pas un problème, car en javascript vous pouvez considérer que n’importe quel bout de code entre parenthèse est un objet en soit (ou une variable pour faire simple). Du coup, on peut à la fois déclarer une fonction anonyme et l’appeler en mettant la fonction entre parenthèse, puis en juxtaposant des parenthèses vides “()” justes après, comme on le ferait avec le nom d’une fonction classique déclarée auparavant. Ce qui nous donne :

(function(){ /* contenu de monScript.js */ })()

Pour bien comprendre, il faut réaliser que les lignes de codes suivantes sont totalement équivalentes :

function tata() { alert("tata") }; tata();
// => Affiche "tata"

var titi = function() { alert("titi") }; titi();
// => Affiche "titi"

(function() { alert("toto") })();
// => Affiche "toto"

b. Garantir l’équivalence jQuery == $

Au final on profite également du fait de passer par une fonction pour lui passer en paramètre l’objet jQuery. L’intérêt est de profiter du fait que lorsque on déclare une fonction, on déclare au passage le nom des variables internes qui vont correspondre au paramètres passés à la fonction. Par exemple dans le code suivant, je passe la variable globale monMessage à la fonction showMessage à l’intérieur de laquelle je manipule cette fois la variable “m” qui à l’avantage d’être beaucoup plus courte.

function showMessage(m) {
  alert(m);
};

var monMessage = "Coucou !";
showMessage(monMessage);
// => Affiche "Coucou !"

Par défaut, jQuery propose déjà une variable “$” qui est l’équivalent de la variable globale jQuery. Malheureusement on ne peut pas toujours s’y fier, car certaines librairies telles que Prototype ou Mootools peuvent venir surcharger elles aussi la variable $. Il est donc plus sûr de redéfinir cette variable nous-même.

Cette astuce a aussi l’avantage inverse, à savoir permettre d’utiliser jQuery en mode “no conflict”. C’est à dire en lui demandant explicitement de ne pas utiliser la variable $ pour qu’elle soit disponible pour d’autres librairies (et donc éviter les conflits). Car après tout jQuery n’a pas le monopole du dollar !

4. Répartir tout le code dans des fonctions simples avec des noms explicites

Il est souvent tentant de commencer un développement (surtout les plus petits) en écrivant le code sans essayer de le structurer. Mais avec le temps on se rend compte que faire du code propre dès le départ est toujours payant.

Pour cela j’essaie d’appliquer 2 grands principes :

1. Je crée des fonctions différentes pour chaque unitée fonctionnelle. Notamment il arrive souvent qu’un développement consiste en deux parties : l’opération en elle même exécutée par le navigateur et le branchement de cette opération sur un évènement (par exemple, le clic sur un lien ou un bouton). Dans ce cas, je sépare ces deux parties en deux fonctions distinctes. L’intérêt principal est bien entendu de pouvoir rappeler la première fonction dans différents cas (on factorise le code). On gagne aussi en clarté et en maintenabilité
2. Je nomme mes fonctions de manière explicite en respectant une nomenclature précise. Par exemple une fonction qui est appelée directement au chargement commence par “init”, si elle consiste à brancher une fonction sur un évènement elle précise “event” ainsi que l’élément sur lequel elle s’applique, etc.

En bonus, vous pouvez aussi décrire vos fonctions avec des commentaires, ça ne mange pas de pain…

Tout cela nous donne un code qui peut ressembler à celui-ci :

(function($){

  // Code exécuté au chargement du DOM
  $(document).ready(function(){
    initEventOnClickOnSaveButton();
  });

  /*
   * Action lors du clic sur le bouton "sauvegarder"
  */
  function initEventOnClickOnSaveButton() {
    $("#saveButton").click(function(){
      saveFormData($(this).closest("form"));
    });
  }

  /*
   * Sérialisation et sauvegarde des données d'un formulaire
   * formElement via une requête POST en AJAX
   */
  function saveFormData(formElement) {
    var $form = $(form), data = $form.serialize();
    $.post($form.attr("action"), data);
  }

})(jQuery);

5. Utiliser des champs cachés pour transmettre des données aux scripts

Dans l’exemple précédant, je simule une fonction qui doit faire une requête AJAX (via la méthode post de jQuery). Pour déduire l’URL à interroger pour faire la requête, elle utilise la valeur de l’attribut action d’un formulaire. C’est une technique assez pratique et élégante dans la mesure où les formulaires contiennent par nature toutes les informations nécessaires pour envoyer une requête à un serveur, y compris l’URL à interroger. Le problème c’est qu’on a bien sûr pas toujours la possibilité de rencontrer ce cas de figure idéal. Bien souvent, quand on doit faire une requête AJAX, l’URL à interroger doit être générée par une méthode côté serveur (une méthode PHP par exemple).

Pour répondre à cette problématique, un réflexe courant est de générer dynamiquement du code javascript dans la page, comme dans l’exemple suivant :

<script type="text/javascript">

// On suppose qu'il existe déjà une variable PHP $ajaxUrl...
var ajaxUrl = "<?php echo $ajaxUrl ?>";
// => On peut maintenant utiliser la variable globale ajaxUrl en javascript

</script>

Cette façon de faire a plusieurs inconvénients, dont certains vont à l’encontre de quelques unes des bonnes pratiques que nous avons vu juste avant :

• Génération d’une balise <script> dans la page
• Utilisation d’une variable globale qui peut entrer en conflit avec d’autres scripts

La méthode que j’utilise pour pallier à ces problèmes est de passer par des champs cachés. La mise en oeuvre est assez simple. Je commence par mettre le code suivant tout en bas de la page concernée (ou plutôt dans le footer global du site si possible, comme ça les données sont dispo partout) :

<form id="dataForJS">
  <input type="hidden" id="ajaxUrl" value="<?php echo $ajaxUrl ?>" />
</form>

Et voilà ! En javascript, il ne me reste plus qu’à aller chercher le champ caché par son identifiant et en récupérer la valeur. Ce qui, avec jQuery, est assez trivial :

var ajaxUrl = $("#ajaxUrl").val();

Vous pouvez même un peu plus automatiser les choses en récupérant directement toutes les URLs s’il y en a plusieurs. En ajouter une revient alors simplement à ajouter un champ caché :

var urls = {};
$("#dataForJs input").each(function(){
  var $input = $(this);
  urls[$input.attr("id")] = $input.val();
});

alert(urls["ajaxUrl"]);
// => Affiche l'URL stockée dans le champs caché avec l'id "ajaxUrl"

En résumé…

Voilà donc au final à quoi peut ressembler votre fichier JS prêt pour accueillir confortablement vos développements javascript avec jQuery :

(function($){

  // Code exécuté au chargement du DOM
  $(document).ready(function(){
    initUrls();
    initEventOnClickOnSaveButton();
  });

  /*
   * Récupération des URLs sérialisées dans la page
  */
  var urls = {};
  function initUrls() {
    $("#dataForJs input").each(function(){
      var $input = $(this);
      urls[$input.attr("id")] = $input.val();
    });
  }

  /*
   * Action lors du clic sur le bouton "sauvegarder"
  */
  function initEventOnClickOnSaveButton() {
    $("#saveButton").click(function(){
      saveFormData($(this).closest("form"));
    });
  }

  /*
   * Sérialisation et sauvegarde des données d'un formulaire
   * formElement via une requête POST en AJAX
   */
  function saveFormData(formElement) {
    var $form = $(form), data = $form.serialize();
    $.post(urls["ajaxUrl"], data);
  }

})(jQuery);

Et vous ? Avez-vous d’autres bonnes pratiques ou des conseils pour préparer vos développements frontend ? N’hésitez pas à les poster en commentaire, je compléterai ou corrigerai l’article au besoin…

Les auteurs du célèbre service Twitter ont dévoilé cette semaine qu’ils allaient refondre leur page d’accueil. J’ai eu l’info via un article d’Eric Dupin sur son blog Presse-Citron (excellent blog que je vous recommande au passage).

Capture de la page d'accueil de Twitter qui va être remplacée

Capture de la nouvelle page d'accueil de Twitter

Dans son article, Eric rapporte d’amblé l’objectif  principal de cette refonte, telle que l’explique Twitter :

[Twitter va devenir] davantage un réseau d’information continue et non plus un lieu où l’on publie son statut personnel.

Ce n’est pourtant pas la première fois que Twitter refond sa page d’accueil. Une précédente mise à jour avait déjà eu lieu cet été et avait déjà pour but de montrer Twitter comme un média et non plus simplement comme un service d’ajout de statut. Benoit Descary expliquait à l’époque que cette refonte s’adressait non-pas aux utilisateurs de Twitter, mais justement à ceux qui ne sont pas encore inscrits :

En revanche, la nouvelle page d’accueil permet à ceux qui n’utilisent pas Twitter ou qui désirent découvrir les conversations sur ce service de facilement créer une recherche. Pour les non-initiés, cette refonte aide à mieux comprendre l’utilité de ce service. Twitter.com pourrait bien devenir la destination pour faire une recherche sur Twitter. Même si plusieurs services similaires sont de loin supérieurs, uniquement le nom Twitter attirera sans doute un grand nombre de visiteurs sur cette page.

C’est donc via la fonction de recherche que Twitter souhaite séduire ses nouveaux utilisateurs, en leur montrant qu’on peut découvrir ce que les gens racontent dans le monde sur un sujet, en temps réel. L’argument avancé pour inciter l’utilisateur à s’inscrire n’est même plus tellement le fait de pouvoir partager son statut, mais surtout de pouvoir lire celui des autres.

Ainsi, on constate que Twitter change de cible au rythme de l’augmentation de sa masse d’utilisateurs inscrits, pour finir par l’inverser totalement. En fait, c’est un point commun à tous les réseaux sociaux : au début ils essayent d’attirer et de séduire essentiellement des contributeurs puis, une fois la taille critique atteinte, ils basculent pour séduire les utilisateurs passifs qui se “contenteront” de consulter le contenu des autres (en contribuant un peu quand même de temps en temps). Cette seconde catégorie d’utilisateur a bien-sûr le mérite d’être très fortement majoritaire…

La nouvelle mouture de la page d’accueil du service à l’oiseau bleu s’inscrit donc dans cette stratégie visant à attirer un nouveau type d’utilisateur (but premier de toute page d’accueil de service Web). Le passage d’un service de contribution à un service de recherche était une première étape. Maintenant Twitter nous montre qu’il veut être reconnu comme un véritable média à part entière, en mettant beaucoup plus en avant son contenu.

En terme de marketing produit, le fait de montrer très tôt le contenu à l’acheteur potentiel est une technique vieille comme le monde et qui a fait ses preuves. On retrouve ce principe notamment sur les jouets : il est inconcevable aujourd’hui de vendre un jouet dont le packaging ne permet pas de voir (et même souvent d’essayer) ce qu’il y a à l’intérieur. Pour les services Web c’est pareil : une page d’accueil efficace doit permettre à l’utilisateur de constater par lui-même la valeur que va lui apporter le site. L’explication ne suffit pas, il faut montrer, prouver la valeur. Les internautes sont de plus en plus exigeants…

La morale de tout cela du point de vue du Web(Product)Designer, c’est que derrière la conception d’une page il y toujours des considérations d’efficacité. Une page d’accueil de service Web est faite pour “transformer” les visiteurs anonymes en membres inscrits (ou au moins collecter leurs coordonnées, mais c’est une autre histoire) et c’est cette problématique qui en dicte la conception, même (et surtout) pour Twitter.

Un tutoriel sur le wireframing sous Illustrator

Moi qui pensait être le seul à faire mes wireframes et mes maquettes sous Illustrator, Adobe me démontre le contraire en sortant carrément une vidéo dédiée sur le sujet.

A l’occasion je ferai probablement un article avec mes propres astuces pour faire des maquettes et des wireframes efficacement sous Illustrator…

Un blog dédié au wireframing

Découvert il y a déjà quelques temps, grâce à Frédéric : un blog complètement dédié au wireframing

On y trouve à la fois des exemples, des logiciels, des templates et autres librairies de composants. Comme d’habitude d’ailleurs, beaucoup de modèles existent uniquement pour Omnigraffle. Ce logiciel renommé pour faire des wireframes, entre autres, n’existe malheureusement que sur Mac.

Un outil pour faire des wireframes volontairement “moches”

Les auteurs de ce blog sont visiblement sponsors de Balsamiq Mockups que je connais bien pour avoir travaillé avec chez Dismoioù. C’est un outil original dans la mesure où il se base sur des composants prêts à l’emploi que vous n’avez plus qu’à disposer (boutons, champs de saisie, listes déroulantes, zones de texte, images, onglets…) et qui ont tous l’air d’avoir été dessinés à main levée (et encore en étant un peu atteint de parkinson).

Le genre de wireframe que l'on peut réaliser avec Balsamiq Mockups : ça ne vous rappel rien ?...

Il existe d’autres outils délibérément contraignants qui imposent de n’utiliser que des formes préétablies et dont le rendu est volontairement peu réaliste. Cette démarche qui se généralise est intéressante car elle répond à deux besoins très courants :

• D’abord le besoin pour les décideurs non-graphistes (responsable marketing, chef de produit…) de pouvoir transmettre leurs idées sans avoir à maîtriser Photoshop ou utiliser des outils peu adaptés comme Powerpoint.
• Ensuite le besoin pour les designer eux-mêmes de pouvoir travailler sur l’ergonomie et le scénario d’usage d’une ou plusieurs pages d’un site sans que le travail soit parasité par des questions purement graphiques ou esthétiques.

Dans le second cas l’avantage pour le designer est notamment de pouvoir avancer progressivement sur un travail de conception en posant des bases solides petit à petit. Il est souvent périlleux de vouloir faire valider un design en proposant directement une maquette graphiquement aboutie, car rien ne garanti que la composition et le contenu de la page sont bons, or si ces éléments changent il est probable qu’une grande partie du travail soit à refaire…

Du papier et un crayon…

Comme certains outils essayent de vous permettre de réaliser des wireframes qui ont l’air d’avoir été fait à la main, pourquoi pas essayer de les faire directement avec un bon vieux crayon et du papier ?

On aura beau dire, même si vous dessinez très mal et que vous êtes perdu sans une souris, commencer par faire quelques essais à la main est très souvent une bonne idée. Les gens qui sont réticents à cette pratiques argumentent souvent qu’ils trouvent l’inspiration en manipulant leur logiciel favoris (Photoshop of course). Mais comme j’en ai déjà longuement parlé, c’est une fausse bonne idée, voilà pourquoi :

• un bon design de site web commence par un bon concept
• un bon concept ne nait pas dans Photoshop, mais dans le cerveau d’un être humain
• les meilleurs outils pour accoucher d’un bon concept restent (encore aujourd’hui !) un bloc de papier et un crayon

Et oui, le challenge quand on part de rien n’est pas d’avancer le plus vite possible dans un processus créatif, mais d’être sûr d’arriver !

Ebauches papier de quelques sites (très) populaires

Si vous doutez encore de l’intérêt d’utiliser un crayon, allez jeter un coup d’oeil sur cet article de Deeplinking qui montre les premières ébauches de quelques un des sites les plus populaires du Web tels que Flickr, Twiter ou Vimeo !

Comme quoi les meilleurs idées se conçoivent simplement…

Première ébauche de la page d'accueil de Twitter

Je cherchais une bonne façon de démarrer ce blog. Quel en serait le premier post ?

Dans un esprit cartésiens, j’envisageais de lister les différentes étapes d’une sorte de méthode pour partir d’un besoin et aboutir à un site fini – en fait plutôt un ensemble de règles pragmatiques que je fini par appliquer assez systématiquement. Cette idée se révélait rapidement assez foireuse… Le but du format “blog” est, pour moi, de pouvoir distiller mes idées au fil de l’eau. Si elles étaient déjà bien structurées et ordonnées j’écrirais directement un bouquin…

Ainsi, laissons tomber le côté “Grand Un, petit A : le B-A-BA de la prise de brief” et tentons une approche plus concrète. Par contre, j’aime bien quand même la tournure “contre exemple” que prennent les choses… La bonne façon de faire apparaît souvent quand on réalise qu’on s’embourbe dans la mauvaise.

C’est donc par la que je vais commencer, par la hantise du Webdesigner qui fini (ou plutôt commence) par se voir, à tort, comme un artiste : le vide ! J’entend par là le moment où il va se lancer dans l’arène et devoir prendre en main un  projet de design de site Web.

Pour ne pas parler dans le vide justement, je vais profiter d’un article sur lequel je suis tombé aujourd’hui grâce au blog SimpleEntrepreneur : Web Design is a Journey

Un bon exemple de ce qu’il ne faut pas faire…
… quand on est pas sûr de ce qu’on fait !

Dans cet article, l’auteur explique qu’il était en charge du redesign du site institutionnel de Carsonified, une agence Web américaine que je ne connaissais pas jusque là, et nous présente ça démarche tel un long cheminement bien torturé… Ce qui a justement retenu mon attention pour écrire le premier article de ce blog.

Pour en revenir au projet en question, il s’agissait donc de refondre le site présentant la démarche et les activités de la société. Le fait qu’il s’agisse du site d’une  agence Web biaise tout de suite la démarche. Car tel un cordonnier qui voudrait porter des chaussures exemplaires, Mike Kus, l’auteur de cet article et du projet en question, nous raconte comment, finalement, ça démarche a été bien peu efficace. Il fini évidement par un happy-end à l’américaine mais admet lui-même dans sa conclusion que si le résultat est réussi, ça n’est pas vraiment grâce à la longue série de tentatives ratées dans laquelle il s’est lancé.

[...] one thing I’ve learned from this is that time restrictions can definitely be a good thing. To much time can mean too many explorations and that just becomes a road to nowhere.

J’en arrive à mon propos : Mike a mis en pratique ici la caricature même du Webdesigner : il est parti bille en tête dans une démarche créative en partant du principe qu’en faisant suffisamment de versions différentes, il finirait par obtenir quelque chose de satisfaisant.

C’est souvent le premier réflexe des Webdesigner peu expérimentés. C’est aussi une pratique assez courante en agence où on retrouve souvent le réflexe hypocrite qui consiste à présenter quelques versions bien pourries en plus de la version qu’on espère voir le client accepter, histoire de lui prouver qu’on a bossé et lui faire croire qu’on a le choix. Bon, je suis un peu mauvaise langue là, il y a quelques bonnes agences qui ne procèdent pas ainsi… enfin pas tout le temps.

Le problème c’est que cette démarche ne tient plus la route dès lors qu’on s’inscrit dans un projet réellement ancré dans une stratégie de temps et d’argent. J’entends par là que quand vous travaillez sur un projet avec des enjeux importants, vous ne pouvez en fait pas vous permettre de passer du temps à tâtonner : il faut produire vite et bien et donc intelligemment…

L’exemple de Carsonified est assez courant, je suis passé par là à plusieurs reprise : vous êtes dans une boite dont l’activité se retrouve dans une période un peu creuse, les gens sont enthousiastes et la direction se dit que ça serait intéressant de passer un peu de temps pendant l’été à donner un coup de frais au site institutionnel de la boite. Là effectivement c’est du pain bénit pour le Webdesigner plutôt porté sur le graphisme qui voit là l’occasion d’exprimer enfin librement sa créativité. Mais il s’agit donc de l’exception qui confirme la règle ! En temps normal une entreprise ne peut pas se permettre de naviguer à vue sur le design d’un projet Web important…

Le malheur là dedans, c’est que malgré tout j’ai rencontré régulièrement des entreprises (type “clients finaux”) qui considèrent (du moins à priori) que c’est comme ça que ça marche et qu’elles n’ont pas le choix ! On touche du doigt le problème de la méconnaissance totale chez une majorité de décideurs concernés de ce qu’est (ou doit être) réellement le rôle d’un Webdesigner.
Ainsi, j’ai presque systématiquement retrouvé le même schéma lors de mon intégration dans une entreprise : au début on me demande d’intervenir en toute fin de projet pour ajouter simplement une “couche” sur un projet où les notions de design et d’ergonomie n’ont pas été structurantes et, presque à chaque fois, on a très vite reconsidéré les projets en me demandent d’intervenir plus en amont. Au final, la phase de Design Produit était clairement identifiée comme apportant une réelle valeur ajoutée et devenait une phase structurante du projet associée bien souvent à la conception et à la réalisation du cahier des charges (quand on en faisait…).

Le Webdesigner n’est pas un artiste, c’est avant tout un communiquant

Pour en revenir à la démarche du Webdesigner de Carsonified, il aurait probablement dû se poser plus de questions avant de démarrer son travail de recherche. Il explique d’ailleurs lui-même qu’il n’avait quasiment pas de brief :

There wasn’t much of a brief but there were a few things the site had to do:

• The homepage had to communicate what we did.
• It had to express our company’s personality and beliefs.
• It had to include the following pages: Home, Events, Mission, Jobs, Contact and Team
• [Our blog] was going to sit within the Carsonified site (whilst retaining it’s own identity).

A part quelques éléments liés à la structure du site et à sa navigation, Mike avait une “totale liberté” sur le design.

The design of the site was down to me and as usual, Ryan gave me total creative freedom.

C’était déjà un mauvais départ que de considérer que c’est une liberté de ne partir de rien. La vraie liberté, c’est celle d’interpréter les choses. Partir de rien c’est plutôt au contraire une grosse contrainte, car il faut alors faire tout le travail de compréhension des enjeux du projet. Car de toute façon si on tombe à côté au final, soit on est condamné à recommencer encore et encore parce que le client ou la direction n’est pas satisfaite, soit de toute façon le résultat est médiocre.

Quand Mike explique que le site devait exprimer la “personnalité” de l’entreprise, il contourne en fait allègrement une règle d’or en design : toute création sert à communiquer un message à destination d’une cible.

Ça fait un peu dogmatique dit comme ça, mais je n’ai pas encore eu l’occasion de tomber sur un cas où ça ne s’applique pas… Si j’explicite la conséquence que ça aurait dû avoir pour Mike, c’est qu’il aurait dû partir d’un travail précis de définition de ce qu’étaient à la fois le message et la cible dans son cas. Au vu du résultat retenu, on peut imaginer les éléments suivants :

• Message exprimé par Carsonified.com : “Nous sommes une agence Web moderne et dynamique avec une démarche créative à la fois originale, décalée tout en conservant une certaine sobriété”
• Cible de Carsonified.com : Des décideurs responsables de projets Web étant eux-mêmes sensibles aux valeurs de l’agence. Donc probablement plutôt jeunes, mais n’ayant pas trop de culture extravagante (“on est loin des minorités underground, mais on fait quand même du Web 2.0 plutôt cool…”)

Bon, je me trompe peut-être dans l’analyse rapide, mais là n’est pas le propos. L’idée est de démontrer qu’il faut partir du message et de la cible pour définir l’orientation d’une créa. Car si on ne le fait pas la communication n’est pas maîtrisée. On risque alors d’intéresser les mauvaises personnes (voir personne) et de véhiculer les mauvaises valeurs (ou au pire n’avoir aucun impact, c’est à dire avoir travaillé pour rien).

Au vu des versions extrêmement différentes qu’a produit l’auteur de l’article qui nous intéresse ici et de la façon dont il commente son “Voyage du Webdesign”, il n’avait clairement pas assez défini ces éléments nécessaires (mais d’ailleurs rarement suffisants) pour structurer et orienter son travail. Il en convient d’ailleurs lui-même dans la conclusion citée plus haut.

Rien ne sert de courir…

Ma conclusion ici est d’expliquer que le travail de Webdesign est forcément d’abord un travail de réflexion et d’analyse. Plus on a conscience de cela et plus on a de chance d’être efficace et d’aboutir à un résultat satisfaisant. Malheureusement j’ai rencontré souvent des Webdesigners qui n’appliquaient pas cette démarche parce qu’ils n’avaient pas assez d’estime d’eux-mêmes ou parce qu’ils étaient sous-estimés par les responsables de projets qui les faisaient intervenir.

C’était donc une bonne occasion pour moi de prendre cet article en exemple pour introduire un peu plus la démarche de ce blog qui va être d’essayer de donner des clés aux Webdesigners pour leur faire appréhender leur métier un peu plus comme une science où l’on maîtrise les effets de ce que l’on produit et un peu moins comme des artistes (et encore) victimes de leur manque d’inspiration.

Comme vous le voyez ce site est en cours de construction…

J’avance petit à petit en essayant de me concentrer sur le contenu. La forme du site est d’ailleurs tirée d’un thème pré-conçu pour WordPress. J’aurais d’autres occasions de vous montrer ce que je sais faire, ce n’est pas le but dans un premier temps.

Vos remarques sont les bienvenues pour m’aider à rendre ce blog intéressant et à ajuster sa ligne éditoriale.