Better search experience

[jancborchardt]

Search is a central part of any maps app. In OsmAnd »Search« is shown prominently in the menu, but it actually is more of a »Browse« function rather than simple search. I really like OsmAnd but the way search currently works really bugs me. So let’s improve it! :)

There currently are six (!) different ways to search/browse:

• Points of interest (default)
• Address search
• Coordinates
• Favorites
• Search history
• Transportation

If you’re looking for a restaurant for example, POI → Search by name is fastest (if you find it among the options).

If you want to look up an address, it gets cumbersome:

1. choose a region
2. choose a city
3. choose a street
4. choose a number

Which is kind of backwards from how people normally approach it. First you search for street+number, and if there are multiple results you either just choose one, or you add the city.

Then it comes to actually seeing the result. In the address search, it takes some time to find out what you actually are supposed to do: Press one of the icons in the bottom bar (not knowing what they are for):

• routing/directions
• add as waypoint
• show on map (the thing I want!)
• add as favorite
• the arrow → gives me »online search«

Interesting, online search is actually the thing I wanted when I pressed »search« in the first place. Or rather: One input field where I can put in what I want to search.

All the other things like history, favorites etc could be suggestions in the results. But not separate categories which make me confused about what I need to select to simply get results.

Then there’s another thing which bars me from simply seeing what I wanted to search: I get a popover asking me if I want

• Directions
• add as waypoint
• Show on map
• add to Favorites

Where instead it could simply just show it on the map automatically and I could then decide what I want to do with it.

If that is a direction you are generally willing to go into, I would be happy to provide mockups, design consultation, and the like. :)

[sonora]

Undoubtedly, the search arena is one of the next things we should re-visit
to re-organize and simplify. Any comceptual help here is warmly welocme!

But please keep in mind that working on a potentially small mobile device
is significantly different from just typing into a google-style search box
on a PC or similar:

• Processing power and memory: It is much harder to provide good search
  result suggestions in a timely manner
• On small devices typing is more cumbersome. so the hierarchical search
  with the buttons for region/city/street etc. at a second glance does make
  some sense, because it saves a lot of typing: Type "I" in the country box,
  and "Italy" is immediately suggested (if you have the Italy map on your
  device). Type "R" and Rome is immediately suggested, and so on. So this is
  quite a useful workaround instead of providing full search suggestions,
  which could be extremely slow.

But let's discuss, and hear your ideas! We will have to double-checlk with
what is feasible on small devices, and also what is ergonomic.

Best,
Hardy

On Tue, Apr 15, 2014 at 1:53 PM, Jan-Christoph Borchardt <
notifications@github.com> wrote:

Search is a central part of any maps app. In OsmAnd »Search« is shown
prominently in the menu, but it actually is more of a »Browse« function
rather than simple search. I really like OsmAnd but the way search
currently works really bugs me. So let’s improve it! :)

There currently are six (!) different ways to search/browse:

• Points of interest (default)
• Address search
• Coordinates
• Favorites
• Search history
• Transportation

If you’re looking for a restaurant for example, POI → Search by name is
fastest (if you find it among the options).

If you want to look up an address, it gets cumbersome:

1. choose a region
2. choose a city
3. choose a street
4. choose a number

Which is kind of backwards from how people normally approach it. First you
search for street+number, and if there are multiple results you either just
choose one, or you add the city.

Then it comes to actually seeing the result. In the address search, it
takes some time to find out what you actually are supposed to do: Press one
of the icons in the bottom bar (not knowing what they are for):

• routing/directions
• add as waypoint
• show on map (the thing I want!)
• add as favorite
• the arrow → gives me »online search«

Interesting, online search is actually the thing I wanted when I pressed
»search« in the first place. Or rather: One input field where I can put in
what I want to search.

All the other things like history, favorites etc could be suggestions in
the results. But not separate categories which make me confused about what
I need to select to simply get results.

Then there’s another thing which bars me from simply seeing what I wanted
to search: I get a popover asking me if I want

• Directions
• add as waypoint
• Show on map
• add to Favorites

Where instead it could simply just show it on the map automatically and I
could then decide what I want to do with it.

If that is a direction you are generally willing to go into, I would be
happy to provide mockups, design consultation, and the like. :)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/607
.

[jancborchardt]

Right – the processing power and memory side is an important point. You know best about that.

On small devices typing is indeed more cumbersome – but even more cumbersome is needing to think about what an app wants you to provide. In your example for instance, I typed »i« in the country box and got Italy – but that essentially gave me nothing. I’m looking for a street or city after all. ;) But I can’t just type in a city because it’s strictly hierarchical.

Performance-wise, search could prioritize the locally downloaded data. Then either automatically (or on prompt) search online as well.

Then interaction-wise, the hierarchical categories could be consolidated into a single input. Or just less for now. Continuously improve. At least the separate »house number« selection is a bit crazy and could just be appended to the street.

