Building an ArcGIS Web App, Part 1: How to integrate Web GIS apps to the ArcGIS system

Knowing how to convert between different coding frameworks is an important skill for Web app developers. Part 1 of this two-part blog post series describes different types of conversion processes and provides an example from a past collaborative project to illustrate the benefits of the ArcGIS system.

Case Study

The Collaborative for Advanced Landscape Planning (CALP) at the University of British Columbia is an interdisciplinary research group that aims to develop new approaches to collaborative learning, planning, and social mobilization within the interdisciplinary domains of climate change, community energy planning, and urban forestry. CALP has 10 active projects, including the Community Energy Explorer (CEE).

CEE is an interactive Web application for local energy planning and carbon emission mitigation. More specifically, the application acts as a knowledge tool for communities and residents of the Metro Vancouver region, informing them of their potential energy demand, greenhouse gas emissions, and renewable energy supply options through a series of information pages, scenarios, and web maps. The long term goal of CEE is to provide up-to-date information and empower civic engagement through sustainability awareness. Our Esri Canada’s Higher Education group was tasked to work with the CEE researchers to convert a series of Leaflet maps to the ArcGIS system and to improve the user interface (UI) and user experience (UX) when interacting with the energy maps.

Types of Framework-to-Framework Conversions

Before we discuss the details of the CEE conversion process and results, it is important for a developer who is considering converting between frameworks to be aware of the specific conversion process and how much technical overhead it will require. Think of it as a nation that is considering converting its electric power generation. As an activist or legislator, you would ask questions about the proposed alternatives including “What are the changes that need to be made?”, “Why do we need to make the changes?”, and “How costly will this be?.” The type and extent of the changes that are needed to the existing system will determine the cost and time required to implement them.

The same concept applies, on a smaller scale, for a developer converting apps, except in this case there are four possible types of conversions.

1. Out-of-the-Box to Out-of-the-Box

Out-of-the-box tools are those that require little to no coding to develop the web application. Typically, these allow you to drag-and-drop widgets and layout elements and change templates on the fly. Their purpose is to significantly reduce the amount of technical work required to develop and maintain an app.

An example of this form of conversion is taking a web application from, for example, ArcGIS Web AppBuilder and converting it to the more recent ArcGIS Experience Builder or switching a templated application from Tableau to ArcGIS Insights. The difficulty level for this type of conversion is low, relatively speaking, as it does not require any coding knowledge but simply requires knowing how to navigate through two different out-of-the-box frameworks.  

2. Custom to Out-of-the-Box

Unlike out-of-the-box tools, custom tools are those where coding is required to develop the web application. A developer may create a custom web application because they prefer it over an out-of-the-box solution, it’s a low or no cost option, the application requires custom functions that are not available with out-of-the-box tools, or a combination of these factors.

An example of this conversion would be converting an application built with the Open Source combination of Leaflet JS (frontend function) + CartoDB (backend function) to an ArcGIS Online templated app that handles both the frontend and backend functions. The difficulty level for this type of conversion is low to moderate, contingent on identifying the equivalents to custom functions that are available in out-of-the-box tools. This conversion occasionally needs to use more than one out-of-the-box tool to provide all of the functionality in the custom app, which will need to be carefully merged together to fulfill the requirements.   

3. Out-of-the-Box to Custom

A developer typically would make this type of conversion only if the current out-of-the-box tools cannot provide the additional functionality that is needed for the application. An example would be converting the template-based ArcGIS Dashboards to the ArcGIS API for JavaScript (JSAPI) and adding third party APIs to conduct extensive querying and to display more advanced visualizations (e.g., using D3.js to display knowledge graphs). The difficulty level can be rated as high as it requires converting the current out-of-the-box tool functionality to custom code plus adding new functions.

4. Custom to Custom

A developer might make this switch if the functionalities in the new framework are more robust and versatile than the original. An example would be converting a web application from Leaflet JS to the ArcGIS JSAPI. The difficulty level is high, and this could possibly be the most difficult type of conversion as the developer needs to know both of the custom code frameworks (original and new) to proceed with the conversion.

In the next section, we will discuss the conversion of the CEE app, highlighting several limitations of the original CEE maps and outlining the steps followed to convert them using the 2^nd conversion type mentioned above, custom to out-of-the-box.

Limitations of CEE Maps

This section highlights areas where the researchers and developers made changes to improve it’s the UI and UX of the original app. Starting with the UX, CEE’s maps landing page consists of two separate maps – one on energy demand and the other on energy supply. The user is required to select one map to view at a time and then to go back to the landing page to select and view the other map. This was a legacy of the original app development process, where the supply map was developed before the demand map, and used an older development framework. One improvement to the UX would be to have both maps in the same app. 

Caption: The original CEE energy demand map displaying energy use intensity (EUI) in Vancouver.

The original CEE energy supply map displaying the solar potential by block and cloudy days contours for the Vancouver area.
 

Another UX improvement to the web maps concerns interactivity. While both maps are easy to use, the interactivity in the energy demand map is limited to changing the variable being displayed (EUI, GHG, or GHGi) and clicking a location to see the values for that location. The energy supply map allows the user to select which layers to display and shows statistics or indicators for the layers when the user hovers over or selects a feature on the map. However, clicking on the map will show the energy demand statistics for the municipality, which could be  confusing for users interested in energy supply.

