SoMood : Les premiers pas

Il était une fois, chez SOAT, des personnes nommées les Soatiens qui, pour garantir une atmosphère idéale, se souciaient de l’humeur de chacun. Pour ce faire, nous – puisque je suis une Soatienne également – avions l’habitude d’utiliser un outil appelé Niko-Niko qui, sous forme d’une interface web, nous permettait de donner notre humeur du jour et de suivre l’état d’esprit de notre équipe. Seulement, cet outil ne répondait pas vraiment aux tendances du moment qui convergent vers le mobile.

Devant l’aspect un peu rébarbatif de cet outil, nous avons donc décidé de nous approprier le principe, et de le porter sur ces objets qui ne nous quittent jamais : les smartphones. C’est ainsi qu’est née l’idée du projet SoMood.

Dans cet article, je vais exposer l’introduction au projet, les choix techniques et architecturaux qui ont été faits, sans oublier une présentation de l’application telle qu’elle est aujourd’hui sur l’App Store et le Windows Phone Store.

Pourquoi SoMood ?

Comme mentionné précédemment, il est dans les habitudes des Soatiens de donner leur humeur (au désespoir de certains, quand celle-ci n’est pas au beau fixe) mais aussi de suivre celles de leurs collègues. Le but est simple : un chef d’équipe peut ainsi rapidement détecter un problème au sein de son équipe ou, au contraire, admirer avec fierté que l’ambiance est optimale et que tout le monde est satisfait de ses tâches. Cette démarche s’inscrit directement dans les principes fondamentaux des méthodes agiles, puisque la finalité est de permettre à chacun de travailler dans de bonnes conditions, ce qui participe au bon déroulement du projet.

Au départ, les différents outils testés semblaient convenir, mais le taux de participation se vit rapidement diminuer, notamment dans mon équipe. Une des raisons était simple : le seul biais pour définir son humeur était d’attendre un mail d’alerte à 17h, qui listait différentes humeurs et donnait accès aux données du jour, de façon anonyme. Ceci n’avait rien de bien attrayant, et le fait d’avoir des données anonymes n’arrangeaient pas vraiment le chef de projet, qui n’avait aucun moyen de savoir qui n’était pas content. Cela donnait souvent des irruptions du chef de projet dans l’open space avec comme superbe accroche « Bon, qui est mécontent ces derniers temps ? », ce qui, même en partant d’un bon sentiment, jetait un froid.

En parallèle de ce constat, les défenseurs du développement mobile et moi-même étions en pleine effervescence pour proposer une idée d’application à développer avec Xamarin. Il n’y avait qu’un pas à franchir pour relier les deux histoires, et très rapidement l’idée de proposer un outil de type Niko-Niko sur mobile germa dans les esprits.

Les fonctionnalités sélectionnées furent les suivantes :

• Pouvoir se connecter et créer un compte, si possible grâce à un réseau social pour gagner du temps
• Pouvoir créer, modifier, supprimer ou quitter un groupe d’utilisateurs
• Pouvoir afficher un résumé sur les derniers jours des humeurs d’un groupe
• Avoir accès au détail d’une journée
• Pouvoir facilement donner son humeur et accompagnée d’un petit commentaire
• Pouvoir visualiser et éditer son profil (nom, prénom, image)
• Pouvoir afficher les membres d’un groupe

Le développement sur mobile de l’application, ainsi que ces différentes fonctionnalités, imposèrent de respecter un certain nombre de contraintes.

Contraintes et choix techniques

Tout d’abord, comme toute application mobile qui se respecte, SoMood se devait d’être disponible sur sur iOS, Android et Windows Phone pour ne pas faire de jaloux. Il a fallu intégrer cet aspect, sans pour autant perdre en performances ou sacrifier l’interface. En soi, les fonctionnalités ne sortaient pas de l’ordinaire, mais nous savions dès le départ, en recueillant les besoins, que le design et l’ergonomie joueraient un rôle principal.

Concernant les choix, abordons dans un premier temps le « choix » de la technologie de développement des applications, Xamarin. Je mets des guillemets, car si vous avez bien suivi le début, Xamarin était presque un prérequis. De plus, l’équipe mobile étant déjà assez familière avec cette technologie, il paraissait naturel de l’utiliser.

En plus de cela, nous avons choisi d’héberger la base de données, le site qui exposerait l’API Rest ainsi que l’espace de stockage des images sur Azure, afin de ne pas être dépendants d’une machine et profiter pleinement des ressources qu’offre le Cloud.

Finalement, avant même le début du projet, SoMood s’est présentée comme une vraie application innovante, qui faciliterait le quotidien dans le cadre des méthodes agiles et qui exploiterait un ensemble de technologies et plateformes dans l’ère du temps.

L’utilisation de la méthode Scrum

