I’ve been very happy with the response to my World Freedom Atlas. But I’ve felt since early on that some of its coolest functionality may be hidden behind an overly minimal interface. And it desperately needs a help system.
Take the bivariate choropleth view and legend. This ability to compare two governance-related variables, for the same or different years, is one of the most powerful tools in the WFA. Bivariate choropleth maps (developed by the Census Bureau in the 1970s) use one visual variable to show two variables (see legend image below). They are often hard to read in a static environment, but are a powerful tool in interactive visualization because the user can use techniques like brushing and linked displays to get specific values from the map. Indeed, the bivariate view relates to my original vision for the atlas — to take a neutral yet critical view of these governance indices. For example, the shot below shows two freedom of the press indices (one from Freedom House, the other from Reporters Without Borders) from the same year. Though there is obvious correlation, there is also notable deviation.
So a lot of work went into implementing these maps and interactive legends into the WFA. Unfortunately, though, the default view upon entering the atlas is a univariate, and I’ve seen more than one person in blog comments bemoaning the inability of the Atlas to compare two variables. This is undoubtedly because I hide the bivariate option behind a very minimal set of interface controls (below).
Another powerful thematic ability of the atlas is the “change map”, a choropleth technique where color and shade are used to represent the change over a period of time, rather than static values. Unfortunately, I feel like the feature is likely underused.
Luckily, my audience includes highly motivated scholars, who will take the time to discover these techniques and learn my interface. The power of the internet, though, is reaching a huge, diverse audience. And if these divergent groups cannot find the tools I’ve built into my applications then they are largely useless.
When building the WFA, I concentrated mostly on functionality and implemented a Tufte-esque, Atlas der Schweiz-style interface. And the last thing I wanted to do was build a help system. But if I want more people to get more out of the World Freedom Atlas, that is exactly what I need to do.
6 Comments
Actually, I guess bivariate choropleth maps technically make use of two of Bertin’s visual variables: hue and value.
I think your problem is not necessarily “hidden” interface functionality, but poorly designed interface widget icons in terms of transparent usability. We all try to take a (data-ink maximized) page from Tufte as we make any cartographic product, but I would argue (and others have also done so - including Colin Ware and Steven Krug) that minimialistic design on interface widgets it not usually appropriate because it removes the affordances necessary for a user to connect function to form. Although the ‘bi’ symbol for the bivariate interface may not be an ideal example of this affordance-based critique on Tufte-inspired interface design, I bet if you had swapped ‘bi’ for the less clever and sleak ‘bivariate’ or even ‘compare two variables’ there would be a lot less complaint and a lot more comparison. A system of tool tips may also go a long way to remedy, as they act as on-demand affordances(although there are serious complaints against this approach to affordances as well, as users are forced to probe the entire workspace to get clues as to what they are supposed to be doing) - this may be in part what you meant as a help system.
In short, I think Tufte is an excellent design mantra for print, but has serious shortcomings when transitioning to trasparently useful and usable interfaces. I am not advocating the bludgeoning of users with ridiculously embellished lollypop interfaces, but I do think there is an opposite and equally fatal instance of usability failure caused by oversimplification.
P.S. Excellent map, but I have always thought your TA never got enough credit for the final product.
I agree with Robert. For further information, see the forthcoming Roth paper, or if you can, look up this conference presentation:
“Addressing Usability Issues of Web-based, Interactive Cartography: Learning from the Lakeshore Nature Preserve Interactive Map.” R. Roth, W. Cronon, M. Harrower, J. Przybylowski, A. Woodruff. Presented at 103th Annual Meeting of the Association of American Geographers, San Francisco, CA, April 17-22, 2007.
I agree, Rob, and really this is what I meant by the functions being hidden behind overly minimal interface controls. So thanks for fleshing that out a bit.
I’m also starting to take Steven Krug’s suggestions about using default/standard interface widgets rather than designing your own (see Don’t Make Me Think). I used to shy away from Flash’s built-in components, in favor of designing my own. And though I still think there is a place for that, I definitely dip into those components when designing a new interface.
Just to clarify a bit more on my (surprisingly non-drunken) ramble from last night, I feel that there is a very important difference between hidden and ambiguous interface controls. ‘Hidden’ to me means controls that are deeply nested into some sort of menu structure. Although there can be problems with this (particularly when designing for an end audience with a consistently low motivation), I think that this kind of cascading interface complexity (i.e., having a simple default view with only basic controls and hiding complex interface controls in nested menus that become available only on-demand) is appropriate for your map given the varying audience.
The question of ambiguity is something altogether different. While hiding parts of the interface is a way to tease out what functionality is immediately essential by a first time user (thus evaluating the interface holistically), the concept of ambiguity applies at the design scale of an individual control (feeding back into the discussion of affordances). You can tell from this discussion that it is my opinion that an interface control may be designed to be initially hidden, but never, under any circumstances, should the design be ambiguous. The ‘bi’ widget in WFA is both hidden and ambiguous - the usability problem, as I see it, is that it is ambiguous, not that it is hidden.
As one of my former coworkers was fond of saying: “if you think something is important enough to put on the map, make it obvious that it’s there” — be it differences between thematic data classes or GUI elements. Mean what you say and say what you mean. Tufte also says not to get caught in techno-babble speak in mixed audiences. I’d say “Compare two variables” instead of “bi”.