Using Map-Based Applications to Elevate Sales and Business Capacity [Video]

In this expert talk with Graphable Senior Consultant Sarah Evans, you’ll learn how to use map-based applications to elevate sales and operational efficiency. We’ll start out with the benefits of developing map-based applications. Then we’ll look at how to power the application and map both regions and points. Finally, we’ll explore how to use several Domo features and key interactions in map-based applications. 

Check out the full transcript below, and view the Domopalooza event video at Domo Palooza.

Video Transcript: Why Use Map-Based Applications?

First, why should we develop map-based applications to start out with? People generally gravitate toward them. They love maps for their design and colors. Often, a user can get much more information from a well-developed map than from a collection of similar cards or graphs. 

In our specific use case, our client was looking to optimize their employee resources when they were visiting their client’s scheduled training sessions. Geography and distance were important parts of their decision-making, but it wasn’t everything they were using to make their decisions. 

There were other factors our client had to consider in determining how to best make use of their employees’ time. Therefore, in our development, we had to make sure we brought in all relevant information. That way our client could make their business decision within the application without needing to use other tools or platforms.

The last reason I recommend developing map-based applications is because Domo maps makes it easy. Typically, in development, you need to handle security, user access, data, manipulation, resource deployment, filters and more. But with Domo, you have everything at your fingertips. Therefore during development, you’re able to easily focus on user interaction and features instead of provisioning development.

At Graphable, we do several full-stack application developments in our graph database practice. So we know that building easy-to-use, beautiful filters is not a trivial task. Luckily with Domo, they’ve already done that for us, which saves us valuable development time. 

Need help with editing and configuring your visualizations in Domo? Check out our post on the Domo Analyzer.

Choosing Map Libraries and Data Sets

In terms of maps, there are a number of map libraries available, such as Google maps, OpenStreetMap and Mapbox. We ended up going with Mapbox. It was ultimately the client’s decision because it’s easy to get started, create an account and get an access token. It’s also highly customizable and has geocoding functionality, which we’ll get to more in a minute.  

Mapbox has two portions. The first is Mapbox Studio, which is a portal for designing custom map styles and managing location data without needing to be a full developer. It’s has a nice user interactive portal. Then there’s Mapbox GL JS, which is a JavaScript library. With that, you’re able to customize your application and create interactive features for your end users.

The second part of powering the application involves the data sets. Here we’re using DOMOS, Magic ETL and SQL to transform our data. We’re able to have our development focused on querying the data and not having to transform filter aggregate so much. That makes the development portion much easier by having standard Domo data flow and the transformation done. 

How to Render Map-Based Applications

Here’s an example of what you need in your application to render the map and get started: 

• At the top, we have our Mapbox access token, which you’ll get when you create your account.
• Next, we have our map container with a first style. This is from Mapbox Studio. It’s one of their standard styles: s v11. You can also customize a style here. If you want to create one that’s unique, you’ll just get the URL and put it in. 
• Following that, you have the center. This is when the map first renders.
• Next, you have the zoom. It shows the level of zoom you’ll have when the map first renders.
• And lastly, we have a tile set, which is used to map regions as opposed to points. (Keep in mind, you don’t need to have a tile set, but we did in our use case.) 

Mapping by Regions With Tile Sets

Next, we’ll touch on mapping by regions. To map a region, you need a tile set. There are a number of tile sets within Mapbox Studio: standard ones like states, cities and countries, or you can create a custom tile set.

In our use case, the client also wanted to map public school districts. Luckily, the information we needed is publicly available. We were able to find it from a government site. However, one challenge we ran into is that it was only available in MBTiles format. So we had to upload it to a tool called Q GIS and put it through some terminal transformations to get the data in an appropriate geoJSON format.

From there, we uploaded it to our Mapbox Studio, which is what we see here in the screenshots. Those are our two custom tile sets. You can also see above that the URL and the last line of code we put in.

Plotting School Districts in Map-Based Applications

In this screenshot example, you can see how we mapped the school district regions. You can also see the popups we provided the users. If they clicked on a school district, they could see the account owner, the account name and their territory. Of course, you can provide a lot of other information as needed (if it’s available in the data set) so users have all the information they need in the application. 

Mapping Business Pipeline Capacity

Here’s an example of a more standard Mapbox tile set. This use case shows mapping by state because the client wanted to map pipeline capacity. We used a nice heat gradient for our client. As you mouse around over the map, the top left displays the actual value of the state. In this example, Mississippi has a capacity of 59. 

Next, we’ll talk about mapping by points. To map a point, all you need is latitude and longitude. If you don’t have that, you can use a Mapbox geocoding API. For that, we developed a script to automatically run the processes.

We first started in Domo with our client’s opportunities, bookings and clients. We created a specific data set with the opportunities or clients that did not yet have latitude, and latitude or an address. Our script was not able to pull that data set, send it to the API to geocode, return the latitude and latitude coordinates, and write those back into Domo on another data flow to store those for future use.

So we weren’t repeating our geocoding each time we stored them. That’s one way to use Domo built-in functionalities. You’re also able to do the transformations you need for other parts of the application, not just a latitude and longitude within Domo.

Then once the points are mapped, we need to make sure we enhance the functionality. Options include icons, colors, popups and geographical reference points. We want to include anything that will be critical in making business decisions for the specific use case.

The screenshot above shows the simple code you need if you just have latitude and longitude to map your points. And below is a screenshot of the application. We were mapping our points of employees and the school districts. As you can see, we used a lot of icons to indicate what type of session we’re looking at.

