Convertir une application web en une application ArcGIS – Partie 2 : créer un sélecteur de couches

Lors du développement d’une application, il est toujours utile de garder à l’esprit les besoins de vos utilisateurs afin de savoir quels outils vous devez inclure pour qu’ils puissent effectuer leurs tâches. Il est tout aussi utile d’en tenir compte au moment de concevoir l’interface utilisateur. Un grand nombre d’utilisateurs de SIG tiennent pour acquis, par exemple, qu’ils pourront activer et désactiver les couches d’une carte. Si vous utilisez des outils prêts à l’emploi, vous n’aurez peut-être pas beaucoup de contrôle sur la conception de l’interface. Il se peut toutefois que vous puissiez apporter au fichier JSON de petites modifications qui amélioreront considérablement l’expérience utilisateur.

Lorsque vous concevez une application, comment décidez-vous des fonctionnalités à inclure et de la manière dont celles-ci seront présentées à l’écran? Si vous utilisez l’un des modèles d’applications web ou des concepteurs d’applications d’Esri, certaines de ces décisions sont déjà prises pour vous. Il se peut que vous disposiez toutefois d’un nombre limité d’options, telles que l’emplacement d’un outil et le contenu d’un volet. Cependant, il est toujours utile de prendre du recul et de réfléchir à ce que vos utilisateurs ont besoin d’accomplir à l’aide de l’application et à ce que cela signifie sur le plan de la conception de cette dernière.

Voici quelques questions que vous pouvez vous poser : De quoi vos utilisateurs ont-ils besoin pour apprendre de vos données? De quoi ont-ils besoin pour les visualiser, les modifier ou les analyser? Pourquoi doivent-ils effectuer ces tâches? Ou, pour reprendre une expression couramment utilisée dans le domaine de la conception d’expérience utilisateur, quelles sont les « tâches à accomplir » de vos utilisateurs? De telles questions vous aideront à créer une application qui correspond à la façon dont vos utilisateurs ont besoin de l’utiliser, de sorte qu’elle soit conçue pour s’adapter aux flux de travaux de vos utilisateurs plutôt que l’inverse.

Dans le premier billet de blogue de cette série en deux parties, mon collègue Anastassios Dardas a décrit une application que notre groupe a développée dans le cadre d’une collaboration avec le groupe de recherche interdisciplinaire Collaborative for Advanced Landscape Planning (CALP) de l’Université de la Colombie-Britannique. L’application Energy Explorer du CALP (CEE) permet aux utilisateurs de visualiser trois mesures différentes de la consommation d’énergie (soit les émissions de gaz à effet de serre, l’intensité des émissions de gaz à effet de serre et l’intensité de la consommation d’énergie) pour les propriétés de la ville de Vancouver. Nous avons constaté que l’utilisation d’une liste de couches pour activer et désactiver les couches cartographiques posait des problèmes de convivialité. Nous avons donc créé notre propre « sélecteur de couches », qui correspond davantage à la structure de l’application.

Quand une liste de couches ordinaire ne suffit pas

La carte web de l’application CEE utilise deux couches pour chaque mesure de consommation d’énergie. L’une est une couche d’entités qui s’affiche lorsque l’utilisateur effectue un zoom avant à l’échelle des quartiers (1:20 000), et l’autre est une couche de tuiles qui s’affiche lorsque l’utilisateur fait un zoom arrière (au-delà de cette échelle). Si aucun zoom n’est effectué sur la carte, l’utilisation de tuiles dont le rendu est généré au préalable permet d’afficher rapidement un très grand nombre d’entités. Si un zoom avant est appliqué, l’utilisation d’une couche d’entités permet d’éviter d’avoir à générer et à stocker un grand nombre de tuiles. Cette méthode est décrite plus en détail dans un billet de blogue rédigé par Kelly Gerrow-Wilcox d’Esri Inc.

Dans le cas qui nous concerne, avoir deux couches pour chaque mesure posait problème : si nous avions utilisé un widget courant de type liste de couches dans ArcGIS Web AppBuilder, les utilisateurs auraient été obligés d’activer et de désactiver manuellement les couches d’entités et de tuiles individuelles chaque fois qu’ils auraient voulu basculer d’une mesure de consommation d’énergie à une autre. Résultat? Une expérience utilisateur de piètre qualité qui se serait vite avérée fastidieuse. Sans parler du fait que cela pourrait également prêter à confusion. Par exemple, si l’utilisateur n’avait activé aucune couche de tuiles, puis avait effectué un zoom arrière suffisant, il aurait obtenu une carte vide avec seul le fond de carte visible.

