User Test: General problems on the search results
publié le , mis à jourDécrivez votre problème, votre suggestion
Firstly thanks to @laem and all the team. I really enjoy with the app and suggest to everyone around me. Regarding the ticket, I have checked the previous issues about search functions and I will cite them below as well. Previously, I had mentioned #1863 some generic experiences but mostly on UI side of the search function.
Searching matching words as category in English
Categorical searches are working quite fine in Cartes (maybe the best so far). There were some issues mentioned #646, #2480, but I think in French that returns well to the proper category.
In English (didn't test other languages), however, it provides inaccurate results. In below example I search "coffee" instead of "café" so the results indexed from the US or Iraq appears, although the "here" option is selected and "English" is a selected language.
Another example with "crêperie" this does not return correctly, although it is in French.
So if I go in categories and choose crêperie, it provides excellent results:
However, if I just type "crêperie", honestly I find much easier to directly type. It finds only one, and it is not even listed as first.
- #2082 Previously referred also double words like "italian restaurants" also do not work well compared to searching only like "italian"._
- #1802 "Leclerc" doesn't return results it supposed to be "E.Leclerc"'
- #1723 The zoom level is effecting the results, there are some streets do not appear. Also adding the name of the city provides more accurate restults although the user location is in the same city.
- #1232 The street search returns many result points in the same street with different icons
Including non-local options while "here" option is selected
In this example I chose a known Coffee shop chain. It appears after finding the local options it completes the list with non-local places.
Suggestion of closest options are default even they are not in the map
It is not necessarily a bug/issue but when I want to check a location in my map, even it is not existed in the frame my search results provide the closest, instead of returning null. Actually that had been mentioned previously in #2410 but the ticket seems still open.
I understand returning null results, in digital services highly scared, which likely associated to incapability of service. But in fact as a user that is quite useful to know by there is no result, better than having arbitrary results. Additionally, providing null result in the selected map pushes users to choose better frame which makes them more attach to the map I believe. As a solution suggestion "here" option can propose the search results on the exact map frame and "everywhere" which includes the closest ones. Or, like the other applications there shouldn’t be “here” and “everywhere” options but always providing proximate results.
No hierarchy in the closest suggestions
Again from the same Starbucks example, the closest location suggestions have no hierarchy of distance, that would be great. If I search "Starbucks" from Grenoble, I would expect the options from Lyon to be listed much before than The US and Japan.
Request for distance and open/close information (if available) like CoMaps
Above I had mentioned that "crêperie" doesn't appear when search, in mobile as well. But another point is I really would like to have distance information and open/close status of the shop. I am not sure how feasible to do that. But actually that exists in Cartes when I choose through categories. So that would be also great to add to each of the results returned.
Thanks a lot for your time !
Système d'exploitation
Mobile: IOS / PC: Windows
Navigateur
Mobile: Vivaldi / PC: Zen
laem
You've nailed lots of problems that we've described elsewhere 👍 It's a good recap, thanks !
The main thing here is that Photon is not good enough. Hence the "leclerc" not finding e.leclerc, or not being able to translate "coffee" to "café". Hence our large layer of client-side category search to compensate. We don't compensate enough indeed. There are lots of smart things to do to provide a way better experience :)
Auto-triggering the "crêperie" category search when the hit is perfect is easy to do. It doesn't solve lots of usages, but it solves a main one !
hyrokc1421
Thanks a lot @laem, yes that could be enough then we can close the isue in anyway the point was providing a comprehensive feedback. And I see it is most likely due to geocoder. So please allow me to ask, you guys plan to continue with Photon, am I catching right? Or do you consider to change the geocoder in future?
Everything's open, as long as we can self-host it. Most geocoders are worse than Photon : the expect exact matches. Photon does some fuzzy matching.
We'll need to integrate Openadresses one day. We've done it for France and people are happy to find all the existing official addresses.
But that doesn't solve regular places search at all.
etienneJr
photon also has several filter options we do not use yet: https://github.com/komoot/photon/discussions/1092#discussioncomment-17403471
I have an idea but not sure if that's possible. Adding city name automatically when "Here/Ici" is selected in the search query. I find adding city name works much more accurate to find nearby shops, that's why I add Grenoble all the time, like FNAC Grenoble. If I do not add the city name, a shop from Lyon appears in the results, although I have "Here" selected.
So do you think, it is possible to repurpose the "Here" option to add city name automatically?
@hyrokc1421 wrote in https://codeberg.org/cartes/web/issues/2704#issuecomment-21539579:
So do you think, it is possible to repurpose the "Here" option to add city name automatically?
Did you notice the new filter per bbox? It a the 3rd option after here and everywhere. @laem added it a few days ago. It will do what you describe : get results only in Grenoble (in fact in the bbox you chose once for all), not close to grenoble (what the here option does) Check this message and the next one in the thread https://mu.social/profile/cartes.app/post/3mtbv46a4f72x
Thanks @etienneJr, apparently I missed that update. I have tested right now. Although I have selected the region it didn't much affect my results. Still I have the same problem, having suggestions from other cities while I have clicked on "here" option. The irrelevant results disappear only when I wrote the city name.
esmenard
@etienneJr wrote in https://codeberg.org/cartes/web/issues/2704#issuecomment-21547511:
Did you notice the new filter per bbox? It a the 3rd option after here and everywhere. @laem added it a few days ago. It will do what you describe : get results only in Grenoble (in fact in the bbox you chose once for all), not close to grenoble (what the here option does)
It works only in a bbox that is registered as a favorite, could there also be an option to search in the current bbox?
Sorry, my mistake. I now understand how it works. In this way, yes, all my options appear as I wish. That's also great, once I have chosen the bbox favorite option becomes my default. So I don't need to go to bbox and choose my favorite to limit the search results.
Do you want me to tag the issue as resolved? Or wanna keep it open because all the search problems have been summarized in this ticket.
No let's keep it open. Lots of problems still are present.
So do you think, it is possible to repurpose the "Here" option to add city name automatically?
To be challenged, but I'm afraid this only works for places that have the city name as OSM tag, or that have been correctly reverse-geolocated by photon.
Whereas the "search here" will be geographical (by distance). Also note that cities are often intertwinned. E.g. Saint-Jacques-de-la-Lande is in big part "inside" Rennes.
Of course, I agree it was my particular case, I believe there much more complicated scenarios. Thanks @etienneJr, since I have learned bbox option that solved my problem. Now I do not deal with Here, Everywhere options :)