wdfriday

La conception dans le navigateur serait-elle un frein pour le processus de création ?

Francis Chouquet — Fri, 20 Apr 2012 13:33:48 +0000

Le sujet est récurrent depuis 2 petites années maintenant: faut-il "designer" ou concevoir un site web directement dans le navigateur ? De nombreux graphistes, de toutes nationalités, ce sont lancés à fond dedans, et des types comme Andy Clarke vont jusqu’à avoir un discours assez radical sur le sujet:

“We aren’t designing photocopies of web page, we’re designing web pages.”

– Andy Clarke J'ai moi-même fait deux conférences sur le sujet au ParisWeb 2010 et au Smashing Magazine Meetup Basel. Mais les divers retours que j'ai pu avoir, et surtout cet article de Sarah Parmenter, ainsi que mon expérience personnelle, m'ont fait réaliser que bien que la conception dans la navigateur apporte pas mal de solutions, ça ne semble pas si évident que ça pour tout le monde…

Un petit retour en arrière…

Tout a commencé avec l'arrivée des CSS3. On pouvait finalement faire des coins arrondis, des ombres et j'en passe, tout ça directement en CSS. Alors, nombreux sont ceux qui sont montés au créneau en disant: "Pourquoi continuer avec Photoshop si on a sous la main l'outil idéal pour développer des sites web, à savoir notre navigateur ?". Ajoutez à tout ça l’émergence du Responsive Web Design qui a, d’une certaine manière, rendu une partie de la conception quasi obligatoire dans le navigateur, et vous avez quand même pas mal de conditions pour promouvoir cette manière de faire. C'est vrai que les avantages sont évidents:

Conception rapide quand on est à l’aise avec le HTML et les CSS,
Faire des modifications est nettement plus simple que lorsqu’on doit le faire sur Photoshop,
Vous savez tout de suite ce que vous pouvez faire et ce que vous ne pouvez pas faire,
Prototypages dynamiques que vous pouvez présenter à vos clients,
Délais projets raccourcis.

Ce ne sont là que quelques points que j’ai pu récupérer à chaque présentation que j’ai pu faire sur le sujet. Et comme dit plus haut, je ne parle même pas du RWD où l’utilisation du navigateur est quasi indispensable.

OK, mais est-ce si évident pour tout le monde ?

Et la créativité dans tout ça ? Nous avons nos processus de création, nos manières de faire. Est-ce que passer de Photoshop à un navigateur peut être si aisée que ça ? Comme le dit si justement Sarah dans son article, penser un design directement avec les CSS l'empêche d'une certaine manière d'être créative. Ca ne se positionne pas bien du tout dans tout son processus de création.

" My creative brain switches at the point when I open my HTML/CSS editor, and starts thinking in terms of structure and how to achieve the look of my design using as much native CSS as possible."

– Sarah Parmenter Et je peux la comprendre. Pour travailler personnellement beaucoup dans le navigateur, il y a des moments où devoir trouver la bonne idée me conduit à nouveau à utiliser Photoshop parce que je me dis que c'est plus rapide que via mon éditeur de code, mais aussi parce que je veux pouvoir tester rapidement des éléments graphiques qui ne sont peut-être pas si simples à mettre en place en CSS. Ou pas du tout d'ailleurs. Lors de ma présentation au Smashing Mag Meetup, je parlais déjà de ces soucis à évoluer vers le design dans le navigateur pour certaines personnes et j'évoquais le fait qu'on n'est déjà pas obligé de faire comme tout le monde. Ce n'est pas parce que certains disent que c'est top de designer dans le navigateur qu'il faut le faire. Ensuite, comme dit plus haut, on a des processus de création qui font que certaines méthodes nous correspondent plus que d'autres, et que de les changer pose certains problèmes. Et encore, on n’aborde pas ici non plus le fait de connaître ou pas le HTML et les CSS.

Et s'il y avait une méthode intermédiaire ?

Du coup, personnellement, j'ai trouvé une solution qui fonctionne plutôt bien dans la plupart des cas. J'ai beau adorer Photoshop, je n'arrive pas à y rester trop longtemps. Je suis trop frustré par certains éléments comme la typographie. Notons ici que j'utilise beaucoup Typekit et que si je veux tester certaines polices, je dois absolument passer par le navigateur. Donc, ce que je fais, c'est que je fait des premières "esquisses" sur PSD, pour choisir un fond, une texture, des couleurs, un certain layout/structure. Puis, je passe très rapidement au navigateur. Et là, je reprends cette structure "globale" et je la détaille progressivement. Je ne reviens plus à Photoshop, sauf si je suis bloqué par un élément graphique à créer par exemple. Le logiciel m'a aidé, au départ, à faire des choix pour mon design, et ces choix ont été possibles parce que je me sens à l'aise sous Photoshop et que la concordance entre l'exécution de mes mains et l'idée dans ma tête fonctionnent de concert. Mais très vite, Photoshop me frustre parce que je commence à penser grille typographique, marge, padding, line-height, etc. Et là, je dois absolument passer sur le navigateur, il ne peut en être autrement. J'ai aussi très envie de mettre en place certaines idées pour les rollover, travailler un peu les transitions ou les animations du site. Donc, même si ça semble facile et logique pour grand nombre de développeurs front-end, ça ne l'est pas forcément autant chez les designers, tout simplement parce que le processus créatif de départ fonctionne différemment. Les automatismes ne sont pas les mêmes. Mais ce n'est pas grave ! Il est bon de savoir que passer rapidement au navigateur dans la création d'un site web va apporter son lot d'avantages, dont certains sont énumérés plus haut. Et c'est clair que si vous souhaitez proposer un site en responsive web design, travailler dans le navigateur est forcément la bonne solution. Mais prenez d'abord vos repères, essayez de faire évoluer votre processus de création et vous trouverez le bon chemin. Je dis souvent que le plus on pratique la conception dans le navigateur, le plus on l'adopte, et le moins on retourne vers Photoshop. Mais il est clair aussi que pour certaines choses, on va avoir du mal à se passer de Photoshop. Au delà d’y concevoir tout un site, il est très important pour concevoir une partie des éléments graphiques de ce même site. N'oublions pas non plus que le job du web designer n'est pas le même partout. Quelqu'un qui travaille dans une grosse structure chez une agence ne va pas forcément avoir le même intérêt que le freelance qui touche un peu à tout. Mais globalement les choses semblent évoluer. Photoshop reste un outil incontournable pour beaucoup d’entre nous et le navigateur se présente comme une alternative ou un complément utile pour grand nombre de choses. Ne serait-il pas le bon moment d'essayer d'adapter nos process à ces nouvelles orientations qui risquent de voir le navigateur de plus en plus présent?

Introduction à la performance pour le Web mobile

Raphaël Goetter — Fri, 06 Apr 2012 09:30:44 +0000

Préambule : le "Web mobile" n'existe pas. Il n'y a qu'un seul Web et il ne change pas de visage selon votre périphérique de connexion. Le terme de "Web mobile" demeure cependant relativement parlant pour évoquer "le Web en situation de mobilité", c'est pourquoi je me permets de l'employer au cours de cet article.

Notre génération a jusque là été habituée à une évolution du Web prévisible et contrôlable : des écrans de bureau de plus en plus larges et des types de réseaux et connexions internet de plus en plus rapides. La démocratisation des périphériques mobiles (smartphones, tablettes et consorts) introduit de nouvelles contraintes et un inversement brutal de la tendance : les écrans deviennent subitement minuscules, et la connectivité en pâtit aussi : au mieux, votre mobile bénéficiera d'un réseau Wi-Fi, au pire... de rien du tout. En passant par les stades 3G et Edge / UTMS. En résumé, plus le marché mobile explose, plus nous - concepteurs Web - devront intégrer des contraintes inédites de "responsive web design" et de "performance web mobile". Selon Google, 6 personnes sur 10 quittent irrémédiablement un site web qui n'a pas été "optimisé pour le mobile" en terme de rapidité d'affichage, et il est vivement déconseillé de dépasser des temps de chargement de plus de 4 secondes pour vos pages si vous souhaitez conserver vos clients "mobinautes".

La notion de performance web

La performance web, c'est à dire tenir compte de tous les possibilités permettant d'accélérer le temps de chargement d'une page web, est devenu une évidence incontournable dans le domaine du Web mobile. Ces possibilités sont nombreuses et variées et l'objet de cet article est d'en dévoiler quelques unes. Entendons-nous bien, il ne s'agit pas ici d'entrer dans les méandres techniques de chaque solution - un livre entier serait nécessaire - mais de se limiter à une introduction superficielle, à un recueil de bonnes pratiques générales. Comme tous les conseils, certains sont bons à prendre, d'autres ne vous concerneront peut-être pas et d'autres encore seront à prendre avec des pincettes, voire être contre-productifs en fonction de votre architecture déjà en place. En guise d'introduction, je vous invite à commencer par tester vos pages web sur les outils dédiés en ligne suivants :

Le testeur de temps d'affichage mobile de Blaze.io (société privée),
Google PageSpeed Mobile en ligne (voir onglet "mobile"),
Le Validateur mobileOK du W3C.

Steve Souders, gourou de la performance web, a conclu que plus de 80% du temps passé par le navigateur à charger une page dépend du côté "front-end". C'est donc sur ce point que nous allons nous concentrer prioritairement (même si l'aspect serveur, telle que la mise en cache, ne doit pas être délaissé pour autant). [caption id="attachment_711" align="alignnone" width="536" caption="Répartition des temps de traitement navigateur entre front et back"][/caption]

media queries et performances sont sur un bateau...

Les media queries CSS3 et plus généralement la philosophie "responsive web design" forment un ensemble de techniques permettant d'adapter rapidement un design existant sur plateformes mobiles. Le principe étant de modifier instantanément les styles CSS, donc de réorganiser la page ou de masquer des éléments superflus, dès lors que des critères de largeur d'écran sont respectés. Voici un exemple d'application classique des media queries :

body { background: url(concombre_big.jpg); }
@media (max-width : 640px) {
 body { background: url(concombre_small.jpg); }
}

Et là, vous êtes déjà à côté de la plaque ! En effet, un navigateur mobile respecte les deux conditions à la fois (les styles globaux et ceux pour écrans de moins de 640px), il va donc en toute logique d'abord charger l'image... puis la masquer. En terme de performances, c'est exactement le type de comportement à éviter à tout prix. L'une des solutions réside dans l'usage de media queries exclusifs, par exemple :

@media (min-width : 641px) {
 /* styles pour grands écrans */
}
@media (max-width : 640px) {
 /* styles pour petits écrans */
}

Mais on se heurte immédiatement à un nouveau problème de taille : les navigateurs qui ne reconnaissent pas les media queries (notamment IE6 / IE8) ne bénéficieront d'aucun style CSS. La page s'affichera au format HTML brut. Là encore, les solutions existent, et là encore elles sont multiples et aucune n'est parfaite. Certaines emploient des commentaires conditionnels pour pallier aux déficiences d'Internet Explorer, d'autres se basent sur des alternatives JavaScript telles que Respond qui émule les media queries sur les anciennes versions d'Internet Explorer. Une solution intermédiaire qui me séduit de plus en plus est de distinguer 3 parties dans le fichier CSS :

les styles de base, qui doivent être affichés sur tous les supports même déficients
les ressources lourdes, qui doivent être chargées uniquement sur écrans larges
les styles et adaptations spécifiques pour petits écrans

Grâce aux classes conditionnelles, nous pourrons également faire profiter de cette méthode les anciennes versions d'Internet Explorer sans douleur. Voici un exemple concret :

