OpenStreetMap usability revisited

At the end of September I took a half-day off from the day job and visited UCL. They were again running an Introduction to OpenStreetMap Mapping Workshop for their new masters students. I went along last year and created some great notes on usability for OSM newbies and did the same again this year. It’s rare for me to be able to watch (and help) so many newbies at the same time.

The main difference between last year and this have been the move to Potlatch 2 as the main editor, so I was especially looking forward to seeing how this performed. Also the students were this year focussing on wheelchair accessibility mapping, which had implications mainly for the detail of our presets compared to this highly-detailed (and relatively unusual) mapping focus.

So here’s the list of notes that I made, in the order that I made them

  1. We need a deselect button. When you have a feature selected it’s not obvious that to deselect you just click somewhere else on the map
  2. The wiki page on wheelchair mapping is unclear about tagging accessibility of toilets when they are in another amenity (e.g. pub) rather standalone toilets (amenity=toilets)
  3. One person triggered EntityUI exceptions when zooming in and out. I was surprised to see the exception showing – normally these only show on debug flash plugins
  4. Still confusion on how to add features that aren’t in the grid of icons (Current solution is to double-click to create a POI, suggestion is to have an “other” poi to drag/drop)
  5. The conflict dialog, which you see when two people edit the same road, isn’t particularly helpful. It only gives the id of the feature, which doesn’t help. There’s no method to reconcile the differences (or even see what they are). Yes/No labels on the buttons are bad.
  6. The backgrounds dialog needs better labels. e.g. “Bing Aerial Imagery” since “Bing” is meaningless
  7. Need to drag/drop “new point” (as above – shows you how often it came up!)
  8. Maybe need a “More…” button on the presets to provide some way to reassure people they aren’t definitive and show them how to figure things out
  9. Click-again (that is, clicking twice slowly) should also create a POI
  10. It’s hard to read the road names, especially when they are at an angle
  11. Duplicate nodes, when shown, aren’t easily figured out what they mean
  12. One person made the advanced tag panel go haywire by having multiple new tag entries – and managed it repeatedly
  13. Wiki documentation on bookmakers still sucks. We ran into this last year – there’s a lot of bookmakers in London, and especially if you know a different term for it (gambling shop etc) the documentation is hard to find
  14. Would be great to highlight mistakes, e.g. tagging building=yes on a node. This happened a couple of times when people had a node of an area selected when they started adding tags
  15. Copying tags from nodes to ways (see above)
  16. Newbies shouldn’t be exposed to the footway vs path controversy on the wiki.
  17. Nobody ever finds the search box on the wiki, especially when they are using browser-based find on the Map Features page.
  18. People accidentally mousewheel out too far repeatedly when editing. Maybe we should prevent it at low zooms
  19. barrier = entrance vs building = entrance is unclear
  20. Nobody reads past the first paragraph of the Key pages on the wiki before just skim-reading the read. Which means sentences like “Some people use the tag ‘foo = bar’ when they should instead use ‘baz = bar’ becomes “….. ‘foo = bar’ ….” and that gets used.
  21. The public transport pages on the wiki are dreadful, and newbies shouldn’t be exposed to two alternative tagging schemes. I have my own views on the whole new pointlessly-incompatible schema in any case.
  22. You can end up with both the rails_port search panel and potlatch 2 open at the same time. If you try closing the search panel you get the “leaving the page” warning, when you aren’t actually leaving the page.
  23. The “loading….” label isn’t obvious
  24. Areas of the map that haven’t yet had the data downloaded could be highlighted (or disabled) so that you don’t think it’s just empty.
  25. We need some way of saying “Zoom in!” when you have too much data showing at the given time and flash is crawling to a halt
  26. The data loading could be improved by having a tile-based map call instead of the current wms-like map call.

Some of these things are familiar from previous user testing, some are new, and some will need a bit of discussion to tackle. This is a good opportunity to plug the upcoming Hack Weekend!

Thanks to Dr Patrick Weber for inviting me along.

