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 II, Part III, Part V.  On February 27th, I will be joining James Fee for an online conversation about this series at SpatiallyAdjusted.com.

This being the season of penitence, let’s start with a confession.  A few years back I had just finished prototyping my first geoprocessing web service and wanted to get some early feedback from likely users.  So I approached a colleague with a PhD in Geology and, more importantly, significantly more zeroes in his bank account than you or I.  I reproduce our conversation in its entirety:

HIM: [knitted brow, looking at my interface] What do you have going on here?

ME: [swelling with geodeveloper pride] On-the-fly buffering and intersecting tools!

HIM:  What’s a buffer?

ME:  [Exit stage left, muttering under breath]

The rest of that morning was filled with hard staring out the window pondering the vast gulf between what I thought was cool and useful and what an intelligent would-be user found confusing and, therefore, irrelevant.

 

As we have learned from the City of Denver’s map usage statistics, the primary use of maps is quick information retrieval, NOT deep interaction with map interfaces.  So toolbars filled with unfamiliar icons are not helpful.  And toolbars with icons plus text descriptions are only marginally more so, because after all, “what’s a buffer?”

Users Do Interact With Hyperlinks, Info Balloons, and Hyperlinks Inside Info Balloons

As a core component of the visual grammar of the web, the text hyperlink is familiar to users.  Further, due to the Google influence, people are familiar with clickable placemarks.  And the Denver stats bear this out:  over two placemarks are clicked per visit, and 12% of the time users click on hyperlinks inside info balloons.  With this insight, you want to drive engagement with your map users right at the very start using a) a large, obvious auto-complete text entry box, b) placemarks that encourage interaction (e.g. zoom-to neighborhoods), and c) text-lists with hyperlinks.  

Making users launch a “tool” or type into a non-responsive text box as a pre-requisite for map interaction is a recipe for rapid disengagement.

Ditch the “Identify” Tool

One of the main goals of any interactive map is to provide detailed information about features on the map.  In traditional GIS desktop software, this is done using an “Identify” tool: click the tool, click on a feature on a map, and somewhere on the screen some attribute information will pop up.  On a web map, the Identify tool is unfamiliar, time-consuming, and makes the critically wrong assumption that a user is interested in all of a map’s features equally. Once you elicit user intent–an address, a neighborhood, etc.–put clickable placemarks in that location and related locations around it.  And use text lists of potential locations of interest: users can scan text much, much quicker than clicking placemarks. Again, there’s plenty to learn from Google Maps and Bing Maps and how they do map-based search for “pizza”, “coffee”, et al: a visual hierarchy of placemarks and a list dynamically refreshed as the user moves around the map.

UTF Grids, FTW

The greatest recent improvement in map interactivity has been the work Mapbox has done with UTFGrid (interactive demo here). Short version: each map tile has a compressed file of attribute info registered to its pixel space.  As tiles get loaded into the interface, the attribute info is readily accessible just by the user mousing over or clicking on any location on the map.  Ingenious!  If your vendor doesn’t support UTFGrid (it’s an open specification), call your sales rep today and say your 1990s Identify tool has to go.

The Toolbar:  the Wrong Tools for the Wrong Job

Icon-laden toolbars are a desktop thing, not a web thing.  For web maps anything besides rapid search-and-retrieval of information is an edge case.  And every second a user spends trying to decode your buttons and what they might do merely strengthens the resolve to leave your site.

 

—Brian Timoney

 

Addendum: Brian Flood noted on Twitter that Google has been using tiles + JSON to improve interactivity for a few years now (see example tile and JSON packet [text file download] ). Of course, no less credit to Mapbox for documenting and opening this approach.

 

 

 

 

 

 

 

“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 II, Part IV, Part V.  On February 27th, I will be joining James Fee for an online conversation about this series at SpatiallyAdjusted.com.

Every IT project needs requirements, right?  And “gathering” them sounds so collaborative, so collegial, and so relentlessly unobjectionable, what could possibly go wrong?

Besides your map portal project coming in late, over budget, and largely unusable? Nothing.  Nothing at all.

Because if you are building any public-facing interface you have exactly four requirements:

FAST  •  INTUITIVE  •  INFORMATIVE  •  FAST

Be clear on this single fact:  you are competing for User Attention.  On the Internet.  You don’t get to set the rules.

But look on the bright side:  you don’t have to write up Help documentation because normal people don’t read Help documentation. If they can’t figure out what to do—quickly—they simply you leave your site.  The web is full of other interesting content that doesn’t need to be puzzled over.

The Vicious Cycle of Bloat

Buying into the feature-laden, layers-upon-layers map portal paradigm quickly kicks off a vicious Cycle of Bloat.  First, the portal gets a full menu of default features intended to serve both internal users as well as the general public.  As layers and tools get added, it becomes necessary to hire a consultant/developer.  OK, now our map portal is officially a Project.  With your hired gun and extra coding fu at your disposal, adding a few more in-house edge cases doesn’t seem like a big deal (after all, you’re getting more value from your outside resource).  And its Middle Management 101 to reach out to other departments to bring them on board if only to be able to spread the reputational blame around should things not work out as planned.

Too Many Engineers Spoil the UX

Playing a critical role in the Cycle of Bloat is our Engineering brethren.  Specifically the subset of engineers who generously broadcast their technical criticisms with a cross-armed petulance gloriously liberated from ordinary self-awareness.  That guy (yes, it’s always a guy), has his own laundry list of features—in-browser feature editing tools, map-composing options, and of course “print-to-plotter” are perennial favorites—without which he’ll unilaterally and loudly declare the whole thing a waste of money.  All because of the obscure need for the map portal to do exactly what the $23,000 of technical software installed on his workstation already does.

The Power of No

The journey to clean, simple map interfaces geared towards the general public doesn’t start with a first step.  It starts with a simple word.

No.

Saying “no” to the premise of a single map portal serving both internal users and the general public is the prerequisite to building anything that will meet the four non-negotiable criteria stated above.  As someone famous once said, you can’t serve two masters—and neither can your map portal.  Stop trying to build the mythical interface that’s all things to all people and you might just be able to pull off something that is worth the valuable time of your general users.

 

—Brian Timoney

 

 

 

 

“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’