MapBrief™

To celebrate the International Open Data Hackathon Day, I’d like to point out that tomorrow marks the 2nd Anniversary of the Department of the Interior’s Bureau of Land Management taking key portions of their GeoCommunicator website offline.  Behold the takedown notice.

 

I’ve blogged about 18 months ago, admittedly with the naive belief that it would get sorted out eventually.   With key datasets pertaining to Oil & Gas leases, mining claims, etc., an ordinary citizen might assume that the problems would be addressed with a modicum of urgency.

The Public Loses Access, But Someone Still Got Paid

But decreased access to BLM data hasn’t been a loss for everyone.  Premier Geospatial, the private sector entity that has the closest relationship with the BLM in the realm of Oil & Gas lease data, sold itself (under its parent entity Xedar) to the international data vendor IHS for…$28  million. A nice payday for someone.

 

Which Side Do You Bet On?

While the democratic idealism of open government information is pleasant to ponder, as a business person investing in products and applications built on top of open data you have to make a hard-headed assessment.  Namely, is a government entity’s commitment to the free flow information credible over the long-term?  Or is it ever vulnerable to changing political winds: a new White House administration, a new City Council, a different set of county commissioners?

In the case of the BLM, the smart money turned out to be on bureaucratic dysfunction and intransigence.

Whether the Open Data movement is currently gaining or losing momentum is great fodder for Internet argument. But folks risking their own dollars might well be waiting for the day when the “movement” is backed by real statutory muscle.  Absent a legal compliance structure with teeth, there’s little to protect open data from the worst instincts of those in the public sector who forget too quickly who pays their salaries.

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

What’s worth waiting for on the web?

Search Twitter for “Hulu ads” and see how much folks enjoy just sitting through a brief ad to get to high quality broadcast television content.

Then imagine what is going through your users’ minds while your map portal is loading.  Puzzlement?  Irritation? Or a sense of eager anticipation?

You know which it isn’t.

And why exactly, is all of that prolonged loading and plugin-requiring necessary?  To push content and functionality of little interest to the vast majority of users.  Because makers of map portals for the general public fundamentally misunderstand what users want.  They want rapid search-and-retrieval with their results contextualized on a map.  The map plays a supporting role–it’s not the lead actor.  So if you’re forcing your users to interact with toolbars and map navigation before they get their answer, you have your users’ priorities backwards.

 

Adobe, the makers of Flash and Flex, has (had?) a marketing pitch about using their products to author “immersive” web experiences.  And as hardworking geospatial professionals, who doesn’t want to author an immersive experience?  For users, however, immersion feels a whole lot like being lost and confused.  They want your site to work like the rest of the web where they might hit a dozen or more sites in quick succession—gleaning a fact here, an opinion there, and hopefully an OMG hilarious cat video somewhere else. And as we mentioned in a previous post, the 10-15% of your users craving an immersive map portal experience already have Google Earth: give them a KML link and send them on their way.

 

So let’s flip the script and instead of structuring our web mapping experience around an inappropriate desktop GIS idiom, let’s take the value of our users’ time as the guiding principle:

• How quickly can you deliver parcel/assessment info to a property owner?
• How quickly can a parent moving to your municipality find the nearest elementary school?
• How fast can you show an investor the ten most recent commercial property transactions in your city?

Previous posts in this series have detailed specific techniques for focusing user engagement based on actual map usage data.  But even without metrics, ask yourself the hardest question of all: would you visit your own map portal if there was a simpler, faster alternative? The 8th most trafficked website in the US is Craigslist.  It’s ugly, it’s crowded, it’s literally nothing but hyperlinks.  But millions everyday without training, without reading PDF Help documentation, find it useful.

Useful.

Dare to turn away from over a decade of misguided map portal habits and create something useful.

 

—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 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.