Le Progress Tracker de Star Citizen devait donner à la communauté une vue plus complète du travail des équipes de développement. En binôme avec un développeur backend, j’ai construit le frontend complet de la V2 : architecture Apollo, vue Gantt, recherche, filtres et navigation entre les équipes et les livrables.
Rendre le planning navigable
La roadmap publique de Star Citizen rassemble des équipes, des livrables et des périodes de travail sur plusieurs trimestres. Elle permet de consulter le planning par équipe ou par livrable, puis de naviguer vers les informations associées.
La première version du Progress Tracker présentait vingt équipes et plus de deux cents livrables. Le guide public mis à jour en juin 2023 documentait ensuite plus de cinquante équipes et plus de cinq cents livrables, avec des fonctions de recherche, de filtrage et plusieurs vues complémentaires.
Le volume et l’incertitude
Le Progress Tracker devait afficher davantage d’informations tout en indiquant clairement leur niveau de certitude.
Dans un développement agile, une période de travail planifiée peut changer. Une dépendance peut déplacer une tâche et une priorité peut être réévaluée. L’interface devait donc rendre la planification consultable sans laisser croire que chaque élément représentait une date de livraison garantie.
Les enjeux incluaient le volume de lignes, le chargement et la transformation des données, la relation entre équipes et livrables, plusieurs points d’entrée dans la même information et les regroupements par date, mois et trimestre calculés côté frontend.
Le frontend que j’ai construit
J’étais le développeur frontend d’un binôme avec un développeur backend. J’ai pris en charge la mise en place complète de la V2 côté frontend, de la configuration d’Apollo à la vue Gantt.
J’ai construit les filtres, la recherche, les vues par équipe et par livrable, les panneaux de détail et leur navigation. L’implémentation devait absorber un volume important de données alors que certains regroupements temporels n’étaient pas préparés côté backend.
Les décisions d’interface et de performance
Proposer plusieurs niveaux de lecture
Une roadmap de cette taille ne peut pas être comprise comme un tableau unique. L’interface permet de commencer par une équipe ou un livrable, puis d’ouvrir progressivement les informations plus détaillées. Cette hiérarchie limite la quantité de données présentée en même temps sans masquer leurs relations.
Relier équipes et livrables
Un même livrable peut concerner plusieurs équipes. La navigation permet de passer d’un point de vue à l’autre sans perdre le contexte. La vue par équipe et la vue par livrable répondent ainsi à deux questions différentes avec la même source de données.
Donner des outils pour réduire le volume
La recherche, les filtres et les actions permettant de développer ou réduire le contenu rendent la consultation plus ciblée. J’ai implémenté ces contrôles dans le frontend de la V2, avec la navigation entre les vues par équipe et par livrable.
Ne rendre que ce qui est utile
La vue Gantt combinait virtualisation, chargement progressif, cache Apollo et mémoïsation afin de limiter les appels et le nombre d’éléments recalculés ou rendus simultanément. Ces techniques répondaient au même objectif : garder la navigation réactive à mesure que le volume de données augmentait.
Construire la grille calendaire avec CSS Grid
CSS Grid structurait l’axe calendaire et alignait les données avec les différentes granularités temporelles. Les regroupements par date, mois et trimestre étaient calculés côté frontend, car ils n’étaient pas produits par le backend.
Représenter l’incertitude
L’interface devait aider les visiteurs à distinguer la période de travail d’une date de disponibilité. La hiérarchie, les libellés et les explications devaient travailler ensemble pour éviter une lecture trop définitive du planning.
Ce que la V2 a rendu possible
Le frontend livré rendait navigable un volume important de données, avec des vues par équipe et par livrable et une grille Gantt réactive.
Une interface qui explique ses limites
Le volume n’était qu’une moitié du problème. Il fallait aussi rendre visible le degré de certitude de chaque période, car une planification agile peut changer.
La roadmap distinguait une période de travail d’une date de disponibilité garantie. Les changements de granularité et les libellés rendaient cette distinction visible.