Choisir le bon concepteur d’applications ArcGIS : une approche de conception EU et IU – partie 1

Le système ArcGIS fournit une variété de modèles et de concepteurs d’applications web qui vous permettent de créer vos propres applications de cartographie sans avoir à écrire de code, notamment ArcGIS Instant Apps, Dashboards, Web AppBuilder et Experience Builder. En plus de proposer divers types de fonctionnalités que vous pouvez inclure dans vos applications, chacun permet de concevoir différents types d’interfaces et de mises en page d’applications. Mais comment déterminer dès le départ le type d’interface ou de mise en page dont vous avez besoin pour votre application? En quoi cela influence-t-il votre choix de modèle ou concepteur d’applications?

Introduction

« 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. »

– Bill Buxton, Microsoft Research (source)

Lors de la Conférence des SIG dans l’éducation et la recherche 2023, nous organiserons un atelier sur la conception d’interfaces utilisateur au moyen d’ArcGIS Experience Builder. Experience Builder est une solution relativement nouvelle de développement d’applications web proposée par Esri, et elle occupe une place unique dans le système ArcGIS. Elle vous permet de concevoir une application web à partir de modèles et de mises en page prédéfinis, d’une manière similaire à ArcGIS Web AppBuilder. En outre, Experience Builder vous permet de concevoir une application personnalisée sans avoir à écrire de code, simplement en glissant-déposant des éléments d’interface dans l’application. Si l’option de mise en page personnalisée vous offre une plus grande flexibilité dans la création d’applications, vous devez toutefois réfléchir à l’endroit où les éléments de l’application doivent être placés et à la manière dont les utilisateurs interagiront avec eux.

Premier d’une série, le présent billet de blogue porte sur certains principes de conception d’expérience utilisateur (EU) et d’interface utilisateur (IU) pour des applications de cartographie. Dans un prochain billet de la série, nous verrons comment ces principes correspondent aux différents modèles et concepteurs d’applications web offerts par Esri, notamment ArcGIS Instant Apps, ArcGIS Dashboards, ArcGIS Web AppBuilder et ArcGIS Experience Builder.

Si vous ne connaissez pas ces outils de conception d’applications, Esri propose de bonnes ressources d’introduction qui expliquent les différences entre chacun :

• Page de renvoi des concepteurs d’applications sur le site Esri.com
• Comment choisir la bonne application web dans ArcGIS Online?, ArcNews, automne 2021 (cette ressource présente d’excellentes questions d’orientation et un aperçu détaillé de chaque concepteur d’applications)

De quel type d’interface d’application avez-vous besoin?

Chacun des concepteurs d’applications énumérés ci-dessus remplit un objectif différent en termes de fonctionnalités, de types d’applications que vous pouvez créer et de flexibilité de conception. Dans cette optique, comment choisir le concepteur d’applications qui convient au type d’interface dont vous avez besoin? Et comment choisir entre les différentes options de mise en page disponibles dans chaque concepteur d’applications?

Pour répondre à cette question, nous devons prendre du recul et examiner certains modèles et principes courants de conception d’applications de cartographie. À cet effet, je vous invite à consulter une ressource inestimable, soit le site web Map UI Patterns créé par Michael Gaigg, responsable IU/EU de l’équipe des services professionnels d’Esri. Le chapitre 2 de ce site web porte sur le choix de la bonne mise en page et présente cinq modèles de conception :

Représentation filaire d’un exemple d’application de type « carte complète »

• Carte complète : la carte web occupe presque tout l’espace de la fenêtre de l’application. Cette option peut être utile lorsque la carte elle-même est au centre de tout ce que l’utilisateur doit faire (p. ex., explorer les données de la carte et ouvrir des fenêtres contextuelles) ou si l’application contient un ensemble d’outils que l’utilisateur devra utiliser de manière non linéaire et ouverte (Michael met de l’avant l’exemple d’utilisateurs SIG expérimentés effectuant une analyse spatiale complexe).

Représentation filaire d’un exemple d’application de type « carte partielle »

• Carte partielle : la carte web est présentée à côté d’un volet qui fournit des outils, de l’information ou du contexte à l’utilisateur. Cette option est utile lorsque l’application cible un flux de travaux particulier. Les outils doivent alors être facilement accessibles à l’utilisateur en un seul endroit, sans cacher la carte et sans obliger l’utilisateur à chercher partout dans l’interface ce dont il a besoin. Pour les utilisateurs qui lisent de gauche à droite, le volet a tendance à être placé à gauche de la fenêtre de l’application.

Représentation filaire d’un exemple d’application de type « carte de référence »

• Carte de référence et carte intégrée : la carte web fait partie d’une page web et vient appuyer d’autre contenu au lieu d’en être le centre. Par exemple, une petite carte web intégrée à un tableau de bord ou une carte narrative.
• Aucune carte : il n’y a pas de carte visible à l’écran, mais pour nos besoins, un lien est établi en arrière-plan à un SIG (p. ex., pour interroger des données ou afficher des graphiques ou des statistiques).