Additionally, neither map has statistics nor indicators that are specifically limited to the features that are within the current map extent. This functionality has become popular in Web GIS as it can show responsive spatio-temporal variations interactively for the current area of interest by zooming or panning the map. As for the UI, the maps have a simple look, however, their aesthetics may seem outdated, especially considering their purpose is to increase awareness about an important and timely topic. To increase awareness, the application has to attract attention by being visually appealing.
 

Converting the CEE Maps to ArcGIS

When the Higher Education group started working on improving the CEE maps, we first tackled the easiest changes by solving the back-and-forth UX dilemma of having two separate maps. We improved this part of the UX by using the Story Map Series template in Esri Story Maps (also known as Classic Story Maps). The tabbed layout in the Map Series template allows a user to switch between different maps from the list of tabs in one click, thus, making it feel like the web application is better organized. The first tab in the new app, labelled Energy Demand, is where the data for energy use intensity, greenhouse gas emissions, and greenhouse gas emissions intensity can be found. The other tab, labelled Energy Supply, is where the data regarding energy produced through hydroelectric, industrial heat recovery, solar, biomass, and wind can be found.
 

Data Conversion

Our second step was to convert the CEE’s GeoJSON data into hosted feature layers and tiled layers. The map in the Energy Demand tab has both hosted feature layers and tiled layers as the data contain hundreds of thousands of building features. Tiled layers are needed when there are such a large number of features to render the visualization quickly on the map; however, tiled layers do not contain attribute information.

In this situation, how can a user view attribute information while also rendering the visualization smoothly? A work around to this UX and UI problem is to set the tiled layers’ visibility range from a scale of the whole country (1:2,300,000) to the scale of a single street (1:10,000), and set the visibility for the hosted feature layer to below the selected street scale (< 1:10,000). Remember, this web application is intended for residents and communities. Thus, there is no need to view a building feature’s attributes at the county or city level. The data conversion and publishing process were done in ArcGIS Pro and the published layers with their respective settings were added to a web map via Map Viewer Classic.
 

Building the Web Apps

For the energy demand map, we wanted to have a dashboard-style app with gauge statistics and out-of-the-box widgets to increase user interactivity with the map. Fortunately, the WebApp Builder has a variety of themes (including the dashboard) and widgets, with customizable styles and different layout options for UI elements. We selected the dashboard theme, added the web map with the energy demand layers, and added three infographic widgets with gauges whose needles change according to user selection and map extent. The configured Web AppBuilder app was then inserted as an iframe in the Energy Demand tab in the Map Series story map (see figure below).

The new CEE energy demand map displaying energy use intensity (EUI) in Vancouver.

We wanted to have a similar theme for the energy supply map, except with more information. Each type of renewable energy needed its own statistics displayed, and we wanted users to be able to select multiple features while a layer is enabled and see, for example, the total potential solar energy for their area selection. Fortunately, these components can be added in ArcGIS Dashboards with little to no custom styling required. First, we added the solar, industrial, hydroelectric, biomass, and wind hosted feature layers to a map in the Map Viewer Classic (figure below).

Map Viewer Classic containing the energy supply layers.

Next, we created a new ArcGIS Dashboard and added the map. We configured the settings for the map in the dashboard to enable pop-ups, filtered features for all the hosted feature layers by map extent, and applied layer actions (selection) on the wind and solar layers. We then added side panels to display instructions on how to use the app and the legend for the selected layer, and five indicators along the bottom of the map that display the summary statistics for each type of renewable energy either based on selection (solar and wind only) (figure below) or based on the map extent (2nd figure below).

Configuration settings of map extent in ArcGIS Dashboards.

Configuration settings of selection changes in ArcGIS Dashboards.

Finally, we added the Dashboard app as an iframe in the Energy Supply tab (figure below) in the Map Series. 

Creating a web application (custom or not) is an iterative process, with small (or sometimes large) changes made and tested until an effective UX and UI has been achieved. Since a user’s experience is subjective, there are no standard guidelines nor grading systems for the UX and UI design, other than if a user can navigate successfully through the app with little to no assistance from the developer. For this project, there were at least 4 major changes to the UX and UI with some minor adjustments in between until the CEE team was satisfied with the final design.

The new CEE energy supply map displaying the solar potential per census tract.

After reading this post, you should have a good feel for the types of conversion processes between different frameworks in web development and an idea of which tools in the ArcGIS system were used to recreate the CEE web maps. While the ArcGIS web app tools described above are elegant and powerful, there is one important UX/UI component that was not discussed. Recall that the energy demand map needed both tile and hosted feature layers to display the building features at the city and county scales and to provide attribute information at the street scale. You can organize the tile and hosted feature layers as a group by type of energy demand (e.g., one group for greenhouse gas emissions). However, in the current out-of-the-box tools the user would still have to manually enable the tile layer to view it at its set visibility range and then manually turn on the hosted feature layer whenever they are viewing the map within this visibility range. With that, if the user disables only the tile layer and zooms out, the map will go blank (or vice versa if the user zooms in). Furthermore, if you want to view a different type of energy demand you need to manually turn the current layers off and turn a different set of layers on for the desired type of energy demand (e.g., turn the layers for greenhouse gas emissions off and turn the layers for energy use intensity on). This manipulation diminishes the effectiveness of the UX and UI use and there is no functionality in the out-of-the-box tools that can group the hosted feature and tile layers and enable them both in one click, while also allowing the user to switch between layer groups. Fortunately, a routine is available that can provide this functionality without having to rebuild the app through custom code.

In Part 2 of this two-part blog post series, my colleague Jonathan Van Dusen will describe in-depth how to make this group layer with switching functionality. 

This post was translated to French and can be viewed here.