/* styles pour tous */
body {width: 960px; background: #fff;}
/* ressources lourdes uniquement */
@media (min-width : 641px) {
 body { background: url(concombre_big.jpg); }
}
/* ressources lourdes aussi pour IE6-IE8 */
.oldie body { background: url(concombre_big.jpg); }
/* styles pour petits écrans */
@media (max-width : 640px) {
 body { width: auto; background: url(concombre_small.jpg); }
}

Cette méthode a actuellement ma préférence car ne nécessite pas de fichier CSS (donc de requête) supplémentaire, ni d'alternative et de traitement via JavaScript. Quelle que soit la technique adoptée, l'essentiel reste - de loin - d'éviter de charger de multiples ressources pour rien si vous les masquez sur mobile.

C'est bien mais... ce n'est pas suffisant

Une fois que cette première grosse épine du pied retirée, ne croyez pas sorti d'affaire pour autant car bien évidemment, d'autres points importants sont à prendre en considération dans la quête d'un affichage le plus rapide possible sur mobile. À travers cette introduction, je vous propose de parcourir cinq axes déterminants de la performance web mobile du côté du navigateur :

Quelques généralités
Réduire les requêtes,
Minifier / compresser,
Ne charger que le nécessaire,
Profiter des technologies modernes.

Quelques généralités

Quelques principes de base, issus des études de performances classiques de bureau sont évidemment applicables dans le monde du Web mobile, en voici certains :

Placez les appels de styles CSS au début (dans l'élément ) et les scripts (JavaScript, jQuery) en bas de document (avant ). Ceci pour faciliter les temps de traitement du navigateur.
Utilisez tant que possible des sélecteurs CSS "performants". Cela signifie qu'il est préférable d'éviter le sélecteur universel *, de même que les expressions comme div#toto au profit de #toto, ou nav ul li a à remplacer par nav a par exemple,
Hébergez les ressources (images, médias) sur plusieurs domaines différents. Cette technique favorise leur téléchargement en parallèle. Un sous-domaine fonctionne aussi (ex. media.alsacreations.com), et un domaine sans cookies est encore plus performant.
N'utilisez pas @import. Car cette méthode empêche la parallélisation des fichiers CSS (sauf cas particuliers et si maîtrisé)
Chargez vos ressources en asynchrone et/ou différé. HTML5 propose les attributs async (asynchrone : le script est chargé dès que possible, quel que soit l'ordre d'apparition dans le HTML) et defer (différé : le script est exécuté à la fin du chargement de la page) Voici un exemple :

Réduire les requêtes

Les requêtes HTTP sont le cauchemar des périphériques mobiles. Chaque requête, aussi minime soit-elle, est coûteuse en temps de connexion et l'on ne sait que trop bien qu'une connexion nomade est très fragile et précieuse. De plus, certains appareils ont la fâcheuse tendance à ne pas permettre les téléchargements parallèles : ils attendent la fin du chargement d'une ressource pour entamer la suivante. Débusquer les requêtes inutiles est devenu le lot de tout intégrateur sur mobiles. Voici quelques pistes à suivre sur ce thème :

Une feuille de styles unique. Faire plusieurs appels de feuilles de styles est coûteux en performance (surtout sur iOS et Internet Explorer qui ne parallélisent pas leur chargement), il est vivement conseillé d'essayer d'unifier les styles dans un minimum de fichiers. Le Saint-Graal se présente sous la forme d'un fichier unique comme nous l'avons détaillé dans la partie précédente.
Réunissez les images d'illustration en une seule ou aucune. C'est le concept des sprites CSS et des images encodées en Data URI / base 64. De nombreux générateurs "Sprites / Data URI" sont disponibles, le plus séduisant et intuitif actuellement est : http://draeton.github.com/stitches/.
Pensez aux caractères spéciaux pour certains symboles ou pictogrammes. Saviez-vous que même les polices de caractères classiques (dites "websafe") contiennent un très grand nombre de caractères spéciaux mal connus, sous réserve que vous serviez votre page web en encodage unicode UTF-8 ? La technique est décrite ici : http://ikwebdesigner.com/special-characters/
Essayez d'unifier les scripts dans un minimum de fichiers. Il existe d'excellents outils pour cela, tels que Google Minify.
Séparez les scripts de base (indispensables) des autres. Vous pourrez ainsi plus aisément ensuite choisir de ne pas charger les fichiers non essentiels. Par exemple :

Minifier / Compresser

Le poids des ressources à télécharger (fichiers, fontes, images, documents), est un élément à surveiller constamment. Pour chaque type de fichier, il existe des outils permettant de réduire le surpoids:

Minifiez les styles CSS. De nombreuses parties de vos styles CSS sont parfaitement inutiles, donc pesantes pour le navigateur : les espaces, les retours à la ligne, les commentaires, etc. Les outils en ligne tels que YUI compressor, CleanCSS ou CSScompressor suppriment toutes des lourdeurs et permettent de réduire le poids d'une feuille de style de parfois plus de 30%.
Compresser fichiers externes. JavaScript, mais aussi fichiers de fontes (par exemple privilégiez .woff qui est mieux compressé que d'autres formats de police pour le même rendu) peuvent également être compressés.
Compresser les images du site. Un certain nombre d'outils optimisent le traitement de compression de vos images. Les plus performants (ImageOptim, Smushit, jpegmini, PNGGauntlet) sont capables de vous faire économiser plusieurs centaines de Ko sans perte de données visuelle.

Ne charger que le nécessaire

Même optimisées, compressées et triturées au maximum, certaines ressources demeureront toujours excessives à charger. C'est le moment de se demander si toutes ces ressources sont bien nécessaires sur un périphérique mobile et s'il n'était pas plus pertinent de ne les proposer que lorsque l'internaute dispose de meilleures conditions. Voici quelques conseils pour éviter de surcharger les mobiles et tablettes de médias et éléments inutiles :

Ne chargez certaines images que sous condition (largeur d'écran). Voici un exemple de script permettant de remplacer les images de classe "kiwi" par leur équivalent en grande taille uniquement si la taille de l'écran est supérieure à 640px (par ex: image_small.jpg devient image_big.jpg) :

if(screen.width>640) {
   var img_list = document.getElementsByTagName('img');
   var i = 0;
   while (element = img_list[i++]) {
      if (element.className == 'kiwi') {
         var url = element.src;
         var posUrl = url.lastIndexOf('_');
         var preUrl = url.substring(0,(posUrl+1));
         var newUrl = preUrl+'big.jpg';
         element.src = newUrl;
      }
   }
}

Ne chargez certain scripts gourmands que sous certaines conditions (largeur d'écran). L'exemple suivant permet de charger slideshow.js que si la taille d'écran est supérieure à 640px :

if(screen.width>640) {
   var bigjs = document.createElement('script');
   bigjs.src = 'slideshow.js';
   bigjs.type = 'text/javascript';
   document.getElementsByTagName('body')[0].appendChild(bigjs);
}

Employez les Mediaqueries pour la vidéo et le son. C'est peu connu (car encore peu supporté par les navigateurs), mais il est parfaitement possible de tirer profit des media queries pour offrir un chargement intelligent des fichiers vidéos et audio :
```
   
   
```
Évitez des frameworks tels que jQuery, jQuery Mobile, jQuery UI si inutiles. Un bon nombre de sites web incluent des librairies telles que jQuery par défaut, sans forcément s'en servir, ou pour des usages basiques tels que le ciblage de sélecteurs. Sachez que ces ressources ne sont pas négligeables à charger et traiter et qu'elles ne sont pas toujours aussi indispensables qu'on ne le croit. Deux outils peuvent peut-être les remplacer avantageusement : Sizzle, qui reprend les sélecteurs jQuery, et jquip.js (jquery in parts) qui ne pèse que 6.6ko et qui couvre 90% des fonctions de jQuery.

Profiter des technologies modernes

Le monde du Web mobile, malgré son extraordinaire pluralité n'en demeure pas moins séduisant : la technologie évolue, les processeurs sont de plus en plus performants, les navigateurs sont souvent à la pointe du progrès. Bref, les possibilités offertes dépassent de loin celles proposées par un bon nombre de navigateurs de bureau (qui a dit IE6 ?). Il ne faut pas hésiter à exploiter toutes les technologies d'avant-garde déployées par le W3C :

Privilégiez CSS3 autant que possible plutôt que d'autres technologies. Certains test démontrent que JavaScript est dix fois plus long à être interprété sur smartphone que sur ordinateur classique. C'est sûrement le moment de se mettre à CSS3, plus performant que JavaScript pour les effets graphiques et le confort (animations, scrolls, slideshows, etc.)
Privilégiez HTML5 en général. Pour de multiples raisons : doctype plus court (donc quelques octets de gagnés au chargement), géolocalisation, web offline, gestion du cache, mais aussi pour l'ergonomie et les champs de type email, url, search, number, tel, etc.

Conclusion

En guise de conclusion, je pouvais difficilement me soustraire à l'exercice de soumettre mon site web personnel à l'ensemble des conseils que j'ai pu livrer dans ce billet. [caption id="attachment_753" align="aligncenter" width="510" caption="Goetter.fr - Site de Raphaël Goetter"][/caption] J'ai donc passé au crible goetter.fr et voici les conclusions que j'ai pu en tirer :

Non optimisé, le poids de la page d'accueil approchait les 400ko et un temps de chargement de 4 secondes sur mobile,
Après quelques modifications et environ une demi-journée de travail, je suis parvenu à un poids de 100ko et moins de 2 secondes de chargement. Soit un temps d'affichage divisé par plus de 2 et un poids total divisé par 4,
Le score de Google Page Speed online est passé de 77/100 à 97/100,
Les progrès les plus flagrants ont été constatés après les actions suivantes : unification des styles CSS (1 seul fichier), chargement de l'image de fond et des scripts superflus uniquement sur grand écran,
Contrairement à mes prévisions, la compression de toutes les images n'a eu qu'un effet assez négligeable.

[caption id="attachment_758" align="alignnone" width="510" caption="Temps de chargement de goetter.fr sur mobile après optimisation"][/caption] Et vous ? Avez-vous fait vos tests de performance ? Avez-vous d'autres techniques pour accélérer l'affichage des pages en situation de mobilité ?

La technique Pomodoro, un atout pour votre créativité ?

Francis Chouquet — Fri, 30 Mar 2012 08:30:57 +0000

Il y a quelques semaines, j’ai vu passer quelques tweets parlant d’une technique de productivité s’appelant Pomodoro. Sur le coup, je me suis dit "encore une...". Il faut dire que j’avais auparavant testé le GTD et que j’avais trouvé ça tellement contraignant au final que je perdais du temps plutôt que d’en gagner. Et puis, à force d’en entendre parler, ma curiosité a pris le dessus et je suis allé voir sur le web ce que c’était.

Qu’est-ce que la technique Pomodoro ?

La technique Pomodoro est une méthode permettant de mieux gérer son temps sur la journée. Le principe est finalement très simple. Vous travaillez par tranche de 25 minutes, et entre chaque tranche vous faîtes une pause de 5 minutes. Chaque tranche de 25 minutes est appelée un "pomodoro", et après 4 pomodoros, vous faîtes une pause de 15 minutes. Donc en gros on a le schéma suivant:

1 pomodoro de 25 minutes
1 pause de 5 minutes
etc... jusqu’au 4ème pomodoro
1 pause de 15 minutes
et on repart pour un cycle de 4 pomodoros.

Cette technique a été élaborée dans les années 80 par Francesco Cirillo et s’est revélée très utile pour pas mal de professions. Alors, qu’en est-il pour le web design ? J’ai testé pour vous ! :)

Simple à mettre en oeuvre

S’il y a quelque chose de sympa avec Pomodoro c’est qu’on n’a pas besoin d’une super organisation. Pour débuter, vous avez uniquement besoin d’une feuille de papier et d’un timer pour la cuisine (ou de n’importe quel objet pouvant servir de chrono). A partir de là, vous notez tout ce que vous avez à faire sur la journée. Notez ici que même si vous n’utilisez pas cette méthode, commencer la journée en faisant une sorte de "todo list" peut être très bénéfique. Donc, vous faîtes votre liste et vous commencez à bosser, par tranche de 25 minutes. A la fin de chaque pomodoro, vous "checkez" la ligne de la liste sur laquelle vous bossez et vous faîtes un break. Mais attention, vous n’allez pas aller voir vos emails ni vos réseaux sociaux, vous allez faire un vrai break, une petite coupure avec votre travail. Profitez-en donc pour aller vous faire un café. Vous revenez, vous repartez pour un nouveau pomodoro jusqu’au prochain break. Sachez que vous pouvez très bien passer plusieurs pomodoros sur une tâche. Par contre, Francesco Cirillo mentionne que si une tache dépasse les 6 pomodoros, cela peut vouloir dire qu’elle aurait pu être divisée en plusieurs tâches. Au contraire, si une tâche dure moins d’un pomodoro, vous auriez pu la regrouper avec une autre tâche. A la fin de la journée, vous reprenez votre liste et vous pouvez constater si vous avez tout accompli, travaillé plus rapidement, ou si, au contraire, vous avez pris du retard.

Ça marche pour le code, moins pour le graphisme...

J’ai donc testé, à la fois sur de l’intégration et du design. Pour ce qui est de l’intégration, j’ai trouvé ça très bien, vous vous concentrez sur 25 minutes, à fond, emails, Twitter et Facebook fermés (ah bah oui, vous êtes là pour bosser, pas pour procrastiner, et 25 minutes c’est pas si long !), et ça permet de segmenter le travail, tout en faisant des pauses. Personnellement, j’ai trouvé que j’arrivais à être concentré plus longtemps sur la journée, plus calme et au final, je terminais plus rapidement ce que j’avais à faire. Je pense que les périodes courtes de 25 minutes ne fatiguent pas trop et que le fait de ne pas se disperser avec tous les "à côtés" fait qu’on avance plus rapidement. Par contre, l’auteur dit de faire des breaks en se coupant de son travail. Je veux bien, mais je checke mes emails et mes tweets quand moi ? Ça se voit qu’il n’y avait pas tout ça dans les années 80 ! J’ai choisi de m’occuper de tout ça quand même sur certaines pauses. Et sur d’autres, j’essaie vraiment de couper de mon travail. Cela dit c’est pas évident ensuite de se remettre dans le bain rapidement. Ça dépend vraiment de ce sur quoi on travaille. Pour le design c’est très différent, en tout cas pour moi. Tant que l’idée n’est pas là, difficile de coller à une technique de productivité. Mais quand l’idée est là et que je me mets à travailler, j’ai du mal à m’arrêter après 25 minutes. Tant que je l’ai en tête, il faut que je fonce ! Donc, vous imaginez que la première fois, quand j’ai entendu le timer sonner et que j’étais en train de faire un bouton pixel perfect, je ne me suis pas arrêté en plein milieu pour reprendre 5 minutes plus tard ! J’ai commencé directement un nouveau pomodoro et ai bossé jusqu’à la fin de celui-ci. J’ai réessayé plusieurs fois et j’ai quand même trouvé ça difficile. D’autres personnes avec lesquelles j’ai discuté de cette technique trouvaient, au contraire, que Pomodoro était génial pour la créativité parce que finalement, ils se disaient "j’ai 25 minutes devant moi, voyons voir ce que je peux faire et trouver", tout en sachant qu’ensuite ils pourraient faire une pause avant de se remettre dans "le bain". Et chacun sait que faire des pauses permet au cerveau de se "régénérer" et donc de revenir avec un esprit rechargé et prêt pour une nouvelle dose de créativité. D’ailleurs, dans une présentation de Denise Jacobs que j’ai pu voir il y a peu, elle évoque la technique Pomodoro comme quelque chose permettant d’être créatif plus longtemps en faisant des pauses régulièrement. Le cerveau a vraiment besoin de ces breaks pour se régénérer et permettre d’être plus actif, plus productif.

Un pomodoro spécial pour les designers ?

En rédigeant cet article, je suis tombé sur des exemples où différentes personnes avaient décidé de choisir un timing différent des 25 minutes. Dans un article, Nascent Studio a choisi de faire des pomodoros de 15 minutes. Plus court mais finalement peut-être meilleure pour la créativité ? Si on part du principe que bien souvent il faut s’éloigner du bureau, prendre l’air, se changer les idées justement pour en trouver des meilleures, est-ce qu’un timing de 15 minutes + 5 minutes de pause pourrait optimiser une certaine productivité tout en gardant un esprit créatif, et ce, plus longtemps ? Finalement, chaque designer est différent et chacun pourra adapter cette technique à son mode de travail.

Un très bon outil de "time tracking"

Au delà du gain de temps, Il y a une chose que je trouve très sympa avec la technique Pomodoro, c’est que je gère beaucoup mieux mes todo lists en en faisant une pour chaque jour et surtout, je peux savoir combien de temps j’ai travaillé sur chaque tâche ! Si vous travaillez sur des projets où vous êtes facturé sur le temps travaillé, c’est parfait ! Un autre aspect intéressant, c’est qu’au fur et à mesure vous arrivez à mieux calculer vos temps de travail. Ça peut être aussi un atout pour faire des devis cohérents ! D’ailleurs, pour vous aider à mieux gérer tout ça, il existe des applications qui vous aident et vous accompagnent. Étant Mac user, j’ai repéré Pomodoro et My Little Pomodoro. C’est ce dernier que j’ai décidé d’utiliser.

Tout dépend de votre méthode de travail...

Alors, certains vont se dire "qu’est-ce que c’est que ce gadget ?", tout comme moi au début, je n’y croyais pas trop. Et puis, après avoir essayé, je me suis rendu compte que j’étais nettement plus productif, et ce, pour une raison toute simple : je ne passais pas mon temps à regarder mes emails et à y répondre tout de suite, ni à aller faire un tour sur Twitter. En gros, je procrastinais nettement moins. Maintenant, si vous gérez tout ce quotidien déjà très bien, vous n’avez probablement pas besoin de plus d’organisation et donc pas besoin de cette technique. Par contre, si vous avez l’impression d’être régulièrement trop dispersé, faites un essai. Ça pourrait changer votre manière de travailler ! ;-) Vous aussi vous avez testé Pomodoro ? Peut-être avez vous préféré le GTD, plus complet ? Ou tout autre méthode ? Si c’est le cas, n’hésitez pas à partager tout ça. Voir comment les autres travaillent est toujours intéressant et peut s’avérer être une source importante d’idées !

Webdesign et Référencement Naturel : la beauté ne fait pas la visibilité

Daniel Roch — Fri, 23 Mar 2012 09:30:34 +0000

Les deux choses sur lesquelles un internaute va s'arrêter sur votre site sont, d'une part, le contenu de la page et d'autre part, le design. Dans les deux cas de figure, cela suppose que le visiteur soit parvenu sur le site en question. Pour cela, l'un des meilleurs leviers de trafic est le référencement naturel. Le hic, c'est que la plupart des designers, graphistes et intégrateurs n'ont aucune notion de référencement, et vont ainsi freiner la visibilité d'un site sans le savoir. Dans ce guide, nous allons donc passer en revue certains des éléments constitutifs d'un site Internet et la manière dont ils doivent être mis en place par l'intégrateur. Certes, sa mission première est de finaliser l'aspect graphique demandé par son client, mais la notion de référencement ne devrait jamais être oubliée lors de ce processus, même si ce n'est pas une tâche qui lui a été expressément demandée. A la base, je pensais axer cet article sur le webdesign et le référencement sur WordPress, qui est un CMS avec lequel je travaille beaucoup, mais puisque la plupart des conseils donnés ici s'appliquent autant à l'intégration sous WordPress qu'avec un autre CMS ou une solution maison, j'ai dirigé cette publication sur le référencement et le webdesign en général.

1. Hiérarchisation de l'information

La balise H1

La balise H1 est un élément relativement basique sur un site Internet. Elle indique aux moteur de recherche le titre de la page actuelle, ce qui se traduit souvent par l'utilisation de cette balise pour le nom du site et/ou son logo.

Titre de la page

Et c'est souvent la première erreur que l'on rencontre : une balise H1 correspond au titre de la page actuelle, pas forcément au titre du site ! Sémantiquement parlant, elle doit permettre à un robot d'indexation (comme Googlebot) de comprendre le contenu en lui donnant un titre explicite, comme le fait la balise title. Elle est donc forcément différente sur chacune des pages. Par exemple :

la balise H1 de la page d'accueil est le nom du site
la balise H1 de la page contact pourrait être "Contacter la société X"
la balise H1 d'un article sera le titre de l'article
...

Deuxième erreur moins grave mais relativement fréquente en webdesign, l'utilisation d'une image pour la balise H1. Dans la mesure du possible, la balise H1 doit être du texte. Si vous n'avez pas le choix, comme c'est parfois le cas sur une page d'accueil (et le logo), veillez alors à bien renseigner la propriété alt de l'image qui va expliquer au moteur de recherche le contenu de celle-ci :

Troisième erreur : la balise H1 doit toujours être unique pour en optimiser l'utilité (même si les règles du W3C indiquent que l'on peut en avoir plusieurs). Si vous en avez plus d'une dans votre page, c'est que vous avez mal intégré votre maquette graphique pour le SEO. Vous devriez donc supprimer toutes les balises H1 en trop. D'ailleurs, pour vérifier que vous avez correctement placé cette balise, il vous suffit d'utiliser l'extension Web Developer de Firefox, et de cliquer sur "Information" puis "Plan du document".

Les balises H2 à H6

Dans la lignée de la balise H1, les balises H2 à H6 ont également de l'importance (même si l'impact est plus faible). Tout comme la balise H1, les autres balises de titres vont segmenter une page en contenus homogènes. Cela aide le visiteur à séparer et rendre plus lisible des sous-parties d'un même contenu, tout en aidant les moteurs de recherche à faire de même. Elles ne sont pas obligatoires, mais elles doivent cependant être bien implantées. Chaque niveau de titre doit en effet avoir systématiquement un niveau supérieur dont il dépend. Par exemple, on ne peut avoir de balise H3 si la page ne contient pas de balise H2 qui la précède, et ainsi de suite. Là aussi, l'extension Web Developer va vous permettre de détecter très vite ce genre de problèmes. [caption id="attachment_578" align="aligncenter" width="510" caption="Exemple de page bien conçue "][/caption]

2. Les liens

La propriété `nofollow`

Par défaut, de nombreux CMS (ou autres solutions) incluent la propriété rel="nofollow" sur certains liens. Pour ceux qui n'en sont pas familiers, elle indique aux différents moteurs de recherche de ne pas suivre le lien et de ne pas le prendre en compte lors de la répartition de la page.

ancre de mon lien

Le problème, c'est que Google a changé la façon de redistribuer la popularité d'une page : quand il rencontrait un lien avec l'attribut nofollow, il l'ignorait totalement et redistribuait la popularité qui lui était dû aux autres liens. Désormais, un lien nofollow bloque la transmission de pagerank, ce qui nuit à l'ensemble des pages de votre site (plus d'infos...). Si par exemple vous avez 5 liens et un en nofollow, vous bloquez l'envoi de popularité, ce qui est encore plus problématique s'il s'agit d'un lien interne. [caption id="attachment_582" align="aligncenter" width="510" caption="Popularité et nofollow"][/caption] Il est donc préférable d'éradiquer cette propriété lorsque vous intégrez un design : elle ne sert à rien sinon à nuire à la visibilité du site que vous créez.