Puisque l’idée du projet s’inscrit parfaitement dans les méthodes agiles, et que les équipes au sein de SOAT veillent toujours plus à mettre en place de l’Agilité dans leur mode de fonctionnement, il en a été de même pour SoMood. Sous l’oeil attentif du Product Owner et avec l’aide du Scrum Master, le projet s’est mis en place, d’abord avec l’élaboration du backlog, puis par l’organisation d’un planning poker, pour sortir du lot de fonctionnalités demandées par le Product Owner celles qui étaient faisables par l’équipe, pour arriver à une application présentable aux Techdays 2015, ce qui n’était pas chose aisée. A ce backlog s’ajoutait le traditionnel DSM, le tableau de post-it, ainsi que les démonstrations, qui avaient lieu tous les mardis en fin de journée, toujours suivies d’une petite rétrospective.

Une application qui ne fait pas le café, mais presque !

Comme expliqué précédemment, l’objectif du projet était de pouvoir, dans un premier temps, montrer une application fonctionnelle en démo, dans un laps de temps très court (1 mois et demi de développement pour un backend et 2 applis mobiles), puis de partir par la suite sur des évolutions sous forme de lots. Actuellement, la version de l’app iOS et Windows Phone est affichée sur les stores comme étant la première version mais, par rapport au backlog, les fonctionnalités présentes correspondent au lot 2 (le lot 1 a été montré sur le stand SOAT aux Techdays mais il n’y a pas eu de publication sur les stores, car les fonctionnalités étaient jugées un peu légères).

Parmi les fonctionnalités disponibles, il y a bien sûr la création de compte et la connexion, mais aussi l’inscription et connexion depuis son compte Facebook. Suite à cela, l’utilisateur est amené à créer un ou plusieurs groupes, qui seront visibles depuis la page d’accueil (voir ci-contre). Un groupe est constitué d’un nom, d’une image, d’un fuseau horaire (indispensable pour avoir une heure cohérente lors de la définition des humeurs) et d’utilisateurs. Ces derniers sont ajoutés grâce à leur adresse mail enregistrée en base de données. A noter que si l’adresse mail n’existe pas dans l’application, un mail d’invitation à télécharger SoMood sera envoyé à la personne.

 

 

 

Un utilisateur qui crée un groupe est considéré comme seul administrateur de celui-ci, et va pouvoir, grâce à une gesture différente selon l’OS, accéder à un menu pour éditer ou supprimer le groupe. Dans la page de l’édition d’un groupe, l’administrateur peut éditer à souhait le nom, l’image, et les utilisateurs (supprimer ceux déjà existants ou en ajouter).

Lorsqu’un utilisateur n’est pas administrateur d’un groupe, la seule option qui s’offre à lui est la possibilité de le quitter.

En accédant à un groupe donné, l’utilisateur va voir s’afficher une nouvelle page (voir ci-contre) qui regroupe l’historique des humeurs jusqu’à 5 jours, et va également pouvoir visualiser son humeur du jour ou, s’il ne l’a pas encore définie, va être amené à la renseigner. La définition de cette humeur journalière se fait tout simplement grâce à la sélection d’un des smileys proposés (chacun avec une couleur correspondante au type d’humeur), et la saisie optionnelle d’un commentaire. L’interface est très simple d’utilisation (voir ci-dessous) pour que l’utilisateur puisse donner son humeur rapidement et en repérant très rapidement quel smiley choisir.

 

 

De retour sur la page d’historique des humeurs, on remarque que plusieurs smileys sont alignés horizontalement, sans détail sur qui a défini quelle humeur, et que les commentaires ne sont pas visibles. Cette page est un affichage rapide et résumé, pour voir en un coup d’œil l’humeur globale de l’équipe. Néanmoins, le détail reste accessible à tous, depuis un clic sur le bandeau où les dates sont affichées. Une nouvelle page s’ouvre alors, affichant une liste des membres du groupe qui ont déjà donné leur humeur, avec le petit smiley à côté de la photo de l’utilisateur et le commentaire associé.

La page d’historique affiche aussi un deuxième onglet pour visualiser les membres qui appartiennent au groupe.

Enfin, l’application intègre sur chaque plateforme un menu hamburger, qui permet à l’utilisateur d’accéder à sa page de profil, pour le consulter ou l’éditer (voir ci-dessous) ou de se déconnecter de l’application.

L’ensemble des écrans présentés précédemment correspond à la version iOS de SoMood. L’application reprend la plupart des guidelines propres à la plateforme d’Apple et rend son utilisation fluide et naturelle pour tout habitué. On retrouve, par exemple, l’utilisation de la Tab Bar pour accéder à l’historique ou aux membres du groupe, le swipe vers la droite sur la page des groupes pour accéder au menu d’administration du groupe, ou encore la présence des actions principales dans la barre de navigation qui se trouve en haut.

La version Windows Phone garde les mêmes codes couleur et certains aspects de l’application iOS, tout en respectant le design préconisé par Microsoft (avec l’utilisation du pivot par exemple, le tap long sur un groupe pour accéder à la gestion, l’app bar en bas, …)

 

Après le pavé, la construction !

Puisque nous parlons de briques, voici tout de suite l’ensemble des briques du projet :

Et ci-dessous, la liste des technologies et outils utilisés :

• Côté mobile
  • 3 applications : iOS, Android, Windows Phone 8.1
  • Xamarin
  • MvvmLight
  • Conteneur IoC : Autofac
• Côté serveur
  • Azure website
  • Web API 2
  • Blob Storage
  • Base de données SQL sever
