Designing a New OpenStreetMap Editor Entering the First Phase of Designing iD
The principle for admittance to OSM should be “I know stuff that can go on this map”, not “I’m good at using an OSM editor”. The more local knowledge that can be added to OSM, the better the map is.
He proposed a redesigned editor that is modal, seamless, and fast - well suited for both beginners and experienced users. Now working on the iD project with redoubled efforts with funding from the Knight Foundation this continues to be our goal.
At this point, much of the basic editing functionality is in place. Still, no actual designer has been involved, and no thorough review of UI details has taken place. The visual design needs work, but that’s the easy part: Icons, button styles, layout details, those things will fall into place. The hard part is laying the groundwork, creating the paradigms for an intuitive, yet powerful user interface.
Some of the challenging questions include: How do we improve the first time experience for new users? How do we progressively expose more complexity while keeping the tool easy to use? How do we balance map legibility with showing as much data as possible? Should map panning and zooming use standard conventions, or should clicking, double-clicking, and the scroll-wheel be reserved for editing mechanics? What should the user flow look like for adding new nodes? These are some of the harder questions that I hope to be able to make informed decisions about as I get deeper into the design process.
Many of these design problems are being tracked & discussed right now on iD’s GitHub project and I welcome additional input. Designing iD will be an iterative process, and if the first take on a feature of user flow isn’t quite right we should make sure to revisit it.
A first review of existing editors and literature
Right now, I am just starting to work on the iD user interface directly, with mock-ups and commits. Before I got my hands dirty with design work, I researched existing literature and experimented with other map editors out there. Here is a short list of the most interesting editors and posts I’ve taken a look at. My notes here reflect less the full result of my reviews but more a quick listing of what I’m aware of in this space. If you have any additional pointers in this field for me, I would love to hear about them.
Potlatch 2 is the go-to editor for in-browser editing on OpenStreetMap.org. One of the best parts of Potlatch is the attention put into keybindings. This makes Potlatch the fastest web-based editor for experienced users. As a designer who spent a lot of time with Inkscape and Illustrator, I can quickly make, connect, and manipulate paths, without constantly searching around for which buttons I need to click or moving through slow step-by-step walkthroughs. Because Potlatch supports the entire spectrum of data manipulations on OSM, it’s more flexible and complex than comparable editors from other organizations.
The Java OpenStreetMap editor (JOSM) is a desktop application and the most popular editor in OSM. JOSM can do more and is faster than any of the other editors on this list, but it has a steeper learning curve. It allows users direct access to the data model and doesn’t force users to use defaults. This is the editor that you can use to map the world from scratch.
OSM is open to describing any geographic feature in the world and its data structure is developed in an organic, community driven process. Hence editors for OSM need to provide a large degree of freedom. JOSM, Potlatch and also iD need to be designed with that kind of flexibility in mind. This is different from the editors I reviewed next like Waze, or the heavily moderated Google MapMaker.
note: In the original version of this blogpost I innacurately said JOSM has “no abstraction”, when in truth users can use presets and bypass the free tagging interface if they’d like to.
Of all the existing editors, the waze map editor impressed me most. It has the advantage of serving a more niche purpose: it’s an editor for a map for car navigation, so a lot of the complexity of an OSM editor can instantly be dropped. Another interesting design decision is the turn restriction UI: It allows for a kind of direct manipulation by clicking icons that would be reserved for sidebars and menus in other editors. Very intuitive and easy to use.
Google MapMaker has one goal in mind: accessibility. The whole tool is designed to encourage someone new to start making a change and commit it. Some ways it accomplishes this goal is through its edit-first, sign-in-later approach. Adding ways and nodes is a guided experience, with many small steps, with one choice to make at each step, so on the first run users know what to do.
I like the way the details panel is hidden, it appears only when you it needs to be filled out. This intuitively pulls users through the process of adding to the map. I know when I should be focusing on manipulating things on the map, and when I should be describing the things I’ve added to the map. The UI also gradually introduces complexity with expandable menus. Even upon expansion, the choices are clear and the UI is attractive.
This is the only editor that takes control of the right click menu. I don’t know if this is the right approach for iD, but it does make it easy to quickly add new nodes and ways. Good keyboard shortcuts can accomplish the same thing.
This list covers some of the reading I’ve done to get up to speed on iD. If you’re interested in the project, you might find these resources helpful.
This link should almost go in the editors section, because it’s about Mapzen, an editor CloudMade began developing a couple years ago. Unfortunately, the mapzen project is no longer actively maintained, and it’s completely offline. Still, a few years ago this was an exciting and promising effort and the developers did a great job of blogging their work. Some interesting features of Mapzen included very tight integration between the editor and a social platform, and deliberate design of the editable data overlays in the editor.
This is Richard’s blog post that I quote above. It’s the starting point for much of the ongoing iD work.
These Wiki pages are essential reading. It’s hard to design an editor when you don’t understand what the results need to look like.
Correction: A previous version of the post suggested that JOSM does not abstract the data model and doesn’t provide a lot of defaults while presets cover actually a large portion of OSM tag configurations.
Devlogging work on the OpenStreetMap project by the MapBox team.
Much of this work is currently focused on improvements to OpenStreetMap funded by the Knight Foundation