MapBrief™

“Why Map Portals Don’t Work” is a five-part exploration of why the dominant visual grammar of GIS interfaces serves its public audience so poorly and continues to diverge from the best practices found most everywhere else on the web. Read Part I, Part III, Part IV, Part V.  On February 27th, I will be joining James Fee for an online conversation about this series at SpatiallyAdjusted.com.

Who doesn’t like choice?

What consumer doesn’t want 11 flavors of Special K, the 200 tasty dishes the Cheesecake Factory serves up, or the all-you-can-eat bliss of Golden Corral?

No one.  Or at least no one I care to associate with.

Turns out there are some folks with PhDs (probably don’t go to Golden Corral) who have discovered that too many choices are psychologically debilitating and make people less happy (cue the TED talk).

So yeah, your map portal has too many layers, leaving your users psychologically debilitated and unhappy.

Like most of the usability problems of map portals, this default reflex can be traced to the web 1.0 legacy idea of GIS-in-a-browser where the ideal was importing as much of the visual grammar of desktop GIS interfaces as a browser could support.  Which worked fine…for those who worked with GIS interfaces on a daily basis.

Central to the GIS experience is the ability to determine relationships between different types of features–loaded in as “layers”–and being able to, say, calculate the number of properties within a flood plain. The more layers one has on hand, the more possibilities for exploring multivariate relationships, etc.

Turns out the general user doesn’t have a whole lot of use for exploring multivariate relationships. No, they are searching for a particular piece of information–their tax assessment (and their neighbor’s), the nearest rec center’s hours, a property’s zoning status, etc.

Problem: Multiple map layers make it difficult to elicit a user’s intent and vastly overestimate the public’s interest in figuring out how to manipulate the map display.

That’s why the City of Denver has found single-topic maps get more than 3x the usage of their portal.  And Pareto’s principle is very much in force:  80% of your users are interested in a small handful of use cases. So build your simple single-topic maps to address the most common use cases:  property lookup, parks, crime, polling places, et al.

But what of the 20% who do want to interact more deeply with more data?

If your organization is of the Open Data persuasion (and it should be), then you have it easy.  Because in 2013, engaged general users who are comfortable with map interfaces have Google Earth already downloaded.  Provide a simple KML link and send them on their way.

Now we’re down to the 3-5% of hardcore users who need shapefiles–let ‘em have shapefiles so they can happily go GIS-ing in ArcMap, QGIS, gvSIG, et al.

But let’s be clear: slapping all of your layers on a single interface to placate the most demanding 3-5% of your audience sabotages the user experience of the vast majority.

Or Build Your Own, Better Basemap

We are in the dawn of a New Golden Age of Cartography.  One of its hallmarks is that now we can create our own basemaps, or exert fine-grained control over 3rd party map tiles.  A great example of this fresh approach is the National Park Service’s “Park Tiles” project which manages to integrate 13 layers of information into a clean, intelligent basemap.

Cures for Layerrhea:  a) break out most important layers into single-topic maps; b) provide data downloads for power-users; c) roll your own basemap with supporting, contextual layers baked-in.

—Brian Timoney

**Image above courtesy of the BLM

Coming Soon: Stop ‘Gathering Requirements’