Fall 2009
 |
 |
 |
 |
 |
 |
Fall 2009 |
||||||||
|
||||||||
|
||||||||
|
The Geospatial Web or GeoWeb is the current darling of location-based technologies and neogeography. As a community, geodevelopers are moving away from exposing lots of complex GIS functionality in the Web browser. The GeoWeb is high-performance maps, mashups, distributed data, game-style navigation, and communal- or user-generated geospatial content. In essence, it is all things Web 2.0 in a map. For Esri customers, it is REST, JavaScript, Flex, and Silverlight APIs for ArcGIS Server. Of late, Esri has been evangelizing on the topic of high-performance Web maps through online training offerings such as Authoring and Deploying Fast Web Maps and articles such as "Five Steps to Better Performance" in the Summer 2009 issue of ArcUser. 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. Geodevelopers are still challenged on the usability front because the typical application with buckets of data, loads of tools, and an unconstrained workflow is still making it into the market in many cases. Creating great apps for public-facing or line-of-business sites serving non-GIS professionals requires focusing on the user and a mental model of how the user interacts with the functionality that the geodeveloper exposes. These four lessons will help a geodeveloper do this. Lesson 1: Always Hide the Details A forester knows trees. A state trooper knows law enforcement. A county auditor knows real estate assessment. However, none of these users is likely to know much about buffer, intersect, or union operations or Thiessen polygons. When a roadway project manager asks for all structures near her project (without knowing it), she is really asking to locate point features in the Structures layer that fall within one mile of the section of Route 6A between mileposts 12 and 25. A GIS professional knows 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 and she shouldn't need to know this.
Consider the application shown in Figure 1. It serves data via the Web Map Service (WMS) capabilities of ArcGIS Server 9.2. Note the minimalist map navigation at the top left of the map and the conspicuous lack of multiple tool buttons, menus, legends, and layer lists. This application is used by state Department of Transportation roadway project managers. To do their job, all these folks need to do is specify what road segment a project is on and list structures along the road (culverts, mast arms) that are impacted by a project. Highly usable 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 in Figure 1. Once the project road segment is selected, this search button becomes enabled. A single click returns a list of affected structures to the user in approximately 0.3 second, allowing her to get back to what's really important. Lesson 2: Provide Your Users with Feedback Nothing presents a bigger usability hurdle than a mapping application that leaves the user wondering, Well this looks cool, but what do I do? This is the principal downfall of applications that try to shove GIS into a Web browser. Geodevelopers know exactly what to do with three different toolbars and four menus containing all manner of map navigation, query, buffer, and analysis tools. Line-of-business users and the public find open workflow applications with no guidance intimidating. The Web mapping industry at large must learn to develop applications that satisfy specific workflows and lead users through those workflows in the application with visual cues and feedback in the user interface. The roadway manager introduced in Lesson 1 uses the interface in Figure 2 to specify the begin and endpoints of a roadway project. First, note the simple information panels that appear in the right-hand column of the site. They explain how to use the features on the page. Second, accept that while a GIS professional knows that clicking a pencil icon will let them draw something on a map, a roadway manager does not necessarily connect these two actions. (Click the map to set the begin point.) For our roadway manager, clicking the pencil icon causes information to appear below the map telling her what to do next. It's as simple as showing or hiding a <div /> element in the page, and it is a critical usability feature that is often overlooked. Hold the user's hand and they will love you for it.
Lesson 3: Reassure the User When GIS professionals execute an attribute query or run an intersect operation, they typically understand that sometimes the resulting set is empty. Non-GIS users get very nervous when they perform an action and are presented with an empty user interface or are redirected to something they didn't expect. Did they delete something important? Is the request still processing? Did the site crash? What happened to the data? The importance of reassuring the user anytime something out of the ordinary happens cannot be overstated. Continuing with the roadway manager example, Figure 3 illustrates a case in which the roadway manager has selected a project with no location information. Rather than showing her an empty interface and having her worry about what has happened, the map interface is zoomed to the general area of the project (indicated by the text under Location Map). An information dialog box explains that there is no need to worry and provides instructions on how to remedy the missing data issue. There is no need for a complicated exception or null case scenario. A simple modal dialog box addresses the usability issue and keeps the user on the right track. Lesson 4: Protect Users from Themselves Despite a developer's best efforts, users can do strange and unexpected things with the systems. This is precisely why focused apps that support constrained workflows are critical. If a user continually finds it easy or convenient to circumvent application logic or generate bad data, this will impact the utility of the application and affect the willingness of a user or an organization to use the app. In Figure 4, the roadway manager is specifying the begin point of her roadway resurfacing project by clicking on a point along a road in the map. Note that she has clicked a point some distance from the affected roadway. The geodeveloper has a couple of viable options to address this issue. Code can be written with complex logic to apply scale-dependent buffers and tell the user that an invalid point has been clicked. She must then click again…and again…and again until she gets it right. The developer can take any user-specified point and simply snap it to the closest point on the affected roadway. From a usability perspective, the second option is clearly preferable. For the user, any mouse click becomes valid, eliminating the need for repetitive actions. The click operation is simply snapped to the roadway, and the begin point coordinate is displayed to the user in the appropriate text box. If the user is dissatisfied with the result, she can elect to do it again. However, in this scenario, the user is never forced to click over and over again because the input point does not pass muster with a bunch of buffer and intersect logic she should never have to know about in the first place. Validate user inputs as soon as possible, prevalidate whenever possible, and never let users do something they're going to regret later. But I Need a Full-Featured GIS
There are 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 colocated in a single data center while providing a desktop experience at remote locations. Having designed, architected, and developed several large implementations, the authors have seen how it can deliver powerful desktop GIS functionality across an enterprise very cost effectively. However, if your goal is to serve the public or users in a specific line of business, then you would do well to create focused applications that help users solve specific problems easily. This is exactly what GeoWeb-style applications do. The next generation of spatial applications, now arriving, are starting to leverage real GIS analytic capabilities behind the scenes. The tendency to mimic the indeterminate workflows of desktop GIS packages in a Web browser is inspired by noble goals. However, implementation, performance, and usability issues usually run rampant and completely overwhelm any cool factor. Instead, focus on solving specific business problems by building tools that are tailored to the actual end user. ConclusionSince Internet users now have a myriad of choices for information, geodevelopers should be designing highly usable systems that give users relevant information right now. If we don't, they'll simply go somewhere else. What does this mean for architects, developers, and project managers in the mapping industry? Usability trumps features. 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 users' questions with a minimum of friction and interaction. For more information, contact Brian Noyle, Senior Software Architect David Bouwman, CTO and Lead Software Architect About the AuthorsBrian Noyle Dave Bouwman |