Les liens dupliqués

Quand Google rencontre deux liens identiques dans une même page, il ne prendra en compte que le premier (comme l'ont démontré plusieurs tests récents). Hors certains clients désirent ajouter plusieurs fois dans la même page un lien vers un autre contenu. On peut ainsi se retrouver dans le cas de figure où ce client aura demandé l'ajout d'un lien vers la page contact dans l'en-tête, mais aussi le menu, la sidebar, le footer, en bas de chaque article, etc. [caption id="attachment_583" align="aligncenter" width="510" caption="Liens dupliqués"][/caption] Non seulement cela ne sert à rien pour l'ergonomie, car il vaut mieux un lien bien placé et visible que des dizaines de liens n'importe où, mais cela ne servira à rien non plus en référencement. Il faut donc lui expliquer l’intérêt de réduire le nombre de liens identiques en les rendant plus visibles. Si vous n'avez pas le choix pour certains liens dupliqués, que votre client souhaite conserver, sachez qu'il existe plusieurs méthodes pour contourner ce problème :

Faire un lien vers une autre page, qui fait une redirection 301 vers la page ciblée (mais cela augmente légèrement le temps de chargement).
Faire un lien avec une ancre # pour le second lien. Par exemple :
Libre à vous d'ailleurs de faire pointer cette ancre vers une partie bien définie de votre contenu.
Faire un lien en javascript, à l'aide par exemple d'un

Voici une image que j'avais réalisée sur le sujet, et qui résume les possibilités laissées en webdesign pour obtenir plusieurs liens vers la même page. En bleu, les méthodes qui permettent de dupliquer un lien sans nuire au référencement, et en rouge celles qu'il ne faut pas utiliser. [caption id="attachment_584" align="aligncenter" width="510" caption="Architecture de liens"][/caption]

`rel="author"`

Pas encore implanté sur Google.fr mais déjà présent sur Google.com, il est possible d'indiquer l'auteur d'un contenu. Le but est d'afficher dans les résultats sa photo, son nom et son prénom, le tout pour augmenter le nombre de clics et de visiteurs. [caption id="attachment_587" align="aligncenter" width="510" caption="Affichage de l'auteur dans les "rich snippets""][/caption] C'est assez simple à mettre en place, surtout que la plupart des CMS possèdent déjà des pages auteurs, et affichent par défaut un bloc sur l'auteur du contenu en bas de chaque article. Pour fonctionner, la page de publication de votre site doit faire un lien avec la propriété rel="author" vers la page auteur du site (qui regroupe les informations sur celui-ci)


Nom de l'auteur

Cette page auteur doit faire un lien rel="author" vers le profil Google+ de cette personne.


Google+

Et enfin, le profil Google+ doit incorporer un lien vers la page auteur du site. [caption id="attachment_590" align="aligncenter" width="510" caption="Profil Google+ de Joost de Valk"][/caption]

3. Le header de la page

Title et description

Les balises title et méta description sont obligatoires et doivent être systématiquement présentes sur chaque page du site. Voici comment elles doivent être implantées :

La balise title
- Taille : Elle fait 60 caractères maximum.
- Contenu : Elle décrit le contenu de la page, comme le fait la balise H1. En général, on conseille de mettre les mots clés les plus importants au début.
- Intérêt de cette balise : elle sert fortement à positionner une page. Il faut donc qu'elle soit la plus explicite possible pour le visiteur et le moteur de recherche.
- Exemple :
```
Titre de ma page
```
La méta description
- Taille : Elle fait 160 caractères maximum.
- Contenu : Elle doit décrire la page de manière plus exhaustive.
- Intérêt de cette balise : elle ne sert pas à positionner un contenu dans un moteur de recherche, mais c'est cependant ce texte qui va apparaître dans la page de résultats. Plus elle sera "accrocheuse", plus elle augmentera le nombre de visiteurs.
- Exemple :

Les balises métas inutiles

De manière générale, la plupart des autres balises métas ont peu d'intérêt. Concernant la méta keywords, elle ne sert plus à rien. Si votre client vous demande de l'ajouter, faites-lui comprendre qu'elle n'a plus aucun intérêt, qu'elle augmente légèrement et inutilement le temps de chargement, et que par contre ses concurrents peuvent s'en servir pour analyser et voler ses contenus. Vous pouvez également bannir toutes les balises métas DC.author, DC.description,... Elles ne servent à rien non plus.

Les balises Facebook

A l'inverse, d'autres balises métas parfois oubliées peuvent vous servir. Pour Facebook, vous avez par exemple les métas Og. Certes, elles ne servent pas directement au référencement naturel mais plutôt au partage de contenus sur ce réseau social. Plus vous facilitez ces échanges, plus vous aurez de chances d'avoir des liens spontanés vers votre contenu (et donc vous augmenterez le trafic et la visibilité). Ces balises se présentent ainsi :

Méta `og:locale`

Elle indique la langue du site.

Méta `og:site_name`

Elle indique le nom du site.

Méta `og:type`

Elle indique le type de contenu.

Cette méta peut d'ailleurs prendre de très nombreuses valeurs :

Activities : activity, sport
Businesses : bar, company, cafe, hotel, restaurant
Groups : cause, sports_league, sports_team
Organizations : band, government, non_profit, school, university
People : actor, athlete, author, director, musician, politician, profile, public_figure
Places : city, country, landmark, state_province
Products and Entertainment : album, book, drink, food, game, movie, product, song, tv_show
Websites : article, blog, website

Méta `og:title`

Elle indique le titre du contenu.

Méta `og:url`

Elle indique l'URL du contenu.

Méta `og:image`

Elle indique le visuel à associer avec la page.

Méta `og:description`

Elle décrit plus longuement le contenu.

D'autres balises pertinentes

Il existe aussi d'autres balises prises en compte par Google.

L'URL canonique

Il peut arriver que plusieurs URLs aient un contenu identique. C'est très mauvais pour le référencement et le chef de projet web devra essayer à tout prix de ne pas commettre cette erreur. Cependant, c'est parfois obligatoire dans certains cas de figure, comme par exemple un site ecommerce où un produit peut être affiché dans plusieurs catégories différentes (et dont la structure d'URL affiche la catégorie en cours). Si les URLs sont différentes mais que les contenus sont identiques, il faut alors utiliser une "rustine" pour indiquer à Google que l'on connaît le problème, et pour lui indiquer la page à mettre en avant. Son utilisation est très simple :

Avec cette balise renseignée dans chaque page au contenu dupliqué avec une URL canonique identique, c'est cette URL que Google retiendra (veillez donc à ce qu'elle existe).

Les balises link Prev et link Next

Dans le cadre de contenus qui se suivent, et où une vraie chronologie peut-être mise en place, voici deux balises intéressantes à mettre en place pour faciliter l'indexation des contenus par Google. C'est notamment le cas des pages d'archives (archives par catégorie, par auteur, par date, ...), de galeries, ou pour des guides scindés en plusieurs articles. En utilisant cette balise, l'intégrateur s'assure que Google renvoie le visiteur vers le début de la chronologie quand cela est pertinent, et que le moteur de recherche comprenne que ces contenus sont liés les uns aux autres. Par exemple, sur la deuxième page d'un guide, voici ces balises telles qu'il faudrait les utiliser :

4. Ergonomie

Les images

Mieux comprendre une image

À l'inverse des internautes, un moteur de recherche ne peut pas comprendre les images. Pour corriger cela, chaque image d'un site doit avoir une propriété alt renseignée pour la décrire.

Si ce n'est pas correctement mis en place, on peut se retrouver sur des sites très réussis graphiquement, avec des photos et des visuels à couper le souffle, mais que Google ne comprends pas et ne peut mettre en avant. Il ne faut jamais oublier que le contexte des images va avoir un impact important. Si votre image est une photographie d'oiseau (avec une propriété alt correctement renseignée), celle-ci aura plus de poids pour Google si le contenu autour de celle-ci parle également d'oiseaux.

La taille d'image

N'oubliez pas non plus d'afficher vos images en taille réelle. Ne les réduisez JAMAIS via CSS : préférez systématiquement la création et la gestion de miniatures, car cela va permettre la réduction du temps de chargement pour le visiteur et pour le moteur de recherche. L'idéal, c'est donc d'afficher une miniature qui fera un lien vers une image de grande taille. Pour mieux comprendre, voici comment intégrer proprement une image de grande taille dans un contenu texte :

La pagination

La pagination des contenus est trop souvent oubliée. La raison est que, dans certains cas, elle n'est pas présente sur la maquette graphique, ce qui pousse parfois l'intégrateur à ne pas ajouter cet élément dans l'ergonomie du site. Et pourtant, la pagination est cruciale pour le référencement naturel, tout comme pour le visiteur. En webdesign, pensez toujours à l'inclure ! Pour le visiteur, elle lui permet de naviguer plus facilement vers des contenus anciens, et pour le moteur de recherche elle permet de faciliter l'indexation de tous les contenus d'un site. Attention cependant à suivre quelques règles de base pour qu'elle soit efficace. Elle doit :

afficher le nombre de pages total
avoir des boutons "première page" et "dernière page"
avoir des boutons "page suivante" et "page précédente"
si le nombre de pages est trop important, elle doit faire des bonds dans la pagination, et ne surtout pas afficher chaque numéro de page.

Par exemple, dans le cas d'une catégorie avec 52 pages, et si le visiteur se trouve en 4ème page, voici ce que le site pourrait afficher : Page 4 sur 52 : 1ère page - 2 - 3 - 4 - 5 - 6 - 10 - 25 - 50 - dernière page

Le Fil d'Ariane

Le chemin de navigation (aussi appelé Fil d'Ariane ou BreadCrumb) est lui aussi régulièrement oublié en webdesign. Et c'est presque "normal" car cet élément d'ergonomie s'intègre rarement convenablement dans une charte graphique. Là aussi, c'est une erreur. Le fil d'Ariane a plusieurs rôles :

Pour le visiteur, il permet de comprendre exactement où il est
Pour le moteur de recherche, il lui permet de comprendre où se situe le contenu dans l'arborescence du site, tout en le liant de manière forte à sa ou ses catégories parentes.

Si vous en avez déjà un, c'est un plus pour votre site. Mais vous avez alors peut-être commis une autre erreur lors de l'intégration du chemin de navigation : le dernier élément de celui-ci ne doit jamais être un lien. Si c'est le cas, cela veut dire que la page fait un lien vers elle-même, ce qui n'a aucun sens pour le visiteur et le moteur de recherche. En le supprimant, vous évitez d'induire en erreur le visiteur avec un clic inutile, et vous permettez de transmettre une popularité plus importante aux autres liens de la page. Si par exemple je suis dans l'article "chocolat fondant", la dernière partie de ce chemin de navigation ne doit pas avoir de lien : Vous êtes ici : Accueil » Recette de cuisine » Recette au chocolat » Chocolat fondant

5. Schema.org

Depuis quelques mois déjà, Google, Yahoo et Bing se sont mis d'accord sur un format de micro-données à utiliser pour afficher des résultats plus pertinents. On peut ainsi voir apparaître des vidéos directement dans les pages Google, des avis produits ou encore des horaires d'ouverture. Voici quelques exemples : [caption id="attachment_596" align="aligncenter" width="500" caption="SERP pour visseuse électrique"][/caption] [caption id="attachment_597" align="aligncenter" width="510" caption="SERP pour Zenith Nantes"][/caption] [caption id="attachment_598" align="aligncenter" width="386" caption="SERP pour Structure Site Internet"][/caption] Pour chaque type de contenu, le format change. Par exemple, voici le code pour ajouter un avis sur une page de contenu :


Nom du test par Auteur, le 20 Avril 2012.


1/
5 étoiles

Avis détaillé et textuel.

Voici quelques liens pour une documentation complète sur les plus importants micro-formats :

Pour toutes les pages : WebPage (notamment pour les chemins de navigation)
Pour les évènements : Event
Pour une personne : Person
Pour un lieu : Place
Pour un produit : Product
Pour un avis ou un test : Review

Notez que l'emploi de ces micro-formats vous permettra de définir des entités nommées, et c'est ce qui servira à Google lorsqu'il deviendra un moteur de recherche sémantique dans un futur proche (Plus d'infos...).

6. La vitesse

Pour terminer, n'oubliez jamais le temps de chargement quand vous pensez au design de vos pages. Il a un impact (faible) sur le référencement et un impact (énorme) sur vos visiteurs. Pour ce point, je ne vais pas réinventer la poudre. Il existe de nombreux tutoriels et solutions différentes sur le sujet. Sachez que vous pouvez réduire le temps de chargement avec différentes actions :

Regrouper vos fichiers CSS et javascripts
Les minifier (pour réduire leurs poids)
Compresser vos images
Optimiser le fichier .htaccess
Réduire le temps de calcul php de vos fonctions
Mettre en cache vos pages
Fusionner vos images dans un Sprite
Utiliser un serveur plus robuste et puissant (Nginx par exemple)
Utiliser un CDN pour héberger les ressources statiques
...

D'ailleurs pour tester vos pages, pensez à employer ces deux outils très utiles :

Web Page Test : un excellent outil pour analyser le chargement pas à pas de son site, avec des préconisations complètes à la clé
GTmetrix : il allie les données de Yslow et de Google Page Speed au même endroit, tout en permettant de mettre en place un suivi journalier et gratuit du temps de chargement de son site.

7. HTML5

La nouvelle version d’HTML permet d’inclure un balisage sémantique lorsque l’on intègre une page. On peut ainsi facilement différencier le contenu réel des parties communes d’un site, comme l'en-tête, le pied de page, le menu ou encore une éventuelle sidebar. On pourrait donc supposer qu’HTML5 permettrait aux différents moteurs de recherche de mieux comprendre une page, de mieux mettre en avant le contenu réel et de pouvoir ainsi mieux classer les résultats, en favorisant ces contenus par rapports à d'autres similaires codés en HTML 4. Malheureusement, il n’en est rien. Actuellement, rien ne prouve qu’une page codée en HTML5 sera mieux positionnée qu’une autre en HTML 4. Et il y a une bonne raison à cela : d’une part la nomenclature de cette nouvelle version n’est pas finalisée, ce qui doit pousser les moteurs de recherche à être prudents sur le sujet, et d’autre part car le HTML5 est présent sur un nombre de sites trop peu important pour leur donner du poids (enfin pour le moment). Attention cependant, les moteurs de recherche évoluent vite. Il est donc probable qu’à terme, une page en HTML5 soit mieux comprise et donc mieux positionnée. Mais ce ne sera le cas que d'ici quelques années.

En conclusion

Quand on travaille sur l'aspect d'un site Internet, il ne faut jamais oublier le référencement naturel, autrement il ne sera jamais trouvé, et ne servira donc à rien. Chacun des conseils donnés ici est d'ailleurs logique en soi. Un site bien réalisé doit en effet suivre quelques règles de base :

être compréhensible
être bien structuré
être rapide à charger
être ergonomique

Et votre site, est-il optimisé ?

Design mobile : différencier web et application ?

Geoffrey Dorne — Fri, 16 Mar 2012 09:50:57 +0000

Lorsque j'ai été contacté par Matthieu Bué pour écrire sur WDfriday, j'ai été très honoré, de part la qualité du contenu, les sujets et thématiques abordés, mais aussi car j'allais pouvoir enfin vous parler de ce qui a beaucoup modifié mon travail de designer ces dernières années : le design d'interface en condition de mobilité (comprenez le "design sur mobile & tablette"). Aujourd'hui, je vais donc plus précisément aborder la question suivante :

Pourquoi & comment différencier les applications web mobile et les applications mobiles natives

Introduction

J'ai souvent autour de moi des entreprises avec lesquelles je travaille qui se posent la question, légitime, de la conception d'une web app ou d'une application native. Je les rassure donc tout de suite car elles ont déjà fait le plus dur : elles ont compris l'intérêt d'avoir leur place dans la mobilité (sur tablette et smartphone) ! Ensuite, vient très vite les choix suivant :

concevoir un site web mobile (en responsive design, pourquoi pas);
concevoir une web application consultable dans le navigateur du téléphone, de la tablette;
concevoir une application native iPhone, iPad, Android, Windows, etc.

avec les problématiques qui correspondent.

1. Le site web mobile

[caption id="attachment_524" align="aligncenter" width="510" caption="Mobile Website vs Standard Website"][/caption] C'est ce qu'il y a de "plus simple" aujourd'hui. Et quand je dis "simple", c'est dans le sens pratique, rapide et peu onéreux. Les navigateurs standards mobiles se perfectionnent (en attendant la sortie de Chrome sur mobile), et les possibilités sont nombreuses. La page web mobile s'adapte donc au format de votre téléphone, de votre tablette, et pour garantir une expérience cohérente entre votre ordinateur, votre téléphone, votre tablette et pourquoi pas le navigateur web de votre télévision, il existe la solution du responsive design pour obtenir un site web qui adapte comme un grand l'intégralité de son contenu, au support sur lequel il est affiché. Nicolas Torres a d'ailleurs écrit récemment un excellent article à ce sujet. Personnellement, en tant que designer, c'est ce que je recommande et conçois le plus fréquemment pour les clients qui ont des besoins assez simples sur mobile.

Côté design

Ici, le design est très orienté page web. On fonctionne donc avec des hyperliens et navigue de page en page ou en scrollant. Le site doit être avant tout pratique, ce qui limite hélas parfois l'expérience et l'interactivité. Il y a cependant encore beaucoup de choses à faire, notamment dans la notion de grille pour les sites web mobile, et notamment sur la façon dont il est possible de jouer sur la modularité de la grille. Alterner, textes et images ne vous empêche pas non plus d'insérer des vidéos sur votre page web mobile. [caption id="attachment_525" align="aligncenter" width="510" caption="Un exemple de site web mobile en image : PixelCloud"][/caption]

2. La web-app, ou application web mobile

C'est un cran au dessus en terme de technicité. En effet, une web-app est théoriquement une page web mais avec une expérience en matière de design et d'ergonomie très différente d'un simple site web mobile, qui se rapproche de l'application native. Par exemple, lorsque je travaillais avec Mozilla, nous avions créé une série de web-app mobiles qui permettaient de lire de la vidéo avec un player circulaire, un Photo Booth like en javascript, une application 3D qui utilisait l'accéléromètre du téléphone, etc. Enfin, les web-app mobiles tirent donc un avantage très fort du fait qu'elles n'ont pas besoin d'être développées une fois sur Android, une autre sur iOS, et encore sur Windows Phone, etc. À l'instar de cet avantage, la web-app mobile possède deux inconvénients : elles ne disposent pas des plateformes de diffusion comme l'Apple Store ou l'Android Mar... pardon, Google Play Store, et elles sont limitées d'un point de vue technique car elles n'ont pas - encore - accès à l'intégralité des possibilités du téléphone.

Côté design

Ici, on s'oriente déjà plus franchement vers les applications natives, on ne joue plus avec les conventions du web, on drag & drop des éléments, on a des "boutons" comme sur une application native, on se retrouve également avec plus d'images, qu'elles soient icônes, photos ou textures. L'idée dans la web app, c'est d'offrir assez de légèreté pour être chargée dans un navigateur web, mais assez d'immersion pour faire oublier que c'est "juste" une page web. L'expérience de l'application est donc très délicate et intéressante à faire passer. Il ne faut pas hésiter à passer du temps avec des utilisateurs pour recueillir leur retour d'expérience et pour voir si l'immersion se passe bien comme vous l'aviez prévue. [caption id="attachment_525" align="aligncenter" width="510" caption="Deux exemples de web-app en image. source | source"][/caption]

3. L'application native

L'application native, si vous avez un iPhone, un Android ou un autre smartphone, vous connaissez ! En effet, il s'agit des applications codées, non pas dans un langage web, mais dans le langage de programmation conçu pour le téléphone. Ces logiciels mobiles peuvent ainsi faire appel à presque toutes les caractéristiques de votre téléphone, que ce soit le gyroscope, l'accéléromètre, la caméra, le carnet d'adresse, etc. Cependant, l'application native demande quant à elle plus de temps, de budget et un développeur spécialisé en Java, l'Objective-C, etc. Plus de contraintes donc car il vous faudra développer votre application spécifiquement pour chacune des plateformes que vous ciblerez, mais vous aurez la possibilité de la retrouver très exposée sur Google Play Store, sur l'Apple Store et donc, souvent téléchargée. De même, il est possible de vendre son application aux utilisateurs, chose qui ne se fait pas - encore - avec les web applications.

Côté design

Ici, tout est permis. Vous allez pouvoir réaliser exactement l'interface que vous souhaitez, sans contrainte. Une application native étant enregistrée sur le téléphone (sauf certaines données qui seront mises à jour depuis Internet), vous allez également pouvoir faire la part belle à la vidéo, à la photo, au son. L'idéal pour une application native étant d'offrir une expérience unique et différente, là aussi, l'interactivité sera importante. Je compare parfois les applications natives aux "sites en flash" où tout est possible. Enfin, avec l'essort du HTML5, la comparaison s'amoindrie. [caption id="attachment_525" align="aligncenter" width="510" caption="Exemple d'une application native"][/caption]

4. Conclusion

Qu'elle soit application native, web-app ou simple page web, il vous faut trouver la bonne solution à votre question. Rien ne sert de développer une application native pour laisser les coordonnées d'une entreprise et quelques photos. À l'inverse, vous serez un peu à l'étroit sur une page web si vous souhaitez créer une application interactive avec beaucoup de fonctionnalités. Cela vous semble sûrement évident mais dans tous les cas, il faut prendre le temps pour bien évaluer ses besoins, ses moyens et ses ambitions. C'est dans le juste milieu de ces trois composantes que se trouvera sûrement votre réponse ;-)

5. Pour aller plus loin

CSS et Mobile First : procéder par amélioration progressive

Nicolas Torres — Fri, 02 Mar 2012 09:30:33 +0000

Le Web mobile est un environnement de développement en plein essors et nécessite une attention particulière de par les contraintes qu’il impose. Penser responsive est un bon début pour rendre l’expérience utilisateur accessible sur tout support, mais peu encore se soucient du temps de chargement qui fait voler en éclats le rapport coûts/bénéfices d’une intégration adaptative.

Voir la démo Télécharger la source

La dégradation progressive en première réponse au responsive

La première vague de designers qui ont répondu à la portabilité de leurs œuvres s’est ruée vers une solution facile qui était la dégradation progressive. Elle consiste en supprimer les effets et éléments moins essentiels d’une page en fonction de résolutions décroissantes. Cette solution royale pour des designs déjà accessibles sur bureaux ne demande que de rétablir les largeurs en pourcentage, et de modifier quelques valeurs ou propriétés CSS pour laisser le tout s’adapter au support de l’utilisateur, comme ci-contre :

article { float: left; width: 31.25%; margin: 1.0416666666%; } /* 3 colonnes(proportions de 960.gs) */
@media screen and (max-device-width: 640px),
@media screen and (max-width: 640px) {
	article { width: 47.9166666666%; } /* on passe à 2 colonnes */
}
@media screen and (max-device-width: 320px),
@media screen and (max-width: 320px) {
	article { float: none; width: auto; } /* on passe à 1 colonne */
}

Quelques exemples : www.juslisen.com, 10k.aneventapart.com, webdesignerwall.com. (Bien entendu, je n’évoque ici que l’adaptation du design, et non du contenu en lui-même, qui soulève bien d’autres problèmes qu’un débat a tenté de résoudre ici même). Comme le souligne Luke Wroblewski dans son ouvrage Mobile First chez A Book Apart, la navigation sur mobile croît sans cesse, au point qu’on peut espérer dépasser le milliard d’internautes mobiles d’ici à 2013. La priorité leur revient due aux performances limitées de leurs smartphones, et à ce jour, comme après chaque découverte, nous sommes à l’étape d’optimisation et de démocratisation des avancées.

L’amélioration progressive en réponse au temps de chargement

Lorsque vous appliquez la dégradation progressive, vous ne donnez pas moins de travail au navigateur mobile. En fait, vous lui en rajoutez, d’autant de « couches » que vous superposez. Le CSS est d’abord interprété comme pour un affichage bureau, pour ensuite, étape par étape, apporter des correctifs et rendre l’affichage adapté au mobile. Le bilan est lourd, une feuille complète et 2 ou 3 quarts de feuilles ont étés interprétés successivement. L’idée est alors de penser d’abord à l’interface mobile, puis d’apporter à chaque palier de résolution une valeur ajoutée à l’expérience utilisateur, traduite par une réorganisation des éléments, l’apparition de contenus moins essentiels, une division du contenu en colonnes etc. Avec quelques media-queries à notre secours, on parvient à quelque chose du genre

article { margin: 1.0416666666%; } /* 1 colonne */
@media screen and (min-width: 320px) {
	article { float: left; width: 47.9166666666%; } /* on passe à 2 colonnes */
}
@media screen and (min-width: 640px) {
	article { width: 31.25%; } /* on passe à 3 colonnes */
}

[caption id="attachment_383" align="aligncenter" width="300" caption="Cliquez sur l'image pour agrandir"][/caption] Chaque support ne chargera que ce qui lui est destiné. Un mobile, pourvu d’un piètre processeur, ne devra alors interpréter qu’une infime partie du CSS. La tablette, un peu plus performante, appliquera sans rouspéter la couche supplémentaire qui lui est destinée, et ainsi de suite. Nous avons donc offert ainsi la solution optimale répondant à chaque palier de besoin.

Notions à prendre en compte : un peu de bon sens

Il manque encore quelques précisions pragmatiques pour savoir assigner de manière pertinente le CSS efficace à vos éléments. Quelque chose qu’on oublie aisément lorsqu’on dégrade, c’est de supprimer les pseudo-éléments :hover pour les mobiles et tablettes pour la simple et bonne raison qu’ils ne sont pas visibles. En amélioration, ces éléments seront donc à placer sur le format bureau de votre design, et non à l’origine, sur mobile ; à noter que c’est d’autant plus primordial si vous utilisez des transitions/transformations :

a.social { display: block; width: 30px; height: 30px; /*...*/ }
@media screen and (min-width: 640px) {
	a.social { transition: all 0.3s ease; }
	a.social:hover { transform: rotate(30deg) scale(0.9); }
}

[caption id="attachment_384" align="aligncenter" width="300" caption="Les transformations ne seront pas chargées sur mobile"][/caption] Enfin, une question que beaucoup se posent sûrement, c’est de savoir quelles sont les largeurs à partir desquelles on « passe au palier supérieur ». Je vois apparaître beaucoup de résolutions d’appareils dans les medias-queries, et personnellement, je pense que ça n’a pas de sens. Vous ne faites pas un site de 1024 pixels pour un écran de 1024 pixels de large ? Pourquoi faire un design de 480 ou 640 pixels ? Commencez par analyser vos besoins avant de figer vos paliers. Définissez un seuil de clarté à partir duquel l’ajustement fluide ne suffit plus, à partir duquel vous réorganiserez vos éléments ; celui-là même qui donnera sa valeur au min-width de votre media-query. Vous aurez alors quelque chose de cohérent et de pertinent, plutôt que de vous contraindre à penser aux résolutions d’écrans, qui changent de mobile en mobile. Pour illustrer mes propos, je vous ai concocté une maquette. Je définis mes paliers de lisibilité en fonction de la taille de l’image. Lorsque j’ai 2 colonnes, je dis qu’elles sont appréciables de 200 pixels à 300 pixels (largeur maximale de l’image), ce qui correspond à un palier de 418 pixels à 626 pixels. Je vous invite à lire les commentaires de la feuille de styles pour le détail des calculs. Afin de vous rendre compte, le mieux est que vous testiez par vous-même en ajustant la taille de votre navigateur : [caption id="attachment_385" align="aligncenter" width="300" caption="D’accord, le formulaire pique les yeux, je vous le concède."][/caption]

Voir la démo Télécharger la source

Conclusion

La première étape pour penser mobile, c’est penser optimisation des performances. L’amélioration progressive est une solution qui demande d’inverser l’ordre des priorités et d’être assez flexible pour penser d’abord au petit écran, mais permettant d’alléger de beaucoup l’interprétation de vos feuilles de styles sur nos pauvres petits smartphones surmenés par notre avidité technologique. Ce n’est là, bien sûr, qu’un pas vers l’optimisation globale d’un site web pour mobiles, mais qui mérite son attention. J’aimerais enfin mentionner l’article de Raphaël Goetter sur le sujet qui complète ce qu’il y a à dire sur l’optimisation des CSS. Merci à vous qui m’avez lu jusque là, à Matthieu Bué pour sa patiente contribution, et à l’équipe du WDFR pour m’offrir cet auditoire. (Les images sont tirées du jeu Rayman Origins, empruntées à jeuxvideo.com)

L’intégration emailing : vous avez dit casse-tête ?

Enza Chaffron — Fri, 24 Feb 2012 10:11:50 +0000

Il arrive toujours un moment dans la vie d’un webdesigner où on va lui demander la créa et/ou l’intégration d’un emailing. Et là, c’est le drame ! Oui, c’est le drame car on le sait, ce n’est pas chose aisée. Des problèmes de décalages, d’espaces blancs, des clients mails qui interprètent correctement et d’autres pas… bref on redoute à l’avance les tirages de cheveux pendant des heures. Cependant, avec quelques astuces et un peu de pratique, on peut palier à tous ces petits problèmes. Je vais vous présenter ici les bonnes pratiques qui vous permettront de mieux appréhender l’intégration et ne plus considérer l’emailing comme votre bête noire.

1. Étape de création

Tout d'abord...

Bien penser son intégration dès le maquettage

C’est un point primordial qui vous évitera pas mal de difficultés lors de l’intégration. À l’étape du maquettage, il vous faudra penser à une mise en page simple mais impactante pour la mise en valeur de votre message. Un emailing doit être beaucoup plus simple qu’un site web. Voici quelques exemples de créations qui, à mon sens, allient une mise en page simple et soignée à un bon design : [caption id="attachment_427" align="aligncenter" width="510" caption="Sources : Blog du webdesign et Naf-Naf"][/caption]

Dimensions d’un emailing

Pensez vos dimensions, notamment la largeur. Il n’existe pas réellement de taille standard, cependant je vous conseille de rester aux environs des 600 pixels, cela pour permettre une bonne lisibilité sur le plus grand nombre de supports. Prenons l’exemple de l’iPhone 3 avec ses 320 pixels de large : même si le contenu de l’emailing ne s’adaptera pas (comme avec du responsive webdesign) la lecture sera tout à fait acceptable. La hauteur sera variable en fonction de votre contenu, mais gardez bien en tête que les éléments importants devront être placés là où ils seront le plus visibles, c’est à dire au dessus de la ligne de flottaison. "Mais qu’est-ce que la ligne de flottaison" me direz-vous ? il s’agit d’une ligne "imaginaire", fixée à 570 pixels de hauteur lorsque vous réalisez vos templates, qui symbolise la limite de la partie visible d’une page avant le scroll. [caption id="attachment_418" align="aligncenter" width="473" caption="Illustration d'une ligne de flottaison"][/caption]

Le choix des polices

Lorsque de la création, il vous faudra penser aux questions de typographie, à savoir quels textes seront en images et lesquels seront en police web. Sur un emailing, il est conseillé de respecter un ratio texte/image de 50% environ, sous peine de passer en spam lors de l’envoi. De même le choix des accroches, des textes est important ! Sachez que tout mot trop connoté commercial ou promotionnel est reconnu comme spam. Veillez donc à en utiliser le moins possible, voire pas du tout.

Éviter les choses trop alambiquées

Comme dit précédemment, il faut rester simple dans votre créa. Évitez par exemple les blocs aux bords arrondis avec du texte web à l’intérieur, ou alors pensez bien qu’il faudra le découper correctement de chaque côté. Préférez également les fonds unis aux dégradés pour les blocs de texte, car lors de l’intégration vous ne pourrez pas utiliser la propriété « background-image » qui n’est pas du tout interprétée. Dernier conseil : n’oubliez pas d’optimiser le poids de vos images, tout comme vous le feriez pour un site web.

2. Passons à l’intégration

Votre maquette est prête, toute belle et validée. Il va falloir maintenant l’intégrer. Vous avez deux choix : faire « à la mano » en utilisant Dreamweaver, le bloc note, ou autre ; ou l’intégrer avec l’aide d’un boilerplate. Celui-ci est, disons, une base de travail saine pour commencer, qui vous permettra de minimiser votre temps d'intégration. Je pense cependant qu'avant d'utiliser un boilerplate, il est impératif de savoir se débrouiller sans, c'est exactement la même chose que lorsque l'on apprend à faire un site web !

Retour vers le passé

Tout d’abord, ne pensez plus aux règles W3C, CSS, tout ça… nada, zéro. Pour l’intégration d’emailing il faut faire un énorme bond en arrière et utiliser le système de tables pour la mise en page... c’est dur je sais… Malheureusement il faut s’y résoudre car les

ne sont pas correctement interprétées par les clients mail de manière générale. Pour éviter les espaces blancs et autres déconvenues, il n’y a qu’une seule solution : imbriquer les tables dès que plusieurs colonnes ou lignes sont requises dans un tableau. Pour que chaque dimension des cellules soient les bonnes à l’affichage, il est nécessaire d’indiquer systématiquement la largeur exacte (en pixels), au risque de voir des décalages apparaître.

De la bonne utilisation des CSS (et compatiblités)

C’est là que tout va se jouer. Il faut savoir que chaque client mail interprète à sa façon les styles CSS dans un emailing. Certains accepteront telle propriété alors que d’autres ne la reconnaîtront pas. Déjà, ne jamais ô grand jamais ! utiliser une feuille de style CSS à part (vous pouvez toujours essayer, ceci dit, mais ça ne fonctionnera pas). Toujours mettre chaque style à l’intérieur de la balise concernée, à l’aide de la propriété « style ». Il existe heureusement des sites qui répertorient les compatibilités CSS en fonction des clients, notamment campaignmonitor.com et emailology.org. Dans tous les cas, comme pour la créa, il faut rester basique et éviter d’utiliser trop de propriétés CSS. La propriété html « height » est très peu reconnue également. Il faut donc ruser et utiliser soit une image d’espace style « blank.gif » (mais avec modération), soit jouer avec la balise
ou bien encore utiliser entre deux balises . Là, vous pleurez, je sais, mais vous n'aurez pas d'autres choix. Les messageries Hotmail et Gmail insèrent par défaut des marges entre les images. Pour palier à ce problème, la solution : la propriété CSS « display:block; ». Avec ça vous n’aurez plus de problème.

Vous avez le choix de l’envoi

Dans le cas où votre emailing serait destiné à un groupe restreint de destinataires, vous pourrez utiliser simplement votre client mail ou votre navigateur pour l’envoi de votre emailing. Sur Safari (sous Mac) par exemple, si vous cliquez sur Fichiers > Envoyer le contenu de cette page par courrier électronique, la newsletter sera directement insérée sur votre client de messagerie et prête à l’envoi. Mais assez fréquemment vous allez devoir créer une campagne emailing à l’aide d’outils de reroutage. Il en existe un certain nombre sur le net et ceux-ci vous permettront de bénéficier de services et d’outils de statistiques approfondis. Une liste non-exhaustive des plus connus : Dolist, CampaignMonitor, Mail Performance, YMLP...

Et n’oubliez pas de tester !

Testez sur un maximum de clients mails afin de vous assurer que tout est bien monté. Il existe des outils en ligne comme EmailOnAcid (préconisé par La Ferme Du Web) qui permettent notamment de le faire. Une dernière chose avant de vous lancer à corps perdu dans votre montage. Un lien du genre “Si vous ne parvenez pas à lire cet email, cliquez ici” est toujours le bienvenu dans le cas où on ne pourrait pas lire correctement l’email, voir les images, etc. Il vous suffira de mettre votre fichier html sur un ftp (avec les images, cela va de soi) et de le lier correctement au message.

Pour conclure

Voilà vous savez maintenant à peu près tout. J’espère que tout ceci vous aura permis de mieux appréhender le montage de nos chers emailings et de ne plus broyer du noir dès qu’un tel projet vous tombera dessus. Pour compléter cet article, vous trouverez un ensemble de ressources utiles, notamment sur l’utilisation de boilerplate. Merci pour votre lecture ! Emailology http://www.emailology.org/ HTML Email Boilerplate htmlemailboilerplate.com/ Smashing magazine http://coding.smashingmagazine.com/2011/08/18/from-monitor-to-mobile-optimizing-email-newsletters-with-CSS/ http://www.smashingmagazine.com/2010/01/19/design-and-build-an-email-newsletter-without-losing-your-mind/ Propriétés CSS supportées dans les emails http://www.campaignmonitor.com/css/ Templates gratuits sur CampaignMonitor http://www.campaignmonitor.com/templates/

Un an de coworking : retour d’expérience

Francis Chouquet — Fri, 17 Feb 2012 14:15:46 +0000

Ça fait exactement un an que je fais du coworking, c'est-à-dire que je partage un espace commun en ville avec d'autres personnes. Après un an, je m'apprête à emménager dans mon troisième bureau, c'est vous dire si le coworking c'est pas toujours simple ! Du coup, aujourd'hui, j'avais envie de partager avec vous cette année pleine d'expérience(s), et surtout les avantages et les inconvénients du coworking, tels que je les ai vécu. Mais commençons par le début. Pourquoi avoir choisi de prendre un bureau en ville ? Je suis freelance depuis 2004, et web designer depuis 2006. Ça fait donc quelques années que j'ai pris l'habitude de travailler chez moi. Avant que ma fille arrive, j'avais ma pièce, mon bureau, puis celui-ci s'est retrouvé à l'étage du dessous dans une pièce qu'on appelle "Hobby room" en Suisse et qui peut servir de bureau. Pendant 5 ans, j'ai donc travaillé de chez moi et je peux dire que j'ai bien apprécié cette période. On fait ce qu'on veut, on peut bosser en pyjama, faire des breaks comme on le sent, se permettre des siestes, jouer à la console, etc. Bosser de chez soi, ça a l'avantage d'être libre de faire ce qu'on veut, comme on le veut. Puis ma fille est née et assez rapidement, je me suis senti un peu claustrophobe. J'aimais toujours travailler à la maison mais j'avais du mal à déconnecter, à retourner à 100% dans ma "first life". J'avais toujours tendance à vouloir retourner derrière mon écran, "finir rapidement un truc…". Au bout d'un moment, je me sentais un peu comme un lion dans une cage. De plus en plus, j'avais besoin de sortir prendre l'air. Alors, j'ai décidé d'aller, de temps en temps, en ville, au Starbucks par exemple, avec un Wifi gratuit et des fauteuils confortables. Là, je passais des demi-journées à bosser sur différentes choses. Et malgré le bruit et le mouvement autour de moi, j'avais l'impression de revivre. Je découvrais qu'en plus d'avoir besoin de prendre l'air, j'avais besoin de voir du monde ! A partir de là, les choses se sont enchaînés. J'arrivais de moins en moins à rester à la maison. En sortant, je me rendais compte que je bossais mieux et surtout que j'avais des idées ! J'ai eu une discussion avec Denise Jacobs il y a peu, et elle me disait que la créativité a besoin de cet air: Elle a besoin de voir de nouvelles choses, de s'aérer. Et c'est exactement ce qui m'arrivait. Je me suis alors décidé à chercher un bureau en ville. Trop cher pour une seule personne (environ 400/500€, charges comprises). Puis, j'ai rencontré un ami britannique et développeur web qui cherchait également un bureau. On s'est donc dit qu'on pourrait peut-être trouver quelque chose ensemble. Et très vite, en février 2011, on trouve un super espace de travail. Ancienne usine des Jeans BigStar, avec vieux planchers et hauts plafonds. Et le tout au-dessus de la rivière qui alimente le moulin de la vieille imprimerie bourrée de presses Heidelberg. Vous voyez un peu le décor ! :D (cf la photo de l'article) Cette ancienne usine a été réhabilitée et occupée par une grosse agence de com’ locale qui partage ses locaux avec d'autres entreprises/freelances. Nous arrivions donc dans un espace avec d'autres personnes déjà installées, structure déjà présente, juste besoin de choisir son bureau et de commencer à travailler ! L'expérience a duré deux mois. Pendant ces deux mois, j'ai appris énormément. Travailler en dehors de chez moi me permettait de séparer ma vie professionnelle de ma vie personnelle. Le changement était énorme et ça se ressentait largement sur ma vie à la maison. Nettement plus disponible et agréable. Autre chose importante : en plus de m'aérer et de voir du monde, je discutais avec des "collègues", je faisais du social ! Ça peut paraître con mais c'est tellement important. Et tout en faisant du social, je rencontrais de nouvelles personnes en allant à des déjeuners, et au final je faisais du networking ! Quel changement ! Si le lieu était génial, il y avait tout de même un point négatif : pas de salle de réunion. Du coup, pour rencontrer des clients "en vrai" ou alors en appeler via Skype, c'était un peu compliqué. En fait, le coworking c'est bien si tu veux faire du social, vivre un peu en communauté. Par contre, si tu veux continuer à bosser dans ton coin, pas être dérangé, je ne suis pas sûr que ce soit la meilleure solution. Tu risques d'être perturbé par le bruit ambiant. En tout cas, personnellement, ça ne m'a pas dérangé, hormis pour faire des appels. Après deux mois, la boîte qui nous hébergeait a fait faillite. On a dû trouver un nouvel endroit. Mais fort de cette expérience fabuleuse, je n’avais clairement pas l'intention de retourner à la maison. On a rapidement trouvé un appartement transformé en bureaux, partagés avec d'autres entreprises, principalement des journalistes. Nous avons pris une pièce à trois. Le problème des responsabilités et du loyer On nous a donc loué cette pièce, mais le contrat de location devait être au nom d’une seule personne. Chacun s’est longuement regardé pour savoir qui prendrait le contrat. Finalement, c’est un de mes deux compagnons qui l’a pris. Mais que se passe-t-il si l’un s’en va ? C’est un des points compliqués, et ça nous est arrivé : le troisième compagnon a décidé de ne plus venir et nous a dit qu’il ne paierait plus. On aurait dû prévoir un contrat entre nous pour stipuler différentes clauses comme le départ de l’un d’entre nous, mais ça n’a pas été le cas. Nous avons donc dû chercher une troisième personne par nous-mêmes, en vain. Du coup, on a dû partager la troisième part du loyer en deux. Cela dit, il existe des structures où vous pouvez juste louer un “emplacement”, un bureau, c’est nettement plus simple à gérer. Louer des pièces à plusieurs peut être parfois compliqué à gérer, mieux vaut le savoir avant de se lancer. Pour revenir à ce deuxième bureau, l'ambiance était très différente de ce que j’avais connu dans l’usine. Toujours pas de salle de réunion, donc toujours compliqué pour les "confcalls". Par contre une cuisine, une salle de bain (ça peut toujours servir). Mais c'est là que je me suis rendu compte qu'en plus d'avoir un espace extérieur à chez moi, j'avais besoin de m'y sentir bien. Et si dans l'usine réhabilitée c'était super motivant, là, dans cet appart, je ne m'y sentais pas bien. Pas vraiment motivant pour trouver de bonnes idées. L'endroit était pas cher mais finalement pas très "créatif". En plus, il était situé dans un quartier populaire bruyant avec pas mal de travaux. Et au fur et à mesure, je suis retourné chez moi. Et c'est de ma chambre que j'écris cet article aujourd'hui. Je n'ai plus envie d'aller à ce bureau, et je l'ai compris rapidement. J'ai donc décidé de chercher autre chose et j'ai proposé à mon ami anglais web dev avec lequel je partageais le loyer de partir avec moi. Il était d'accord. On a finalement trouvé un autre bureau à partager, mais cette fois ci dans la vieille ville, et surtout à partager avec une photographe et un écrivain/éditeur. Je crois qu’en fin de compte, les soucis avec mon deuxième bureau était liés au lieu mais aussi aux personnes qui y bossaient : peu présentes, peu intéressées par le lien social (contrairement au premier bureau). On emménage le 15 mars et j'ai hâte d'y être. Le quartier est génial (vieilles ruelles du XVIème siècles) et plein de boutiques et bars branchés. De quoi se changer les idées. Et puis, partager un bureau avec d'autres créatifs, c'est important pour moi. Au final, cette première année de coworking aura été un peu mouvementée mais très riche en enseignements :

