Projets responsive : mise en commun de retours d'expérience – Atelier Paris Web 2013

Cet article fait partie de la série sur les ateliers Paris Web 2013.

Jérémie Patonnier (@JeremiePat) et Rudy Rigot (@rudyrigot) sont co-auteurs du livre “Projet Responsive Web Design” chez Eyrolles.
L’idée de cet atelier était que tout le monde profite des retours d’expérience de tous sur les projets responsive : alors que le concept est maintenant considéré comme “incontournable”, il reste de nombreux points en suspens et on trouve au final peu d’échos sur les obstacles rencontrés (et franchis) à chaque étape des projets menés.

On commence donc par l’amont du projet : définir les besoins du client.
Responsive ou site/application dédiée ? Quelle audience (existante, souhaitée…) ? Quelles fonctionnalités ? Et… quel budget ? On s’accorde sur une estimation 30% de budget supplémentaire si le responsive est prévu dès le départ, et un pourcentage indéfini si cela arrive après la conception.
Il faut également s’engager contractuellement sur les compatibilités visées. Quels seront les efforts de test ? Navigateurs, technologies, devices ? Le client fournira-t-il certains devices ? Les concepts d’amélioration progressive ou dégradation gracieuse ont-ils été suffisamment explicités ?

Conception et design : la méthode agile est privilégiée, car itérer souvent permet de vérifier constamment que l’on est en phase. Procéder par petites phases de validations pour être sûr d’avancer dans la bonne direction, et éviter la montagne de documents à étudier et valider. Le rôle du chef de projet est alors primordial pour éviter les débordements.
Axure, Sketch, sont privilégiés pour les zonings et le prototypage. On préfère employer les termes “grand”, “moyen” et “petit” plutôt que “tablette” ou “mobile”, afin d’abstraire encore plus l’idée du device employé et ne pas se figer sur les résolutions.
Les designers et intégrateurs doivent faire partie intégrante du process et échanger constamment, afin d’éviter les surprises graphiques ou technologiques plus tard dans le projet.
Pas forcément de prototypage HTML, car cela requiert du temps d’intégrateur, et produit souvent du code “prêt à jeter”. Mais il reste indispensable de présenter les zonings ou maquettes sur les écrans de tailles visées, afin d’avoir un rendu au plus proche de l’utilisation finale.
Outils pour les designers : Skala ou Adobe Muse, pour envoyer des captures d’écran sur différents devices.
Dernier rappel : si le périmètre du projet bouge, alors le budget va également bouger… Le plus important restera toujours la communication.

Côté intégration et développement, on s’accorde sur le fait que les images restent LE point problématique, sans solution parfaite. On conseille l’utilisation, partout où c’est possible, du format SVG ( via Illustrator, Inkscape, Fireworks…).
Les points de rupture ne doivent pas dépendre des résolutions “standard” mais être au service de la présentation du contenu. Il y a d’ailleurs souvent plutôt des points de rupture majeurs et mineurs, toutes les zones de la page ne changent pas au même “moment”.
Mobile-first ou non : “ça dépend” toujours des contraintes du projet. Il faut également différencier la conception mobile-first de l’intégration mobile-first : la première permet de focaliser sur les fonctionnalités primordiales pour élargir l’expérience au fur et à mesure, tandis que la seconde est plus un choix de quelle taille d’écran on prend comme repère par défaut, comment sera le site si le navigateur ne reconnait pas les media-queries ?
On revient toujours à “où on a mis le curseur”, qu’est-ce-qui a été défini comme vital même pour les anciens navigateurs, qu’est-ce-qu’est prêt à accepter le client.

La dernière phase sera la recette, avec tout le périmètre de test défini en amont, et les surprises sur des devices exotiques. Pour chaque cas il faudra estimer la prise en charge et éventuellement faire des avenants.
On souligne une initiative intéressante, Open Device Lab, pour mutualiser les périphériques de test entre agences et professionnels.

Vous pouvez consulter le “bloc-note” de l’atelier en ligne.

Cet atelier aura été pour moi le plus riche de la journée, puisque centré sur les échanges avec les participants, et mes prises de parole m’ont d’ailleurs donné la chance d’y gagner le livre “Projet Responsive Web Design”.

A lire aussi :

Première participation aux ateliers Paris Web

Test unitaire ? Mock ? TDD ? Kezako ? (En finir avec les régressions)

Et si on enrichissait nos frameworks CSS ?

Rendre son application HTML5 accessible en 4 étapes

Retourner sur la liste des articles