De nombreux modèles et concepteurs d’applications sont configurés pour créer des applications de type « cartes complètes » par défaut. Vous devez toutefois prendre le temps de déterminer si ce modèle de conception est celui qui convient le mieux à votre application, en fonction des critères ci-dessus. Par exemple, si vous devez concevoir une application orientée tâche où les utilisateurs sont « dirigés vers un flux de travaux précis », Michael indique que le modèle de conception de type « carte partielle » est souvent idéal.

Questions d’orientation relatives à la mise en page d’applications

Voici d’autres questions auxquelles vous devrez réfléchir lorsque vous élaborerez la mise en page de l’interface de votre application :

• Les widgets doivent-ils être visibles par défaut à l’ouverture de l’application? Il peut s’agir d’un widget de légende de carte, d’un outil fréquemment utilisé (voir le point suivant) ou d’un widget de texte contenant des instructions ou des renseignements généraux sur l’application.
• Certains widgets doivent-ils être toujours visibles? C’est utile si votre application répond à un objectif unique et clairement défini, pour lequel un certain outil peut être un élément essentiel du flux de travaux. En fonction de l’application, il peut s’agir de filtrer des données, de calculer des itinéraires ou même simplement d’activer ou de désactiver des couches.
• Est-ce que plus d’un widget devra être visible à la fois? Pensez aux flux de travaux de vos utilisateurs et à la fréquence à laquelle ils devront passer d’un widget à l’autre pour accomplir une tâche donnée (p. ex., si l’utilisateur doit copier des données entre des widgets ou s’y reporter simultanément).
• Où doivent être positionnés les widgets les uns par rapport aux autres? Si vos utilisateurs doivent fréquemment passer d’un widget à l’autre pour accomplir une tâche donnée, il vaut mieux qu’ils n’aient pas à naviguer dans toute l’application pour le faire. La loi de Fitts stipule que plus un objet est proche (et grand), plus il est rapide de cliquer dessus.
• Les widgets doivent-ils s’afficher au-dessus ou à côté de la carte? Pour certains flux de travaux (p. ex., filtrer ou modifier des données sur la carte), il serait préférable de ne pas cacher la carte avec la fenêtre d’un widget, et afficher plutôt ce dernier à côté de la carte.
• Combien de fonctionnalités devez-vous réellement inclure, selon les besoins de vos utilisateurs? Comme le note le gourou de l’ergonomie Jakob Nielsen dans l’une de ses classiques heuristiques de conception, tout ce que vous ajoutez à une interface est en concurrence avec tout le reste pour attirer l’attention de l’utilisateur. Michael Gaigg donne l’exemple d’une application de type « fourre-tout », où trop de widgets ont été inclus et où il devient difficile pour l’utilisateur de trouver la fonctionnalité dont il a besoin.

Je vous recommande de commencer par faire un croquis de l’application sur papier, afin de trouver des idées très variées sur la façon de concevoir l’application et d’en organiser les fonctionnalités (regardez la vidéo sur le prototypage et la mise à l’essai de l’interface utilisateur sur le site Chercheur de ressources en éducation supérieure d’Esri Canada). Ensuite, vous pouvez affiner votre conception pour choisir celle qui convient le mieux, la mettre à l’essai auprès des utilisateurs et opter pour un modèle ou concepteur d’applications qui vous permette de vous en approcher le plus possible. Cela vaut généralement la peine de consacrer un peu plus de temps à la réflexion et à l’optimisation de la conception, afin d’épargner à vos utilisateurs du temps et des frustrations par la suite.

Conclusion

Dans ce billet de blogue, nous avons étudié certains modèles de conception d’interfaces utilisateur pour des applications de cartographie web. Nous nous sommes également penchés sur plusieurs pistes de réflexion qui vous aideront à concevoir vos interfaces. Dans un prochain billet de cette série, nous ferons le pont entre ces principes et les modèles et concepteurs d’applications d’Esri, et nous réfléchirons à la manière d’appliquer ces principes. Nous nous intéresserons plus précisément à ArcGIS Instant Apps, ArcGIS Dashboards, ArcGIS Web AppBuilder et ArcGIS Experience Builder. Nous verrons également comment choisir entre ces concepteurs d’applications en fonction du type d’interface utilisateur que vous souhaitez créer, et comment vous pouvez utiliser chacun d’entre eux pour mettre en œuvre les différents modèles de conception abordés dans ce billet.

Entre-temps, si vous souhaitez en savoir plus sur la conception d’interfaces utilisateur pour des applications de cartographie, consultez le parcours d’apprentissage sur la conception d’interfaces utilisateur sur le site Chercheur de ressources en éducation supérieure. Ce parcours d’apprentissage se compose actuellement de deux vidéos, et nous y ajouterons d’autres ressources pendant l’année.

D’ici là, bonne expérience de conception!