The ArcGIS system provides a variety of Web app templates and builders that allow you to create your own mapping apps without writing any code, including ArcGIS Instant Apps, Dashboards, Web AppBuilder, and Experience Builder. Each of these offers different types of functionality that you can include in your apps, and they also allow you to build types of app interfaces and layouts. But how do you know what sort of interface or layout you need for your app in the first place, and how does this affect which app builder or template you choose?
“Everything is best for something and worst for something else. The trick is knowing what is what, for what, when, for whom, where, and most importantly, why.”
–Bill Buxton, Microsoft Research (source)
At our upcoming 2023 GIS in Education and Research Conference, we will be offering a workshop on user-interface design using ArcGIS Experience Builder. Experience Builder is a relatively new web app development option from Esri, and it occupies a unique place in the ArcGIS system. It allows you to design a Web app using pre-built templates and layouts, similarly to ArcGIS Web AppBuilder, but it also allows you to design a custom app layout without writing any code by dragging and dropping interface components into the app. While the custom layout option provides you with more flexibility when building an app, it means that you need to think about where each element of the app should be placed and how users will interact with them.
This blog post is the first in a series. In this post, we’ll look at some user-experience (UX) and user-interface (UI) design principles for mapping apps. Later in the series, we’ll consider how these principles match up to the different web app builders and templates available from Esri, including ArcGIS Instant Apps, ArcGIS Dashboards, ArcGIS Web AppBuilder, and ArcGIS Experience Builder.
If you’re unfamiliar with these app builders, Esri has some good introductory resources that explain the differences between them:
- App Builders landing page at Esri.com
- How to Choose the Right Web App in ArcGIS Online, ArcNews, Fall 2021 (this presents some great guiding questions and a detailed overview of each app builder)
What sort of app interface do you need?
Each of the app builders listed above has a different focus in terms of the functionality they offer, the types of apps you can build, and the amount of design flexibility they provide. With that in mind, how do you choose between the app builders based on the type of interface you need? And how do you choose between the different layout options available within each app builder?
To answer this question, we need to step back and consider some common design patterns and principles for mapping apps. An invaluable resource for this is a website called Map UI Patterns, created by Michael Gaigg, the UI/UX lead for Esri’s Professional Services group. Chapter 2 on Gaigg’s website is on selecting the right layout, and lists five design patterns:
Wireframe of an example Full Map application
- Full Map: the web map takes up almost all the space within the app window. This can be useful when the map itself is the focus of everything the user needs to do – e.g., exploring the map data and opening popups – or if the app contains a set of tools that the user will need to use in a non-linear, open-ended way (Gaigg uses the example of advanced GIS users doing complex spatial analysis).
Wireframe of an example Partial Map application
- Partial Map: the web map is presented alongside a panel that provides tools, information, or context to the user. This is useful when the app focuses on a particular workflow, where tools need to be easily available to the user in one place, without covering the map and without making the user hunt around the app’s interface for everything they need. For audiences that read from left to right, the panel tends to be placed on the left side of the app window.
Wireframe of an example Reference Map application
- Reference Map and Embedded Map: the web map is part of a larger web page and supports other content instead of being the focus. An example of this is a small web map embedded into a dashboard or a story map.
- No Map: there’s no map visible on-screen, but for our purposes there’s still a connection to a GIS in the background (e.g., to query data or to display graphs or statistics).
Many app builders and templates are set up to create “Full Map” apps by default, but you should consider carefully whether this design pattern is the best choice for your app, based on the criteria above. For example, if you need to build a task-oriented app, where users are “funneled into a clear workflow”, Gaigg notes that a “Partial Map” design pattern is often ideal.
Guiding questions for app layouts
Some other questions you’ll want to think about as you consider how to lay out the app’s interface:
- Should any widgets be visible by default when the app is opened? This could include a map-legend widget, a frequently used tool (see the next point), or a text widget with some instructions or background information for the app.
- Should some widgets always be visible? This is useful if your app has a single, clearly defined purpose, where a certain tool might be a core part of the workflow. Depending on the app, this could be for filtering the data, calculating routes, or even just turning layers on and off.
- Will more than one widget need to be visible at a time? Think about your users’ workflows and how much they will need to switch between widgets to accomplish a certain task (e.g., if the user will need to copy data between widgets or refer to them simultaneously).
- Where should the widgets be positioned in relation to each other? If your users will need to switch between widgets frequently to accomplish a certain task, it’s helpful if they don’t need to jump all over the app for this. Fitts’ Law states that the closer (and larger) something is, the faster it is to click.
- Should the widgets appear over top of the map or beside it? For some workflows (e.g., filtering or editing the map data), you might not want to cover the map with a widget’s window, and instead display the widget alongside the map.
- How much functionality do you actually need to include, based on your users’ needs? As usability guru Jakob Nielsen notes in one of his classic design heuristics, everything you add to an interface will compete with everything else for the user’s attention. Michael Gaigg gives the example of a “kitchen sink” app, where too many widgets have been included and it becomes difficult for the user to find the functionality they need.
I recommend sketching out the app on paper first, to come up with some wide-ranging ideas for how to design the app and lay out its functionality (see the video on UI prototyping and testing on our Esri Canada Higher Education Resource Finder). Afterwards, you can narrow your designs down to the most suitable one, test it with users, and look for an app builder or template that lets you get as close to this as you can. It’s usually worthwhile to put in a bit more time to think through and optimize the design first, in order to save your users time and frustration later on.
In this blog post, we looked at design patterns for the user interfaces of web mapping apps and also considered several questions that help you consider how to design the interface. Later in this series, we’ll connect these principles to Esri’s app builders and templates and think about how to apply the principles. We’ll look more specifically at ArcGIS Instant Apps, ArcGIS Dashboards, ArcGIS Web AppBuilder, and ArcGIS Experience Builder. We will also discuss how to choose between these app builders in terms of the type of UI you want to build, and how you can use each of them to implement the different design patterns discussed in this post.
In the meantime, if you’d like to learn more about UI design for mapping apps, please check out the User-Interface Design learning path on our Higher Education Resource Finder. This learning path currently consists of two videos, and we will be adding more resources to it this year.
Until then, happy designing!