La version 4 de mon portfolio est enfin en ligne, après quelques mois de gestation dispersée (mais néanmoins appliquée). Petit point sur ce qui est nouveau ici, et résumé des étapes qui se sont succédées pour accoucher de ce bébé coriace… J’ai essayé de faire court mais comme d’habitude il y en a des tartines, prévoyez un petit quart d’heure.

Pourquoi une refonte ?

Mon précédent site commençait à prendre la poussière (4 ans déjà !) et je ne le mettais plus à jour depuis un moment.

Cette v3 avait d’abord été codée tout en statique ou presque, puis j’y avais greffé une partie « blog » avec un WordPress au milieu de mon bazar : c’était proprement cauchemardesque ! Des fichiers éparpillés partout, des règles de réécriture en conflit permanent, des mises à jour qui menaçaient de faire tout péter à chaque manipulation… Bref, il fallait changer, et TOUT changer, back comme front.

D’autre part, m’étant remis à mon compte l’année dernière, j’ai logiquement fait évoluer mon positionnement professionnel : freelance occasionnel et freelance à plein temps, sacrée différence ! Il convenait donc de refondre un peu mon identité et mon propos afin de coller davantage au recentrage de mon activité.

Identité

J’avais déjà commencé par refaire mes cartes de visite en septembre, ça m’a servi de base pour décliner une DA qui garde la gamme colorimétrique du site précédent mais se veut plus abstraite.

J’ai réutilisé pour ma charte l’élégante et subtile fonte serif Gentium que j’affectionne particulièrement (c’est un peu ma Lobster à moi), en couple avec une sans-serif Calibri pour la titraille et les éléments périphériques. La typographie n’a jamais été ma spécialité, c’est pourquoi me rabattre sur des valeurs sûres qui ont fait leurs preuves me rassure toujours un peu…

Je ne voulais pas d’un site blanc passe-partout comme on en voit passer des dizaines ces temps-ci, avec un logo impersonnel, un zoning trop sage et une mosaïque de créas simpliste. C’est pourquoi j’ai pris le parti de forcer le trait en gardant mon « logo » bien massif associé à une baseline un peu riante, histoire de colorer franchement l’identité du folio. Le reste demeure volontairement très sobre, avec des filets fins et des ombres portées toujours très légères.

Web design

Sur le zoning et le contenu du site, j’ai mis l’accent sur l’espace et le minimalisme : finis les conteneurs étriqués, les carrousels, les popins, les widgets Twitter et consorts, les multiples pushes dans la sidebar, le footer démesuré bourré de liens, le blabla indigent.

Le but était clair : aller à l’essentiel, lisibilité, clarté, épure, pas de parasites visuels, pas de fonctions superflues.

Je suis parti sur une grille maison de 1120px (parce que le 1024×768 ça commence à bien faire), quatre colonnes de 280px chacune, avec une grosse sidebar gauche bien marquée pour diviser le layout. Le tout avec l’idée d’adapter ça au support mobile via responsive design au fil de l’eau (naïf que j’étais).

Et place aux contenus donc ! Les visuels des travaux présentés dans le portfolio sont volontairement démesurés et empilés les uns à la suite des autres sans autre forme de procès, pour une visibilité complète immédiate. La taille du texte de labeur est fixée à 16px (adieu l’Arial 11px). Les titres sont gros, les paragraphes bien espacés et en drapeau, l’interligne de 1.5, les champs de formulaire pleins de padding.

Ça ne m’a pas empêché de chipoter comme un névrosé sur des détails dribbblesques insignifiants, de mettre partout des petites textures, des petits reliefs, des petites fioritures. Je serai probablement le seul à les voir mais j’y peux rien, c’est plus fort que moi, je suis un besogneux.

Reste que dans ma volonté de simplification, j’ai également tenté un coup de poker ergonomique sur la navigation : tout se passe via un fil d’Ariane boosté en haut de page, avec un seul rappel générique des sections du site en footer. C’est un pari un peu osé et j’espère que ça fonctionne !

