OpenStreetMap – Where’s the Search?
Roughly 70% of visitors who open an account do not go on to make a single edit to OpenStreetMap. Why do the majority of people interested in editing OSM fail to add data? Is the user experience not good enough? What are some specific issues that stop contributions? These are some of the questions that I, together with Dr Kate Jones, are currently investigating through an in-depth OpenStreetMap usability study, which will be presented at the upcoming SOTM-EU conference.
We just finished our data collection exercise, which included eye tracking and screen recording ten OSM novices through their first experience registering, adding and editing information to OSM. A OSM test server enabled participants to complete registration, search for a specific scenario area, add and edit 11 features using Potlatch2, while being tracked and observed by a researcher. Although we will present comprehensive results from this study at the conference and the proceedings, I want to give just a quick glimpse into some of the very basic issues we have uncovered so far.
Where is the OSM Search?
We discovered that users have difficulty locating the Search on openstreetmap.org. This has been highlighted before. This video shows the gaze plot of one participant looking for the OSM search. The participant first tries to find the search functionality at the top of the page, scanning from left to right and back in vain. Only after having spent 6 seconds looking at the top, the participant starts to scan and read down the left-hand side of the page, before stumbling over the search at the bottom of the page.
Questions arise over the natural way in which users scan a webpage,and preconceptions about where they would expect a search functionality to appear. According to Nielsen, user reading behaviour of websites exhibits a dominant reading pattern which looks somewhat like an F, with two horizontal movements across the top and middle of a given page, before moving on to a vertical movement scanning the left content section. This pattern has been recognized and adopted by many prominent websites, creating in turn preconceptions in users as to where to expect prominent content/functionalities. Google for example consistently locates their search box on the top-left to middle of a given website.
This video is only an example of the consistent behaviour we have observed of participants exposing the F pattern when looking for Search. As the OSM website now stands, the Search functionality (which works well and is helpful once found!) is not in a clear and quickly visible area of the website, but “hidden” in a “drill-down” area last seen by the user.
As I said, lots more stuff to come out of this study, watch this space if you can’t make it to SOTM-EU!
14 Comments to “OpenStreetMap – Where’s the Search?”
Leave a Reply
Why do you think it is a usability issue rather than a motivation issue?
Perhaps it remains there from when the search was extremely slow and not very helpful. A good reason to move it up though.
I’m used to holding shift and drawing a box on the map to zoom into where I want. Or I search right away with Chrome, http://www.livingwithdragons.com/2011/01/searching-in-chrome
Kevin, I am assuming they asked “find this place using the search” or “search for…”, when recording this.
I would like to ask the 70% of signed-up users why they signed up. Perhaps they thought they had to log-in to use the search or the map? :p
Sounds a really interesting study as far as general usability goes for map-based web sites, but I tend to agree with Kevin. Think your average user just wants to browse rather than edit despite opening an account… They LIKE to think they will contribute but I think editing takes some level of commitment. A commitment which would not wear off if you don’t find the search function on first glimpse…
Really interesting, looking forward to more.
What do you think about simply moving the search box up on the left side, as a straightforward first step?
It would be interesting to respond in code to the results you get, and then go through another round of testing.
Since the issue came up – do you think locating the search box slowly is a problem? Try not having the search box on the screen at all – because you happen to have a not-quite-state-of-the-art laptop, with an 1280×800 native resolution, on which the search box simply falls off below the bottom screen edge. The SOTM ad was the last straw – I simply threw out everything but the search box using the RIP extension from the page, end of story.
Also, out of curiosity – how long does it take for a novice to realize that on the OSM wiki, the search box he just located on the bottom-left earlier jumped right back top-right…? I’m a member for over three years now, and I still lose a few seconds realizing this every single time I look for it…
…anyway, sorry to “take this out” on you, good job pointing all of this out!
Mikel – This is the usual way that usability evaluation *should* be included in the design and development process for an app, but this doesnt often happen, especially for open source software development. I hope that our work first gives some practical tips and hints at basic things that need changing, but also perhaps instil in the developers a desire to continue with usability evaluation.
Usability evaluation doesn’t need to expensive and time consuming. A developer wishing to evaluate the usability of his app just needs a (his) computer, perhaps with screen recording software for later review, and a willing “non-expert” which hasn’t used his software/website/service before. The eye tracking is a nice to have rather than a necessity. The key point is for the first time user to “Think Aloud”, ie express verbally what they are trying to do, where they expect things to be, how they feel interacting with the software, and a patient passive! observer. The observer has to be passive, ie not be quick to jump in and help/guide the user, or else you wont be able to see where things dont work.
It would be great to have some details about how to do a usability evaluation at home. Have you published your procedure and questions?
Mikel – lots of good resources and a “Usability” 101 can be found here:
http://www.useit.com/alertbox/20030825.html
this article successfully ignores people with Netbooks and Notbooks, equipped with 1280×800-screen:
There you need to scroll down (manually) to see the search field!
Having so many zero-edit users makes me wonder whether some of them intended to do any edit at all. Maybe they thought creating a user was necessary to do X, but X is either possible without logging in (but was hard to find or not exactly what they expected), or simply not possible.
Another possibility is that they wanted to do non-edit stuff, like asking on help.osm.org or using the diary.
Sorry for the wild speculation (and for not knowing how to turn that speculation into knowledge). But I think it’s wrong to assume zero-edit users were all thwarted by the complexity of editing the map.
The search box has been moved on the OpenStreetMap front page, perhaps in response to this analysis. Guess another difficulty with looking into use-ability is that it can be a moving target.
Yea, I moved it. But there should be a more systematic look at redesigning the front page. More to come soon.
[...] I want to address in this context of OpenStreetMap usability is Patrick Weber’s. I noticed his blog post describing initial results of the extensive OpenStreetMap usability research he and his colleagues [...]
[...] with OSM’s editing tools, in this case Potlatch2, in continuation of previous work done in usability analysis, reported previously. Apart from some of the previously discussed problems in the usability of Potlatch2, of which Andy [...]