forecastie icon indicating copy to clipboard operation
forecastie copied to clipboard

Some suggestions on the "location search" UI

Open benji1000 opened this issue 3 years ago • 2 comments

Hello,

I would like to submit multiple UI improvements to the location search functionality.

1) Difficulty to attain the "Search for a city" popup

My issue: the way one user can indicate his or her location (by clicking on the magnifying glass icon) does not seem very intuitive to me. Searching is not something that immediately comes to my mind to perform this action.

What I suggest: here are three ways I would like use to attain the "Search for a city" popup:

  • Replacing the magnifying glass icon by a map marker icon (such as this one, or similar).
  • Clicking on the current city name on the top left of the application.
  • Adding a "Specify location" entry below the "Detect location" entry in the main menu.

It makes sense to me to provide multiple ways to do that, since indicating a city is probably the main thing that people would want to do in a weather app (except actually getting the weather forecast, of course).

2) Difficulty to find a city

My issue: I often have troubles finding a city if I make a typo in my search query or if I don't write the city name exactly as the app would expect me to type it. Here are some examples. Pardon my French!

  • Thonon-les-Bains: can't find it when I search for "thonon" or "thonon les bains".
  • Aix-en-Provence: can't find it when I search for "aix en provence".
  • Chalon-sur-Saône : can't find it when I search for "chalon".
  • La-Chapelle-sous-Dun: can't find it when I search for "chappelle sous dun" , "chapelle sous dun" or "chapelle-sous-dun".
  • ... many more city names with dashes in their names.

In these cases, I get the "Can't find city" toast message on the bottom of the screen. So I guess these scenario come from either small mistakes made by the user (doubled letter typed as one letter, and vice-versa) or omission of characters or terms that are generally not necessary to designate the city in the user language (like dashes or articles).

What I suggest: perform a loose search on what the user typed. I really don't know how it is feasible, or how easily, but that would certainly improve the usability of the app,in my opinion. Also, provide an extended search results page. When I search for "aix", I would expect the search result page to display "Aix", "Aix-les-Bains", "Aix-en-Provence"... Currently, it only displays the city of Aix in France, plus a city with the same name in the USA.

3) Too discreet "Can't find city" error message

My issue: as said above, a user can often get the "Can't find city" toast message when performing the search if he/she is not precise in the query. However, I find that this error message is too discreet: one can miss it. Also, when the search is being performed, the user doesn't have any indication of it: this is especially visible when the user has a slow Internet connection, and a few seconds might pass before getting the result. Finally, the text message could be a little more empathetic.

What I suggest: displaying a "Loading..." or "Searching..." popup or icon when the search is being performed, moving the "Can't find city" text to a bigger popup, and changing this text to "Sorry, can't find this city... Did you spell it correctly?" or similar.

4) Duplicate results

My issue: more often that not, I get a search result page containing the same city multiple times. Clicking on either one provides the same result, but it is quite confusing. "Should I click on the first one or the second one? What's the difference between the two?". I ran this test on multiple cities (Aix-en-Provence, Marseille, Thonon-les-Bains, Chalon-sur-Saône...), and it almost always happen.

What I suggest: de-duplicate the cities in the search results. I guess it would involve understanding why this situation does happen in the first place, then maybe only return one city between multiples results if the multiple cities returned by the search are located within a few kilometers from one-another.

Thank you for taking the time to read this and considering these improvements. Should I have created a separate issue for each one? Feel free to tell me if you would prefer it that way. I understand some of them represent a good amount of work, but the first one seem to be easily implementable, and the top priority in my mind.

benji1000 avatar Sep 02 '20 21:09 benji1000

There's a lot to think about here, at first glance all of it positive/interesting.

robinpaulson avatar Sep 04 '20 05:09 robinpaulson

There are multiple scopes, here (pure UI versus dataset). I'll address the latter.

I get a search result page containing the same city multiple times. Clicking on either one provides the same result

I recently learned (via a mail exchange with staff) that OWM uses GeoNames (map) for locations.

So, it would be sensible to first ensure that the desired cities are not duplicated in the GeoNames data.

Lee-Carre avatar Mar 15 '22 03:03 Lee-Carre