Le projet et son environnement :
Au cours de mes deux ans sur le projet, voici ce que j’ai appris et compris de l’application et de son contexte. Je vais tenter d’être bref, mais cela va être difficile en raison de la complexité du sujet :
KIKLOS, mot grec pour « Cycle » en français, est une application web à l’interface en anglais, conçue pour suivre et participer à l’ensemble du travail administratif politique réalisé par le Comité Européen des Régions à Bruxelles.
Une des notions clés du Comité des Régions est qu’il émet, au travers de ses membres réunis en Commissions, des Avis sur des sujets ou textes de lois du parlement Européen (Notez la majuscule à Avis).
Ces Avis, dont tient compte le parlement, possèdent un cycle de vie et leur contenu évolue en versions au cours des différentes étapes de leur traitement administratif.
Ils sont matérialisés sous forme de documents textes dont ces versions successives sont enregistrées et consultables.
Tout au long de leur traitement, d’autres documents leurs sont associés, comme premièrement le projet ou le texte de loi émis par le Parlement et sur lequel il donne … un Avis, d’où son nom.
Ces documents associés peuvent être de sources externes, internes, et de formes variées.
L’interface
Une fois saisie l’url de l’application, et après une page de connexion fournie par les services IT du Comité, voici ce qu’on découvrait comme page d’accueil début Mars 2019, lors de mon arrivée sur le projet :
Un bandeau d’en-tête / header horizontal contient le classique logo, puis les éléments périphériques comme la zone de notifications, le bandeau de connexion de l’utilisateur et enfin un bouton de recherche.
Le menu de navigation est calqué sur celui d’un site plus que d’une application, à l’horizontale, et la zone de contenu s’étend sur toute la largeur directement sous cette zone.
Premières propositions: la navigation
J’ai commencé par reprendre le travail en cours de la designer précédente.
La navigation avait besoin d’une refonte pour dégager de l’espace pour de prochains modules qui ne tiendraient pas dans l’espace supérieur à l’horizontale.
Ces modules sont « Agenda planning », « Thematic Planner » et « Communication Planner », situés au-dessus des options courantes « Themes », « Commissions » et « Timeline ». Nous avions beaucoup de retours utilisateurs signalant que le menu était difficile à comprendre du fait de cette double-barre : modules puis navigation principale.
Voici ce menu dans un autre contexte :
un des Thèmes de l’application, servant à catégoriser les avis et différents types de contenus, comme les publications du Comité des Régions, ou bien les « Meetings » et « Events », deux type d’éléments calendaires différents.
A cette question de place de navigation du menu, et de sa localisation dans la composition globale de l’application, s’ajoutait une question de place verticale très importante.
Occupée par les filtres de la plupart des vues, elle présentait les résultats de requêtes en base de données sous forme de cartes ou de tableaux.
Ces deux rangées de filtres sont encadrées en vert sous la capture suivante :
Ces deux rangées de filtres avaient donc besoin d’être compactées et réorganisées pour permettre aux données d’être vues plus rapidement. C’était une demande remontée par la plupart des utilisateurs des différents services du Comité.
La designer avait déjà proposé de « pousser » le menu sur la gauche, et d’enchaîner les filtres dans la navigation, par exemple en Themes > Theme > Sub-theme sous forme de wireframes.
Les collaborateurs de la partie « Business » ayant du mal à saisir l’idée encore plus que moi, j’ai décidé de pousser le rendu des maquettes jusqu’aux maquettes d’aspect afin de pouvoir en discuter plus sereinement :
Un problème de mélange de concepts
A chaque présentation des scénarios (il y eût en tout six itérations), les utilisateurs avaient du mal à comprendre la dernière étape, ou la sélection d’un sous-thème conditionnait les cartes ou tableaux qui étaient affichés dans la vue finale.
Il fallût plusieurs entretiens et réflexions puis analyses pour comprendre que le mélange de deux types d’actions la navigation et le filtrage étaient source de confusion pour les utilisateurs. Qui ne comprenaient pas du coup comment naviguer, et perdaient plusieurs dizaines de secondes avant de comprendre qu’il fallait cliquer sur les sous-thèmes pour finir par afficher la vue des thèmes avec un filtrage sous-thème pré-sélectionné et quitter la page d’accueil.
Finalement, un compromis a été trouvé, proposant de conserver la nouvelle navigation proposée, mais en conservant le filtrage des sous-thèmes dans la vue.
La navigation serait implémentée, et le problème d’occupation de l’espace par les filtres serait traité dans une autre « Story » ou tâche, selon la taxonomie de Jira et des méthodologies agiles avec lesquelles nous travaillons sur le projet.
Nous avons abouti à ceci:
Et la page d’accueil telle qu’elle était avant une refonte ultérieure.
Durant la phase de design du menu latéral de navigation, les développeurs et le chef de projet avaient acté l’achat d’un template de la librairie de composants PrimeNG.
J’ai mis un peu de temps à me faire à l’intégration de ce design à la fois dans le système de composants d’Angular 8 que je découvrais sur ce projet, et dans cette bibliothèque de composants complètement nouvelle pour moi.
Mais au bout de cinq jours, nous avons pu mettre ceci en ligne la semaine suivante :
