Projet global :
On a dû concevoir et développer une application mobile de la conception au développement. Le cahier des charges est en annexe. Le mode de fonctionnement en 100% télétravail ne nous a permis que de rencontrer uniquement notre maitre de stage (le dirigeant de l’entreprise). Nous n’avons pas eu accès à d’autres personnes de l’entreprise. On était à 100% en autonomie.
Missions :
Planifier les étapes du projet dans le temps grâce à un diagramme de Gantt.
Pour ce stage, la base de départ était un cahier des charges décrivant les attentes fonctionnelles liées à l’application. Connaissant le nombre de pages attendues, nous avons essayé de planifier notre stage dans le temps grâce à un diagramme de Gantt.
Voici le diagramme de Gantt macro utilisé pour ce stage :
En clair, nous avons structuré les 2 mois de stage en deux parties :
– La première moitié du stage autour de l’UX/UI sur une durée d’environ un mois. Au vu de la quantité de travail estimée,nous avons fait une grosse partie de cette phase à deux.
– La seconde moitié sur le développement de l’application
– Durant cette phase j’ai travaillé seul sur les développements technique – En parallèle, Kim finissait les ressources graphiques (motion design, partie légale, rédaction des CGU, illustrations …)
Ce qu’on a fait en réalité et la problématique dégagée :
À partir du brief et des informations complémentaires qu’on a obtenu sur la cible de l’application on a dégagé une première problématique :
Comment permettre via à une interface et des exercices de respiration d’apaiser un utilisateur et le faire lâcher prise/voyager ?
Planifier la partie UI n’a pas été très difficile. On a même réussi à s’y tenir. Par contre, ça a été beaucoup plus difficile de planifier l’organisation de la partie technique du projet. Je n’ai pas réussi à atteindre les objectifs que je me suis fixé car c’est quelque chose qui a été beaucoup plus incertain pour moi. Les bugs ont pris plus de temps à être résolus que la marge que je m’étais fixé.
On a mis 1 mois à finaliser l’UI de la MVP. Je pense malgré tout avoir commencé le développement un peu tard. Ce qui a aussi fait que dans la version finale, quelques bugs subsistaient.
Mettre en place des séances de questiorming (Un brainstorming de questions) sur le sujet et chaque fonctionnalité du brief qui ont permis de bien cerner le sujet.
On a réalisé un Brainstorming avec des questions en suivant la méthodologie enseignée par M.Capdeville. Il nous a permis de beaucoup mieux cerner le sujet. Pas trop de difficultés à ce niveau-là.
Recherche :
La première étape a été de faire des recherches sur différentes thématiques comme :
les animations, les feedbacks, la concurrence, des illustrations, des mascottes, des écrans en particulier…
Avec du recul, je me demande si notre Benchmark inspirationnel n’a pas été trop important et s’il n’a pas biaisé nos réflexions.
Je m’explique, ci-dessus, à droite, vous avez une partie de notre Benchmark inspirationnel. Et ci-dessous vous avez notre première interface satisfaisante.
Conception UX/UI :
Réalisation de maquettes. Des recherches de connaissances ont été nécessaires. Feedbacks sur des wireframes : Notre objectif était d’être user-centrique dès le début. La question qu’on s’est posé et qu’on se pose toujours est comment gagner du temps tout en restant centré sur l’utilisateur ? Dans le livre : « Sprint » de Jake Knapp dans lequel ils décrivent comment ils testaient des concepts extrêmement rapidement chez Google Venture, les auteurs décrivent des moyens originaux de tester des concepts à la technique extrêmement complexe. L’intention était de faire la même chose, ou du moins de s’en inspirer. Des idées, on en avait beaucoup de potentiellement pertinentes, les trier était une tout autre histoire.
Tests utilisateurs :
Au niveau des tests utilisateurs voici ce qu’on a fait :
Demande de feedback de personnes de l’école après chaque grande avancée. Ça s’est avéré être très utile pour les illustrations. L’aspect esthétique était important pour le maître de stage donc voici ce qu’on a fait.
À différentes étapes du projet on a comparé nos maquettes avec des prototypes dribbble qu’on estimait être au niveau qu’on souhaitait atteindre. Notre objectif était de faire en sorte que notre travail ressorte premier. La personne répondant à notre questionnaire n’avait pas connaissance que nos maquettes étaient présentées.
En clair, nous avons structuré les 2 mois de stage en deux parties :
– La première moitié du stage autour de l’UX/UI sur une durée d’environ un mois. Au vu de la quantité de travail estimée,nous avons fait une grosse partie de cette phase à deux.
– La seconde moitié sur le développement de l’application.
Durant cette phase j’ai travaillé seul sur les développements techniques. En parallèle, Kim finissait les ressources graphiques (motion design,partie légale, rédaction des CGU, illustrations …) Ce qu’on a fait en réalité et la problématique dégagée :
À partir du brief et des informations complémentaires qu’on a obtenu sur la cible de l’application on a dégagé une première problématique : Comment permettre via à une interface et des exercices de respiration d’apaiser un utilisateur et le faire lâcher prise/voyager ?
De la même manière on n’a fait la même chose avec nos illustrations. Dans l’exemple ci- dessus on a comparé quatre de nos illustrations mais dans d’autres cas on les a comparés avec des illustrations qui n’étaient pas les nôtres.
Cette démarche nous a permis de prendre du recul dans notre travail et de ne jamais avoir un excès de confiance sur la qualité de ce dernier. On a mis beaucoup temps avant de commencer à avoir des résultats qui montraient une progression par rapport à nos modèles de référence.
Même si la méthode a des limites comme par exemple le fait que notre échantillon ne soit pas représentatif de notre cible, la démarche à comme même été très utile.
Développement de 8 pages et de 4 pop-ups.
J’ai dû intégrer 8 pages retrouvables en annexes. Certaines étaient composées de composants plus techniques comme la réalisation d’un d’un slider sans librairie dans le but de changer le temps d’inspiration, d’expiration ou d’apnée (voir à gauche).
D’ailleurs, en fonction du type de respiration l’ordre des lignes changent. On peut même avoir 2 types de respirations. La réalisation de ce slider n’a pas été facile.
Troisièmement, je n’avais pas totalement compris comment fonctionnait une librairie nommée react-navigation en React.js qui a pour but de permettre la navigation de pages en pages. Au début j’ai eu du mal à l’utiliser, mais j’ai réussi au final à régler les problèmes.
Sauvegarder un historique des données dans la mémoire du téléphone :
Pour ce faire, j’ai du utiliser une librairie nommée MMKV storage car la gestion de la mémoire de react-native est trop lente et déconseillée. J’ai eu un problème car en mettant à jour
mes librairies, le fonctionnement de la mémoire a changé. Je n’ai pas compris tout de suite d’où venait l’erreur.
Intégration d’animations sous un format adapté à Lottie (animations vectorielles).
Lottie est un moyen d’avoir des animations grâce à la suite de svg ou vecteurs. Elles sont donc beaucoup plus légères par rapport à un GIF par exemple. La documentation pour react-native n’est pas extrêmement complète. Cela m’a pris un peu de temps pour arriver à
bien faire fonctionner la librairie Pour atteindre mon objectif j’ai dû comprendre ce qu’était Animated qui permettait d’utiliser Lottie.
Intégrer des musiques en react-native
Autre difficulté, je ne savais pas comment utiliser l’audio d’un téléphone mobile. Je me suis donc mis à chercher sur google, la documentation de react-native et npmjs pour trouver deux solutions.
– La librairie react-native-sound
– Expo. J’avais une très mauvaise expérience avec expo avant ce stage. J’ai donc décidé d’utiliser la première solution. À ce stade là je n’étais pas conscient qu’utiliser expo m’aurait facilité la vie. Je l’ai découvert après le stage en regardant un peu plus en détail ce que la SDK proposait. On avait une page où deux types de son existaient.
Une musique continue tant que la respiration fonctionnait et un gong à chaque fois qu’on passait d’une inspiration à une expiration.
Pour développer cette fonctionnalité j’ai utilisé un Hook nommé « useEffect » en react. Un useEffect va permettre que le son se lance lorsqu’on est sur la page de respiration et que le son s’arrête quand la page se ferme. Le problème c’est que ça n’a pas du tout fonctionné. Et je ne comprenais pas pourquoi.
Une session de débogage a alors commencée. Un réglage partiel du problème a été d’enlever toute utilisation de « useContext » de la page.
Deuxièmement, pour corriger des bugs de son j’ai dû faire des recherches qui m’ont fait prendre conscience que la solution (temporaire) était un « Hook » de React non vu en cours qui se nomme le « useRef ». Solution temporaire car le son se remet à bugger après 10 minutes d’utilisation.
NB : En cours nous avons vu les principaux Hooks de react mais pas tous.
Le fait de ne pas avoir de référent technique a rendu le débogage extrêmement désagréable. Je ne me suis jamais dit que le problème venait d’un manque de connaissance de ma part. Ce qui a fait que je me suis plongé tardivement dans la doc de React pour découvrir les autres hooks existants. Travailler avec des personnes ayant plus d’expérience m’aurait permis d’éviter de passer 2 jours à me casser l’esprit dans le but de tenter de résoudre ce problème.
Même avec ça des bugs persistaient.
Les problèmes de son auxquels j’ai dû me confronter étaient en partie dus aux choix de la librairie. J’avais eu une mauvaise expérience avec expo, un SDK (un ensemble de fichiers rajoutant des fonctionnalités) pour react-native permettant par exemple d’utiliser la vibration du téléphone, le micro ou encore les haut-parleurs du téléphone.
Synchronisation entre les animations et le minuteur de la respiration :
J’ai dû synchroniser l’écoulement des secondes avec les animations. Lorsque le compteur était à zéro, l’animation devait être finie. Pas de soucis à ce niveau-là. Pour cela j’ai utilisé un autre Hook nommé « useContext ».
Réaliser une barre de progression pour le test de respiration et la respiration en elle-même.
Une fonctionnalité dans le but d’aider l’utilisateur à mesurer sa progression. Pas de difficultés à le faire ici.
Principales problématiques rencontrées :
Globalement nous avons manqué d’encadrement, métier, et technique, ce qui nous a forcé à nous adapter et avancer avec une grande autonomie.
Encadrement global du stage
Il nous manquait cet encadrement durant toute la durée du stage pour faire le lien entre – Les objectifs fonctionnels à atteindre
– Les étapes à passer pour chaque aspect fonctionnel
– Les enchainements entre la conception et le développement de l’application
– Le niveau de complexité de chaque partie semblait très peu visible au dirigeant de l’entreprise.
Nous avons donc en plus de nos parties respectives, du nous préoccuper de la gestion globale du projet et proposer des raccourcis ou des limitations de périmètre pour rester dans les temps tout en essayant de respecter les attentes du dirigeant.
Approche fonctionnelle
– On avait un point toutes les semaines avec notre maître de stage
– Les sujets abordés étaient essentiellement autour du fonctionnel et de la conception
– Nous étions confrontés à un ‘client’ ne pouvant nous aider que sur les sujets métier (le positionnement de sa société) le concernant mais pas du tout sur le reste.
– La conception de l’application (UX/UI) nous a demandé beaucoup de temps et d’aller retours avant d’arriver à une approche fluide et intuitive répondant aux attentes.
Encadrement technique
– En termes de structuration globale, il est apparu rapidement que le temps estimé pour la partie développement front end était trop court.
– On n’avait pas de référent design ou technique ce qui a rendu ce stage rapidement difficile avec à chaque fois une difficulté additionnelle pour expliquer au dirigeant la nature du problème technique, de façon compréhensible.
– Chaque problème rencontré nous demandait beaucoup d’efforts pour le résoudre tout en respectant notre planning initial.
Gestion du temps et des difficultés
– La structuration du projet au global, le niveau de difficultés de chacune des parties, et le temps nécessaire pour les traiter sont autant de problématiques qui aujourd’hui ressortent mais qui durant le stage étaient difficiles à appréhender.
– Les estimations de temps à passer sur chaque partie élémentaire, étaient les plus difficiles et ne tenaient pas compte de la réalité des problèmes, des interrogations ou des bugs rencontrés.
Avec le recul, le nombre de sujets fonctionnels à traiter d’une part, et l’objectif d’arriver à une application à l’issue du stage semble aujourd’hui beaucoup trop ambitieux pour les étudiants que nous étions