Avoir un bureau en dehors de chez soi permet justement de sortir, de s'aérer et de voir du monde, d’avoir donc un lien social et de faire du networking,
Ça permet de séparer clairement la vie personnelle de la vie professionnelle,
On ne tombe pas dans le confort de la maison, ou l'on gère pépére son temps,
Avoir un bureau en ville m'a permis d'être, de ce fait, nettement plus productif.

"Quels sont les aspects négatifs ?" Pour moi, si tu as une salle de réunion, il n’y a pas vraiment d'inconvénients. Si tu veux être tranquille, tu as toujours la possibilité de rentrer à la maison. Cette option est toujours disponible ! Privilégier la location d’emplacements plutôt que de pièces. Louer plutôt seul qu’à plusieurs. Vous pouvez toujours bosser ensemble mais ayez des contrats séparés, vous serez plus tranquilles. "Le coût du coworking ?" Premier loyer: 500 CHF, deuxième loyer: 230CHF et le bureau à venir sera 220CHF par mois. (1 euro = 1,2 CHF). C'est certes un coût non négligeable quand on est freelance mais quand on voit la hausse de productivité et le networking que tout ça permet, je suis convaincu maintenant que c'est plus que rentable. "Quelques conseils ?" Comme dit plus haut, je pense qu'il est important d'avoir une salle de réunion. Ensuite, éviter les boxes ambiance consultants de SSII avec des bureaux "mobiles" et des personnes différentes qui y viennent de temps en temps. Souvent les espaces de coworking proposent la possibilité de louer un bureau pour une journée, une semaine, un mois. C'est quand même plus sympa de partager un bureau sur le moyen terme avec les mêmes personnes (mais comme dit également au-dessus, tout en ayant un contrat individuel !). Et essayer de voir si elles aussi sont intéressées par ce lien social. Parce que si c'est pour tomber dans un endroit où personne ne se parle, je ne suis pas sûr que ce soit intéressant ! :) En tout cas, je conseille fortement le coworking. Si ça vous tente, n'hésitez pas à vous renseigner autour de chez vous, à visiter différents espaces, c'est la meilleure manière de voir ce qui existe et de savoir si le coworking est fait pour vous. Parce que pour certains, rester chez soi est idéal. Chacun a ses propres besoins. Si vous ne trouvez rien, vous pouvez toujours demander via Facebook ou Twitter si d'autres personnes qui habitent dans la même ville souhaitent monter une structure de coworking ou tout simplement partager un bureau ! Bref, différentes possibilités existent, à vous de voir ce qui vous convient le mieux ! :)

