Search forms redesign

[mjourdan]

On www.openstreetmap.org, the search forms (both single location and directions) have a few issues...

Problems

• picking up a search results clears the search field
• pressing the "directions" icon also clears the search field
• button to reverse directions is visually disconnected from directions, and placed after the "go" button
• the routing engines are displayed prominently, while they are technical details most people won't understand
• input fields lacks of readability once locations are found
• search mode and destination mode feel disconnected (forms have different width and no clear alignment)
• lots of gray area eating estate from the map

Also, maybe adding some extra features could satisfy common expectations, like:

• multiple destinations
• public transports

Screenshots

[mjourdan]

Proposal

Please find below two static mockups. The first one only aims to fix the issues previously mentionned, while the second one also adds the features mentionned:

Feel free to tell what you think!

[tomhughes]

Just having mode selectors mean we have to make a policy decision to prefer one engine over another which whilst it may be good UX is bad politics.

You should also be aware that routing only exists to allow for connectivity testing - it is explicitly not a goal to provide an end user google maps replacement.

[systemed]

public transports

OSM doesn't store timetable information so can't really provide a public transport routing service. See https://help.openstreetmap.org/questions/78247/transport-options .

[mjourdan]

There must be other ways to play good politics and still improve the ux. For example, the mockups above could allow sending requests alternately to one provider or the other, unless people picked their choice in the options.

Regarding the expectations about the routing service (and more widely about the website), the thing is OpenStreetMap is sometimes advertised as a privacy-friendly alternative to Google Maps. See here or there. I know this is inaccurate, still it contributes to forge people expectations.

As of public transports routing, the wiki also highlights OSM is not meant to store timetables information, but also states OSM could provide basic routing services. Still if such service provider existed, it could make sense to integrate here. Nothing mandatory though.

[gravitystorm]

There are definitely parts of this proposal that I like, others less so. For example, I think the contents of the search box should be retained when the directions panel is opened and closed, and I think it would be good to use the search results as the start of the route when activating directions.

But the choice of routing engine isn't something to try to hide away. As @tomhughes says, the goal is to help mappers debug connectivity, not to provide a smoother experience for non-mappers at the expense of our mappers.

I'm surprised to hear that the panel is different widths for you, since they are identical width for me (at all screen sizes). Any debugging information on this would be helpful.

