WHAT
The no map pattern does not use a map. It is used when the task doesn’t require a map but still uses the full power of geographic information systems (GIS) in other ways, such as through charts or a dashboard.
WHY
Of all the UI components, dynamic maps fall into the category of “difficult to use.” Not everyone can navigate multiscale, data-rich dynamic maps, let alone understand how to read and interpret the spatial content presented. It takes a lot of effort to design dynamic maps well, and thus most maps are far from perfect. Making maps accessible for people with physical or situational disabilities is a constant challenge, as well.
Factoring it all in, it is sometimes a better choice to not show a map but use the available screen real estate otherwise. Often the core value of an app lies in the structured output of the data and can be brought to the forefront in the form of a dashboard instead. This works well when the analysis and the geographic area are well known and don’t change. It is then possible to gather and analyze spatial information without the need to display it on, and interact with, a map.
WHEN
Use the no map pattern when displaying a map doesn’t add value or is distracting to the task. Location-based intelligence is common, valuable, and can often be represented without a map. Good examples are dashboards that report performance indicators or location services. No map is also recommended when the spatial analysis can be performed and presented more easily without difficult map interactions.
HOW
Design your app without taking up space on the screen for a map. Present the spatial information in an alternative form such as a dashboard with KPIs and charts. Remember that presenting the user with a mapless interface doesn’t prevent you from using a map elsewhere in the app. Create separate pages that host a map and provide navigation such as hyperlinks or tabs to access them.
EXAMPLE
The Bin Collection Canberra app is a demo app that shows how location analytics can be used without a map. The only input needed from the user is their location, which is provided by typing their address in the location finder or clicking the locate me button. The app uses that location information to run a query and report back when the next rubbish, recycling, and green waste pickup days are scheduled. These simple answers are what most users need — mission accomplished. Having a map would unnecessarily complicate the interface and provides little additional value to the app. Quite the opposite, map authors would have to solve new questions that arise: How should we visualize multiple trash truck routes across the city in a meaningful way? Should we aggregate the routes into polygons such as service areas? How do we deal with overlapping service areas? Ask yourself, what do your users really need, and resist the urge to add a map at all costs and just because you can.
MORE EXAMPLES