We want you !

Francis Chouquet — Fri, 10 Feb 2012 13:10:03 +0000

Aujourd'hui, nous allons un peu déroger à la règle d'un article chaque vendredi pour lancer un appel solennel à des rédacteurs extérieurs. Tout d'abord, un petit rappel. Fin décembre, nous avons décidé de mettre le tweetup entre parenthèses afin développer notre blog. Nous sommes convaincus qu'un blog est toujours, en 2012, un bon moyen de partager des informations et en ce qui nous concerne, de partager pas mal de choses avec la communauté web design francophone. Nous avons donc décidé de proposer des articles de qualité, si possible des articles de fond sur des sujets qui nous intéressent, traitant de notre métier au quotidien, les aspects créatifs du web designer, tout en allant toucher à l'intégration en vous parlant HTML et CSS, voir même JavaScript et jQuery. Nous voulons vraiment faire du WDfriday une ressource incontournable sur tous ces domaines. Cependant, nous n'avons pas vocation à rédiger des articles toutes les semaines, déjà parce que nous sommes une petite équipe de 5 personnes participant plus ou moins selon les disponibilités, mais aussi parce que nous ne sommes pas non plus forcément les mieux placés pour parler de certains sujets. Puisque nous voulons proposer des articles de très bonne qualité, nous avons décidé de contacter une trentaine de rédacteurs potentiels pour leur proposer de venir écrire un article chez nous, bénévolement*, sur un sujet qui leur est cher, et qui pourrait s'avérer très utile pour la communauté web design. Je le répète : ici, le but est de proposer du contenu de qualité qui permettrait à chacun de mieux travailler au quotidien, sur des aspects techniques, créatifs ou administratifs. Nous espérons donc que, parmi ces contacts, un certain nombre accepteront de se lancer dans l'aventure et d'écrire un article pour le WDfriday. Mais nous ne souhaitons pas nous arrêter à ces rédacteurs potentiels. Nous ne connaissons pas forcément tous les bons rédacteurs de la communauté francophone et peut-être y a-t-il parmi vous des personnes qui souhaiteraient rédiger un article pour la communauté via le WDfriday. Si tel est le cas, n'hésitez pas à nous contacter. Nous discuterons ensemble de vos propositions et si votre idée est retenue, nous mettrons en place un planning de publication qui vous permettra d'avoir le temps de rédiger votre article. Nous serons également à vos côtés pour vous aider si besoin est. Vous l'aurez compris, nous avons besoin de vous. Le succès du blog dépend de vous et de vos articles. Nous allons bien entendu participer en continuant à rédiger des articles qui nous tiennent à coeur, mais nous pensons que la diversité des auteurs, des points de vue et des compétences peut être un grand atout pour la communauté web design. Donc, pour conclure simplement, si vous aimez rédiger des articles et autres tutoriels, et souhaiteriez écrire pour nous, n'hésitez pas à nous laisser un commentaire et à nous proposer vos idées !! ;-) Nous allons mettre en place un formulaire de contact dans les prochains jours. * Pour ce qui est du bénévolat, nous allons travailler à une solution qui permettra de rémunérer chaque auteur. Souhaitant éviter de placarder un trop grand nombre d'annonces comme sur Smashing Magazine par exemple, nous allons étudier chaque solution et vous tiendrons au courant sur ce point. Nous prendrons le temps de trouver la meilleure solution. D'ailleurs, si vous avez des idées pour gagner un peu d'argent sans trop défigurer le site, n'hésitez pas à nous en faire part ;-)