Dans le même ordre d’idée j’ai épuré énormément les formulaires, me passant de labels visibles (ma seule concession à l’accessibilité — enfin j’espère) en espérant que les placeholders choisis soient suffisamment explicites… Pas sûr que ça marche, n’hésitez pas à me dire votre ressenti sur ce point dans les commentaires.

CSS pour les finitions

Une fois fini tout ça sous Photoshop, j’entame l’intégration. Cette transition est toujours un peu épuisante pour moi parce que je suis déjà usé par tout le boulot abattu en créa auparavant et que j’ai bizarrement l’impression de reprendre un projet à zéro.

C’est pourquoi, quand j’ai la chance de travailler à la fois sur la DA et l’intégration d’un site, j’essaie de plus en plus souvent de lâcher Photoshop tôt en amont pour terminer le web design directement en CSS. Ça fait souvent gagner du temps, et c’est surtout bien plus sécurisant de designer en pouvant évaluer directement le rendu final du projet dans le navigateur (là où un PSD ne restera jamais qu’une intention). Cependant ce n’est possible que si la DA du projet est déjà bien arrêtée : s’il faut revenir sur des éléments graphiques structurants ou l’intention initiale, on commence à enchaîner les aller-retours problématiques.

Un autre avantage de passer rapidement en CSS, c’est qu’on peut tester rapidement les possibilités de rendu offertes par les derniers supports CSS3 des navigateurs. Ici, ça a été l’occasion pour moi de bidouiller avec les trucs à la mode : j’ai notamment bien rigolé avec les animations permises désormais par CSS, ça augure de bien belles choses à venir quand IE sera mort.

Malheureusement ça a été aussi l’occasion de constater que, comme d’habitude, les navigateurs font leur cuisine avec des priorités qui leur sont propres et que le support de ces nouveaux gadgets reste assez hétérogène. Et ce n’est pas forcément ceux qu’on attend au tournant qui déçoivent : je me suis par exemple rendu compte qu’à ce jour Webkit ne supporte pas les CSS-transitions sur les pseudo-éléments générés en CSS (alors que Gecko fait ça depuis Firefox 4)…

HTML5 ?

« Tu fais du HTML5 ? », me demandent souvent mes clients. La circonspection me gagne alors : techniquement, oui, mon Doctype est HTML5. Mais dans la pratique, je n’utilise probablement rien qui les fasse rêver la nuit, dans la mesure où le souci de rétro-compatibilité est au cœur de mes préoccupations et que pas mal de features du draft de HTML5 restent encore du domaine de la science-fiction.

Alors oui, j’essaie, quand c’est possible, d’utiliser HTML5. Par exemple, je suis passé aux liens de type block avec un plaisir non feint. Je truffe aussi mes formulaires des nouveaux types d’inputs (email, url, search) et des attributs qui commencent à être reconnus (placeholder, required), mais tout en prenant bien soin de dégrader systématiquement avec un fallback.

Du coup j’ai un peu de mal à considérer ça comme de prodigieuses avancées high tech, dans la mesure où je dois me farcir quoi qu’il arrive les fallbacks pour les anciens browsers, mais c’est sûrement très bon pour mon snobisme et à l’avenir ça simplifiera certainement les choses. Le fait est qu’aujourd’hui j’utilise largement plus CSS3 que HTML5, parce que ça se dégrade bien plus facilement et n’interfère que rarement avec le fonctionnel.

Si ce sujet épineux (mais passionnant) vous intéresse, on a écrit un article sur le sujet avec Vincent dernièrement.

body {display : table; }

Alors là, j’ai voulu faire le malin : don’t try this at home kids!

À chaque fois que je refais mon site, c’est l’occasion de me mettre à jour sur pas mal de choses, d’approfondir des domaines que je délaisse en temps normal et de tenter des tricks que je n’aurais pas le temps d’expérimenter dans un contexte projet habituel (ou alors de façon imparfaite).

Ici, j’ai donc pris le parti de faire l’architecture CSS totalement en display:table, pour « voir comment ça fait », et ça m’a valu quelques arrachages de scalp mémorables (merci à Vincent — encore lui — pour son œil avisé au passage).

