As I write this post, I'm attending the GeoWeb 2009 Conference in Vancouver, BC.  This is then a pretty appropriate time to drop part 3 in the Usability and the GeoWeb series.  Part 1 in the series discussed the importance of hiding unnecessary complexity from the user, while Part 2 focused on the importance of never leaving your users guessing and providing them with consistent, meaningful feedback.  In an effort to encourage the incorporation of key usability features into emerging web mapping applications, the lesson plan this time focuses on key application elements designed to protect the users from themselves. While that statement may sound a little rough (nobody should be out insulting their customers and clients after all) it is not meant as such.  I most certainly am not saying your users are foolish, stupid, or otherwise deficient in any way.  Recall Scott Karp's assertion that in the age of Google,

"...there are no stupid users, only inadequate designs"

On the contrary, I simply mean that otherwise well-meaning users frequently do things within an application that the application does not expect or that create coding/logic challenges for the developer.  Our task then in building next generation systems to support/integrate with the GeoWeb requires that we anticipate as many corner cases or unexpected results as possible, and architect and code solutions to prevent the user from becoming frustrated at best, and destroying critical information at worst.  Keep the user focused on the application, and put out fires before they arise With that intro, here's lesson 3...

Read the rest of this post »

This post is the second in a multi-part series on usability in web-mapping applications.  Dave has spoken extensively on this topic of late...and much of this is just putting fingers to keyboard on the issues we've been harping on for some months now.  The first post in the series asserted that we, as developers and architects of these systems have a tendency to make things too complex and flood the user with all manner of features, functions, and data layers they don't need.  In essence, the age of GIS in a browser is ending (I sincerely hope) and we're moving toward highly performant, intuitive, and focused applications in a browser that serve a particular purpose, and do it very well.  Why? Because someone else is bound to be offering the same stuff you are, and if they can provide the information faster, they win...bye, bye users and bye, bye clients. Part 1 discussed hiding unnecessary complexity from the user, while our lesson plan this time around uses extensive feedback mechanisms within a site to keep the user on our side and make them feel comfortable when visiting our site.  A confident user is a comfortable user. A comfortable user gets what they need and gets back out fishing, golfing, spending time with their kids, or otherwise doing something else besides staring blankly at your interface.

Read the rest of this post »

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.

Read the rest of this post »