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 #3123 (comment) @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!