Thursday, September 22, 2011

Point Clustering Usability Example

Intro: A number of times before (1, 2) I’ve discussed point clustering maps. I thought it would be useful to present an actual case study of a mobile app* that makes use of clustering to explain why I think the technique has problems from a usability point of view.  

Herd of Sheep Problem: Clustering maps have appeared as a solution to an old cartographic problem: If you have too many points on screen they overlap each other producing a map that looks like a herd of sheep has wandered over it (particularly if you use white markers as below).

Barclay's bike hire Stations map in Zoomed out view   

The Technique: The clustering solution involves sorting points into groups, each group then gets a maker (usually a circle) which is labelled with the number of points in the group.  This reduces the total number of markers rendered on screen.  As the user zooms in on an area big groups break up into smaller groups.  At a low altitude  the point icons themselves separate out from the groups.  

Boris Bike Example: My case study is the London Cycle App for the iPhone which shows in real time where Boris Bikes (aka 'Barclays Bikes') can be hired from.  Bikes can be picked up from a large number of docking stations and the app is very useful as bike stations often become empty as a typical day progresses.  The app needs to deal with the herd of sheep problem, the screenshot above is actually the bike stations it needs to visualise, it does this using group clustering.  We'll discuss the map's symbolization at high and medium zoom levels and compare that to the needs of an imaginary user who's using the app to find a bike to hire for a trip into town.

High Alitude Zoom:  At this viewpoint we see two cluster circles which show how many bikes are available for hire in two groups (repeated 3 times below).

High Altitude View with different possible group catchments.

The major usability issue here is that the catchment areas that the groups have been created from are not visible.  Any of the dotted catchment areas I've added in the three screenshots above are possible.  This is an issue for our user for two reasons:
  • Where are the bikes?  It isn't possible for our user to know precisely where the 230 and 178 bikes are so how can she know where to head to?
  • Density:  Knowing the total number of bikes in a group isn't as useful to her as knowing the density of bikes per square km.  For example, if the centre map catchments applied she'd be sensible to head for the 230 group SW of Islington but if the right hand map catchments apply the 178 group may well be a better bet as it has less bikes but in a much smaller area.
Overlap?  Not knowing the catchments of the cluster groups isn't a complete fail, its just unnecessarily vague. However, what is clearly a serious problem is the group circles overlapping.  That's plainly confusing for our imaginary user, it has no meaningful interpretation that I can think of.

Alternatives:  I think that both heat maps and grid density maps (below) are better solutions to the herd of sheep problem in this context as they communicate the data as density of bikes rather than total count.

Alternatives: heat map of house prices (bottom) Grid map of mobile web coverage (top) from this BBC site).  Boundary is of the whole bike scheme.

 (Note that I didn't have the time to create actual maps of the data we're discussing, these are maps of different data sets over London but they illustrate the techniques).  

High Zoom Best Alternative: No Data  My solution to the head of sheep problem is not heat or grid maps and is shown below:

its slightly counter intuitive but I've come to it by thinking about what the user actually needs.  She's probably getting into London by public transport and therefore knows the rough area that she wants to pick up a bike from.  My reasoning is that at this zoom level, the data is actually a visual distraction, what she really wants is to see landmarks so she can zoom in on her chosen area.  The bike availability is best kept off screen until she has zoomed in   You can see I've used three landmark layers above:
  • Boundary: A polygon showing the boundary of the area covered by the Boris bike scheme 
  • Big Train Stations: The location of a number of mainline train stations.  Not only are these well known landmarks in London but a large number of people wanting to pick up bikes will be arriving here (red pins).
  • Bike Stations: The location of the bike stations themselves (blue circles)*
Medium Zoom: As the user zooms in from the High Altitude Zoom view, the two big clusters resolve into smaller groups (below left).

Medium zoom screenshot (left) and suggested alternative (right) created by screen capture from excellent oobr's bike share map

With each further progression down the zoom levels the number of clusters, their size and their location changes.  This change of symbolization proved highly confusing to users.  My PhD student Craig did some user tests on a similar visualization, his observations show that users expected that the circles would persist across zoom levels - some even said they wanted to use them as landmarks and were very put out when they disappeared from the screen!  

Medium Zoom, Improved View (above, right):  At this zoom level, by reducing circle size, its actually possible to present circles representing all the bike stations with color coding showing where bikes are available (red = lots available, blue = few, circle size = number of docking points at each bike station).  Our user can probably locate a station to head for without having to zoom in further, a good usability gain plus she avoids the problems of changing symbolization outlined above.  The alternative map isn't optimized for an iPhone screen but I think you can see my point.

Conclusion:  My suggestions for improvements to the bike app screen shots at high and medium zoom levels involve not using a clustering technique at all. They could be combined as an complete alternative to the app; at high zoom levels the user sees just landmarks, when she zooms on her chosen area the map view switches to the medium zoom visualization illustrating bike availability. This alternative app would;

  • Avoid multiple confusing changes of symbolization with zoom (the most important advantage)
  • Avoid cluster circle overlaps
  • Avoid obscuring the view of the map by big cluster circles at high altitude zoom levels 
  • Show landmarks to aid effective zooming in
  • Show the user bike location data precisely - the user only sees bike availability at each station, there is no ambiguity created by grouping stations.  
  • Present the user with bike availability at the highest zoom level meaning she doesn't need to zoom in unnecessarily.  

I don't think this technique of avoiding point clustering completely would work in all situations but in the case of the Boris Bike app, I think it's the best solution.

Further Testing:  My PhD student Craig is going to be comparing the usability of alternatives such as the heat and grid map to the cluster circles in the future.  So far preliminary results show there are serious issues with point clusters but also that there are issues with the alternatives as well.

*I've got the boundary of the Boris Bike scheme and the station points wrong in some screenshots but I haven't corrected it because I'm short on time at the moment and it doesn't impact the discussion.

No comments:

Post a Comment