Notification center : Comment Lumapps a retravaillé la fonctionnalité vers les standards actuels

Les notifications dans une application web sont de nos jours une fonctionnalité cruciale. Dans LumApps, elles permettent à l’utilisateur de se tenir au courant des dernières informations d’entreprise, des nouveaux posts de communautés ainsi que de leurs activités liées, comme les commentaires ou les réactions.

La fonctionnalité des notifications était initialement limitée sur LumApps. Elle permettait uniquement de voir la notification et cliquer dessus pour atteindre le contenu concerné, puis la notification disparaissait.

Dans le cadre du travail fait sur la partie du header du produit (aussi appelé Topbar) qui devait évoluer techniquement, nous avons également repensé le centre de notifications, lui donnant à la fois un nouveau design et de nouvelles actions possibles, plus en phase avec ce qui est attendu de nos jours.

Cet article revient sur le déroulement du développement de ces nouvelles évolutions.

Le header (ou Topbar), en haut

Feature team, task force team

LumApps fonctionne en Feature team, c’est-à-dire que chaque équipe gère l’ensemble d’une ou de plusieurs fonctionnalité(s) au sein de l’application LumApps, sur l’ensemble des processus et couches techniques, (conception, design, développement backend, développement frontend, QA…). Chaque équipe (aussi appelé pod) est responsable de sa partie du code, qui peut cohabiter avec celui des autres pods, contrairement à une organisation en composants où chaque fonctionnalité métier est gérée de manière transverse par toutes les équipes tout en restant techniquement autonomes.

Dans un premier temps, le besoin était de refondre visuellement et techniquement l’ensemble du header Topbar, afin de le rendre plus rapide au chargement et légèrement remis au goût du jour, sans le changer fonctionnellement. Le centre de notifications faisant partie intégrante du header, il est également inclus dans ce travail de refonte.

La majorité du travail se faisait au niveau du design et de la couche front-end ; il n’était donc pas nécessaire de mobiliser un pod entier, d’autant plus que la top bar contient des fonctionnalités gérées par plusieurs équipes. Une “task force” a donc été créée, regroupant plusieurs designers et développeurs de différents pods.

Dans un second temps, une fois le nouveau header dans un état stable, un travail de refonte fonctionnelle pour la partie du centre de notifications a été prévu. Le besoin était de laisser l’utilisateur gérer plus simplement ses notifications :

• Pouvoir les marquer comme lues/non lues
• Les filtrer selon leurs statuts et retrouver les contenus plus tard
• Et améliorer la réactivité générale de l’interface.

Cette partie nécessitant un travail backend et n’étant pas directement en lien avec les objectifs de la task force, elle a été gérée par le pod social, responsable de la fonctionnalité du centre de notifications.

Gestion de projet

Le cycle de développement de LumApps au moment de cette refonte se décomposait en releases toutes les 6 semaines, elles même décomposées en 3 sprints de 2 semaines. La raison pour laquelle nous avons décidé de diviser l’évolution du centre de notifications en deux étapes est parce que d’un point de vue gestion de projet, la refonte du header était prioritaire par rapport à l’ajout de nouvelles fonctionnalités. Il était également plus simple et moins risqué pour la release de diviser le travail en faisant la refonte technique et visuelle tout en gardant un fonctionnel identique d’abord, puis ensuite d’ajouter les nouvelles fonctionnalités dans la release suivante. De plus, les éléments techniques comme le le design system Lumx ont pu être adaptés et réutilisés, il n’y a donc pas eu trop de développements d’états intermédiaires amenés à être remplacés par la suite.

Le projet s’est ainsi divisé de la manière suivante :

• En premier lieu, la task force a été chargée de faire évoluer le header Topbar dans son ensemble, centre de notifications compris, en reproduisant son fonctionnel existant.
• Environ deux sprints avant la release du travail de la task force, les développeurs backend du pod social ont entamé le travail préparatoire nécessaire aux évolutions fonctionnelles prévues pour la release suivante.
• La première release sort ainsi avec le centre de notification migré visuellement et techniquement, et le backend prêt pour son évolution fonctionnelle.
• Les trois sprints suivants, les développeurs frontend du pod social ont pu s’attaquer à la refonte fonctionnelle, en reprenant le travail de la task force et en s’appuyant sur le travail backend déjà réalisé.

Une gestion de projet la sorte n’est pas évidente à gérer, avec plusieurs équipes et plusieurs sprints en ligne de mire. Le travail a été conséquent et plusieurs points de difficultés ont dû être surmontés, notamment :

• Le travail de la task force nécessitait un travail important, et on a préféré privilégier la qualité à une date fixée de release, ce qui a décalé celle-ci d’une release par rapport à ce qui était prévu, et de fait, a également décalé le planning de la refonte fonctionnelle.
• Le travail backend en amont était nécessaire mais en raison du timing et des nouveaux composants créés côté frontend, il était difficile de le tester pendant son développement, ce qui fait que des bugs backend ont été remontés tardivement.
• En raison de conflits de plannings, la migration technique et visuelle de la task force a été réalisée par des développeurs frontend qui ne venaient pas du pod social, et qui n’étaient pas amenés à travailler sur son évolution fonctionnelle ; un transfert de savoir a été nécessaire, ce qui prend forcément du temps supplémentaire.

Néanmoins, dans l’ensemble, le travail réalisé à été à la hauteur de ce qui était attendu.

Release 1 : Refonte du header Topbar et du centre de notifications

Le header historique a été développé en angularjs, et afin de le migrer dans la nouvelle architecture en React, l’équipe Task force “Frontend Core Topbar” a été spécialement constituée pour que des développeurs normalement de différents pods travaillent à temps plein sur ce chantier. Parmi les tâches de cette refonte, se trouvait celle de la partie centre de notifications. Le travail de migration était double :

