Usability and the GeoWeb: Part 1 of ?

Myself and my partner in crime, Dave Bouwman, have talked incessantly in trade publications and at conferences of late about the Geospatial Web or “GeoWeb” and what it means to GIS professionals and software developers.  This post is the first in a several part series on usability issues and concerns when designing and building applications for the GeoWeb.  How many parts will the series have?  Well that all depends upon how worked up I get and how often and long I want to rant.

It is my sincere hope that we, as a community, are finally moving on from the era of exposing buckets of complex GIS functionalities in the browser.  As noted in a previous post, the GeoWeb is, in essence, all things Web 2.0 writ large on a map. For ESRI customers it is REST, JavaScript, Flex, and Silverlight APIs for ArcGIS Server.  Beyond the ESRI realm it is Microsoft Bing Maps, Google Maps, Google Earth, or myriad FOSS offerings.

Since internet users now have a myriad of choices in where they go for information, we as professionals should be designing highly usable systems that give users relevant information…and give it to them right now. If we don’t, they’ll simply go somewhere else. What this means for all of us as architects, and developers, and project managers in the mapping industry, is that usability trumps features. Since our customers are foresters, real estate agents, state troopers, and roadway managers, not GIS professionals, we need to hide GIS complexity, provide determinate, task oriented interfaces, and answer the user’s question with a minimum of friction and interaction.

While quick performance and a killer site skin with an open, uncluttered layout are certainly important in the age of the GeoWeb, they are only part of the equation. Based on my unscientific observations, geodevelopers are still challenged on the usability front in that the typical application with buckets of data and loads of tools with an unconstrained workflow is still making it out the door and into the market in many cases. Creating great apps for public facing or line of business sites serving non-GIS professionals requires a lesson plan that focuses on the user and on the mental model of how the user interacts with functionality that the geodeveloper exposes.

But I need a full featured GIS in my browser

Oh no you don’t.  We at DTSAgile maintain that there are very few situations that actually call for a web-based GIS. When these web applications are built, they are so complex that only GIS professionals understand how to use them. Perversely, the performance and technical limitations of web development make these applications too limited to be useful for GIS professionals! Give GIS professionals access to professional GIS tools – desktop GIS applications. Citrix or Terminal Services technologies provide an excellent means to do this in a distributed environment. This allows all the GIS applications and data to be co-located in a single data-center, while still having a “desktop” experience at remote locations. Having designed, architected and developed several large implementations, we’ve seen how it can deliver powerful desktop GIS functionality across an enterprise very cost effectively.

If however your goal is to service the public or users in a specific line of business, then you would do well in creating focused applications which help a user solve a specific problem easily – which is exactly what GeoWeb style applications do. The next generation of spatial applications is now arriving on the scene and starting to leverage real GIS analytical capabilities behind the scenes. While the tendency to mimic the indeterminate workflows of desktop GIS packages in a browser has noble goals, implementation, performance, and usability issues usually run rampant and completely swamp any cool-factor. Instead, focus on solving specific business problems by building tools that are tailored to the actual end user.

With that introduction…here’s lesson 1.

Lesson 1: Stash complexity away

Foresters know trees, state troopers know law enforcement, the County Auditor knows real estate assessment, the public knows a whole variety of things, but likely none of these user groups knows specifically what a buffer, intersect, union, or thiessen polygon is. When a roadway project manager asks for all structures near her project, without knowing it she really means,

“Locate point features in the Structures layer that fall within 1 mile of the section of Route 6A between mile posts 12 and 25.”

A GIS professional would know that getting this information requires an initial point selection, followed by a buffer, an intersection with a second layer (roads), followed by a buffer of the resulting road segment, followed by an intersection of the second buffer with the structures layer. The roadway project manager does not know this, nor should she.  Furthermore, why in name of Pete would we give her 5 or 6 separate tools and ask her to figure out that process in the correct order?

Consider the application shown in the figure above.  For those keeping track, the app is an ASP.NET MVC implementation consuming data via the WMS capabilities of ArcGIS Server 9.2 within the OpenLayers client interface.

Fewer Layers

Note how few layers are in the map.  I’m sorry to say so, but if you think your users need or want to see all 150 layers in your Geodatabase, you are dead wrong.  Unless your application operates on or depends on that really detailed point layer of GPS’d mailbox locations for correct function, leave it at home and let’s keep it simple okay?

Consider using a base tile cache with some sexy cartography, and then roll in 3-5 operational layers that contain only the information that the user needs to accomplish their goal.  The example above contains roadways, separated into scale appropriate layers for display purposes, and counties to provide locational context.  To our roadway manager, everything else is noise in the system and doesn’t contribute substantially to her ability to do her job so it is left out.  Using fewer layers also has the side effect of dramatically increasing map rendering performance…which is topic for a separate post in this series dealing with real and perceived performance.

Hide the Details

Check out the minimalist map navigation at the top left of the map and the conspicuous lack of multiple tool buttons, menus, legends, layer lists, etc. in our example above. This application is used by State DOT roadway project managers and all these folks need to do their job is to:

• Specify what road segment a project is on
• List structures along the road (culverts, mast arms, etc.) impacted by a project

Highly useable systems hide complex GIS operations from the user and get the desired answer quickly. The selection, buffers, and intersections that get the roadway manager the information she needs to do her job are hidden inconspicuously behind the “Search for Structures” button highlighted below.

Once the project road segment is selected, this search button becomes enabled, and a single click returns a list of affected structures to the user in approximately 0.3 seconds in this application allowing her to get back to what’s really important…spending that stimulus check.

Future Zen

Keep checking back here for additional posts on usability, performance, etc. for building the next generation of web mapping applications.  Future posts will deal with feedback to the user, user reassurance, protecting users from negative outcomes in your app, real and perceived performance, and anything else I can think of that irks me when I look at some of the “Web GIS” sites I see rolling out onto the internet.