11 thoughts on “OpenStreetMap usability revisited

  1. GrahamS

    All great points.

    Regarding point 25: I’m of the opinion that when you zoom out you should just get normal pre-rendered non-editable map tiles and they should only become editable when you zoom back in to a certain level.

    I typically only zoom-out when I’m editing because I want to move a few miles further down the road. I never actually edit in the zoomed-out state, I just move and zoom back in.

    I’d question if anyone actually edits anything at z15 or further out, as it would be very imprecise.

  2. Harry Wood

    I hadn’t realised you’d gone along to this in the end. Awesome.

    I love things like number 6. As an experienced OSMer I just wouldn’t think about it.

    Point number 13, Still no agreement on how to tag a bookmakers/betting/gambling place. I just updated the usage stats listed here. Maybe we should roll a dice to decide πŸ™‚

  3. Shaun McDonald

    With regard to item 18, I’ve always been confused when I scroll and the map zooms in and out, as I expect it to be panned around. Maybe I’m just too used to 2D scrolling, as the horizontal scroll would zoom in and out, whereas I want to pan around and expect to be able to do it without dragging in the same way that I can scroll this page.

  4. Richard Fairhurst

    Some notes as much for memory as anything else.

    Things that can be summed up as “the wiki sucks” so happily Someone Else’s Problem:


    Things that are really just a Simple Matter Of Programming:

    5. Yeah, absolutely. The conflict feature is really the minimum required at the moment. The reason the buttons are currently just “Yes” and “No” are that Flex 3.x doesn’t let you customise them, amazingly. (Does 4.x?)

    6. Sure, why not? In due course it would be nice to have a hierarchical menu too, so we could group (say) all the OSM Inspector views.

    9. Again, no particular why not. Though most desktop UIs have a time-limit on double-clicking.

    12. Please tell me “repeatedly” equates to “steps to reproduce”? πŸ™‚

    18. Like Shaun says, scrollwheels are for… scrolling. But we’re Mac users. Maybe simply disable zooming in/out more than one step at a time?

    23. Reinstate P1’s more obvious rotating-circle thingy?

    24. Certainly not disabled! But a light hatching pattern would work. Someone else can do the maths…

    26. An quicker win would be to send two (or however many) simultaneous small /map calls, rather than one big one, when most of the new bbox is actually already in memory. Matt wrote some whizzy Ruby code to calculate this, and I got most of the way through porting it to AS3 but got confused by some of the Ruby iterator magick. Resurrect at the Hack Weekend?

    More complex things:

    1. Interesting thought, but not sure I agree. Any desktop OS or indeed word-processor has the concept of “click to deselect”, and we don’t have any precedent for buttons which affect the selection. Might be better to explain the behaviour in the “30-second guided tutorial” as part of the tutorial branch.

    3. Hmmm. Steps to reproduce for this would be good. But I have sometimes wondered whether we should buffer reloads on zooming in/out – people will often click/click/click to zoom in (say) three levels, and we should only fire off the final /map call.

    4/7/8. Nice idea. The immediateness of the grid needs some thought anyway. It takes me longer to find the draggable pub icon with P2 than it did with P1, because we don’t have accompanying text (…though that’s how we get more icons).

    10. I kind of take the view that “the road names aren’t really meant to be read”. Which sounds daft, but really, the reason it says “High Street” is mostly to give you the shape of the road name, so when you’re quickly scanning for the High Street (so you can, say, drop a POI beside it), your eye locates it readily. (Same reason why real-world road signs are in mixed case.) Given enough CPU you can of course make any rendering more faithful; given an alternate stylesheet you can prioritise one part of cartography at the expense of another. But I’d personally not rate this as a priority.

    11/14. This is one of those long-standing ambitions (trac #3777 refers) – to have a friendly, positive-reinforcement mapping quality palette rather than something prescriptive like JOSM’s Validator.

    15. Yep, but needs some thought as to the UI.

    25. Yep. P1 used to do this. Not so easy with P2 unless we go back to the awesome amf_controller which obviously we should do. πŸ˜‰

  5. GrahamS

    18) I completely disagree with Shaun and Richard that “scroll wheels are for scrolling”.
    Zooming in/out using the scroll wheel is a VERY common feature.

    Off the top of my head, the map interfaces at Google, Bing, Yahoo!, and National Library of Scotland all use it.
    In fact the only map site I can think of that doesn’t use it is, which has a pretty poor interface.

    We already have two very effective ways of scrolling the map (by dragging or by using the cursor keys).
    So why add a third way that would only add vertical scrolling for most users (as most mouse wheels are still only vertical), would break the established convention, and remove the ability to easily zoom in and out (something I do a lot of while editing)?

  6. Andy

    While I lean towards GrahamsS’s point of view, I think the key thing is consistency. Scrollwheels, keyboard shortcuts, icons etc should be consistent between the viewing and editing interfaces. I know they use different toolkits, and I know they use different software, and I know they are developed independently, but a user should neither notice nor should care.

  7. Baz

    My usability nit: Potlatch2’s grid of icons for POIs is an awful UI. The icons are often not obvious (eg: postbox vs post office?), and have at times contained duplicate images (eg barbequeue, picnic site); you need to hover over them to figure out what they’re for. They are arranged in a structure that depends on a changeable classification of the POIs. The menu for ways is even worse – with the submenus, you can’t even see all the options. Finding the thing you want to put on the map can be frustrating, and then if you want to do that again… you have to go find it again.

    What I’d want: let me *type* what I want, to filter the list – ie as I type, filter to show a list of labelled icons (no hover required) that contain what I’ve typed as a case-insensitive substring; sort the results alphabetically (not split into categories).

  8. Andy

    !i!, I mean that I watch people scrolling up and down map features, and opening a browser search dialog (e.g. ctrl+f on Firefox) and not finding the results they want. For example, searching for “bookmakers”, which isn’t found on that page. I often have to point out to them that there is a search box at the top of the page that lets them search the entire wiki.

    To be honest, I think the map features page should be removed in favour of a short page with a big search box, that searches all of the Key: namespace in the wiki.

  9. Pingback: OpenStreetMap Chile » Blog Archive » Resumen Semanal OSM #30 y #31

Comments are closed.