To take your example with Rome: To get to a street in Rome, say Via Merulana – I would just type »meru…« – 4 keystrokes. From the searchbar. Which is always available on the top.
In the current OsmAnd, the workflow is like this:

1. go to the search
2. go to address search
3. press region chooser
4. choose a region or type (possibly large amount of letters)
5. choose a city or type …
6. choose a street or type …

As you see, it’s already 6 steps, way more than the 4 keystrokes above. But what’s more important than the simple quantitative measuring of the tasks is the complexity which you have to deal with when putting it in. Currently you basically need to fill out an SQL query to get to a result. ;)

And again here is the example of Google Maps – it’s widely used as navigation app and works the same way. I think the ergonomic aspect is less a question here.

The interesting thing is as you mention: How can we make it performant?

• search locally cached data first
• cache and prioritize favorites
• cache and prioritize recent searches
• prioritize points of interest, also because they might be »good enough« results in a street
• if we have some kind of inkling on the location, prioritize nearby locations
• if we have contact’s addresses, prioritize those
• lots more ways, improve database queries, stuff I don’t particularly know about and you are experts in. :)

[jancborchardt]

(Forgot to mention: For the »Via Merulana« example I used google maps – they even take into account the whole world, not even locally cached maps. So when typing ~four letters already puts the street you look for in the ~5 suggested items, that’s better than drilling down.)

[sonora]

Yes, all good comments! As I said, there is potential for improvement here,
and your thinking goes in the right direction.

Interestingly, I immediately used maps,google.com and typed "meru". What I
got was:
Meryua Utara. Jaklarta Indonesia
Meru Kenya
Pekan Meru Kang Serangor Malaysia
Meru France
Meruoca Ceara Brazil

I did get hits in Rome only after specifying "Rome", or"Italy", or
pointing google maps to show Italy and using their "apparently location
aware" content somehow. So all in all it did take me as many
clicks/keystrokes to find the street in Rome that in OsmAnd.

So you see it is not trivial. And we need to do some thinking what the use
cases are. True that most restaurant searches would be needed in your
immediate vicinity. But if you look for hotels for planning a vacation, or
for an address 200km away for a navigation, things are different.

Just to make sure: You are aware that the hierarchical search can be
aborted (via show on map, directions, etc.) at any point, you do not need
to follow it through to street or even house number, right?

And also: Your last address search is always cached, so if you live in
Rome, and all your searches are in Italy/Rome, you an leave these 2 buttons
unchanged and always directly start typing the street name.

But you are right: Combining the POI and address search in an meaningful
way must likely be a project objective for us some time soon.

Best,
Hardy

On Tue, Apr 15, 2014 at 11:15 PM, Jan-Christoph Borchardt <
notifications@github.com> wrote:

(Forgot to mention: For the »Via Merulana« example I used google maps –
they even take into account the whole world, not even locally cached maps.
So when typing ~four letters already puts the street you look for in the ~5
suggested items, that’s better than drilling down.)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/607#issuecomment-40535393
.

[jancborchardt]

Interestingly, I immediately used maps,google.com and typed "meru". […]
I did get hits in Rome only after specifying "Rome", or"Italy", or
pointing google maps to show Italy and using their "apparently location
aware" content somehow. So all in all it did take me as many
clicks/keystrokes to find the street in Rome that in OsmAnd.

Right, let’s not get stuck in the example. Maybe they improved the search algorithm, or or or. (I got the road as 5th suggestion after typing »merul« in an incognito tab, with the current/old maps which has the permanent sidebar.)

Still, the point is not about the pure keystrokes, but about the cognitive load. The 5 keystrokes of the road are all one and the same thing – the road name. When drilling down from the region to the street name though, you need to think a lot – first the region, then the city, then the road. Even if it turns out to be the same or less actions by the number (which it likely won’t though), the cognitive load is much much higher.

So you see it is not trivial. And we need to do some thinking what the use
cases are. True that most restaurant searches would be needed in your
immediate vicinity. But if you look for hotels for planning a vacation, or
for an address 200km away for a navigation, things are different.

Yes. For that the search and suggestion backend has to be solid. Of course that is more something which can optimized in code.

Just to make sure: You are aware that the hierarchical search can be
aborted (via show on map, directions, etc.) at any point, you do not need
to follow it through to street or even house number, right?

Yes I am aware of that. The thing is that only the region is not very useful, and only the city is also not very useful in most cases. But I am barred from typing in a street name until I specified the two above.
In other words: People expect a maps app to know in which country/city a certain street is. And if there are several results they are comfortable choosing from one. But needing to choose before blocks your flow.

And also: Your last address search is always cached, so if you live in
Rome, and all your searches are in Italy/Rome, you an leave these 2 buttons
unchanged and always directly start typing the street name.