Font-size, Responsive et Accessibilité : le Bon, la Brute et le Truand

Matthieu Bué — Fri, 03 Feb 2012 01:00:04 +0000

Lorsque j’ai commencé à apprendre le métier de webdesigner, il y a maintenant 9 ans, on m’a dit de créer mes maquettes sous Photoshop. Bon, depuis j’ai appris qu’on pouvait très bien les créer sous Illustrator ou Fireworks, mais dans tous les cas, le constat est le même : la majorité d’entre nous pensons les mesures en pixel. "Normal", me direz-vous. Je suis d’accord. Mais lorsqu’on parle de la taille des textes, définie par la propriété CSS font-size, là, rien ne va plus. Certains sont accros au px, d’autres sont entrés à l’école em, et les derniers attendent le messie rem. Il y en a d’autres, mais ce sont les trois plus importantes. État des lieux.

1. Une font-size à sa mesure

On va commencer par le plus simple...

L’unité px

L’unité px, qui correspond au pixel de votre écran, est celle que la plupart des webdesigners utilisent, ou ont utilisé à leur début. C’est une unité absolue. Son avantage est que votre texte aura l’exacte hauteur que vous lui avez définie, à l’endroit que vous avez choisi. Le problème : si vous décidez de changer de taille sur toute une zone, de vous-même, ou (par exemple) avec un bouton laissé à l’utilisateur pour augmenter ou diminuer la taille du texte, titres y compris, là, vous n’aurez d’autre choix que de redéfinir chacun des éléments sur lesquels vous avez spécifié une taille. [caption id="attachment_271" align="aligncenter" width="193" caption="Ex. : http://www.ouest-france.fr"][/caption] C’est là où la solution de l’unité em est intéressante.

