out through the winter throat

out through the winter throat le blog de Anahkiasen.

Redesign de mon portfolio

Redesign de mon portfolio

J’ai je l’avoue une habitude assez superficielle — et peut-être partagée par d’autres dans ma profession — quand je commence à m’adresser à quelqu’un qui fait mon métier, la première chose que je fais c’est cliquer sur le lien de leur site. Je jette un œil aux sources, et de là la critique vient vite.
Ce n’est pas logique je l’avoue car même moi qui suit très au courant de tous les bons codes et pratiques en terme de webdesign, je n’ai pas toujours encore le temps ou les moyens de tout mettre en œuvre. Mais certaines choses ne passent pas, comme les sites qui lient treize feuilles CSS et douze Javascript; du code non sémantique bourré de tirs croisés entre présentation et contenu; des designs soit ni fluides, ni reponsive, soient pseudo-proclamés mobile-friendly mais qui balancent à l’utilisateur des pages de 24 mégas.

Le double-tranchant c’est que d’autres s’adonnent aussi à cela et que dans des discussions houleuses, mon portfolio personnel donnait une bien triste image de moi professionnellement. J’ai fait mon portfolio peu avant de sortir de l’école, avant même de trouver mon premier emploi (que j’occupe toujours). À l’époque ayant seulement des bases en web et étant plus tourné vers le graphisme, j’avais fait ça vite fait, tout en pages statiques et n’y avait plus touché depuis.
Les années passant, j’étais dans un premier temps fier de montrer mon portfolio, puis progressivement gêné, et enfin honteux. Du coup j’ai mis un bon coup de collier, je me suis retroussé les manches, et je m’y suis enfin mis.

Penser device-agnostic

Avec l’explosion du mobile, et désormais des tablettes — pire, des frigos, des voitures, et j’en passe — tout le monde va sur internet, tout le temps. Dans ce contexte il est devenu de plus en plus complexe de faire des sites en gardant en tête les anciens préceptes et méthodes où l’on faisait de jolis sites de 960px de large sur Photoshop. Ce temps est révolu tout simplement car le web est désormais flottant, il n’est plus uni, c’est un bazar de centaines de hardware différents, chacun avec leurs tailles d’écran, leur capacités propres, et j’en passe.
De là est né le responsive design — altérer la feuille de style à des points clés pour adapter, masquer, afficher, réorganiser les blocs fondateurs à mesure que l’espace disponible varie. Ça a bien vite tourné malheureusement à la foire de l’Apple où si ça marchait sur iPad et iPhone, alors on considérait que ça marchait partout (ce qui est bien sûr complètement con). Le design device-agnostic c’est celui qui se réadapte quand il se casse, non par rapport à d’éventuels téléphones ou tablettes existants, garantissant que le site est préparé à tout ce qui sortir dans les années à venir. Et à la vitesse où ça va c’est la moindre des choses.

Don’t define your breakpoints according to some device, define your breakpoints when your design breaks

J’ai refait mon design pour qu’il s’adapte en conséquence de l’espace disponible. J’avoue être encore parfois coupable d’employer des largeurs assez peu agnostiques, en particulier sur ce portfolio. Utilisant des helpers SASS qui me restent, les breakpoints majeurs sont encore dans la veine des 768px et autres.



Le design est entièrement (à trois poils près) structuré par des unités non fixes comme des pourcentages bien évidement, mais aussi em et rem. Pour ceux à qui ces deux unités sont inconnues, l’em est une unité variable dépendant du corps du bloc sur lequel il est appliqué. Plus concrètement, au sein d’un paragraphe ayant un corps de par exemple 16px, 1em == 16px.
Mon idéal était de calculer toutes mes marges, hauteurs, corps etc en em qui cascaderaient depuis le corps général du site. Le problème c’est que dès qu’on travaille par exemple sur des titres, la valeur d’un em change radicalement et tout s’emporte.

Entre alors en jeu l’unité rem ou root em qui dépendent en toute situation du corps du site.
Ainsi un rythme vertical est maintenu, et comme toute le design est en SASS, un simple changement du corps du site cascade sur tous les blocs du site et leurs marges. J’ai pu ainsi aisément rendre le texte un poil plus grand sur mobile simplement en changeant la taille de corps à la racine.

html {
  font-size: 100%;
  line-height: 1.5em; }

@media (max-width: 768px) {
  html {
    font-size: 112.5%; }
}

SASS et Compass m’ont aussi permis d’implémenter des _fallbacks_ aux rems pour les anciens navigateurs, vu que Compass connaît le corps du site, il peut aisément faire les calculs correspondants.

