July 15, 2009
Ed. note: This article first appeared on Brian Noyle's blog and is reprinted here with permission.
Articles in this series:
Usability and the GeoWeb: Part 1 of ?
Usability and the GeoWeb Part 2: Provide Feedback
Usability and the GeoWeb Part 3: Protect Your Users From Themselves
Usability and the GeoWeb Part 4: Make it Fast
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?
 |
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 a 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
 |
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.
|
Your Comments Post a comment All comments provided in this section are those of the individual who has created the post. These are not the opinions of Directions Media, its editors, staff or owners unless otherwise noted. Directions Media retains the right to edit or delete any comments posted herein.
|