• Outils
  • GIT hébergé sur TFS Online
  • Visual Studio
  • Xamarin Studio
  • Xcode

Ligne de front du projet : la partie mobile

Comme décrit plus haut, la partie mobile est composée de trois applications, respectivement pour iPhone, Android, et Windows Phone 8.1. Ces applications ont été développées à l’aide de Xamarin, une technologie qu’on ne présente plus aujourd’hui. En résumé tout de même, Xamarin fournit de très bonnes performances, la possibilité d’avoir des interfaces en adéquation avec chaque plateforme, et utilise le langage C#, ce qui en fait un candidat idéal pour la réalisation d’une application comme SoMood.

En plus de Xamarin, nous avons profité de frameworks innovants et d’autres plus pérennes pour améliorer le développement, la maintenabilité ou encore la lisibilité. Bref tout ce qu’un bon développeur aime. Xamarin préconisant l’utilisation du pattern de développement MVVM, le framework MVVM Light, qui se prête très bien au domaine du mobile, a donc été retenu, d’autant qu’une version pour Xamarin iOS que nous mourrions d’impatience de tester était sortie quelques mois auparavant. Ayant été éprouvé pour le développement Windows Phone et profitant de bons avis sur la version Xamarin iOS, c’était l’occasion de nous forger notre propre avis et de confirmer ou non s’il pouvait être viable pour nos besoins futurs.

En revanche, plutôt que d’utiliser le conteneur IoC proposé avec MVVM Light (Simple IoC), nous avons préféré Autofac, qui dispose de plus de fonctionnalités.

Le côté obscur du projet : le backend

SoMood ayant besoin d’utilisateurs et fournissant des informations qui ne seraient pas uniquement en local sur le téléphone, il était nécessaire d’avoir une base de données. La structure de celle-ci restait tout à fait classique, puisqu’elle se composait de plusieurs tables (User, Group, Mood, TypeMood) reliées entre elles grâce à des foreign key.

En plus de cela, l’ajout et la récupération de données impliquait l’utilisation d’une API Rest, donc d’un site web qui pourrait fournir le pont entre l’application et la base de données. Pour toute cette brique, nous avons choisi d’utiliser le cloud, plus précisément Azure. En effet, celui-ci fournissait l’ensemble des services dont nous avions besoin, comme le site, la base de données, ou encore le Blob Storage, qui contenait toutes les images.

Finalement, le backend permettait de récupérer et manipuler les données depuis l’application cliente, de traiter les informations Facebook pour l’inscription ou la connexion, de gérer l’ajout/suppression d’images dans le Blob Storage, ainsi que d’envoyer les urls qui seraient affichées pour l’utilisateur.

Un marteau ou des aiguilles pour la réalisation ? Non !

Voici le contenu de la boîte à outils du parfait développeur SoMood (mais cela peut s’appliquer à bien des projets Xamarin) : tout d’abord, utiliser GIT comme contrôleur de code source. Les habitués des projets Windows Phone/Windows 8, ou les amoureux de Microsoft diront : pourquoi GIT et pas TFS ? Tout simplement parce que TFS n’est pas disponible sous tous les IDE qui seront utilisés pour un projet Xamarin. Et comme nous ne sommes pas vraiment des fans de la ligne de commande, nous avons utilisé Source Tree (disponible sur OS X et Windows) pour gérer tout cela.

Autre outil indispensable pour développer : l’IDE. Je l’avais déjà abordé dans un précédent article sur le fonctionnement du storyboard : pour le moment si on veut être efficace lors du développement d’un projet Xamarin, il faut coupler l’utilisation de Xamarin Studio, Xcode, et bien sûr Visual Studio (pourquoi s’en passer ?) essentiellement pour Windows Phone.

Pour ce qui est des téléphones, il y a la solution des simulateurs ou des périphériques physiques. D’expérience, pour la partie iOS, le simulateur fourni avec Xcode est tout à fait viable pour un projet comme celui-là. Les problématiques de performances n’étant pas très complexes dans notre cas, il suffit de se munir d’un logiciel Network Link Conditioner qui va permettre de simuler les différentes connexions internet (3G, Edge, …) et nous voilà tranquilles jusqu’aux phases finales de test. De même pour Windows Phone, le simulateur fait très bien le travail. Dans notre cas, le point noir a été le simulateur Android. Entre la lenteur de celui que propose Xamarin Studio (le Xamarin Android Player venait à peine de sortir) et l’impossibilité d’accéder à internet et donc aux APIs, le temps perdu a été assez considérable sur un point pourtant basique. Les tests se sont donc effectués directement sur un téléphone, ce qui finalement a permis de s’apercevoir très rapidement des problèmes de performances, entre autres.

 

Conclusion

Lors de cette introduction, vous aurez pu voir la Genèse du projet SoMood, comment il s’articule et grâce à quels outils et méthodes de développement il est arrivé au stade de maturation idéale pour être publié sur les différents stores d’applications. Dans le prochain article, nous aborderons la problématique de sociabilisation de la connexion utilisateur, un aspect aujourd’hui quasiment indispensable pour ce genre d’application.