With this application, each one of those had a popup that gave the end user the information they needed, including the type of session, if an employee was already scheduled for it or if it was not assigned.

If the session hadn’t been assigned, they could click on a nearby employee and see if they were available and had the capacity to fill in for that session. Then they were able to have that employee go to multiple sessions at nearby schools to optimize his or her travel.

Multipurpose Map-Based Applications

Example 1: Mapping Employee Resources and Sales Opportunities

As I’ve hinted out throughout the talk, our client had two use cases. The scheduled sessions and employee resources were the main use case. However, sales was also interested in using the application. They wanted to map their sales territories and opportunities. 

To accommodate both use cases, they wanted to make a multipurpose application instead of having two separate map-based applications. However, they would need specific differences down to the detail that each user would want to see. 

You can see here at the bottom a screenshot of our web form. They were able to fill in their information and render the map. Each instance of the map-based application in Domo would has its own web form with its settings here so they could decide if they wanted to map a state or region layer. 

They could map by state (as we did in the pipeline capacity example we looked at earlier), sales territories or neither. They could then map up to three points or layers. For example, they could map opportunities, bookings and sessions if they wanted. 

We could also add in some customizations. For example, they may have wanted to map sessions by color according to the weekdays they were scheduled. In another map-based application deployment, they may want to see if it’s assigned or unassigned, or unassigned and needs a resource.

We were able to allow them to put that column here, then the application could render and color them correctly. This gave them the customization they needed without us developing a full settings app portion of the application. So we’re able to create multipurpose applications instead of needing to develop two per use case.

Example 2: Mapping Dunkin’ and University Locations

Let’s take a look at another map-based application. Here we have the application coming from New England. Of course, when I’m looking for Domo data, I naturally gravitate toward Dunkin’ Donuts locations. I was also looking for something else to map, and of course. In this case, I wanted to incorporate school information as that was one of the main portions of the original application.

First, we’ll look at how to use the web form. Here we’re looking at just Dunkin’ Donuts. You can see if we zoom around, these are all the Dunkin’ Donuts within the United States. We’ll then come over to our web form. As you can see, I didn’t have a region tile here, but we have Points Layer 1 and Points Layer 2.

Currently, we just have the Dunkin’ Donuts locations mapped. We can edit this and input our information. We can then come back to our application and refresh the page. Now we see that we have both our Dunkin’ Donuts and our schools, which are colleges and universities across the United States. 

Keep in mind, that process I just went through wouldn’t be typical for our users who typically work with map-based applications. Those settings in the web form would be set initially for the deployment of the application, and they typically wouldn’t be changed.

Next, like any Domo dashboard, we can use our filters up at the top. If I were determining where I wanted to go to college, I might be looking for a business school in New England. I know that if I stay at school in New England, there’s a very high chance I’ll have a Dunkin’ Donuts nearby. One feature of the application is a circle radius showing how, in this case, a Dunkin’ Donuts is within a 10-mile radius.

In the client’s use case, they chose a 50-mile radius as a reasonable distance for an employee to drive to a different school. And of course, you can customize that to your specific use case.

In this example, there’s no Dunkin’ available. So that rules out this school. These two other schools look like the best candidates. If I zoom in, I can see that both are close within our radius. As you can see from clicking on the icon, we see can learn information about that school, including the name and number of students currently attending. If I’m interested in attending a large school, that helps me rule out any small universities.

I can also consider the features available at nearby Dunkin’ Donuts. For example, I can click here and see it has a turbo oven, which is very important for a good breakfast sandwich. I can also see if they’re open 24 hours a day, which is important for a college or business school student. 

Optimizing User Experience

Next, we’ll talk through some things we learned throughout the development process. In terms of handling historical data, as you can see from the Domo, we often looked at a small range of data at once. But with our use case, the client wanted to load in all historical data from all sessions in case they’d ever want to look back in time. But at any given point, the user would often only look at a week of data within a very small portion of the application.

For that reason, handling large amounts of data, but being able to quickly zoom in to exactly what they needed was a requirement. We also had to prioritize what information should be in the popup and what information should live elsewhere. Use of screen space is always important because data paralysis is a real thing.

We had several working sessions with the end users to determine what information they needed to make critical business decisions and what’s needed in the application. Furthermore, we wanted to understand how the information should be presented (e.g., in a different tab or popup) and what information should stay in Salesforce. 

We also had to address calculating the right aggregation level for the popup. Of course, we did most of our data transformations within Domo within the ETLs. But for the popups, we needed to aggregate some data. We also wanted to focus on having as few queries as possible back to those Domo data sets at the right aggregation level. 

Next, in terms of handling interactions, clicks and hovering in a multipurpose application, there are different use cases for when you want to click and have different popups or mouse over something and highlight key information.

Being able to handle those wants from the user (e.g., having something happen when you move your mouse) without being overwhelming for the user was a priority. 

Lastly, we focused on keeping the legend flexible and generic. Presenting all the information in the application was critical so end users could make their business decisions right there. And of course, having a legend was highly important to help the user remember and understand what each icon or color represents. And as before, screen space was very important. So once the user started moving around in the application, the legend minimized to give them more screen space. We wanted to keep it as minimal as possible while displaying critical information.

I hope this walkthrough has been helpful and that you’ll have an opportunity to explore more map-based applications in the future. In the meantime, if you’re interested in exploring Graphable’s thriving, modern application development practice where we uniquely leverage graph database technologies such as Neo4j, contact us today.