• Technique pour migrer le code historique angularJS vers React
• Visuel pour avoir une première mise à jour du style, plus en phase avec le nouveau header.

La migration d’angularjs vers React nécessite une réécriture complète du code, car la structure même du code est totalement différente entre ces frameworks. Ce travail a été effectué par des développeurs non membres du pod social, pour des raisons de planning.

Bien que non idéal, cela n’a pas posé de problème majeur car ils avaient la connaissance technique nécessaire pour le faire ; c’est l’avantage des feature teams, même en faisant partie d’une autre équipe, ayant travaillé la même couche technique, l’appropriation du code est simplifiée.

Visuellement, le design a été repensé pour utiliser la bibliothèque de composants React open source créé par LumApps : le design system Lumx. Les changements peuvent paraître mineurs mais ceci facilite également le développement et la maintenance du produit car elle évite de créer des composants à utilisation unique.

Finalement, le résultat est fonctionnellement identique à l’ancien centre de notifications, tout en ayant été adapté à un nouveau design. Sous le capot, la migration vers React permet également une meilleure maintenance future, et une performance accrue, deux objectifs qui ont initialement motivé le travail de refonte.

Cette évolution a été intégrée dans la première release, avec l’ensemble de la refonte du header Topbar. Le tout a pu être testé en interne, afin de pouvoir l’ajuster et fixer les bugs dans la release suivante, avant son déploiement dans les environnements clients.

Avant/Après : Centre de notifications originel et centre de notifications dans le nouveau header, pour la Release 1

Release 2 : Nouvelles fonctionnalités dans le centre de notifications

Pour la release suivante, le besoin principal était de faire évoluer le centre de notifications vers des standards plus actuels : au lieu d’avoir uniquement une liste de notifications qui disparaissaient au clic, nous voulions ajouter un système de notifications lues ou non lues, qui permettaient de garder la notifications visible même après la visite du contenu. L’utilisateur pourra dorénavant faire la distinction entre marquer comme lu, marquer comme non lu et supprimer entièrement la notification. Il pourra également tout marquer comme lu ou tout supprimer, et pourra filtrer la liste pour n’afficher que les notifications non lues. Enfin, le centre de ne comptera pas la totalité des notifications (information non utile), mais uniquement celles non lues.

Les différentes tâches nécessaires à cette évolutions étaient les suivantes :

• Côté backend, faire évoluer le service pour ajouter un statut aux notifications pour distinguer entre non lu, lu et supprimé, et migrer les notifications déjà existantes en base pour les rendre compatibles avec le nouveau format, tout en restant utilisables par le système actuel, pour éviter une rupture de service.
• Préparer un script qui va sanitiser la base de données actuelle, pour ne plus garder les notifications supprimées après un certain temps, pour des raisons de performances.
• Côté frontend, depuis les changements faits par la task force, faire encore évoluer visuellement les notifications pour qu’elles suivent les nouvelles maquettes.
• Ajouter les nouvelles fonctionnalités prévues en retravaillant les composants existants ou en créant de nouveaux, puis en les branchant au backend.

Les tâches backend ont été faites par le pod social en même temps que la refonte du header, lors de la release précédente, puis mis en attente pour son utilisation dans la release suivante. Quant aux tâches frontend, elles n’ont pas été réalisées par les mêmes développeurs que pendant la refonte du header, mais grâce à des standards de développement communs ainsi qu’à l’utilisation du design system, la transition s’est faite sans accroc majeur.

Il y avait encore beaucoup de travail à abattre. Néanmoins il a pu être réalisé dans les temps et trois sprints plus tard, le nouveau centre de notifications a donc été amélioré pour permettre tout ce qu’on peut attendre d’un centre de notifications moderne. Ces évolutions ont pu donc être comprises dans la release suivant celle du nouveau header, 6 semaines plus tard, et seront déployées chez les clients au fur et à mesure que les clients adoptent le nouveau header Topbar.

Avant/Après : Centre de notifications du nouveau header Release 1 (sans évolution) et centre de notification Release 2 (avec nouvelles fonctionnalités)

Evolutions futures

Le chantier de la refonte du centre de notifications est assez conséquent. Le code ayant été changé en backend et totalement réécrit en frontend, la stratégie de déploiement a été donc en premier lieu de ne pas imposer cette nouvelle refonte aux clients, mais de le tester intensivement en interne, sur l’intranet LumApps. Un certain nombre de bugs et petites améliorations ont ainsi pu être corrigés avant le déploiement chez les clients.

Certaines petites améliorations ont ainsi été ajoutées après la fin du cycle de développement :

• Une version optimiste des fonctionnalités tout marquer comme lu et tout supprimer, qui sont effectifs immédiatements au lieu d’attendre le retour du backend
• Un peaufinement des états de chargements lors du passage entre toutes les notifications et les notifications non lues uniquement
• Quelques mises à jour visuelles et mises à jour de texte
• Ou encore une amélioration des performances backend.

Et d’autres possibles évolutions futures pourraient être à venir, par exemple :

• Avoir plus de contrôle et de finesse sur les notifications envoyées
• Avoir des actions contextuelles sur les notifications (par exemple, aller directement sur la zone Commentaires, accepter la demande d’un membre à rejoindre une communauté, etc.)
• Avoir des notifications en temps réel, grâce à l’utilisation de websockets.

Après 2 mois de travail, et l’apport de plusieurs équipes, le nouveau centre de notifications est maintenant plus en phase avec un centre de notifications moderne. Les premiers retours lors de la release interne pour les employés LumApps sont très positifs, et nous espérons que l’adoption de LumApps sera améliorée en partie grâce au centre de notifications lors du déploiement chez les clients.