Just a quick pointer to the recording of the presentation of the joint work between Dr Catherine Jones and myself here at SOTMEU (I only got the video to work in Firefox!) So, far a great and vibrant conference, and our research into usability issues in OpenStreetMap was well received. I was particularly pleased by the positive reaction from a lot of conference attendants to our work, it seems that most core community members are well aware of the issues we raised, and recognise the need for improvement.
This small research project from us then represents the first of an ongoing effort to better embed and implement a usability engineering culture in this great project!
Last weekend I attended the 2011 edition of WhereCampEU, held this time in sunny Berlin. It was a great conference, altough smaller than previously in London, but with more diverse presentations than last year’s unconference. I also presented our recent work on geoweb usability at the conference, even though we haven’t had a chance yet to do a comprehensive analysis of the user experiments data we collected. I will put online the presentation in due time. Some lively discussions ensued about the nature of OSM and to what extent it should conform to establish practice in terms of UI (established by Google with for example the Search Bar).
Apart from my own presentation, I just want to highlight some of the more interesting presentations here that I attended:
The first morning for me started to get interesting with a good discussion session on spatial databases, organised by this guy, leading with the definition of their necessary characteristics (does a spatial database need to handle projections!?!). The discussion in my opinion showed still a deep distinction between different application domains (this is obviously a continium): neogeographerswho want lean, fast spatial databases and are happy with minimal spatial support functions, versus paleotards who want comprehensive entreprise class spatial databases loaded with advanced spatial features such as topological operators, comprehensive projection support and metadata handling… . These two extremes in my opinion needn’t be opposites, but the challenge for future spatial databases will be implementing a complete set of spatial functionalities while remaining, small, nimble and user friendly!
Before our own presentation, Tim Waters from Geocommons gave an indepth demo of the new features of their 2.0 platform. Geocommons to me now stands as one of the best examples of a new generation of advanced geoweb applications, dangerously (for traditional GIS vendors?) coming closer to fully featured GIS app in the cloud. Geocommons now features a complete set of thematic mapping controls, allowing good cartographic prinicples in webmapping. One thing that struck me as something obvious, yet innovative is their use attribute data histograms to guide users as to the choice of thematic formatting. They also now allow users to store, display and analyse very large datasets with great performance, enabling users to go beyond visualisation to analysis of their data ( notably they now implement a set of topological operators). Again, given the advanced abilities of Geocommons, they had to solve a lot of usability challenges, which we would like to investigate further!
The second day came with a set of more advanced technical discussions, most notably for me a discussion session on differences between webmapping frameworks (nicely captured in this whiteboard). We first established that altough there are other libraries, for most geoweb developers, the choice really comes down to Google Maps API vs Openlayers (on its own or inside a UI framework such as GeoExt or MapQuery). I won’t go into much detail here, as the discussion and its outcomes have been discussed by both people in the session, as well as members of the OpenLayers team.
Lastly, the conference closed with a very thoughtful presentation by Martjin van Exel on his initiative for the development of an API dedicated to historic OpenStreetMap data. In his presentation, he justified the development of a dedicated separate database and API from the main OSM database, based on some deficiencies of the current OSM data model, for example the fact that the versioning approach doesn’t catch all edits on a given object. Another challenge is the classification of OSM edits according to changes in ground truth, or simply refinements of the same data. Again, Martjin and his collaborators explain this all much better than myself.
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!
Recent Comments