AMP : Principes de design

Après avoir expliqué en quoi consistait AMP et comment le mettre en place, je vous propose une parenthèse design à notre série consacrée au projet AMP. Dans ce deuxième article, nous allons passer en revue ce qu’il faut savoir pour concevoir une page sous AMP, et quelles en sont les limitations.

Design + AMP = ❤  ou 💔 ?

AMP ayant été créé pour résoudre le problème des sites mobiles lents et mal foutus, on pourrait imaginer que les limites en terme de design sont importantes. Honnêtement, en l’état actuel des choses, je ne vois pas de contrainte insurmontable.

Quelques règles à connaître :

• Le CSS est limité à 50ko (pour comparaison, le fichier CSS minifié de Bootstrap v4.1 pèse 140ko)
• Certaines propriétés CSS interdites : !important, filter (traitement CSS sur les images)
• Les animations sont possibles, mais uniquement sur les propriétés transform et opacity (pas d’animation sur la taille d’un élément par exemple)
• Les polices web sont autorisées, uniquement depuis certaines sources comme Google Fonts et fonts.com. Les fichiers des polices ne sont pas pris en compte pour la limite de 50ko.

Les contraintes du designer sont fortement liées aux contraintes du développeur. Au lieu d’utiliser des balises HTML classiques et de créer ses composants en JS, le développeur est obligé d’utiliser les composants fournis par la bibliothèque AMP. Le style de ces composants est complètement surchargeable en CSS, par contre le fonctionnement et les interactions sont imposés.

Par exemple, un carousel version AMP permet de d’afficher des miniatures de photos en bas du carousel, mais pas de les animer. Impossible également de contrôler le défilement du carousel par le scroll, ou par le clavier.

Autre exemple, les onglets. AMP ne propose pas de composant pour créer un contenu organisé sous forme d’onglets. Et encore moins la possibilité d’ajouter des animations entre chaque onglet. L’agence Upperguard (très beau site au passage), en charge du design et du développement du site ampproject.org, a été confronté à cette problématique. La seule solution qu’ils ont trouvé : remplacer les onglets par des liens statiques. Je vous laisse visionner ce court extrait de leur passage à la conférence AMPConf 2017 pour en savoir plus (extrait à partir de 08:10) :

Pour finir, de manière générale, les évènements attachés au scroll de la page sont à bannir : apparition du contenu selon le scroll, changement de la taille du header selon le scroll, déclenchement du scroll vers un élément au clic sur un bouton, etc.

Quid des pubs ?

Google étant à la manoeuvre, vous pensez bien que les pubs sont belles et bien présentes. Evidemment, tous les formats intrusifs (popups, overlays, scroll to play…) sont absents. Je n’ai vu que deux formats autorisés : la bannière classique de différentes dimensions, et la zone sticky en bas de page (max 100px de hauteur).

Compromis et coopération

Les composants fournis par AMP ne couvrent pas tous les cas d’usage. Par conséquent, les designers doivent trouver des façons de contourner ces limitations, et surtout faire des compromis.

Encore plus que d’habitude, il est très important d’impliquer les développeurs très tôt dans la phase de conception. Ils pourront valider la faisabilité technique des propositions graphiques, et le cas échéant, discuter avec le designer pour trouver un compromis satisfaisant.

J’espère que cet article aura répondu à certaines de vos interrogations. N’étant pas designer moi-même, j’ai sans doute oublié pas mal de sujets qui peuvent poser soucis. Si c’est le cas n’hésitez pas à m’en faire part via les commentaires (ou Twitter/Instagram).

Sur ce, je vous dis à la semaine prochaine pour le dernier article de cette série consacrée au projet AMP. Dernier article certes, mais pas le moins interessant puisque nous répondrons à la question suivante : AMP est-il une menace pour le Web ouvert et indépendant ?