Usability and the GeoWeb Part 3: Protect Your Users From Themselves

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

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


Lesson 3: Protect Users from Themselves
So you've built your shiny new GeoWeb application, and you've done everything right...required field validators, dynamically enabling/disabling input fields to prevent spurious results, targeting distinct workflows to reduce errors introduced by open and undefined function execution, enabling/disabling map tools appropriately. You turn the users loose on your application and what happens? Defects start to roll in. Well, not really defects so much as comments of frustration and questions on "How do I make this work?". Turns out, the application needs more work: user's have been entering incorrectly formatted dates, and your click function to select a point on a route is nearly unusable. Explaining to a run-of-the-mill user that a point has no size and a line has no width so selecting a line feature exactly by point is difficult is a fool's errand. Prevalidation of inputs, and novel approaches to handling open-ended map interactions (like clicking a point to select a road) are required to prevent users from creating invalid data, removing critical data accidentally, or entering an endless loop of retries when interacting with spatial data.

Validate as Soon as Possible
Ever bought plane tickets from a certain large travel site? The basic workflow is that after the user has gone through the multiple screens to purchase tix, just as the purchase is about to go through, they get a validation message telling them they need to go back to page 2 because the middle initial field is required...or some other ridiculous message that should never occur. Even better, when the user returns to said page, the offending field may be highlighted, but data in the other 20 required fields was never cached and is now gone. How fun is that?

Our roadway manager from Lessons 1 and 2 has been such a good and enlightening sport on the subject of usability that we're going to leverage her experience again here. Consider the figure below.

(Click for larger image)

Our roadway project manager is updating a road segment to reflect the correct extent of her paving project. In this case, she's going to manually enter the beginning point (mile number) of her project on the highlighted segment. In this case, she indicates that her project starts at mile 90 on Route 40. Focus on the data entry text box is lost as she goes on to do other work and what happens next is shown below.

(Click for larger image)

Uh-oh! Let's look at what happened here. We have, in the browser, knowledge of the start and end mile markers for our PM's road segment so we can help her out a little. The system has done some quick validation and noted that 90 is less than the allowed minimum mile number for this road segment, shown a red 'X' which is almost universally understood to mean something has gone awry, and has displayed a message telling her what's wrong with the data. In addition, another important thing has taken place. We have reset the value in the input box to the original value. We have not destroyed or altered any data, nor have we asked our user to remember what the original value was. Much like the medical profession, we as developers must "first do no harm" to our client's data.

And when did all this good validation happen? Right now! We didn't let the user play with the structures grid at the bottom of the page, we didn't let her make any other changes only to warn her five minutes from now. We caught the issue early, provided her with a visual cue, preserved the data, and gave her a potential solution to her problem...all with a little JavaScript.

Validate as soon as you possibly can to maintain data integrity and reduce/eliminate user frustration with your app.

Prevalidate Whenever Possible
If validating early is good, prevalidating to avoid problems entirely is even better. So I know it's painful but we're going to leave the realm of the roadway project manager for a second in favor of world health issues. We've built, and continue to enhance, a system for a prominent world wide NPO to track H5N1 (bird flu) incidence around the world. The system is used by personnel in multiple countries around the world which presents some special issues surrounding data entry...for this specific example let's consider the entry of dates.

(Click for larger image)

While folks in the US are used to entering date information as MM/DD/YYYY or some variant thereof, other countries like DD/MM/YYYY or YYYY/MM/DD. Heck some countries (Nepal comes to mind) have entirely different calendars that map by mathematical formula to the Gregorian calendar we're all familiar with. While we could simply format date entries to UTC, etc. on the server side, this requires logic at the server to accept information on where in the world the user is entering their data, and complex client logic to turn that UTC into a date that is meaningful to the local user on the other end. No so fun to deal with. Why not just use an internationalized date picker? This is prevalidation at it's best, the date picker shows a calendar to the user, and when the user picks a date, it is formatted and transmitted in the appropriate format for the local users. The use of a simple JS widget completely eliminates any chance of an invalid date, or a correct date incorrectly formatted, from squeaking into the system and frustrating or confusing users. At the same time, the picker knows that a date entered in Europe needs to be formatted differently for a user in the US.

Short Circuit Open or Vague Inputs
So we're going to jump back to check in on our friendly roadway project manager for our last point in the lesson. She's back in our system setting the segments up for a roadway project and telling the system where her paving project is at. This time, she will be setting up her project road segments by clicking on the map. This is where things can get interesting because the user can click anywhere she wants.

(Click for larger image)

In the figure immediately above, the user has clicked, whether accidentally or intentionally, a point that is nowhere near the roadway she is working on. Now, we could try to write code to maximize the efficacy of buffering the point to intersect with the line based on map scale but things can get pretty complex when scale dependent buffers etc. are involved. A run of the mill user is going to get red faced quickly if we keep telling them to "try again you're not close enough". So why not do something like the result shown in the figure below?

(Click for larger image)

In response to a less than optimal map click for setting the end reference of a roadway project, we simply snap to the closest point on the selected segment. We've avoided coding complex scale dependent buffer/intersect logic that the user will never understand anyway, we've avoided the potential for an infinite click-retry loop for the user, and we still get a value that, while it may be incorrect from the user's perspective, is still a valid point on the segment. If she doesn't like it she can enter the mile marker by hand or simply click again. Low friction protection for the user and it short circuits a whole series of potential outcomes, all of which are bad.

Up Next...
Since I've yet to meet a client or user that says their system is too fast, our next usability topic(s) will deal with both real and perceived performance in your GeoWeb application and how to maximize each of these critical performance factors. Stay tuned...

Share