L’unité em

Un em correspond à un cadratin, c’est à dire la largeur de la chasse de la lettre "M" majuscule de la police utilisée. (Plus d’informations sur la page Wikipedia Cadratin) Dans la pratique, en CSS, cette unité correspondra à 16px puisque c’est la taille par défaut des navigateurs, et pourra être assimilée au pourcentage. Comprenez 100% = 1em = 16px. C’est donc une unité relative, et en ce sens, le problème précédent peut être facilement résolu : vous modifiez uniquement la taille de l’élément englobant votre zone, et les éléments à l’intérieur hériteront de cette nouvelle valeur de référence. Cette histoire d’héritage nous simplifiera la vie dans ce cas, mais la plupart du temps, disons-le, c’est une vraie plaie ! Partons de ce principe : c’est une unité relative, il faut donc une valeur absolue de référence, qui sera la taille par défaut du navigateur, donc 16px. Espérons déjà qu’elle ne change pas ! 16px est alors l’équivalent de 1em... pas simple pour calculer les équivalences en pixels ! Une petite astuce nous permettra d’y voir plus clair : définissez une nouvelle taille à la racine de sorte que la base soit équivalente à 10px. Pour cela, appliquez une font-size à 62.5% de la taille par défaut (produit en croix power !), les dimensions du reste de la page seront ainsi simplifiées.

body { font-size: 62.5%; } /* 16px * 62.5% = 10px */
h1   { font-size: 2.4em; } /* = 24px */
p    { font-size: 1.4em; } /* = 14px */

Vous noterez sûrement l’emploi du pourcentage plutôt que l’équivalent 0.625em. “Pourquoi” ? Vous pouvez remercier nos amis Internet Explorer 6 et 7 qui n’interprêtent pas l’unité em sur les éléments html et body ! (Merci Raphaël Goetter pour cette info !) Bon, jusque là, tout va bien. Mais c’est maintenant que cette histoire d’héritage vient tout gâcher dans nos calculs ! Imaginons :


    Titre
    Texte

Je définis sur ma div une font-size à 1.4em, et sur mon titre h1 une font-size à 2.4em... ERREUR ! Ces 2.4em ne seront pas calculés à partir de mes 62.5% de 16px, mais bien à partir des 1.4em de son élément parent, soit donc 16px * 62.5% * 1.4em * 2.4em ! Chaque élément de votre page hérite de la taille de son élément parent. Une vraie plaie je vous dis ! Vous comprenez donc que l’utilisation de l’unité em est un vrai casse-tête de calcul et de tentative de non-superposition de valeurs. Mais réjouissez-vous, maintenant arrive l’unité rem !

L’unité rem