Exemple du widget Liste des couches par défaut dans Web AppBuilder avec la mesure des émissions de gaz à effet de serre affichée. Notez que, puisque le zoom avant est très rapproché, la couche de tuiles ne s’affiche pas (même si elle est activée); on voit plutôt la couche d’entités.

Si nous avions utilisé ArcGIS Experience Builder et la nouvelle visionneuse de carte d’ArcGIS Online pour développer l’application, nous aurions pu créer des groupes de couches dans notre carte pour regrouper les couches de tuiles et d’entités pour chaque mesure, afin que les utilisateurs puissent les activer et les désactiver en tant que groupe. Cette solution n’est toutefois pas idéale, car les utilisateurs pourraient tout de même développer les groupes pour activer et désactiver les couches individuelles. S’ils avaient effectué un zoom arrière, ils auraient alors obtenu le même résultat : une carte vide.

Exemple d’utilisation d’un groupe de couches dans la nouvelle visionneuse de carte d’ArcGIS Online, où les groupes de l’intensité des émissions de GES (GHGi) et de l’intensité de la consommation d’énergie (EUI) sont désactivés. Dans cet exemple, nous avons effectué un zoom arrière, et seules les couches de tuiles sont visibles sur la carte.

Dernier point : une liste de couches permet aux utilisateurs d’activer et de désactiver toute combinaison de couches, ce qui n’est pas utile dans notre cas. Puisque nos couches montrent la consommation d’énergie pour chaque parcelle à Vancouver, elles se chevauchent complètement. Par conséquent, si l’utilisateur active une couche sans désactiver celle qui y est superposée, il se peut qu’il ne voie aucun changement sur la carte, ce qui pourrait également prêter à confusion.

Besoins des utilisateurs et complexité de l’interface utilisateur

Sur le plan de la conception de l’interface utilisateur, Alan Cooper explique, dans un article publié dans Technical Communication, que tout repose sur la différence entre le « modèle de mise en œuvre » du programme et le « modèle mental » de l’utilisateur. Il s’agit de la différence entre la façon dont tout est mis en œuvre « en coulisses » pour créer l’application, et la façon dont l’utilisateur comprend les fonctionnalités de l’application et s’attend à être en mesure de les utiliser. Étant donné la complexité de la mise en œuvre d’une application, il est utile de concevoir l’interface de manière à ne pas obliger l’utilisateur à gérer des éléments complexes dont il n’a pas besoin.

Dans le cas de l’application CEE, le modèle de mise en œuvre comprend des couches de tuiles et d’entités distinctes pour chacune des mesures de consommation d’énergie. Le choix d’un tel modèle visait à améliorer les performances. Les utilisateurs finaux n’ont pas besoin de connaître ce fait, et cette multitude de couches rend l’interface complexe. Par ailleurs, comme nous présentons à l’utilisateur des mesures de consommation d’énergie, ne serait-il pas plus logique de concevoir l’interface autour de ces mesures, plutôt qu’autour des couches de données sous-jacentes?

Nous pouvons également envisager l’interface sur le plan des « tâches à accomplir ». Les utilisateurs de l’application CEE n’ont pas besoin de pouvoir manier librement les couches SIG. Ils ont simplement besoin d’un outil pour les aider à en apprendre plus sur la consommation d’énergie dans la ville, ou peut-être pour leur propre quartier ou logement. Les couches SIG servent cet objectif plus large, plutôt que d’être le point de mire de l’interaction.

La solution

Pour notre projet, nous avons trouvé une solution aux problèmes décrits ci-dessus en utilisant le widget Géosignet de Web AppBuilder. Ce widget est normalement utilisé pour fournir un ensemble d’étendues de carte prédéfinies auxquelles les utilisateurs peuvent accéder rapidement. Il s’agit d’un outil particulièrement utile pour l’application CEE, car il permet de préciser les couches cartographiques qui doivent être activées et désactivées pour chaque signet. En ayant un signet pour chaque mesure de consommation d’énergie, il est possible d’activer seulement ces deux couches et de désactiver toutes les autres.

