TheGreatRefrigerator
commented
3 years ago @koebi We already had a whole meeting on this: (restricted links) https://confluence.gistools.geog.uni-heidelberg.de/display/openrouteservice/Features+and+usability+of+the+new+maps+client https://confluence.gistools.geog.uni-heidelberg.de/display/openrouteservice/ORS+maps+client+usability+meeting
with the following result for this question: 1 - Should the app have two place inputs at start?
Currently at start the app shows only one place input.
We offer many services on ORS, including geocoding, reverse geocoding, POI search, roundtrip and isochrones. We do not offer only routing, but as we all know, routing is very important. From an UI/UX perspective, we should have an interface that is as consistent as possible, among all the features we offer.
Many of the map clients available on the market use the progressive displaying approach, So the elements that are essential to the activities are displayed at the initial state. From that point the users can access other features. Find a point or a place is the very first task a user has to do to start any activity. Routing requires more than one place (at least two) but the other activities don't. What is the common thing among geocoding, reverse geocoding, POI search, roundtrip, isochrones and routing? Essentially, determining a place is the very first action to use all the features. We also offer routing services with intermediate stops, what requires multiple inputs, and we allow the users to add the inputs according their needs, based on the use case.
I just compared with our old map client and using the mouse, it is necessary four clicks (plus keyboard) to calculate an A to B route: 1 - client on the first input to focus on it (then the interface shows only one input and the user has to type something) 2 - click on a suggested item 3 - click on the second input (then the interface shows only one input and the user has to type something) 4- click on a suggested item
On the new client: The app automatically put the focus on the first input when loaded and then the user types something 1 – the user click on a suggested item 2 – the user clicks on the directions button (the interface opens the sidebar with the previously selected destination on the second input and with the focus already on the first (origin) input). So the user types something for the origin 3 – the user selects a suggested item
So fewer clicks are necessary to calculate a route than it is in the old client.
All the most used map clients on the market, like Google Maps and Bing Maps use the same approach. The first view shows a single place input and there is a “directions" button. By the way, we use the exact same icon that these clients use in our directions button, because in general people recognized it as a representation of the direction activity. Other clients based on OSM also use the single input approach, like: brouter.de/brouter-web www.komoot.de/plan wego.here.com www.mapquest.com
Having two inputs at start would definitely make it easier for the user to calculate a route. But it would bring side effects to the other features. We would have to introduce more buttons or tabs so that the user can alternate somehow among the possible activities (find a place, round trip, isochrones with a single center) It would possibly not be that intuitive to have to remove inputs to just find a place, for example.
Do you think we should have two inputs at the start? If yes, then we should be able to answers the questions below:
A- What is the suggestion to keep other tasks/activities tha requires only one place input intuitive if we have two inputs at the start?
B- Do we think the users would be familiar with such approach? Currently only three clicks (and typing the places’ name) are necessary to calculate an A to B route.
Meeting outcome:
keep one input (6 out of 8)
Keep two (1 out of 8)
Does not matter (1)Result: keep 1 input
amoncaldas
I propose to have the side menu and open by default if there is enough space on the screen.
In a mobile context, the behaviour mirrors that of e.g. gmaps, where one usually wants search&go. For this, it is advantageous to have as much map view as possible and only a single input field for the place the user wants to go to. This is especially important since most screens of mobile devices are rather small, and I assume we'd want to take up as little of it as possible with unneccessary¹ information
On a regular laptop or desktop with a comparatively big screen, there is no need to hide information the user might want to use. I think a big part of usage is private route planning, and with only presenting a single input field, we're forcing the user to first specify their destination. This is not how the route planning workflow for our users might work - they might want to specify their means of travel first, set any route options or specify a starting point. I therefore think it would be beneficial to default to opening the sidebar in the mode where you can specify start- and endpoint as well as routing options and choose a profile.
[1]: the user specified the place he wants to go to, so in my mind it is not neccessary to show this to him once it's set