Are you able to prototype any of these changes using the real codebase? For example, it took me a while of considering this before I realised the cross beside the "from" input was probably meant to close the panel, rather than clear the input (since there is no corresponding cross beside the "destination" input. I also think it is worth prototyping in the real codebase, so that the controls and buttons look realistic.

[mjourdan]

Checking again, the difference of width is due to the scrollbar when the results are displayed. So it also happens between empty search and search with results.

What do you mean by realistic?

On the technical side, most of the stuff should be pretty straightforward:

• as the bootstrap icon set were missing way of locomotions, I got car, bicyle, and pedestrian icons from GNOME
• those 3 icons would be put in a group of 3 radio toggle buttons or button groups
• other widgets are basic buttons and dropdown

The heaviest work I see is with the input fields:

• having a location icon at the start should not be a problem, but not sure how hard it would be to make it draggable
• styling of the search results may also need some attention

If by realistic you mean something which integrates well with the rest of the site, one thing to consider is we don't really have guidelines nor a cohesive set of patterns and styles to rely on.

[mjourdan]

Please find some more mockups to address the issue raised so far.

A basic prototype could be doable, but later ^^

[pnorman]

I prefer the layout of C for putting the routing engine next to the mode selector.

[mjourdan]

It's made with Penpot rather than based on the actual codebase, but here it is: an interactive prototype based on proposal C.

[gravitystorm]

What do you mean by realistic?

I mean matching the controls and look and feel that we currently have on the website. This is best achieved by forking the project and editing the html, so that it uses the same colours, corner radius, button sizes, and so on.

I looked at the interactive prototype, but I couldn't really understand what was going on. Some of the labels were cut, and of course I can't view source to see what divs and bootstrap classes etc would be used to create the desired result.

[Alex-Esko]

Hello there.

Anyone stumbling upon the clunky user-interface will neither use nor contribute to OSM. They are lost to Gmaps.

So the user experience of OpenStreetMap.org is very important to attract users and subsequent mappers.

The first two problems are the most pressing, and they were not broken a few month ago:

• selecting a search results clears the search field
• clicking the "directions" icon also clears the search field (Screenshots: Search -> Route -> empty field)

I think Proposal D is great and i changed it a little bit according to the concern from https://github.com/openstreetmap/openstreetmap-website/issues/3123#issuecomment-803632318 @pnorman.

Regards, Alexander

[graue70]

You should also be aware that routing only exists to allow for connectivity testing - it is explicitly not a goal to provide an end user google maps replacement.

@tomhughes You might want to know that it definitely comes across as an end user google maps replacement. I have thought for years it was exactly that (and used it like that) until I read your surprising statement just now.

From that perspective, the mentioned UI/UX problems are incredibly annoying.

[mjourdan]

Better late than never, I took proposal C to make #3400 as per requested by @gravitystorm

I suggest we keep discussing the design aspects of it in this thread, rather than in the PR. Cheers!

[AntonKhorev]

pressing the "directions" icon also clears the search field

Not sure if this ever happened but that button was supposed to copy the search string into the starting point input. This was broken at the time. Fixed in #4877.

[hlfan]

So what is still left of the issues? IMO the current state is this:

• [x] selecting a search result clears the search field
• [x] pressing the "directions" icon also clears the search field
• [x] button to reverse directions is visually disconnected from directions, and placed after the "go" button
• [x] the routing engines are displayed prominently, while they are technical details most people won't understand
• [x] input fields lack readability once locations are found
• [ ] search mode and destination mode feel disconnected (forms have different width and no clear alignment)
• [x] lots of gray area eating estate from the map

So are there any other things besides the recoloring?

[mjourdan]

Thanks for the changes! It's great to see markers are in the input form, the reverse direction button is well placed, and the mode is finally separate from the routing engines.

Did a quick informal user review with a panel of 1 person, and what came up immediately:

• there is no clue of what the dropdown is for, what OSRM, GraphHopper, and Valhallah are
• pressing the go button during a calculation seemed to break the route that was beeing processed (could not reproduce today though)

The issues I see too:

• The close button is a bit too close the reverse directions button and the input form
• the matching locations are not suggested while typing, which likely results in routing beeing calculated for non-expected locations (this might deserve an issue on its own)

Ideally we could improve things further by:

• adding a short message to advertise that routing engines are used by the mapper community to ensure the points they add to the map are well connected.
• triggerring the calculation as soon as two locations are selected, a location is changed, the transport mode is changed, or the routing engine is changed
• removing the go button

I could update mockups to reflect those suggestions if that sounds sensible.

[hlfan]

• there is no clue of what the dropdown is for, what OSRM, GraphHopper, and Valhallah are

Do you think an optgroup with a label and a title on the select would be enough hints?

• adding a short message to advertise that routing engines are used by the mapper community to ensure the points they add to the map are well connected.

This would need space, where would you put it?

• the matching locations are not suggested while typing, which likely results in routing beeing calculated for non-expected locations (this might deserve an issue on its own)

Probably, as the Nominatim usage policy prohibits autocompleting results, so that can't as easily be added.

• The close button is a bit too close the reverse directions button and the input form

Sticky close buttons have been introduced since, maybe reusing that style could add more separation?

• pressing the go button during a calculation seemed to break the route that was beeing processed (could not reproduce today though)
• triggerring the calculation as soon as two locations are selected, a location is changed, the transport mode is changed, or the routing engine is changed
• removing the go button

Maybe for the sake of having a submit button for accessibility just make it hidden, I don't know if that would need to be discussed further.

[AntonKhorev]

• there is no clue of what the dropdown is for, what OSRM, GraphHopper, and Valhallah are

Do you think an optgroup with a label and a title on the select would be enough hints?

optgroup is probably a good idea. Maybe the title will be unnecessary.

Probably, as the Nominatim usage policy prohibits autocompleting results, so that can't as easily be added.

And you can also get rate-limited on routing engines, so those are questionable:

• triggerring the calculation as soon as two locations are selected, a location is changed, the transport mode is changed, or the routing engine is changed
• removing the go button

---

• pressing the go button during a calculation seemed to break the route that was beeing processed (could not reproduce today though)

There is a bug in request abort code. I don't know if it's related.

• The close button is a bit too close the reverse directions button and the input form

Sticky close buttons have been introduced since, maybe reusing that style could add more separation?

#5817, although it doesn't add a lot of space. Previously there was more, see #5288, then #5765.

[mjourdan]

Thanks @hlfan and @AntonKhorev, I updated the mockups according to your remarks.

[hlfan]

• there is no clue of what the dropdown is for, what OSRM, GraphHopper, and Valhallah are

Do you think an optgroup with a label and a title on the select would be enough hints?

optgroup is probably a good idea. Maybe the title will be unnecessary.

Without the title and avoiding adding "unnecessary controls" like an info circle to trigger a tooltip, how else would you introduce the users to routing engines? A hover-only solution won't work on touch devices.

[AntonKhorev]

For touch devices title is not the best choice. optgroup looks like this if you tap the select:

Maybe the optgroup label should be "Directions provider(s)" or "services" for those who don't know anything about osm.

[hlfan]

@mjourdan I'm looking for another round of feedback, let's get this resolved!

[mjourdan]

The biggest issue I see is on mobile, where directions are disconnected from the input field. This is because of:

• the directions coming with a close button
• the input fields being embedded in the menu

People presented with the results and willing to change routing settings would have to either:

• close the results and then realize they have to open the menu again
• directly open the menu, but be confronted to an illegible screen where the menu and the results would be visually mixed up

Moving the input fields away from the menu and placing a "back" button on the results would certainly give a more effective pattern. Not sure if that can be done without affecting the whole language and main menu.