Le theming responsive dans Drupal - Part II - Les maquettes et wireframes responsives

Mercredi 18 Juin 2014

Seconde partie de notre étude, de nos recommandations concernant l'intégration et le theming responsive avec Drupal : maquettes et wireframes responsives.

Seconde partie de notre étude, de nos recommandations concernant l'intégration et le theming responsive avec Drupal : maquettes et wireframes responsives.

Retrouvez l'ensemble des considérations traitant du responsive dans Drupal :
Le theming responsive dans Drupal - Part I - Approche générale
Le theming responsive dans Drupal - Part II - Les maquettes et wireframes responsives
Le theming responsive dans Drupal - Part III - Le mode opératoire de bluedrop.fr

Je crois que nous sommes tous d'accord (au moins moi) pour dire que présenter une maquette à un client sous forme d'image jpg n'est plus une bonne solution car :
- Le web est désormais responsive (voir plus haut si vous n'êtes pas encore convaincus, sinon voir plus haut)
- Une maquette figée ne permet pas au client de voir ni : * les différents affichages en fonction des dimensions du terminal; * ni les interactions de l'utilisateur (menus, diaporamas, etc.).

Récemment, lors d'une réponse à appel d'offre que j'ai ratée, l'entreprise retenue avait fourni dans sa réponse un lien vers une présentation en ligne de la maquette. Et cela a représenté un plus décisif (bien que non exigé) dans la notation.
Cela va nous poser plusieurs problèmes.

Dépasser Photoshop

C'est l'outil de référence, à tel point même que certains confondent la connaissance du design web et la maîtrise de ce logiciel propriétaire (les fous...). Tout comme à une époque (pas si lointaine malheureusement), l'intégration web se résumait à une seule ligne dans les offres d'emplois : * Maîtrise de Dreamweaver. Il y'a depuis quelques temps une fronde (pas totalement imméritée) vis à vis de Photoshop. Certains ne jurant plus désormais que par le design 100% dans le navigateur.

Je pense qu'il ne faut pas aller jusqu'à jeter le bébé avec l'eau du bain, mais il est vrai que dans sa version actuelle, PS n'est plus adapté au web d'aujourd'hui.

Il sera toujours utile pour l'illustration, mais il ne l'est plus pour la mise en pages. Il y a beaucoup de logiciels (comme Sketch, uniquement disponible sous Mac OSX désolé) qui tentent d'offrir une meilleure alternative aux besoins actuels. Mais on peut raisonnablement penser qu'Adobe rectifiera le tir prochainement.

Il reste qu'à l'heure actuelle, une maquette HTML statique est la meilleure alternative.

La multiplication des frameworks

C'est bien joli de vouloir réaliser un design directement dans le navigateur, mais il faut avouer que c'est bien moins rapide, direct et intuitif que de le dessiner dans Photoshop.

Il n'y a pas une semaine sans que je découvre via les canaux d'information habituels (Twitter, flux RSS, etc.) un nouveau framework de développement HTML / CSS.
C'est un peu la jungle, comme cela l'a été dans les framework JS avant que jQuery ne rafle la mise. Il y a différentes approches du problème :
1. Ceux qui ne jurent que par le fait maison;
2. Ceux qui préfèrent les solutions les plus légères possibles comme Skeleton, Susy ou encore Bourbon, Neat, Bitters, Refill (mes chouchous du moment);
3. Ceux qui préfèrent les solutions clé en main comme Twitter Bootsrap ou Zurb Foundation (mon préféré dans cette catégorie), qui en plus d'un système de grilles, fournissent des composants de navigation, des diaporamas, etc., etc.;
4. Toutes les solutions intermédiaires.

Je ne pense pas qu'une solution plutôt qu'une autre arrive en situation de monopole (en attendant que le W3C statue définitivement et que les navigateurs s'y conforment pour les grilles). Tout dépend du but à atteindre.

Au-delà de fournir une base solide (c'est à cela que sert un framework après tout) pour le développement front-end, le but de ces outils est également de servir au prototypage rapide d'une application. En d'autres mots, on peut aussi s'en servir pour remplacer Balsamiq et Axure.
• La question n'est plus aujourd'hui de savoir s'il faut utiliser un framework ou pas ?
• La question est : quel framework utiliser dans quelle situation ?
• Photoshop, Balsamiq, Axure sont encore des outils utiles. Mais il faut se poser la question de la chaine de production : ** Ne pas refaire les choses plusieurs fois (rester DRY quoi...). Prendre du temps sur Balsamiq pour qu'en suite quelqu'un le perde à nouveau pour faire un site HTML Statique ?

Générer rapidement des sites statiques / prototypes ?

Comment faire pour :
• Présenter des pages statiques à nos clients / prospects plutôt que des images ?
• Réduire au maximum le temps de passage d'une page statique à une page Drupal ?
• Avoir des outils simples utilisables aussi par les chefs de projet ?

C'est la quadrature du cercle. Si l'on veut réduire au maximum le temps passé à l'intégration à partir d'une maquette statique, cela revient déjà à faire de l'intégration. A l'inverse, si nous utilisons des systèmes trop simples, le travail risque d'être à faire deux fois.

Il existe actuellement de nombreux outils pour générer des sites statiques. On peut légitimement se demander à quoi cela peut-il bien servir en 2014, mais ils ont encore leur utilité :
• Ils ne font pas travailler PHP ou MySQL, il n'y a rien de plus performant.
• Lorsque le site est petit et qu'il n'est pas souvent mis à jour, * parce que le client ne sait / veut pas le faire. * parce que le client a les compétences pour le faire.
• Pour prototyper rapidement un site et le présenter en situation réelle.

Mais pourquoi ne pas simplement tout faire à la main ?

Fonctionnalités / Avantages

La plupart fonctionnent sur le même principe :
• Il existe un gabarit de base (à la manière de page.tpl dans Drupal) qui sera utilisé de pages en pages.
• Il est possible d'utiliser des partials (l'équivalent d'includes en PHP) pour les éléments qui reviennent de pages en pages (ex : header, footer...). Ces partials peuvent accepter des variables qui modifient leur présentation (ex : passer en variable les intitulés d'un menu ou encore les images d'un diaporama).
• Mais surtout ces systèmes fournissent au développeur / designer :
* Un environnement de test (serveur local) simple à mettre en place et à travailler (Livereload)
* Un système type guard pour prendre en compte tout changement dans une feuille de style ou un gabarit et recharger le site.
* Une chaine de traitement des _assets_ (CSS, images, js) pour les compresser / _minifier_ / agréger, etc.
* Des scripts pour déployer le site final.
* Des outils de test (ex : Phantom.js)

Quelques générateurs

En voici quelques-uns choisis très subjectivement. Ils sont assez rares en PHP, on les retrouve surtout en Pyhton, Ruby ou plus récemment Node.js bien sûr ! Mais il faut bien garder à l'esprit qu'au final ce sont toujours des pages HTML qui sont générées.

Middleman

Je le connais bien, j'ai même fait une présentation rapide de cette solution lors d'un pastisrb à Marseille.
• accepte tout compilateur CSS (Sass, Compass, Less...)
• accepte tout compilateur HTML (Markdown, Slim, Haml...)
• accepte tout compilateur JS (Coffeescript...)
• Système de partials et helpers basés sur Padrino (un framework de développement Ruby) très extensible.

Jekyll (et dérivés)

C'est une solution très utilisée (il y a même un module Drupal pour rendre un site 100% statique) pour les blogs.
Exemple : La revanche du site

Wintersmith

La même chose mais avec Node.js.

Yeoman

C'est un projet de Google pour faciliter le travail des dev front-end. Ce n'est pas vraiment un générateur de sites statiques, mais une suite d'outils qui peuvent être utilisés dans ce sens. Le but premier de Yeoman est plus de faciliter le développement d'applications javascript complexes (basées sur node.js ou angular.js) mais il a été rapidement détourné et on trouve toutes sortes de generators.

A noter que Yeoman utilise massivement 2 technologies à connaître impérativement aujourd'hui dans le développement front-end :
Grunt
Bower

Patternlab

J'ai gardé celui-là pour la fin, car il se destine exclusivement au prototypage et à la génération de style guides. C'est un projet de Brad Frost qui est loin d'être un débutant en la matière et qu'il utilise pour ses propres clients. Il est disponible en Node.js et en PHP ce qui n'est pas négligeable pour nous.

Philosophie
Patternlab permet de construite au final des pages comme on pourrait les présenter sous formes de PSD. Ces pages sont des instances des templates (blog). Ces templates sont composés d'organismes (articles, commentaires...).
Ces organismes sont eux-mêmes composés de molécules (blocs, médias, navigations) qui sont eux-mêmes produits à partir d'atomes (textes, headings, images, champs...). Dans le sens inverse : atomes > molécules > organismes > templates > pages. Tout cela est extrêmement modulaire et suit les principes OOCSS et Smacss.

Patternlab ne fait aucune supposition sur le framework, le compilateur CSS utilisé. Il laisse l'utilisateur libre de ce choix. Il utilise uniquement le langage de Mustache pour le templating.
Tout l'intérêt de Patternlab est qu'il va présenter automatiquement tous ces atomes, (...), pages et permettre également à l'utilisateur de faire varier la taille du site dans différentes résolutions. Il est donc idéal pour tester un affichage responsive.

Voir : http://demo.patternlab.io/

A suivre...

Le theming responsive dans Drupal - Part I - Approche générale
Le theming responsive dans Drupal - Part II - Les maquettes et wireframes responsives
Le theming responsive dans Drupal - Part III - Le mode opératoire de bluedrop.fr

Ludovic Coullet
Twitter : @lcoullet