What is this “Usability”, anyway?
Once again, OpenStreetMap usability is all the rage. Or rather, its lack thereof. Development Seed, a US-based software development and consulting firm, have applied for a $500k grant to help them, among other things, make OpenStreetMap editing easier. This, and also some minor web design contributions from Development Seed employees that we’ve had in the run-up to their application, has prompted discussion – on twitter, on the blogs, and elsewhere – about how bad the “OSM UX” (for user experience) really is and what needs to be improved.
Of course, this is not new.
Back in 2008, CloudMade already believed to have identified OSM UX as one of the major factors holding OSM back, and they planned to either get the Potlatch editor rewritten or do a new editor altogether. (In the end, both were done; CloudMade’s own editor, MapZen, is dead, Potlatch2 lives on.) Steve Coast pops up on the mailing lists about once a year to start a thread about usability – in March 2009 with site designs from CloudMade staff, in February 2010 with “It’s the number one complaint I hear when I fly all over the world talking to people about OSM” (and asking us to deploy uservoice.com because OpenStreetBugs had “crappy UI”), or in December 2011 starting a design competition on CrowdSpring and taking everyone by surprise. Nothing has ever come of this.
Why is it so hard to improve the OSM UX?
If you hire a designer and ask them to help you improve your UX, then one of the first things you will be asked is: What is the purpose of your web site? Whom are you trying to reach? Who are your users?
Bummer. Guess they won’t take “everybody” as an answer! The reason why it is so hard to improve OSM UX is that we don’t have answers to these questions; or, perhaps, we have too many.
The way I see it, we want to be usable to three kinds of people:
- active contributors who are editing;
- curious passers-by who are not active contributors but whom we could make into such;
- people who just take our data and use it, thereby hopefully raising awareness of OSM and bringing us more visitors whom we could make into contributors.
If someone complains about OSM usability, it is always a good idea to find out which of these three they’re talking about, because each of these target groups requires a different approach to usability, and not everyone sees these three groups as equally important. (Some might even have still other target groups in mind.)
The group I’m least worried about is (3) because that group is most likely to help themselves. Using OSM data may not be easy but it is so damn attractive that we’ll have more and more players in this field building stuff. Big companies like ESRI integrating our data into their supply chain; smaller companies who, as middlemen, make OSM easily available on the commercial market; universities who prove that they’re up to speed by offering OSM-based services; and last not least hordes of hackers who love the opportunities our data presents them with. My own company, Geofabrik, sells OSM data preparation services, but for every client we sell something to, we serve free downloads for hundreds of people, and other businesses do likewise.
So, then, what about (2), the passers-by who look at our web site. What do we want from them, what does “usability” mean here?
The purpose of our project is to make a high-quality, world-wide map database that is maintained by a large community and that is accessible under a free and open license. The purpose of our web site, therefore, must be primarily to explain the project to passers-by and entice them to join our community. We are not a map portal and we have no reason to try and replace Google or Bing Maps; we will always show a map on our web site but this is meant to illustrate he quality of our goods, not to provide a map in itself. Our web site primarily has to show people what we do, and attract those who are likely to make a contribution to our project.
It doesn’t make sense for our web site to communicate the message that “everyone can contribute” because that would be a lie; even with the simplest of tools, a certain level of abstract thinking is required to participate in making a map database. And since we are a community working for a common goal, OSM is not for loners either. I was criticised when I brought this up in my “Barriers to Entry” post on the mailing list last September, but I still believe that we do not have to sell something with our web site – we’re not some Silicon Valley startup that needs to prove to their VCs how much mindshare we can acquire in a given time. We can afford to tell it like it is – we can afford to say that “OpenStreetMap is for you if …”.
Our web site’s usability for the casual visitor could be improved by our not trying to look like any old map web site, but by conveying what we do and how we do it. There’s a lot of potential there – we can let the community take stage, we can tell stories of mapping parties, of brave individuals, and past successes. If you’re not a mapper then our web site should give you a comprehensive and honest picture of the project and of how you could help.
And finally, (1), usability for people who edit OSM. In my mind, this is more a question of usability of the editor software, than one of usability of the web site, because I am a JOSM user and don’t even log in to the web site when I make edits. I like it that way, but times are changing; even though Potlatch2 is a separate piece of software people often perceive it as an integral part of the web site, and the future might even see a HTML5 editor fully integrated with the web site (one is already being built – caution, German slides!). So depending on your personal preference, you might see a different face of “the web site” as your environment for editing OSM, or you might use a completely separate piece of software.
The target group for editors and supporting software (whether integrated in the web site or separate) is people who want to help make the map. Usability, for these people, of course means that things should be simple and intuitive – but I feel that usability is too often reduced to that. Most people who complain about OSM UX complain about how hard it is for a non-technical person to, say, add a node. This is something that can be fixed with good software; for a while, CloudMade achieved that with their iPhone MapZen POI Collector (until more and more POIs were not nodes). CloudMade also announced but never really built a suite of special-purpose editors, e.g. for different sports users, and there are a few successful single-purpose editors around, e.g. on the WheelMap site. But if you are a “power user”, then good UX for you means that you can effortlessly slice and dice public transport relations with 23 variants – an abstract concept that some might find daunting to even visualize in their heads, much less edit, no matter how simple the editor. Usability is not simplicity. Placing a POI is simpler than mapping a bus route, but we must be careful not to lose those who map bus routes or we will become a POI database.
Usability is not pure window-dressing either. Take, for example, the way we express complex areas as multipolygon relations. To a degree, this is an implementation detail that can be hidden away by a good user interface, but that can only go so far and there will always be cases where the ugly reality shows through. Having a proper area data type can improve this situation; it may sound like a minor backend detail but a solid design of the lower layers is a prerequisite for a good UX. There are other areas where established OSM practice and good UX are at loggerheads – the tagging freedom is one of them. Most of our current editors have already relegated free-form tagging to some kind of “advanced” or “expert mode” panel, and a first-time user will only see a very limited selection of suggested “presets”. Free-form tagging is deemed incompatible with the simplicity that one would like to offer to the entry-level user, but at the same time it has until now been a cornerstone of OSM’s success so maybe we have to be careful not to erode that.
Usability for mappers, then, also means that what you map today is not destroyed by someone else tomorrow, or at least that it can be easily detected and repaired if things go wrong; that there actually is a data model that allows you to express what you want; that the server is up and running to accept your edit, and so on.
We can do a lot to improve our usability for mappers, but it is a multi-faceted issue and must not be reduced to “how quickly can a new user map a deli that’s missing from the map”. I would love to have a good editor that lets me master the aforementioned 23-variant public transport relation with ease, or that quickly shows me where exactly the self-intersection in the 14,000 node German border polygon is so that I may fix it. That, however, might not be sexy enough to attract grant funding any time soon.
In a nutshell:
Talking about usability requires that you define your audience and goals. In OSM editing, good usability needs a strong technical foundation, and we must not disregard “high end” editing.
There's 4 Comments So Far
April 3rd, 2012 at 12:22
Frederik, I don’t often find myself agreeing with you but I think you are spot on in a lot of what you have said here.
But I think your “three kinds of people” is only one way of thinking about our potential users and contributors. Another way is to think about:
* Individuals who are interested in maps or geodata
* Well resourced companies and charities who might benefit from using and contributing to our data
* Poorly resourced companies and charities who stand in the same position
The OpenStreetMap community is largely comprised of the first group, for whom the usability of the main web sites and tools is paramount. I agree with you that we shouldn’t be too quick to break down barriers. Editing geometry, as opposed to metadata (tags), is complicated. I think we sometimes forget that because many of us already posess sophisticated technical skills. The trick, with these people, is to make it more likely that they will be interested enough to persevere in learning the ropes and becoming valued contributors.
Companies such as your own are bubbling up and growing to serve the second group. If they want to contribute or use data, they can make it work.
It’s the third group I’m interested in. WheelMap is a great example of a tool that enables a community of interest – disabled people – to contribute in an extremely useful way with a very low-barrier tool. Maperitive is a great example of a tool that makes it easy for them to then use that data to create their own maps by just downloading and running a desktop program.
These people aren’t going to launch straight into the high-end skilled work of editing 14,000 node polygons. But they could see an explosion of low-level contributions and set OSM up as a uniquely valuable community project.
Instead of chasing generic low-skill users, we would be better off trying to make it easier for communities to enable their members to contribute and use data. Something for all those groups of people interested in allotments, trees, bicycle parking, heritage and so on who lack the resources to roll their own solution from scratch. All communities who currently set-up Google Maps because they’re easier.
April 3rd, 2012 at 13:22
When telling a newbie about the editors, I try to not label them with stereotypes. E.g. potlatch is for newcomers, JOSM is for experienced editors or those people of a more techie nature. But I think with what you’re saying we should be doing this, infact the editors should be deciding what users they are for and making it very clear that other users might get confused. If this was done, users might be more likely to switch editors because they would know that another one was more certain to certain tasks.
For example, I usually use JOSM. When I just want to add a quick few POIs I use Potlatch. If there was an editor or two that said they were primarily good for relations, I would try that out when I’ve been on a bus trip.
When there is talk about a website/homepage redesign, I’m always a big fan of actually asking the viewer what kind of user they are what they want to do, then listing appropriate links. Openstreetmap.de has done this well at times, and it’s done on the wiki main page but not as the main/first box you see.
April 3rd, 2012 at 18:26
Gregory, that’s exactly how I approached the redesign of the wiki’s Vietnamese main page (translation). It starts out with a slippy map (showing a different location every day) to pique every visitor’s interest, then proceeds with starting points for each of the three audiences Frederik identified.
One of OpenStreetMap’s underrated features is the ability to translate anything into any language. For many languages, Wikimedia’s localized OSM map needs a lot of work before it’ll be useful, but translating place names is a painful experience. Wikipedia’s many translators would be happy to improve the translation, but they currently have to: a) wrestle with Potlatch’s Find POI dialog to jump between places; b) install JOSM; or c) write a bot. I’d love to see a translator-centric editor that finds a POI, lets you enter the translation in an HTML form or search Wikipedia, and hit “Next POI”.
April 3rd, 2012 at 22:54
Great post – I think I agree with nearly all of your points. To add a few more:
So far, UX has been a combination of two things: more or less finishing the OSM homepage UI, and then being a sort of trojan horse for moderate style improvements. The latter is important – while I’m still relatively ‘new here’, I get that big redesigns in .png files are usually a dead-end.
Before making changes, I’ve been asking whether there’s some super-user use case for the feature. You gave some good comments on the changeset redesign, I believe, and they were very useful. It’s doable to have a ‘manual power mode’ part of the design for improved pages.
The principle of OSM being data first is useful and I don’t think anyone agrees, but the three groups of people is missing one: people who want maps. Not that OSM.org should handle this, but it needs to address it in some way – should it push users elsewhere to services that do present OSM data as rendered layers, directions, etc? Should it provide a subset of those features, or aggregate external services?
Basically, this is an issue that won’t go away by ignoring it. OSM is framed as a mapping service by the press, and used as a mapping service by some segment of its users.
Everyone is far away from making anything better than JOSM for advanced editing – it’s a powerful tool. The real plus is that another editor effort, with more users and a different way of interacting, will push for performance improvements (whether code or servers) that make editing faster for advanced users.