Maps Part 1: The Problem
Robert Scoble has an interesting interview with Chandu Thota about The Dealmap (recently bought by Google).
Although I completely take Thota’s point about APIs and 3rd parties, what strikes me is the apparently automatic assumption that using a map (and the now nearly ubiquitous Google API mashup) is the best way to show his data. It’s as if we are now locked into the idea that if we want to use information visualisation to discover things that exist in space, we must use a geographic map.
But there are clearly problems with this assumption. Firstly, using geographic maps to display things brings with it an amount of irrelevant data. What, for example, is the use of knowing that a school or a hospital exists near a shop offering 10% off a haircut? Does it matter that the road on which a crime has been reported runs north to south, or that there is a creek to the east of a hotel?
Of course, these things might well matter if you are going to use that map to find the barber, avoid the crime, or stay in the hotel. But almost all maps that show such data on the web are not presented in a manner that allows them to be easily used for that purpose. The tacit assumption is that you are to be left to your own devices (pun intended) to find those things in the real world. In fact it’s somewhat quaint that Thota is not putting his efforts into a mobile application straight away and ignoring the web for this reason. But I’m sure there are good reasons for that.
Another problem with maps is their rampant inefficiency. At one point in the video, Thota calls our attention to the throbbing mass of deals at the highest zoom level over the US. It looks like the entire country is plastered in them. In fact this is a design bug. The heat map belies the true density of deals because the markers that indicate them can only shrink to a minimum size before they just overlap each other. On most maps on most screens, such markers can only convey about 100 items before they just merge into “many” and you have no further clue about their true density over the territory. Yes, the use of colour helps, but not much.
A secondary effect of this “marker overlap” problem is that it reduces the utility of the geographic map. The more data you overlay on a map, the less useful the map becomes if you cannot see the name of a road or a landmark because it is obscured by marker pins.
In a related problem to this, the size of markers must be kept as small as possible so as to minimise the destruction of the visualisation. So they can only contain a tiny amount of information before you have to interact with them. In most cases, marker pins only convey one thing: the location of something, sometimes augmented with a type (a restaurant as opposed to a museum, for example).
The design of The Dealmap also demonstrates another weakness maps have. By defaulting to showing the whole world, you are forced to waste time orientating before you get to a comfortable zoom level around where you currently are. Unlike with the highly efficient “zooming interface” (ZUI) model, in the case of a map, the chances are you are somewhere on it – but the UI of The Dealmap assumes you have adequate geographical knowledge to find that position yourself. Of course, this might be another design bug – there are now geo-locating technologies that can be used to help this problem. But Thota isn’t using them.
So The Dealmap (in common with many other such mashups) shows you where a bunch of nearly anonymous things are relative to quite a lot of irrelevant data, through which you have to dig before you find anything of interest. Put that way, it’s a rather underwhelming proposition.
Might there might be a better method of allowing people to discover simple things that have a fixed position in space relative to your own? I think there is. And I shall call upon the great god Tufte by invoking his first principles: show the data and try to remove pixels.
Stand by for the next instalment in Maps Part 1: The Solution, where I manfully attempt to supply a better design!