myblock
  +rem(margin, 1rem 0.5rem)

// Génère
myblock {
  margin: 16px 8px;
  margin: 1rem 0.5rem;
}

Propre, net, les navigateurs qui savent lire le rem le lisent, les autres l’ignorent et gardent la dernière chose qu’ils comprennent : les pixels.

En web depuis un certain temps il y a deux grands principes : la dégradation gracieuse (graceful degradation) et être préparé au futur (future-proof).
Ce qui risque de se casser doit le faire de manière gracieuse et ne doit pas altérer l’expérience de l’utilisateur sur un site.
Ce qui est déjà en place doit être préparé aux futures évolutions du web et ne doit pas dépendre de technologies flottantes.
Beaucoup (dont moi) pour cela utilisent des librairies comme Modernizr qui permettent de tester les capacités du navigateur et de faire évoluer le site en conséquence — mais beaucoup se reposent trop sur ces dernières en oubliant que le CSS par nature ignore les propriétés non reconnues et permet ainsi via son principe de cascade de répondre gracieusement aux failles de l’âge dans le navigateur du visiteur.

C’est le même principe que quand on déclare une propriété background brute avec une couleur plate avant d’ensuite déclarer un fond dégradé.

Pleine utilisation de l’OOSASS

Pendant longtemps le CSS a été un peu délaissé face à d’autres langages. Il faut dire qu’à l’heure où l’on brandit l’étendard du HTML5/Javascript/CSS, ce dernier reste celui des trois qui met non seulement le plus de temps à valider les modules, mais de surcroît celui dont les mises à jour sont souvent les plus mineures.
On a eu quelques apports majeurs tels le CSS3D ou justement les rems, mais des modules cruciaux comme Flexbox (module de présentation et structuration de page) que l’on attend depuis la création du langage peinent toujours à montrer le bout de leur nez. C’est pour ça que dans énormément de feuilles de styles on retrouve pléthore de préfixes (-webkit-, -moz- etc) tout simplement car attendre que ces fonctions soient officiellement validées et recommandées vous mettrait en retard de plusieurs années en terme de webdesign.

Bref, CSS est un peu le vilain canard délaissé du lot et de fait la manière de coder en CSS a assez peu changé depuis sa création avouons-le (tout du moins jusqu’à l’arrivé des préprocesseurs qui a tout fait exploser).

Un des rares (voire seuls) changements majeurs dans la méthode ces dernières années est l’OOCSS — ou l’orienté objet appliqué au design. Résumé simplement : plutôt que de définir le style de chaque élément les uns après les autres jusqu’à avoir tout bouclé, on repère et isole des patterns dans le design que l’on abstrait en des modules (en l’occurrence des classes).
Si vous avez du mal à cerner l’idée pensez par exemple à de célèbres frameworks CSS comme Twitter Bootstrap ou Zend Foundation qui emploient l’OOCSS. On style ainsi les éléments comme cela :

.light-block {
  background-color: rgba(255, 255, 255, 0.5);
  color: #333;
}
.quote {
  text-align: right;
  font-style: italic;
}
<p class='light-block quote'>Lorem ...</p>

Les styles sont abstraits en des modules que l’on répartit ensuite aux blocs. La feuille de style est ainsi beaucoup plus concise et optimisé puisque le principe DRY (Don’t Repeat Yourself) si cher à la programmation est appliqué au CSS.
Si vous voulez en savoir plus l’OOCSS je ne peux que recommander de suivre des gens comme Harry Roberts qui est pour ma part mon point de référence en la matière.

L’OOSASS ne fait que varier peu le principe mais propose plusieurs avantages non négligeables. Les modules sont abstraits et définis de la même manière qu’en OOCSS, mais plutôt que via des classes, ils sont définis des placeholders SASS. Cela implique deux changements : on n’applique non pas les modules dans le code HTML mais bien au chaud dans sa feuille de style, ce qui produit des pages ainsi beaucoup plus propres et surtout sémantiques.
Ensuite, les placeholders ne sont générés dans la feuille de style finale que s’ils ont été employés, à l’inverse des modules OOCSS qui doivent être présents dans la feuille finale vu que celle-ci n’a pas moyen de savoir lesquels ont été appliqués ou non (le CSS n’étant à la base pas un langage de programmation).

%light-block
  background-color: fade(white, 50)
  color: grey(30)

%quote
  text-align: right
  font-style: italic

.article p
  @extend %light-block
  @extend %quote