L’unité rem (pour "root em"), introduite par le CSS3, est un peu celle qu’on attendait tous. C’est en fait la même que l’unité em, donc relative, mais sans la notion d’héritage. Tout est fonction de la taille de la racine, c’est à dire la taille font-size définie sur l’élément html. Vous pourrez donc choisir une dimension de base en pourcentage comme ci-dessus, ou en choisir une en px, et ensuite définir vos dimensions sur chaque élément par rapport à celle-ci. Vous aurez la possibilité de tout modifier en une seule fois en changeant uniquement votre dimension de base. "Mais quel est le hic" me direz-vous ? Et le hic, celui qu’on attend toujours à chaque bonne nouvelle, a justement tendance à s’estomper : c’est la compatibilité entre navigateurs. Si on s’en réfère au site caniuse.com/rem, on se rend compte que finalement, on pourrait déjà se mettre au rem puisque compatible sur Firefox 3.6+ (Emmanuel Clément soulève tout de même un problème au zoom sur FF 7.0.1), Chrome 6+, Safari 5.0+ et Opera 11.6+, pour ne parler que des navigateurs desktop. Il faudrait bien sûr prévoir un fallback en px pour Internet Explorer puisqu’elle n’est introduite qu’à partir de la version 9. Enfin... c’est déjà pas si mal.

html { font-size: 62.5%; }
h1   { font-size: 24px; font-size: 2.4rem; }
p    { font-size: 14px; font-size: 1.4rem; }

Ainsi, nous avons la taille en px pour les navigateurs ne comprenant pas l’unité rem, et la deuxième pour écraser la première définition pour les navigateurs plus récents. Après ça vous me demanderez "mais alors, quelle unité utiliser ?". En premier lieu, je vous dirai de choisir celle qui convient le mieux à votre manière de coder, mais dans le contexte actuel du multi-supports, notamment le webdesign responsive, je préfèrerai vous répondre "attention" !

2. Le contexte multi-supports

Si vous vous êtes penchés sur la question du webdesign mobile, tablette et smartphone, pendant plus de 15 minutes, vous avez probablement dû tomber sur des articles tels que celui-ci ou celui-là qui vous expliquent que la résolution unique pour le web à 72dpi, c’est fini ! Désormais, quelqu’un au dessus de nos têtes de webdesigners passionnés semble vouloir s’acharner à nous donner la migraine dès qu’on veux réfléchir à la résolution des supports cibles et aux mesures à employer ! Dites-vous qu’un pixel sur votre écran d’ordinateur n’a pas la même taille qu’un pixel sur votre smartphone ou votre tablette, et même entre appareils de même type. Il faudra donc adapter les tailles de vos textes en fonction du support, voir même le contexte de lecture sur ce support. Le plus sage donc, selon moi, sera d’employer l’unité rem. "Donc on part sur le rem, c’est ça ?". Minute, papillon ! Maintenant arrive une question essentielle, celle de l’accessibilité !

3. Et l’accessibilité dans tout ça ?

Rappelez-vous, sur les anciennes versions des navigateurs, notamment Internet Explorer 6, lorsque vous vouliez zoomer, c’est la taille du texte qui s’agrandissait. Mais si cette taille avait été définie par une unité absolue, donc px, impossible de zoomer. C’était le propos principal du choix de l’unité de mesure pour les tailles de texte : l’accessibilité ! Il fallait utiliser une unité relative, le em, pour assurer cette accessibilité pour le plus grand nombre, sans mettre de côté les personnes à la vue déficiente. Mais ça, c’était avant ! Si vous testez le zoom sur votre navigateur actuel, vous verrez alors la page toute entière s’agrandir. Quelle que soit l’unité utilisée pour les tailles de texte, ça fonctionne, et même bien mieux qu’avant. Alors la question se pose : y’a t-il toujours une question d’accessibilité dans le choix d’une de ces unités ? Mieux vaut-il toujours privilégier une unité relative ? N’ayant pas les réponses, je laisse la place aux experts en la matière : Élie Sloïm, spécialiste en qualité, conformité et accessibilité des services en ligne, et Laurent Denis, expert en accessibilité, tous deux chez Temesis, Thomas Parisot, consultant web indépendant chez CyneticMonkey, et Stéphane Deschamps, expert en accessibilité et interopérabilité des sites web chez France Télécom - Orange.

Élie Sloïm et Laurent Denis : les référentiels d’accessibilité

Sur le plan de l'accessibilité, utiliser une unité proportionnelle aux réglages de l'utilisateur (em, ex, %, mots-clés) et non avec une unité dépendante du périphérique de consultation (px, pt, cm, etc.) va permettre aux utilisateurs équipés de navigateurs qui ne gèrent pas l'agrandissement des polices en taille fixe d'agrandir les polices sans difficulté. Pour sa part, le pixel pose un problème particulier : en pratique, l'absence d'unités en pixels était exigée dans certains référentiels d'accessibilité. Elle est liée à l'impossibilité d'agrandir la taille des caractères dans certaines versions d'Internet Explorer (6 et 7).
Note de Raphaël Goetter : IE6 et IE7 figent tous deux la taille en px en effet, mais IE7 introduit un "zoom de page entière", différent du "zoom texte", et le zoom par défaut sur IE7 est "zoom sur toute la page" (donc tout s'agrandit, contenus en px y compris), et non "zoom texte uniquement" (où les px sont figés). Il s'agit donc d'un choix volontaire d'utiliser le zoom texte uniquement sur IE7 qui pose des problèmes.
Maintenant : si vous décidez de ne pas vous occuper de ces versions de navigateurs ET de ne pas respecter des référentiels qui contiennent cette exigence, vous ne poserez pas de vrais problèmes d’accessibilité à vos utilisateurs. Si IE6 et 7 vous importent ou si vous devez respecter un référentiel accessibilité, dura lex sed lex, oubliez le pixel. Note : le pixel est une taille indépendante du media (contrairement au point ou au cm par exemple), mais il a été considéré comme une taille fixe à éviter à cause d'Internet Explorer 6 et 7. Les unités fixes telles que le point sont en revanche parfaitement adaptées dans le cadre d'une feuille de style CSS d'impression (media print).

Thomas Parisot : la relativité du support

L’héritage de la mesure en pixel doit très certainement beaucoup au mode de conception dans… Photoshop (pour boucler sur l’introduction de l’article) : tout est fixe, et à l’opposé de ce que peut être une page Web. Pour peu que l’on vienne du print, le cadre d’un écran d’ordinateur revient à mimer une feuille de papier. Canevas fixe ou pas, il est plus pérenne de concevoir les grilles de manière relative, rapport à la taille du texte et de la page : la largeur d’une colonne sera en réalité calculée en fonction de la largeur maximale de la page, leur nombre ainsi que la largeur souhaitée des gouttières. Il en va de même avec tout élément auquel on souhaite attribuer une taille, finalement ; que ce soit du texte ou des blocs.

Stéphane Deschamps : le monde n’avance pas si vite

Il y a pile trois ans, je posais exactement cette même question : et si on se dispensait des polices proportionnelles ? Après tout, tu l’as bien expliqué, les polices en pixels sont déjà recalculées avec des règles de trois internes pour deux raisons : la densité de pixels (dpi, dots per inch, points par pouce) n’est plus de 72dpi depuis longtemps, mais de 96 au minimum sur un écran de bureau et de plus de 300dpi (je crois) sur un iPhone avec retina display. À l’époque j’ai choisi le status quo et je suis resté en polices proportionnelles, le parc n’était pas assez mûr (beaucoup, beaucoup de IE6-IE7 circulaient encore). En novembre dernier, ressortie du serpent de mer sur Twitter (lire un résumé de la discussion), et là davantage de voix disent que voilà, ça y est, le parc de navigateurs est mûr. Raphaël (Goetter) notamment, comme tu le notes dans l’article, poussait déjà l’argument que si les gens ne font grossir que la police avec IE, c’est un choix. Je ne suis absolument pas d’accord, il s’agit de modalités opératoires différentes. Certaines personnes ne comprennent pas leur interface graphique et vont chercher dans les menus, d’autres ne cherchent pas et ont des raccourcis clavier au bout des doigts (j’en suis), et les plus nombreux, c’est sûr, auront les yeux qui zigzaguent sur l’écran et trouveront les contrôles de zoom global de la page (ils sont toujours en bas à droite dans IE ? Je n’en ai pas sous la main pour tester — au passage c’est diablement moins affordant que là où l’on est habitué à chercher les boutons d’interface : dans le bandeau vers le haut du navigateur). Les premières personnes citées iront dans le menu Affichage > Texte > Plus grand. Et boum, seul le texte sera agrandi, si et seulement si on utilise une police proportionnelle ; sans elle, point de salut. J’ai noté aussi (mais la pratique décline donc c’est sans doute anecdotique) que la technique des faux columns est très mal interprétée par IE7 si on met l’image de background sur le body et qu’on zoome la page. Donc on casse tout, assez violemment. Je n’ai pas les moyens ni même simplement l’envie de m’aliéner tous les utilisateurs potentiels d’IE qui soit utilisent le clavier et zooment le texte seul, soit utilisent le zoom page et subissent des dégradations inacceptables de l’affichage — je veux bien faire de la dégradation grâcieuse, mais uniquement quand elle est... (wait for it) grâcieuse. Merci de votre attention et pardon pour ma logorrhée, mais dès qu’on me donne une estrade et un micro, c’est plus fort que moi !

4. Conclusion ?

Le constat est donc clair : lorsqu’il est question d’accessibilité, il est fortement conseillé d’employer une unité relative ! De par son historique, la plupart des experts auront tendance à vous conseiller l’unité em, mais pour ma part, je trouve l’unité rem tout simplement géniale, à tel point qu’elle risque un jour de me faire perdre ma religion (blague de Raphaël — si si, on t’a vu ici !). Mais pour être totalement accessible, compatible, et plein-d-autres-choses-ible, il faudra prévoir un fallback pour IE 6/7 non pas en px, mais bien en em. Maintenant que les choses sont claires, à vous de voir le parti que vous déciderez de prendre : votre aisance de codage, ou l'accessibilité. Vous pourrez retrouver ces intervenants sur leur sites respectifs précédemment mentionnés, et également sur Twitter : Raphaël Goetter @goetter, Élie Sloïm @eliesl, Laurent Denis @ldenis, Thomas Parisot @oncletom, Stéphane Deschamps @notabene, et moi même, Matthieu Bué @twikito. Merci encore pour leur généreuse participation.

Pour aller plus loin…

Font sizing with rem sur Snook.ca
Polices, quelle taille choisir ? chez Alsacréations
Em, px, pt, cm, in… chez W3.org

Merci à tous ceux qui liront jusqu'ici ! :)

wdfriday

La conception dans le navigateur serait-elle un frein pour le processus de création ?

Un petit retour en arrière…

OK, mais est-ce si évident pour tout le monde ?

Et s'il y avait une méthode intermédiaire ?

Introduction à la performance pour le Web mobile

La notion de performance web

media queries et performances sont sur un bateau...

C'est bien mais... ce n'est pas suffisant

Quelques généralités

Réduire les requêtes

Minifier / Compresser

Ne charger que le nécessaire

Profiter des technologies modernes

Conclusion

La technique Pomodoro, un atout pour votre créativité ?

Qu’est-ce que la technique Pomodoro ?

Simple à mettre en oeuvre

Ça marche pour le code, moins pour le graphisme...

Un pomodoro spécial pour les designers ?

Un très bon outil de "time tracking"

Tout dépend de votre méthode de travail...

Webdesign et Référencement Naturel : la beauté ne fait pas la visibilité

1. Hiérarchisation de l'information

La balise H1

Titre de la page

Les balises H2 à H6

2. Les liens

La propriété nofollow

Les liens dupliqués

rel="author"

3. Le header de la page

Title et description

Les balises métas inutiles

Les balises Facebook

Méta og:locale

Méta og:site_name

Méta og:type

Méta og:title

Méta og:url

Méta og:image

Méta og:description

D'autres balises pertinentes

L'URL canonique

Les balises link Prev et link Next

4. Ergonomie

Les images

Mieux comprendre une image

La taille d'image

La pagination

Le Fil d'Ariane

5. Schema.org

6. La vitesse

7. HTML5

En conclusion

Design mobile : différencier web et application ?

Introduction

1. Le site web mobile

Côté design

2. La web-app, ou application web mobile

Côté design

3. L'application native

Côté design

4. Conclusion

5. Pour aller plus loin

CSS et Mobile First : procéder par amélioration progressive

La dégradation progressive en première réponse au responsive

L’amélioration progressive en réponse au temps de chargement

Notions à prendre en compte : un peu de bon sens

Conclusion

L’intégration emailing : vous avez dit casse-tête ?

1. Étape de création

Bien penser son intégration dès le maquettage

Dimensions d’un emailing

Le choix des polices

Éviter les choses trop alambiquées

2. Passons à l’intégration

Retour vers le passé

De la bonne utilisation des CSS (et compatiblités)

Vous avez le choix de l’envoi

La propriété `nofollow`

`rel="author"`

Méta `og:locale`

Méta `og:site_name`

Méta `og:type`

Méta `og:title`

Méta `og:url`

Méta `og:image`

Méta `og:description`