Il y a toutefois un problème avec cette approche : les signets dirigent l’utilisateur vers une étendue de carte différente, ce qui n’est pas nécessaire. Il n’y a aucun moyen de désactiver cette fonctionnalité dans l’interface de Web AppBuilder, mais il y a une option cachée dans le code JSON de l’application Web AppBuilder qui permet d’ignorer les étendues. Toutes les applications Web AppBuilder (ainsi que celles conçues avec les autres modèles et concepteurs d’applications d’Esri) stockent leur configuration dans un fichier JSON qui peut être modifié en dehors de l’éditeur principal de l’application. Ainsi, avec une modification appropriée, nous pouvons créer des signets pour des étendues de carte définies à l’aide du widget Géosignet de Web AppBuilder, puis modifier le fichier JSON par la suite pour ignorer les étendues de carte.

Vous pouvez apporter ces modifications en suivant les instructions de ce document.

Le résultat? Un widget qui permet aux utilisateurs de basculer entre les thèmes de données que nous voulions leur montrer, sans avoir à manipuler les couches SIG sous-jacentes. De plus, les boutons de signet sont beaucoup plus attrayants visuellement que les cases à cocher ou les boutons radio habituels.

Les étapes décrites dans le document PDF ci-dessus vous aideront à créer un sélecteur de couches personnalisé. Mais ce n’est pas tout ce que vous devez savoir :

• Si vous apportez des modifications au widget Géosignet ultérieurement dans Web AppBuilder, vous devrez peut-être apporter de nouvelles modifications dans le fichier JSON.
• Pour maintenir une certaine cohérence entre la carte et les signets, assurez-vous que les couches qui sont activées par défaut dans votre carte web correspondent à l’un des signets que vous avez créés.
• Contrairement aux cases à cocher dans une liste de couches qui indiquent les couches qui sont activées, le widget Géosignet n’indique pas quel signet est affiché à un moment donné. Il s’agit d’un problème si l’utilisateur a ouvert la carte, mais n’a pas encore sélectionné de signet, car il se peut qu’il ne sache pas quelles couches sont chargées par défaut. Une façon de contourner ce problème est de créer pour chaque signet une miniature qui en représente le contenu. Dans l’application CEE, chaque miniature était constituée d’une icône aux couleurs similaires à la symbologie des couches. Nous avons réalisé par la suite qu’il serait plus pratique d’employer une capture d’écran de la ou des couches cartographiques que la miniature permet d’afficher, comme dans la capture d’écran ci-dessous. Quel que soit le projet de conception d’interface utilisateur, il y aura toujours des problèmes que vous ne remarquerez pas tant que vous et vos utilisateurs n’aurez pas commencé à utiliser l’application.

• Il se peut que ce sélecteur de couches ne convienne pas si les utilisateurs finaux de votre application doivent pouvoir choisir une combinaison personnalisée de couches à afficher sur la carte. Dans le cas de l’application CEE, ce n’était pas nécessaire. En fait, nous ne voulions pas que les utilisateurs puissent le faire. Dans ce contexte, rappelez-vous les mots de Bill Buxton de Microsoft Research : « Tout est mieux pour quelque chose et pire pour autre chose. L’astuce, c’est de savoir ce qui est quoi, pour quoi, quand, pour qui, où, et surtout, pourquoi. »
• Si vous utilisez Experience Builder au lieu de Web AppBuilder, vous avez également la possibilité de modifier de façon similaire le fichier JSON. Dans Experience Builder, le fichier JSON ne possède pas la propriété « isSaveExtent ». Vous pouvez toutefois supprimer les blocs de code « extent » et « viewpoint » pour chaque signet afin de parvenir au même résultat.

Conclusion

Dans le présent billet de blogue, nous avons examiné une application Web AppBuilder dans laquelle nous voulions que les utilisateurs puissent passer d’une paire de couches à l’autre. Avec une liste de couches habituelle, les utilisateurs auraient été obligés de basculer manuellement entre les couches. C’est pourquoi nous avons repensé la façon dont ces couches pourraient être présentées à l’utilisateur. Nous avons utilisé le widget Géosignet afin de créer un signet pour chaque ensemble de couches. Nous avons également désactivé l’étendue de la carte pour chaque signet afin que seule la sélection de couches soit modifiée (et non l’étendue de la carte) lors de la sélection du signet.

Même si vous utilisez un modèle d’application « prêt à l’emploi », il est toujours possible d’y déroger et de jouer un peu avec la conception de votre application. Restez à l’affût d’autres billets de blogue qui porteront sur la conception d’interface utilisateur avec les modèles et les concepteurs d’applications d’Esri. De plus, nous vous invitons à consulter le parcours d’apprentissage sur la conception d’interface utilisateur accessible sur le site Chercheur de ressources en éducation supérieure.

Ce billet a été écrit en anglais par Jonathan Van Dusen et peut être consulté ici.