Pour ce portfolio j’ai essayé de tirer au maximum profit de l’OOSASS même si je n’ai pas l’expérience OOCSS de personnes comme Nicole Sullivan que je recommande de suivre aussi au passage.

Du statique au dynamique

Mon premier portfolio était entièrement statique — le problème du statique c’est qu’il entraîne incontournablement une grosse part de copier/coller dès que l’on veut rajouter quoi que ce soit. Et du coup c’est la merde.
À l’occasion de refaire mon portfolio j’ai décidé de le refaire entièrement sous Laravel cité dans l’article précédent. La plupart des concepts clés de ce que je fais ont été répartis dans des modèles, les miniatures sont générées automatiquement, et je récupère mes photos et albums de Flickr directement depuis leur API via une petite classe faite vite fait maison.

Toute la mise en page est découplée en vues — chacune avec son but propre — pour permettre une mise à jour simple et concise, avec des hooks aux endroits clés pour permettre des variations si besoin selon les pages.

La base de données est entièrement en SQLite qui était amplement suffisant pour le peu de besoins que j’avais vis-à-vis de ma base de données.

Mobile-first

Je parlais plus haut de responsive design — il faut savoir qu’en la matière il y a deux écoles. Desktop first et mobile first.
La première c’est la méthode qui aux premiers pas du responsive a été privilégiée car il s’agissait à l’époque d’adapter des sites existants en versions mobiles — ou alors qui est pratiquée par des gens n’ayant pas passé le cap et dû aux habitudes préférant encore faire d’abord un site version large pour ensuite le réduire.

La seconde approche (et celle qui est aujourd’hui largement recommandée) en est simplement l’inverse. On part du plus petit espace possible, et on construit de là. Faisant pendant longtemps partie de la catégorie de gens sus-nommée ayant du mal à passer le cap, c’était je l’avoue mon premier essai.

Le mobile-first n’est pas vraiment une technique en soi, plus une méthode subconsciente. Quand on part de la vue la plus large, on a tendance à simplement masquer deux trois blocs, tout passer sur une colonne, et se laver les mains l’air de dire “Bon bah ça marche, voilà !”.
Partir d’un cadre de 300px de large implique plusieurs choses que l’on va exécuter sans forcément s’en rendre compte.

D’une : la hiérarchisation du contenu viendra naturellement. Quand on a autant d’espace qu’on le souhaite il est facile de continuer à bourrer les pages çà et là. Posséder un espace restreint force à réévaluer quel contenu doit être mis en avant pour chaque page, et à mettre en place des moyens de passer/masquer le contenu secondaire.
De deux, le contenu rajouté sur les espaces plus larges sera plus en accord avec celui déjà en place, puisqu’en tête sera bien établi ce qui est à mettre en avant.

J’ai du mal à décrire les différences de démarches, mais le résultat souvent décrit et qu’au lieu d’avoir une version bureau encombrée et une version mobile délaissée, on a deux versions traitées en égal et tout autant léchées.

Voir le portfolio

portfolio

Vous pouvez voir le portfolio en cliquant sur la miniature ci-dessus. Notez que même cet article publié, je compte encore améliorer quelques points, et suit plus qu’ouverts à vos remarques (ou aux bugs éventuels).

Les sources sont en libre consultation sur Bitbucket, en particulier dans le dossier public/app/sass pour voir l’OOSASS dont je parlais au-dessus.

