Cette étude de cas fait suite aux articles expliquant comment concevoir le web de demain en s’inspirant des méthodes de conception des jeux vidéos. Les articles en question:

• Les Signs & Feedbacks
• Les 3C
• Les étapes de conception

Le site que nous allons voir est celui du teasing de la Citroën C4 Cactus, que nous avions développé. Le client souhaitait réaliser une succession d’animation présentant la voiture. Pour jouer l’animation et passer d’un tableau à l’autre, l’utilisateur devait utiliser le scroll ou les flèches de son clavier.

Les 3C

Pour réaliser les animations il a fallu adopter le langage adéquat.

Les contrôleurs sont la molette de la souris, les flèches, et le doigt pour mobile. Il fallait s’assurer qu’il soit pratique à utiliser. Pour donner l’impression que la voiture roule, il fallait donner un minimum d’inertie à la voiture, qu’elle continue à avancer quand l’utilisateur arrête de scroller. Nous avons testé plusieurs situations: l’utilisateur scroll sans s’arrêter, va doucement, très vite. Nous avons pu calibrer une expérience qui ne défile pas trop vite, mais ne lasse ni ne fatigue un utilisateur qui scroll ou swipe pour découvrir les animations.

Le character, c’est la voiture. Ses actions possible sont d’avancer ou reculer suivant l’action de l’utilisateur. Les roues étaient animées de façon à être cohérente avec le mouvement. Elle avait aussi un effet de profondeur: il a fallu gérer l’effet de zoom par rapport à la caméra.

La caméra état sous 2 angles suivant les tableaux. Soit en vue de côté par rapport à la voiture, soit en vue du dessus. Généralement la caméra suivait la voiture, mais parfois la caméra s’arrêtait alors que la voiture continuait à avancer, et pour les passages d’un tableau à l’autre la caméra faisait un effet de travelling. L’écran n’était pas utilisé comme un simple outil de navigation mais comme un vrai outil d’animation.

Les phases de conception

Phase de recherche

La première phase de conception a été de chercher une librairie permettant de réagir au scroll. Après quelques recherches Skrollr semblait parfaitement correspondre. Nous avons donc fait quelques tests en dehors du projet pour s’amuser à utiliser la librairie, et approfondir son fonctionnement. Le site d’exemple de the Walking Dead et l’explication détaillée de son développement nous a convaincu quant à la puissance de Skrollr!

Prototypage et version Alpha

L’idée était ensuite de réaliser un premier prototype, une version alpha, très rapidement, afin que le client puisse intervenir très rapidement dans la validation de notre choix,  adapter ses spécifications et faire ses premiers retours sur l’expérience utilisateur.

Pour cette première version nous avons simplement exporté les images des specs mises bout à bout. Au scroll l’utilisateur passait d’une image à une autre. Les images n’étaient pas retaillées, le menu était sur les images et pas dans le code de la page, mais l’idée était là: la version alpha était fonctionnelle.

Elle nous a permis de tester sur tous les navigateurs et devices possibles et montrer les limites de Skrollr. Le site propose une expérience « horizontale », forçant l’utilisateur à être en format paysage, mais Skrollr ne permet que de scroller en vertical. Nous avons dû adapter la librairie à notre besoin. Un autre soucis a été la vitesse de scroll: suivant le navigateur, la configuration, la sensibilité de la souris, du trackpad, du swipe pour mobile… la vitesse et l’expérience était complètement différente. Pour certains le scroll passait très vite, ne permettant pas de voir correctement l’animation; pour d’autre il était très lent, obligeant l’utilisateur à faire énormément de scroll pour tout voir. C’est un soucis qu’on remarque sur beaucoup de sites utilisant Skrollr. Nous avons pu rapidement travailler sur ce point pour proposer une expérience uniforme à tout le monde.

Version Beta

Le site étant découpé en 7 animations, nous sommes passés en version beta: chaque développeur avait 2 tableaux à réaliser, plus une partie liée à l’animation de la voiture, commune à tous les tableaux.

De cette façon chacun a pu développer librement des prototypes de son animation indépendamment des autres. Petit à petit les images ont été remplacées par des vraies animations.

Nous avons utilisé un processus itératif pour chacune de ces parties. Dans les premières itérations la voiture était statique, les images étaient des placeholders, puis nous avons utilisé les bonnes images et animé les roues de la voiture. Le client a pu voir la progression de chaque animation et soulever des problèmes rapidement afin d’adapter le site comme il fallait.

Dernières optimisations et version « gold »

Une fois la version beta finalisée, nous avons pu passer à une grosse phase d’optimisation afin de donner aux utilisateur l’expérience la plus fluide possible. Grâce aux outils de Chrome nous avons pu faire en sorte que l’ensemble des animations reste entre 40 et 60 fps, ce qui est largement suffisant et très satisfaisant pour nous vu la quantité d’animations du site.

Les Signes et Feedbacks

L’écran de chargement offre une barre de progression. Le site étant rempli d’images pour les différentes vues de la voiture, nous avons inclus un système de pré-chargement pour ne pas avoir le chargement en cours d’animation et que l’utilisateur risque de louper certains effets. A mon sens la créa n’était pas assez poussée pour voir vraiment l’avancement du chargement, le seul feedback était le texte du pourcentage d’avancement qui changeait.

Une fois le chargement terminé le visuel se changeait légèrement et un message indiquait à l’utilisateur de scroller ou swiper, suivant le device utilisé. Dès que l’utilisateur commence à scroller, le menu en bas apparaît et une barre de progression se remplit, indiquant sa progression dans le tableau en cours et sur le site en général.

Sur la version mobile ou avec une résolution réduite, le menu était caché et s’affichait par la gauche en appuyant sur un bouton: on n’avait pas l’affichage de cette barre de progression. Pour avoir montré le site à plusieurs personnes, le constat est simple: quand le menu affiche la barre de progression, pourtant légère et en bas (l’oeil étant plutôt porté par la voiture et les visuels qui apparaisse à chaque scroll), les gens allaient au bout. En montrant la version mobile ou avec un faible résolution, plusieurs personnes se sont rapidement arrêté après la premier affichage de texte ou à la fin du premier tableau quand il n’y a plus trop d’animation visible à l’écran pendant la transition.

Ce cas pratique est l’exemple même de l’importance de toujours montrer à un utilisateur où il en est et ce qu’il se passe sur sa page.

Bilan

La façon de concevoir ce site a été extrêmement positive. Malgré une deadline assez courte et de nombreux défis techniques (énormément d’animations, support de nombreux navigateurs et mobiles, soucis d’optimisation pour une expérience fluide, réagir au scroll ou au swipe pour les animations…), tout a été respecté.

• Le fait de faire une vraie phase de recherche, un découpage clair des tâche à effectuer nous a fait gagner un temps précieux sur le reste du projet. En ayant testé Skrollr en amont nous avons pu nous inspiré d’autres personnes pour certaines étapes d’animation, et nous assurer que la librairie couvrait tous nos besoins.
• Avoir réalisé un prototype en alpha avec les placeholders, et de l’avoir dès ce moment montré au client l’a rassuré puisqu’il a pu suivre l’avancement très rapidement et émettre des retours avant que tout soit calé en version finale.
• La fait d’avancer par étape nous a permis de voir à partir de quel moment les performances étaient dégradées, pour rapidement trouver des solutions et garder une expérience fluide.