Convertir une application web en une application ArcGIS – Partie 1
Savoir comment convertir des applications web d’un cadre de codage à l’autre est une compétence importante pour les développeurs. Le premier volet de ce billet de blogue en deux parties présente différents processus de conversion ainsi qu’un exemple d’un ancien projet collaboratif pour illustrer les avantages du système ArcGIS.
Étude de cas
Le groupe de recherche interdisciplinaire Collaborative for Advanced Landscape Planning (CALP) de l’Université de la Colombie-Britannique crée de nouvelles approches collaboratives en matière d’apprentissage, de planification et de mobilisation sociale dans les domaines multidisciplinaires des changements climatiques, de la planification énergétique communautaire et de la foresterie urbaine. Parmi les dix projets en cours du groupe CALP, on retrouve l’application Community Energy Explorer (CEE).
L’application web interactive CEE est axée sur la planification énergétique et l’atténuation des émissions de carbone à Vancouver. Cet outil informe les communautés et les résidents de la région métropolitaine de leur demande potentielle en énergie, de leurs émissions de gaz à effet de serre (GES) et de leurs options d’approvisionnement en énergie renouvelable à l’aide de pages d’information, de scénarios et de cartes web. L’objectif à long terme de CEE est de fournir de l’information à jour et de favoriser l’engagement en sensibilisant la population à la durabilité. Le groupe voué à l’éducation supérieure d’Esri Canada a été chargé de travailler avec les chercheurs de cette application pour migrer des cartes Leaflet vers ArcGIS ainsi que pour améliorer l’interface et l’expérience utilisateur des cartes relatives à l’énergie.
Types de conversion « cadre à cadre »
Avant d’examiner le processus de conversion de l’application CEE et ses résultats, il faut souligner que les développeurs envisageant une conversion « cadre à cadre » doivent bien connaître le processus requis et les frais généraux techniques connexes. Voyez cela comme un pays qui envisage de convertir sa production d’électricité. En tant que militant ou législateur, vous poseriez des questions sur les solutions possibles, comme « Quels changements sont requis? », « Pourquoi devons-nous faire ces changements? » et « Combien ce processus coûtera-t-il? » Le type et l’étendue des changements à apporter au système actuel déterminent le coût et le temps requis pour les mettre en œuvre.
Ce concept s’applique à plus petite échelle aux développeurs convertissant des applications. Quatre types de conversions s’offrent à eux.
- Conversion d’applications prêtes à l’emploi en applications prêtes à l’emploi
La création d’applications web à l’aide d’outils prêts à l’emploi nécessite peu ou pas de codage. Habituellement, ces outils vous permettent de glisser-déposer des widgets et des éléments de mise en page, en plus de modifier des modèles à la volée. Ils visent à réduire considérablement le travail technique requis pour développer et tenir à jour une application.
Un exemple de ce type de conversion serait de convertir une application web créée avec ArcGIS Web AppBuilder en une application ArcGIS Experience Builder ou bien de transformer une application basée sur un modèle de Tableau en une application ArcGIS Insights. Le niveau de difficulté dans ces deux cas est relativement faible : la conversion ne nécessite aucune connaissance en codage, mais il faut savoir naviguer entre deux cadres prêts à l’emploi différents.
- Conversion d’applications personnalisées en applications prêtes à l’emploi
Contrairement aux outils prêts à l’emploi, les outils personnalisés nécessitent du codage pour concevoir une application web. Les développeurs créent des applications web personnalisées pour une foule de raisons : ils préfèrent les solutions personnalisées, le processus est gratuit ou à faible coût, l’application requiert des fonctions qui ne sont pas offertes par les outils prêts à l’emploi ou bien c’est un mélange de tous ces facteurs.
Par exemple, il pourrait s’agir de convertir une application créée avec la combinaison à code source libre de Leaflet JS (fonction frontale) et de CartoDB (fonction dorsale) en une application basée sur un modèle ArcGIS Online (qui gère à la fois les fonctions frontales et dorsales). Le niveau de difficulté varie de faible à modéré selon les équivalents offerts par les outils prêts à l’emploi aux fonctions personnalisées. Ce type de conversion nécessite parfois plus d’un outil prêt à l’emploi pour trouver toutes les fonctionnalités de l’application personnalisée, lesquelles devront être soigneusement fusionnées pour répondre à toutes les exigences.
- Conversion d’applications prêtes à l’emploi en applications personnalisées
En règle générale, un développeur effectuerait ce type de conversion uniquement si les outils prêts à l’emploi actuels n’offrent pas les fonctionnalités supplémentaires requises pour l’application. Il pourrait s’agir de convertir une application basée sur un modèle d’ArcGIS Dashboards en une application ArcGIS API for JavaScript (JSAPI) et d’y ajouter des API tierces pour effectuer des interrogations approfondies et afficher des visualisations plus avancées (comme utiliser D3.js pour afficher des graphes de connaissances). Le niveau de difficulté de cette conversion est élevé, car il faut convertir la fonctionnalité de l’outil prêt à l’emploi en un code personnalisé, en plus d’ajouter de nouvelles fonctions.
- Conversion d’applications personnalisées en applications personnalisées
Cette conversion est requise si les fonctionnalités sont plus robustes et polyvalentes dans le nouveau cadre que les originales, comme lors de la conversion d’une application web Leaflet JS en une application ArcGIS JSAPI. Le niveau de difficulté est élevé, et il pourrait même s’agir du type de conversion le plus difficile : le développeur doit connaître les deux cadres de codage personnalisés (original et nouveau) pour procéder à la conversion.
Dans la section suivante, nous examinerons la conversion de l’application CEE en soulignant plusieurs limites des cartes d’origine et en décrivant les étapes suivies pour réaliser la conversion de cette application personnalisée en une application prête à l’emploi (2e type mentionné ci-dessus).
Limitations des cartes de l’application CEE
Cette partie présente les modifications apportées par les chercheurs et les développeurs pour améliorer l’interface et l’expérience utilisateur de l’application d’origine. Commençons par l’expérience utilisateur. La page d’accueil des cartes de l’application CEE comprend deux cartes distinctes – l’une sur la demande en énergie et l’autre sur l’approvisionnement en énergie. L’utilisateur doit sélectionner une carte pour la consulter, puis revenir à la page d’accueil pour sélectionner et visualiser l’autre. Ce fonctionnement est hérité du processus de conception de l’application originale (la carte sur l’approvisionnement a été élaborée avant celle relative à la demande) qui repose sur un ancien cadre de développement. Pour améliorer l’expérience utilisateur, les deux cartes devraient se trouver dans la même application.
La carte de la demande en énergie de l’application originale CEE montrant l’intensité de la consommation d’énergie à Vancouver.
La carte sur l’approvisionnement en énergie de l’application originale CEE affichant le potentiel en énergie solaire par îlots et les courbes de niveau des journées nuageuses dans la région de Vancouver.
Améliorer l’interactivité permettrait également de rehausser l’expérience utilisateur des cartes web. Bien que les deux cartes soient faciles à utiliser, l’interactivité dans la carte sur la demande en énergie se limite à modifier la variable affichée (intensité de la consommation d’énergie, GES ou intensité des émissions de GES) et à cliquer sur un emplacement pour voir les valeurs pertinentes. La carte sur l’approvisionnement en énergie permet à l’utilisateur de choisir les couches à afficher et présente les statistiques ou les indicateurs connexes lorsque l’utilisateur survole ou sélectionne une entité. Toutefois, en cliquant sur la carte, on obtient les statistiques de la demande en énergie de la municipalité, ce qui pourrait être déroutant pour les utilisateurs intéressés par l’approvisionnement en énergie.
En outre, aucune des cartes ne présente de statistiques ou d’indicateurs sur les entités comprises dans l’étendue actuelle de la carte. Rendue populaire par les SIG web, cette fonctionnalité montre de façon interactive les variations spatio-temporelles réactives dans la zone d’intérêt actuelle en effectuant un zoom ou un déplacement sur la carte. Quant à l’interface utilisateur, le style simple des cartes peut sembler désuet, surtout si l’on considère qu’elles ont pour objectif d’accroître la sensibilisation sur un sujet important et d’actualité. Pour ce faire, l’application doit être visuellement attrayante.
Conversion des cartes de l’application CEE vers ArcGIS
Lorsque la division de l’enseignement supérieur a commencé à travailler sur l’amélioration des cartes de l’application CEE, elle s’est attaquée d’emblée aux problèmes les plus évidents de l’expérience utilisateur, notamment à la nécessité de faire des allers-retours entre deux cartes distinctes. Pour y parvenir, elle a utilisé le modèle Story Map Series des cartes narratives d’Esri (également connu sous le nom de Classic Story Maps). La mise en page par onglets de ce modèle permet à un utilisateur de basculer entre différentes cartes en un seul clic, ce qui donne l’impression que l’application web est mieux organisée. Le premier onglet de la nouvelle application, intitulé « Energy Demand » (demande en énergie), contient des données sur l’intensité de la consommation d’énergie, et sur la quantité et l’intensité des émissions de gaz à effet de serre. L’autre onglet, intitulé « Energy Supply » (approvisionnement en énergie), contient des données sur l’hydroélectricité, la récupération de chaleur industrielle, l’énergie solaire, la biomasse et l’énergie éolienne.
Conversion de données
Notre deuxième étape consistait à convertir les données GeoJSON de l’application CEE en couches d’entités hébergées et en couches en tuiles. La carte dans l’onglet « Energy Demand » (demande en énergie) utilise à la fois des couches d’entités hébergées et des couches en tuiles, car ses données portent sur des centaines de milliers d’entités de bâtiments. Lorsqu’il y a autant d’entités, les couches en tuiles sont nécessaires pour afficher rapidement la carte; cependant, elles ne contiennent pas de renseignements sur les attributs.
Dans ces conditions, comment un utilisateur peut-il visualiser les renseignements sur les attributs tout en profitant d’un rendu fluide? Une solution à ce problème d’expérience et d’interface utilisateur consiste à faire passer la plage de visibilité des couches en tuiles de l’échelle du pays (1:2 300 000) à celle d’une seule rue (1:10 000), et à définir la visibilité de la couche d’entités hébergée avec une valeur inférieure à l’échelle sélectionnée (< 1:10 000). N’oubliez pas que cette application web est destinée aux résidents et aux communautés. Ainsi, il n’est pas nécessaire de voir les attributs d’une entité de bâtiment au niveau du comté ou de la ville. Nous avons effectué le processus de conversion et de publication des données dans ArcGIS Pro, et nous avons ajouté les couches publiées avec leurs paramètres respectifs sur une carte web grâce à la visionneuse de carte classique.
Création des applications web
Pour la carte de la demande en énergie, nous voulions une application de type tableau de bord avec des jauges représentant les statistiques et des widgets prêts à l’emploi pour augmenter l’interactivité de la carte. Heureusement, Web AppBuilder offre une variété de thèmes (y compris le tableau de bord) et de widgets, avec des styles personnalisables et différentes options de mise en page pour les éléments d’interface utilisateur. Nous avons sélectionné le thème du tableau de bord, inséré la carte web avec les couches de demande en énergie et ajouté trois widgets infographiques avec des jauges dont les valeurs varient en fonction de la sélection de l’utilisateur et de l’étendue de la carte. Nous avons ensuite intégré l’application Web AppBuilder configurée en tant qu’iFrame dans l’onglet « Energy Demand » (demande en énergie) de la carte narrative du modèle Map Series.
La nouvelle carte de la demande en énergie de l’application CEE, montrant l’intensité de la consommation d’énergie à Vancouver.
Pour la carte de l’approvisionnement en énergie, nous voulions avoir un thème similaire, mais présenter davantage de renseignements. Il fallait afficher les statistiques sur chaque type d’énergie renouvelable, et nous voulions que les utilisateurs puissent sélectionner plusieurs entités sur une couche activée et voir, par exemple, l’énergie solaire potentielle totale pour la zone sélectionnée. Heureusement, ces composants peuvent être ajoutés dans ArcGIS Dashboards, sans qu’il soit nécessaire ou presque de personnaliser le style. D’abord, nous avons ajouté les couches d’entités hébergées sur les énergies solaire, industrielle, hydroélectrique, de biomasse et éolienne à une carte dans la visionneuse de carte classique (voir la figure ci-dessous).
Visionneuse de carte classique contenant les couches de l’approvisionnement en énergie.
Ensuite, nous avons créé un nouveau tableau de bord ArcGIS Dashboards et ajouté la carte. Nous avons configuré les paramètres de la carte dans le tableau de bord pour activer les fenêtres contextuelles, filtré les entités sur toutes les couches d’entités hébergées en fonction de l’étendue de la carte, et appliqué des actions (sélection) aux couches des énergies éolienne et solaire. Nous avons ensuite ajouté des panneaux latéraux pour afficher des instructions sur la façon d’utiliser l’application ainsi que la légende de la couche sélectionnée. En bas de la carte, nous avons inséré cinq indicateurs qui résument les statistiques pour chaque type d’énergie renouvelable, soit en fonction de la sélection (énergies solaire et éolienne uniquement) (voir la figure), soit en fonction de l’étendue de la carte (voir la figure).
Paramètres de configuration des modifications de l’étendue de la carte pour les couches de l’approvisionnement en énergie dans ArcGIS Dashboards.
Paramètres de configuration des modifications de sélection pour les couches de l’approvisionnement en énergie dans ArcGIS Dashboards.
Enfin, nous avons ajouté l’application ArcGIS Dashboards en tant qu’iFrame à l’onglet « Energy Supply » (approvisionnement en énergie) (illustration ci-dessous) du modèle Map Series.
La création d’une application web (personnalisée ou non) est un processus itératif qui implique que des modifications (souvent petites et parfois grandes) soient effectuées et testées jusqu’à l’obtention d’une expérience et d’une interface utilisateur satisfaisantes. L’expérience utilisateur étant subjective, il n’existe pas de directives ni de systèmes de notation standard relatifs à sa conception, ni à celle de l’interface utilisateur. On évalue simplement si l’utilisateur peut naviguer dans l’application avec peu ou pas d’aide du développeur. Pour ce projet, il y a eu au moins quatre changements majeurs à l’expérience et à l’interface utilisateur, ainsi que quelques ajustements mineurs, avant que l’équipe de l’application CEE soit satisfaite de la conception finale.
La nouvelle carte de l’approvisionnement en énergie de l’application CEE affichant le potentiel en énergie solaire par secteur de recensement.
Après avoir lu ce billet, vous devriez avoir une bonne idée des types de processus qu’implique une conversion entre différents cadres de développement web, ainsi que des outils du système ArcGIS qui ont été utilisés pour recréer les cartes web de l’application CEE. Bien que les outils d’application web d’ArcGIS décrits ci-dessus soient perfectionnés et puissants, il reste une composante importante de l’expérience et de l’interface utilisateur que nous n’avons pas abordée. Comme nous l’avons mentionné, il fallait des couches en tuiles et des couches d’entités hébergées pour que la carte de la demande en énergie affiche les entités de bâtiments aux échelles de la ville et du comté et pour fournir des renseignements sur les attributs à l’échelle de la rue. Eh bien, vous pouvez organiser les couches d’entités hébergées et de tuiles en un groupe par type de demande en énergie (par exemple, un groupe pour les émissions de gaz à effet de serre). Cependant, avec les outils prêts à l’emploi actuels, l’utilisateur devrait tout de même activer manuellement la couche de tuiles pour la visualiser à la plage de visibilité définie, puis activer manuellement la couche d’entités hébergée chaque fois qu’il visualise la carte dans cette plage de visibilité. Avec cela, si l’utilisateur désactive uniquement la couche de tuiles et effectue un zoom arrière, la carte deviendra vide (ou vice versa si l’utilisateur effectue un zoom avant). En outre, si vous souhaitez afficher un autre type de demande en énergie, vous devez désactiver manuellement les couches actuelles et activer un autre ensemble de couches pour le type souhaité (par exemple, désactiver les couches des émissions de gaz à effet de serre et activer celles de l’intensité de la consommation d’énergie). Cette manipulation diminue l’efficacité de l’interface utilisateur et nuit à l’expérience utilisateur, et il n’y a pas d’outil prêt à l’emploi pour regrouper les couches d’entités hébergées et de tuiles afin de les activer toutes les deux en un seul clic, tout en permettant à l’utilisateur de basculer d’un groupe de couches à l’autre. Heureusement, une routine peut fournir cette fonctionnalité sans qu’il soit nécessaire de reconstruire l’application au moyen d’un code personnalisé.
Dans la deuxième et dernière partie de ce billet, mon collègue Jonathan Van Dusen décrira en détail comment créer cette couche de groupe avec la fonctionnalité de basculement.
Ce billet a été écrit en anglais par Anastassios Dardas et peut être consulté ici.