11 commentaires pour “Redesign de mon portfolio”

  1. Mousse dit :

    Tu fais chier. Tu m’a donné envie de refaire le miens.

  2. Strutter dit :

    Complètement HS ;

    Je suis sincèrement impressionné par l’ensemble de tes travaux… j’en avais déjà une idée en voyant tout ce que tu avais posé sur ton blog pendant les précédentes années mais ton portfolio enfonce cette impression. Pour un procrastinateur de folie comme moi, sache que tu as l’air d’un extraterrestre.

  3. xandar dit :

    Vraiment impressionnant de voir le niveau que t’as pris en quelques années sur un domaine où a la base, c’était franchement flippant de voir ce que tu codais.

    Ton portfolio est vraiment cool, toujours dans un style décalé comme dans chacun de tes designs. J’aimerai avoir tes connaissances sur tout ce qui responsive-design.

    En revanche, seul point noir, certains de tes anciens sites/projets qui sont aujourd’hui complètement cassés (genre OVAP) et qu’on peut atteindre via ton protfolio.

    Gaffe aussi sur certains effets d’opacité, qui a mon avis sont trop poussés (genre certains blocs qui passent en opacité 100% quand on les survol alors que par défaut ils doivent être a 20%. C’est à mon avis vraiment trop peu.).

    Mais sinon j’adore. Vraiment.

  4. Anahkiasen dit :

    Ouais OVAP c’est la merde. Mais genre vraiment la merde. Au début j’étais tout guilleret genre “Je vais juste le refaire et ça sera niquel !”. Sauf qu’en fait sur le vieil hébergement il y a plus de BDD, rien. La seule sauvegarde des suggestions c’est vite fait le premier post du thread sur le SdZ que je mettais à jour de temps en temps.
    Pour l’opacité, après reste encore des détails à fignoler donc ouais je vais voir ça.

    Les nouvelles aussi sont pas encore en ligne, y a un boulot de conversion derrière, c’est la merde.

  5. xandar dit :
  6. Anahkiasen dit :

    Petit pédéraste.

  7. xandar dit :

    Also, quand on met la souris sur la zone a l’extrémité droite (FNFNFNFNFNFN) des images de la section “portfolio” (memorabilia, ovap, etc), ton image derp a mort. L’animation se joue pleins de fois en boucle (roll over, roll out)

  8. MathieuFROG dit :

    Ca me fout les boule de voir que tu as 22 ans et que tu es clairement plus calé que moi en développement web alors que c’est mon boulot depuis plus de 10 ans :D

    Mais quelque part c’est bien, ça me met des coups de pieds au cul pour que je ne me laisse pas ramollir !

    Merci pour tes articles.

  9. Thermostat dit :

    Très sympa, par contre fais gaffe aux fautes de syntaxes (Genre “qui je suis?” à remplacer en “Qui suis je?”)

  10. MatTo dit :

    Très chouette article, un bon état des lieux du web qu’on aimerait tous faire. Mais comme tu le dis, on est trop souvent rattrapés par la réalité, les clients, la direction, le temps, et l’argent. Et les designers aussi.

    Dans cette philosophie de servir le meilleur contenu pour le device, tu ne parles pas par contre des solutions de distributions d’images adaptées à l’écran de l’utilisateur. C’est de plus en plus pertinent de s’en soucier, entre les réseaux 3G avec des fair-uses ridicules, les tablettes et téléphones retina++, les vieux appareils qui rament quand on scroll du contenu trop grand, etc.
    Il existe beaucoup de solutions, dont beaucoup obligent à altérer le markup et proposer, via javascript, le chargement différé des images en différentes résolutions.
    D’autres, comme http://adaptive-images.com/ sont vraiment astucieuses, et délèguent la distribution des images (via une config htaccess) à un script php couplé à GD qui met crée des caches des images selons les résolutions en prenant connaissance de la résolution de l’utilisateur via un cookie défini soit en javascript, soit en php.
    Je recommande chaudement ce fork https://github.com/johannheyne/Adaptive-Images qui permet de prendre un peu plus la main sur les différents scénarios de distribution, et plus de facilité pendant le dev (debug infos sur image, gestion du cache, etc).

  11. Anahkiasen dit :

    Dammit, j’étais sûr que quelqu’un allait me piquer sur les responsive images :D
    J’ai longtemps réfléchi à inclure un paragraphe dessus dans l’article puis me suis dit que c’était déjà assez long.

    Je suis bien au courant de toutes les avancées sur le sujet, et de tout le bordel qu’il y a eu il y a 6/7 mois autour du rejet de <picture> au détriment de srcset. Apparement le poussière est un peu retombée depuis et le spec en cours propose un peu un mélange des deux idées, après faut voir le temps que ça mettra à implémenter. À l’époque ce qui posait surtout problème c’était les préparsers des browsers qui du coup chargaient toutes les images citées dans le bloc picture au lieu de celle qu’il faut.

    En tout cas il y a deux trois polyfills de picture et srcset dispos déjà, et effectivement j’étais tombé sur Adaptative Images à l’époque. C’est toujours mon plan d’intégrer ça au portfolio mais il faut d’abord que je regénère toutes les photos et images pour retina/mobile/etc.

    @Thermostat : C’est un peu fait exprès la tournure, c’est pour rendre le tout un peu moins officiel que les douzaines de “Qui suis-je ?” que je vois sur tous les portfolio. Après ça plait ou pas, c’est autre chose.

    En tout cas merci à tous pour les commentaires, ça fait plaisir :)

Laisser un commentaire

Si vous avez un compte sur WeFrag, connectez-vous pour publier un commentaire.

Vous pouvez, entre autres, utiliser les tags XHTML suivant :
<a href="" title="">...</a>,<b>...</b>,<blockquote cite="">...</blockquote>,<code>...</code>,<i>...</i>