Many apps contain maps or location-based intelligence, yet they can be very different. Have you ever thought about why they differ so greatly? These differences may be attributed to the many individual and creative ideas of the different designers and developers. But quite often the look and behavior of these apps are due to the developers and designers recognizing the specific goals of their users and adapting their app to meet those goals.
While this topic provides a detailed look at the main types of native, location-based apps (patterns), you also need to have a solid understanding of your users and what they need to achieve with the app.
The patterns can be categorized into two main groups: apps with maps and mapless apps. The latter group is by no means inferior. ArcGIS Runtime SDKs contain a large amount of functionality that can be leveraged with and without a map.
For details about choosing among the native, hybrid, and web patterns, see Native vs. web.
Maps can be added to an app for different reasons. It is the context in which the map is used that determines how it should appear and behave in the app, which, in turn, is determined by what your users need.
In map-centric apps, the map is the most important thing about the app. Usually the map opens first and is the focus of the app. Examples include the ArcGIS App and Collector for ArcGIS. The user gets value out of the app by interacting with the map; it's the map that provides the desired intelligence or information.
Many of these apps open only one map or allow the user to choose from a few maps that are important to them. Users interact with the same map for some time.
An example of this type of app is one that allows field workers to:
- View their organization's assets in relation to their current location.
- Determine the route and time it will take to get to the asset.
The value to the user is the map itself.
In these apps, it's imperative that users get to the map as quickly as possible every time they start the app. Re-opening the last map they were looking at is usually good practice. To do this, store information about the map (and its state, if desired) on disk so it can be retrieved when the app restarts.
Device form factor
The form factor of the device will also affect how the map is presented. Map-centric apps will take over the entire screen of devices such as tablets and phones, whether in portrait or landscape. However, on tablets in landscape mode or on desktops, there may be enough screen real estate to incorporate side panels that contain information about the map. Some apps restrict the screen orientation to ensure a good user experience. For example, an app may restrict phones to portrait because in landscape, the map is too small and getting to the tools too difficult. Consider carefully what the user needs to do and whether they get usability benefits from using the app in the different orientations.
If you do support multiple screen orientations and sizes, you should make sure that you optimize the design for each of those that you support. This may mean designing specific screen layouts for the different options. You may also have to consider what happens when a user turns the device from one orientation to another.
The cartography of the map is also important. Full cartography recommendations are outside the scope of this topic, but many resources are available to help you make maps like professional cartographers do, such as the Esri Mapping Center. In general, use appropriate symbols that make sense to the user without having to look at a legend. A legend should be the user’s last resort. Ensure layers are visible at appropriate scales. Using scale dependency settings not only provides the right information at the right time (scale), but it also can improve performance. Also ensure that colors of symbols and the commonly used basemap in your app work well together.
Be aware of the tools your apps expose. Your default tools should be the most commonly used, and they should be provided to the user in an appropriate way for the platform and form factor your app is running on. For tips on appropriate use of tools, see Provide mapping tools.
In maps-as-navigation apps, the map is important, but it's not the most important part of the app. The map in this case drives the navigation of the app and lets the user discover additional information and access other screens that provide value to the user. From the user's point of view, the map itself has little value in this app; it's a tool to get to the information they need.
The toolset associated with the map should be focused, as the user will not be performing many additional map functions unless it allows them to get to the target information more quickly or add some value to the information they receive. Often a drawing or selection tool is appropriate to allow users to quickly draw their area of interest as a graphic on the map. The resulting graphic is then used to query information (in the form of a QueryTask or query on a layer in the map). It's possible to query for information as the graphic is being drawn to provide instant feedback, although the performance considerations of this should be evaluated. The use of geoprocessing to retrieve data and provide information can also be used in this scenario.
Cartography is typically important, as the map should be simple and allow the user to select the areas or features that will display the information of interest without any distractions. Consider which basemap you should use in this scenario.
An example of this type of app is one that allows users to define areas on the map that show what properties are for sale, what school districts the properties are in, and what the average sales price is. The valuable content for the user is not the map, but the resulting information. However, without the map, the user is unable to get to the target information.
Pop-ups can be used to display information based on features in the map. These are UI components that are provided in the SDKs that allow you to build rich user experiences through map configuration rather than code.
In a map-as-context app, the map is an additional or auxiliary view in the app and is mainly used for contextual purposes. The map is created and shown based on some other source information also visible in the app. The map displays additional information, which the user can choose to consider. The map is typically auto-populated with the correct layers, layer filters (also called layer definitions), location, and zoom level specifically based on the source information.
In this case, map tools should be limited. In many cases, there should be no map tools, and the source information actually navigates or changes the map. This requires binding the map's behavior to other view controls or elements that hold the source information and can provide for an intuitive user experience, especially for those users who are not used to working with map interfaces.
Again, cartography is important for this scenario, as there should be few distractions on the map.
An example of this scenario is displaying a weather map for a specific location and time. The source information in this case is the location name, the time of day, and the weather forecast for that area (temperature, wind speed, humidity, and so on). Initially, the map shows additional weather information (cloud cover and rain radar for example) for the location and its surroundings at the time that is being displayed. If the user changes the time of day, the map updates to show the weather information for the new time. The information the user wants to know is the weather forecast (the source information); the map in this case is additional contextual information that adds value to the source information. A map can be useful in this scenario, for example, when the source data shows the location will have clear skies at 1:00 p.m., but the map shows a rain cloud nearby, at 2:00 p.m. the forecast is still sunny but the rain cloud is closer, the user now knows a rain cloud is heading in their direction.
Mapless apps that contain location-based intelligence are common and valuable, especially in devices that leverage GPS and motion sensors to provide information to users. In this pattern, the user should never know about GIS, spatial intelligence, or mapping, and you should choose your tool names and information screens carefully to hide these from the user.
Any spatial tasks that are run in these apps are run in the background and should not interrupt the user's flow. This typically requires asynchronous development for tasks to run on background threads (not on the UI thread).
Some of these mapless apps (as well as many mapping apps) may require local data to be on the device. To achieve this, you can use services, or you can provision the device with the data. For details on how to retrieve and access offline data (whether using a map or not), see Create an offline map.
ArcGIS Runtime SDKs have many functions, described in the following bullets, that can help you build a mapless app.
- Geometry engine allows you to:
- Measure distances—How far away is a location I'm interested in?
- Determine intersections/proximity of features and geometries—What county am I in? Does this road cross any rivers?
- Buffer locations to find other features—How many coffee shops are near me?
- Perform conversion from one coordinate system to another—Where am I on the map? You can convert lat/long coordinates from a GPS to a projected coordinate system.
- Geocoding allows you to:
- Find places—Where is Redlands, CA? Can you show me coffee shops near me?
- Reverse geocode—What's the address at this location?
- Routing allows you to show directions without a map—What are the driving directions to get from one location to another?