The problem with web mapping UI design
I was reading James Fee’s blog post that the map bar has to go, and it did strike a cord that web mapping UI’s are largely broken. I do not profess to be a UI expert, particularly when it comes to web mapping, but I do hold some thoughts on the issues surrounding web mapping UI’s, many of which could be argued as unique to the geo world.
Content vs Context
I believe one of the largest problems facing developers of web mapping applications is that of content versus context. For the bulk of web pages, it is very easy to have a design that clearly segregates the two, yet still retains an easy transference of content to context and back again. Take for example a typical blog post or news story, the content attracts the users main focus, and as they read through, the context is displayed and accessible without interfering with the content flow:
We can see other examples of content vs context in youtube, where the content video is supplemented with context, but the two do not juxtapose.
Now if we take a look at a typical mapping application, we are having to deal with two problems; (1) how do you adequately display content and context so the two do not interfere which each other, and (2) which is which is a mapping application anyway!
If for now we assume that the map is the content (we’ll come back to that later…..) there are essentially two methods to display it’s data’s context; info windows or sidebars. With info windows, one would click on a marker or poly and contextual information about that feature will display
The problem with the info window is that it interferes and hides part of the map content, and the flows can be interrupted. My largest bug bear of info windows is they tend not to have any form of state – if you open an info window that contains a fair amount of text, start reading, decide to return to the map content when you get to a particular sentence or statement to look at the map data in more detail, when you reopen the info window to continue reading this contextual information it takes you right back to the start. The flows involved in browsing maps and consuming the info window based contextual information is clunky and painful.
With sidebars, it is similar in that a user clicks on a marker or poly, but this time the contextual information about that feature is displayed in a sidebar (I have also seen many examples of a bottombar rather than sidebar, which on widescreen monitors looks plain horrible).
Many developers create sidebars so that there is no interference or hiding of the map content, and so that users eyes can flip between the map and sidebar without having to worry about problems of info window state as described above, but it does bring problems of it’s own. Sidebars do exactly what they say on the tin, they sit to the side. This can mean that this contextual information can be far away from the feature you are interested in, breaking a smooth flow between content and context.
Out of info windows or sidebars though, I do prefer the sidebar approach as it offers less conflict.
Which is content and which is context anyway?
In the above mapping examples, we assumed the map to be the content. However, this is not always the case, and the many examples of poor web mapping UI’s are a result of developers struggling to come to terms with what is content and what is context. This is highlighted easily by taking a look at the consuming of georss feeds in Google Maps.
What we see here is a clear illustration of the problems defining content and context – is it the news story that is the content, and the location of the news story the context or is it the other way around? Clearly from a UI point of view, Google Maps is struggling to come to terms with this, as neither the map takes the main focus of content, or the news story takes the main focus with it’s small info window.
(As a quick aside, I am firmly of the belief that georss has not taken off as it could because there is no decent georss feed reader out there. Nobody has placed the text as content, with location displayed as context, it has always been the other way around with users presented with an array of markers to click. Imagine if Google Reader or net news wire were to support georss – the news story would remain the content, with a small map available to display the locational context.)
The problem of content or context can be seen in many examples, just take a look around at the web mapping applications you use and see if the developer has got it right. I would wager that for the most part, your flows as a user are interrupted and the user experience is negatively affected by an inability for the developer to easily define and represent the content and the context.
Moving from the desktop
Leaving content vs context now, lets take a look other problems with web mapping ui’s. Software as a Service, cloud computing, rich web applications (the list goes on) all seem to be the buzz at the moment. The claim is we will move from the desktop to the web, and applications like Google Docs or Office 2010 web version are an effort to replicate desktop apps in a web browser. Many web mapping applications are taking the same steer, trying to replicate ArcGIS Desktop or similar.
This brings problems of how to fit in or replicate the desktop ui.
As you can see in the image above, the web browser navigation functions and buttons are already taking up a large proportion of the screen, so the toolbar of extmap creates an application within an application. This results in the user being given tool overload, and decreasing space for the developer to work with for the mapping part (extmap is actually not too bad, with a slimline row of tools, there are plenty worse examples I could have used).
Most users are familiar with a desktop office application, recreating them is fairly easy and users can pick it up in a short period of time, there is no large learning curve (above tool overload issue aside). With web mapping applications however, you are trying to deal with two types of people, GIS users who are familiar and comfortable with desktop GIS products, and users who are not. Any web application that seeks to replicate ArcGIS Desktop (other products are available) straight away creates barriers for general consumers.
The desktop ui also brings about problems when you look at the pixel space you have to travel with your mouse to go up to and from the toolbar. Compare that against a traditional web page, where all the actions (clicking on links, highlighting text to copy etc) are within the sphere of your focus, with very little mouse movement.
The map bar that James refers to is an effort to remedy the above problems of the desktop ui, by maximising the space available for the actual map and by attempting to create toolbars and functions that are easier for general users and GIS professionals alike to learn. However, it is just that, an effort, and falls woefully short in a number of areas (i’ll not reprint what James has already said). I do not have a problem with the concept of a mapbar per se though, it is the ESRI implementation that is poor.
Guiding Principles
Asa Raskin at humanized has a number of guiding principles for UI design:
Simple things should stay simple.
Some tasks—for instance, teaching a child arithmetic—are intrinsically pretty complicated. But some aren’t. Setting the time on a wristwatch, for instance, shouldn’t be that hard; on old analog wristwatches, it basically involved pulling out a knob, twisting it until the watch showed the correct time, and pushing the knob back in again. But on newer digital wristwatches—ones that claim to be more powerful and feature-loaded than their analog counterparts—it involves pressing a series of buttons in a hard-to-remember, often unforgiving order. Most people dread setting the time on their digital watches, and for good reason.
It’s right and proper for complicated tasks to take time and expertise to accomplish. But something that is fundamentally simple—like changing the time on a wristwatch—should stay simple.
For the web mapping application, how many times have you had to go through countless clicks and dialog boxes to perform a common task, functionality buried behind complexity and inconsistency.
Fewer choices mean fewer worries.
People love having choices, because having choices means having freedom. Well, we don’t think this is necessarily a good thing when it comes to usability. We believe that when someone wants to do something on their computer, they want to spend their time doing it, not deciding how to do it. For instance, Microsoft Windows provides you with at least three different ways to launch applications and services on your computer: desktop icons, a quick-launch bar, and a Start Menu. Each one of these mechanisms is useful in one or two situations but horrible in others, and each has completely different instructions for operation. Microsoft even gives you a wealth of choices to configure them the way you want, which makes the situation that much more complex.
When we can, we try to avoid burdening our users with choices like this. We’d rather just take the time to make one simple mechanism that the user can use for all their purposes. The less burdened a user’s mind is with irrelevant decisions, the more clear their mind is to accomplish what they need to get done.
For the web mapping application, choices, choices and choices seems to be flavour of the month. A trip to a web mapping application will present you with a plethora of choice.
Your train of thought is sacred.
You can only really think about one thing at a time. If you’re thinking about paying your taxes, you can’t be thinking about your vacation in Tahiti. Indeed, thinking about that vacation in Tahiti will actively prevent you from thinking about your taxes. That’s why when you want to get something done, you want to get everything out of your head except the task at hand.
Quite simply, you need to preserve your train of thought. And that means that the interface you’re using can’t derail it. No talking paper clips bothering you from the sidelines, no fiddling with windows to find your work, no distractions.
Info windows, sidebars, options dialogs, navigation tools, x/y coordinates updating with every pan – the list of things in web maps that distract your train of thought can go on and on.
Good interfaces create good habits.
When you’re first learning how to use even the best of interfaces, preserving your train of thought can be hard because so much of your mind is focused on how to use the interface, rather than on what you need to do. But as you become more proficient at using a good interface, it eventually becomes second nature—it becomes a habit, like walking or breathing. You don’t need to think about what sequence of motions you need to perform an action because it’s like your hands have memorized them as a single continuous gesture, saving you the trouble of having to think about them.
Bad interfaces, on the other hand, prevent habits from forming—or they can make you form bad habits. Have you ever closed a window and hit “Do Not Save”, only to realize a split second too late that it was exactly what you didn’t want to do? That’s a bad habit developed from using a bad interface.
Good interfaces make forming good habits really easy, and they make forming bad habits nearly impossible.
This one is quite crucial I feel, nobody has really ‘cracked’ a good, reusable web mapping ui that is easily transferable across the many use cases, that allows for the formation of good habits.
Modes cause misery.
There exists a mortal enemy to your habits and your train of thought: it’s called a mode. If an interface has modes, then the same gesture that you’ve habituated performs completely different actions depending on which mode the system is in. For instance, take your Caps Lock key; have you ever accidentally pressed it unknowingly, only to find that everything you type LOOKS LIKE THIS?
When that happens, all that habituation you’ve built up about how to type on a keyboard gets subverted. It’s like your computer has suddenly turned into a completely different interface with a different set of behaviors. That derails your train of thought, because you’re suddenly confused about why your habits aren’t producing what you expect them to.
When you think about it, almost everything that frustrates us about interfaces is due to a mode. That’s why good interfaces have as few modes as possible.
I do occasionally come across modes with web maps, which I would describe as map as the start or map as the end. With map as the start, you are presented with a fairly basic map, zoomed out and you are expected to pan, zoom, add data and layers etc as you go to build up to the information you require. With map as the end, you might carry out a textual query and the map with all the information is presented as the search result. I do not have a problem with either approach, but it can be a problem if one website is trying to do both, as they tend not to either particularly well.
It’s easy to learn.
Good interfaces aren’t just effortless to use once you know them—they’re also easy to learn to use. This doesn’t necessarily mean that someone should be able to use it without any instruction—it just means that knowing how to use any feature of the interface involves learning and retaining as little information as possible. Keep it simple, and keep it consistent.
As previously mentioned in the desktop ui section, web mapping is currently suffering from a race to replicate desktop interfaces within a webpage. These are easy to learn for desktop GIS users, but not general users unfamiliar with GIS.
It’s not your fault.
The main thing you have to remember—and please remember this, because it could be vital to your sanity—is that any problems you have with an interface are not your fault. If you have trouble using your microwave, it’s not because you’re “not good with technology” — it’s because the people in charge of designing the interface for that microwave didn’t do their job right. User interface design is incredibly hard, and carries with it a great deal of responsibility; this is something that’s taken quite seriously when it comes to life-critical systems such as flight control software. But in today’s consumer culture, what should be blamed on bad interface design is instead blamed on the “incompetence” of users. Just remember that it’s not your fault.
Map services are a great leap forward. However, it is simply wrong to pass the buck using services. Just because the UI sucks, never should the availability of services be used to say ‘if you don’t like the ui, use these services with your own ui instead’. Services are not designed to remedy bad ui, so don’t push them for that purpose.
Wheres the good design then?
In summary, web mapping UI is generally poor because it is led by desktop GIS paradigms that pay little attention to detail over content, context, simplicity, and usability.
It is very easy for me to criticise, so in a follow up post I would hope to look at the other side of the story, highlighting good examples of web mapping UI.