Arrachage de scalp parce que premièrement, tous les navigateurs modernes ne comprennent pas exactement la propriété de la même façon (pour la petite histoire, Opera a besoin d’un display:table > display:table-row > display:table-cell complet là où les autres sont plus permissifs sur la structure). L’iPad m’a également fait quelques surprises rigolotes que je vous épargnerai ici.

Et parce qu’évidemment, supporter IE6-7 avec pareille lubie technique se transforme rapidement en numéro d’équilibriste bourré : il a fallu tenter de tout émuler par des float en abandonnant en route pas mal de ce qui faisait le sexy de la chose, pour au final, face à l’ampleur du charnier, lâcher purement et simplement l’idée de servir aux ancêtres un design qui ressemblerait (même de loin) au layout servi aux navigateurs modernes.

Bref.

Je n’en étais de toute manière qu’au début de mes ennuis puisque j’ai attaqué ensuite la déclinaison de tout ceci en responsive web design…

Responsive web design

Le responsive web design, c’est so 2011. Mais comme j’ai souvent du retard à l’allumage, je ne m’y étais encore jamais frotté sur un vrai projet : c’était l’occasion.

J’avais envie d’un gros site bien large pour que le DC d’agence sur son iMac en prenne plein la tronche : je me suis donc dit que j’allais commencer par une version wide (1120px) et décliner ensuite par paliers descendants pour les écrans plus petits.

Ha ha. Sauf que IE6-7-8 n’entravent strictement rien aux media-queries, et qu’ils affichent donc fort logiquement la seule partie de la CSS qu’ils comprennent, à savoir la version wide. Il a donc fallu recommencer, en prenant comme base la version 1024×768 pour décliner ensuite vers le haut (1120px) puis vers le bas (tablettes, mobiles).

Si IE8-9 et les différents supports mobiles que j’ai pu tester ont plutôt bien réagi à cette tambouille, sur IE6-7 il a bien fallu que je commence à regarder la réalité en face : faire le grand écart entre le web d’il y a 10 ans et le web de dans 3 semaines, ce n’est plus possible. J’ai donc mis à la poubelle tous les hacks que j’avais faits pour les ancêtres depuis le début du projet pour leur balancer une feuille de style minimaliste décalquée sur la feuille destinée aux téléphones… et finalement c’est pas plus mal.

Pour tout dire, je n’ai pas ouvert IE6 une seule fois depuis que j’ai commencé la refonte. Si vous aimez les feux d’artifice, tentez-donc l’expérience…

Bonnes pratiques

Je ne comptais pas aborder le sujet, mais c’est une piqûre de rappel qui peut faire du bien par les temps qui courent, où une génération de développeurs imbéciles commence à pondre des sites « Webkit only », reproduisant sans le savoir les erreurs du temps jadis où on « optimisait son site pour IE6 » sous prétexte qu’il était majoritaire.

Les bonnes pratiques, c’est pas fait pour les chiens, ça permet de faire du boulot solide, propre et pérenne.

C’est d’abord la séparation des couches sémantique, présentation et interaction de façon la plus stricte possible : un site doit idéalement être surfable sans CSS, sans Javascript, sans images, sans couleurs.

C’est aussi, dans la mesure du possible, une interopérabilité maximum, une accessibilité renforcée, une navigation possible uniquement au clavier, une attention particulière portée aux performances et à l’optimisation.

Bref, toutes ces belles choses qui font qu’on fait des sites web et pas des applications fermées et jetables. Mon site est très certainement imparfait, mais ce sont des notions que je garde en tête à chaque étape de la conception, j’ose espérer qu’il en reste quelque chose à l’arrivée.

Fin de la parenthèse…

LESS

LESS, c’est mon dernier grand amour. Pour ceux qui ne connaissent pas, il s’agit d’une méthode de pre-processing pour les CSS qui permet de nombreuses factorisations malines, des fonctions multi-usages, des héritages puissants.

Si certains lui préfèrent son cousin SASS, grand bien leur fasse (c’était pour la rime) ; en revanche je suis moins convaincu par les dernières bidouilles JS que j’ai vu passer sur le sujet, qui patchent les feuilles de style à la volée. Toujours cette répugnance à mêler les couches (du script pour la présentation, pouah !) et comme dans l’idée que ça doit un peu fâcher les performances.