Yeah, that would be the same for the search bar on the map view then. Your most searched/used cities and streets would be remembered in the backend and prioritized. As well as when clicking the search field, it would show the latest searches.

But you are right: Combining the POI and address search in an meaningful
way must likely be a project objective for us some time soon.

All 6 different searches, yes.

[jpotterm]

For whatever it's worth, I prefer the heirarchical approach on mobile devices. It allows OsmAnd to give meaningful suggestions in real time because it greatly limits the options. And since OsmAnd saves your previous query, I almost never need to enter the country or region because it's usually correct from the last search. So that leaves you only having to type the street like you desire.

Not to say the experience can't be improved, but IMHO the hierarchical approach is not the problem. All offline GPS apps I have seen do it that way, so people are used to it.

I agree that the online search needs to be more prominent. At the very least it should have a different icon (maybe a globe?) I think it should also be moved to a different place. To me it would make a lot more sense to put it in the top bar as a sibling to POI and address search. So you could instead have POI, offline address search, online search, etc. The bottom bar that it's currently in has actions for what to do with an address once it's been selected and I would never think to look there for a different way to search. If it can't go in the top bar, then it should at least be some sort of toggle (maybe a radio button or checkbox) in the content area of the address search.

Another thing that was very confusing to me was the "Search villages/postcode" button. It feels strange that in order to search for a village you have to start searching for a city and then press that button. But I can't think of a really good solution. Would it be incredibly slow if you just lumped villages in with the city search? Sometimes it's hard to know if the thing you're searching for is considered a city or a village.

Hopefully that's useful feedback. OsmAnd is by far the best OSM app. Thanks for the incredible app!

[jancborchardt]

First off I agree that OsmAnd is a great OSM app – that shouldn’t prevent us from making it better though. ;)

The main question is: Why is the online and offline search different at all? Both should work the same. Whether I am online or offline should not differentiate the search experience, only the results (because not everything is available offline).

Especially on a mobile device, the amount of tapping you need to do with this hierarchical search can get annoying. Instead of selecting Germany, then Munich, then Rotkreuzplatz, why not just enable people to write it all out »Germany Munich Rotkreuzplatz«?

OsmAnd surely is good enough software that it can notice Germany is the country, Munich is the city and Rotkreuzplatz is the street, right?

[jpotterm]

That's a good question. I think the reason they are different is the suggestions. Because offline mode has suggestions, and using a hierarchy allows you to get much better suggestions. So instead of typing out all of "German Munich Rotkreuzplatz" you could just type "Ge" click Germany, type "M" click Munich, type "Rotk" click Rotkreuzplatz. That's much easier on a phone than typing the whole phrase out. It's less tapping and it also confirms along the way that you don't have any typos (instead of waiting till you press search to find out you had a typo).

But in online mode, at the moment, there are no suggestions. So since you have to type the whole phrase out anyway it's more natural to type it the way it is usually written.

But if we could get suggestions in online mode, then I agree that it'd be really good to combine both views. If that happened I think the combined search should be similar to the current offline search.

[jancborchardt]

Of course for the single input, you would just have to type in »Rotkr…« (some characters more or less) and would get some suggestions which would include the Rotkreuzplatz.

The performance of this could be improved by looking first at:

• where you are
• where you searched last, and where you searched often
• which countries you have downloaded
• where your favorites are
• suggesting addresses from your contacts
• etc.

[Kjarrval]

Some input based on Iceland:
Some houses (with housenames only) aren't assigned to any specific street. Some of them are only known as [housename] in [municipality/county]. In essence, they wouldn't be searchable in Osmand using the offline mode in the current situation.

Two ideas for solutions in the address search tab:

1. Enable people to directly select a building without selecting a street. Only buildings with housenames would be displayed. People would still be forced to pick a city first.
2. Add a street to the street selection list where all housenames go into, and it would be the first street on the street list.

The technical aspect would be roughly the same. In the data file, all buildings with housenames would be assigned to a street (within each city) with a specific reserved name. In idea 1, if people pick a building without picking a street first, Osmand would assume this street was selected and display the entries. In idea 2, people would be forced to specifically select that street first in order to choose the building with the housename.

[Mannshoch]

A little imput from me.
Many times I'm searching Adresses from a Directory app.because I do not have anymore Googlemaps on my device I tell them to view the adress on OsmAnd but this not work.

I now that Streetnumbers are missing in my region. I would be glad if Osmand is not able to find my streetnumber it will mark the street form the last entered number until the next or street end and prompt the Question to place the Number. I will help then and place this new Information for others on it.

[vshcherb]

Thanks for input, This is going to be changed.

[jancborchardt]

@vshcherb can you let me know in which way it’s going to be changed? I’d be happy in assisting further to improve the design of OsmAnd.

[vshcherb]

Please take a look at POI Search latest version or if possible at iOS port