Bref ! LESS associé à Zen-Coding dans mon éditeur c’est un gain de productivité bien trop intéressant pour que je puisse maintenant imaginer m’en passer.

WordPress

Voilà probablement la partie de la refonte qui m’intéressait le moins, mais il a bien fallu s’y coller.

Mon précédent folio était tout en statique, ceux d’avant également ou alors nourris par une base de données maison avec un back-office codé à la main. Là je me suis dit que quitte à utiliser WordPress pour le moteur de blog, autant profiter de l’outil pour me permettre d’administrer l’ensemble des contenus du site via une même interface.

J’ai donc creusé les custom post types qui permettent désormais de faire de WordPress un véritable petit CMS en créant des taxonomies à part pour des contenus « non-blog ». Je vous mentirais si je vous disais que ça a été une partie de plaisir et que j’ai fait ça en 5 minutes, mais au final je suis bien content du résultat ! J’ai des urls super propres, un back-end clair, un site relativement simple à maintenir. Merci à Gilles et Samy pour leurs conseils sur tout cela.

J’ai installé ensuite mes deux plugins fétiches, que je vous présente brièvement :

• Markdown Extra pour utiliser la syntaxe Markdown dans les articles, les pages et les projets du portfolio.
• SmartyPants Typographer pour avoir une belle microtypographie bien carrée.

Et nouveauté, j’ai également utilisé le plugin WP Resolutions qui adapte l’excellent script Adaptive Images pour WordPress. Pour faire court, ça permet de servir à votre navigateur des images redimensionnées à la taille de votre device automatiquement côté serveur : par exemple, si vous parcourez ce site sur iPhone, les images qui seront affichées seront plus petites que celles que vous verriez sur un ordinateur de bureau. C’est la solution la plus propre que j’aie trouvée pour effectuer ce petit trick qui me tenait à cœur, mais il en existe d’autres…

Si j’hésite souvent à utiliser des plugins (que ce soit pour WordPress ou jQuery d’ailleurs), c’est que le code HTML qu’ils pondent en fin de chaîne est souvent merdique. J’ai donc cherché (comme un forcené) des solutions pour pouvoir coder moi-même le front des features « vitales » de WordPress tout en les gardant bien pluggées sur le back-office afin de continuer à profiter de la puissance de l’outil. Le tout exclusivement via des fonctions, jamais via des plugins.

Le code HTML des formulaires de contact et de commentaires est par exemple 100% de ma main, ce qui m’a permis d’avoir un contrôle total sur la sémantique HTML et de gérer facilement le JS et l’AJAX par dessus.

Dans le même ordre d’idée, j’ai également essayé de nettoyer au maximum toute la crasse que laisse nativement WordPress dans le code (meta abscons, etc.).

À l’arrivée c’est plutôt clean et j’avoue savourer une petite pointe de fierté à avoir réussi à contorsionner WordPress à mes obsessions de propreté front-end…

En touche finale, j’ai branché sur chaque page mon outil de stats minimaliste préféré, BBClone (car je n’aime pas trop Google, et encore moins Google Analytics). WordPress a eu du mal à l’avaler d’ailleurs le BBClone, ce fut très pénible et c’est encore imparfait.

Et enfin, j’ai rajouté mes bidouilles habituelles dans le .htaccess pour les performances : gestion du cache sur les fichiers, de Gzip, des Etags. Et aussi, pour la petite histoire, une variable d’environnement PHP 5 pour OVH, dont les serveurs tournent encore par défaut en PHP 4 (si si)…

Et voilà

Ouf, j’ai fini. C’était la petite histoire de ma refonte, merci de l’avoir lue ! Je peux vous montrer mon bug tracker à présent :

Il reste probablement des bugs, n’hésitez pas à m’en faire part ici si vous les trouvez. Je suis également friand de toute sorte de retours, sur le fond comme sur la forme : les commentaires vous tendent les bras !

Et rendez-vous en 2016 pour la v5…