I was on a wavering network recently and this lead to sluggish loading of items in Nearby. As I was a little impatient I tapped on the 'Refresh' icon to see if that helps in some ways. Instead of the nearby items I expected, what I got was the "Location has not changed." toast. I don't think showing that toast when there's no items in the Nearby list is the most informative thing we could show to a user. There's something better,
So, we have to handle this scenario correctly.

Not sure if related, but recently I had the following problem:
@nicolas-raoul Seems to me that it goes into a separate issue. Of course, only if Fake GPS had did it's job correctly :)
Of course, only if Fake GPS had did it's job correctly :)
Maybe, the commons app didn't fall to it as prey ;)
Actually I experienced both cases and agree with @sivaraam about displaying more informative message like "Poor network connection" etc. Or course firstly we need to recognize what is the cause reason of this latency.
For other issue with FakeGPS I will create a new issue.
Or course firstly we need to recognize what is the cause reason of this latency.
Ah, it's just one you would expect, sluggish network. The network speed was wavery as a consequence of the environments in which I was at that time.
Yes, I agree that the toast is not informative enough. The purpose of adding the toast was to avoid page refresh if the refresh button is clicked without the location getting changed. It should ideally be aware of more states, where page has not loaded fully and show meaningful feedback. Having no feedback might prompt the user to click on the toast multiple times.
I can start working on this. I'll use it as an opportunity to introduce myself to everyone working on the project :)
@rjb2179 It's yours, please let us know about your progress once in a while :-)
@rjb2179 It's good to see that you're willing to work on this. Just to be sure you're on the right track, could you briefly describe what you're about to do?
@sivaraam
If the location has not changed, then we don't want the user to continue refreshing. If the page is not loading, the user may be tempted to continue refreshing. I'm going to figure out how to make the app "aware" that the page has not yet loaded, and show something like "Hold on. Page still loading" or "Poor network connection."
@rjb2179 Nice idea. But I think it would be better to disable the refresh button when nearby items are being loaded and enable it only after the items have been loaded successfully or when loading fails. That would be better than allowing the user to refresh when the items are being loaded.
@sivaraam OK, I'll go ahead with your suggestion.
@sivaraam Do you think it is enough to replace showLongToast(...) with return? This way refresh will be disabled until Nearby "realizes" that the location has changed.
/* from refreshView(), NearbyActivity.java */
if (curLatLang != null && curLatLang.equals(lastLocation)) { // refresh view only if location has changed
if (isHardRefresh) {
ViewUtil.showLongToast(this, R.string.nearby_location_has_not_changed);
}
return;
@rjb2179 yes it would prevent the toast message being displayed. However I think this discussion requires more. Without the toast message it would be even more frustrating for user, clicking refresh button, see no toast and nothing happens.
I think most important part of the fix is detecting when nearby places aren't loaded and informing user accordingly.
And @sivaraam I am not sure whether it is a good idea to disable refresh button if location has not changed. For a scenario with an empty list (due to network issues) user can click on refresh button and see "bad network connection" message instead of "location has not changed message", and result would be a happy user.
Additionally, we already have onLocationChanged refresh view logic. So why do we have a refresh button then? (probably @misaochan knows, she worked on this). If the purpose is handling the situations onLocationChanged doesn't work, then we can't disable it. If there is no purpose at all we should remove it already.
I think we can use our refresh button with the purpose of reloading attempts for empty lists. So that user can click and see "poor connection message", remember the happy user. Or only option is to set a timeout to display "poor network connection" to the user.
I agree with @neslihanturan . Disabling the refresh button while it is loading would still be an improvement (which @rjb2179 can work on), but we probably also need to have a discussion on the refresh logic in general. I do not think the toast should be removed for the time being.
I am not sure if the refresh button is still needed in our current state. :)
@rjb2179 Sorry, but I'm not well acquainted with the code base to help you with this. But on taking a cursory look it seems that replacing that toast with a message results in the toast never being shown. Also it possibly would not disable the refresh button. It would just prevent the toast from being shown. That doesn't seem to be what I was suggesting (maybe I wasn't clear enough :( ).
And @sivaraam I am not sure whether it is a good idea to disable refresh button if location has not changed.
Just for the sake of clarity, I was just suggesting to disable the refresh button when the nearby locations are loading not when the location have not changed.
Additionally, we already have onLocationChanged refresh view logic. So why do we have a refresh button then? (probably @misaochan knows, she worked on this). If the purpose is handling the situations onLocationChanged doesn't work, then we can't disable it. If there is no purpose at all we should remove it already.
I think we can use our refresh button with the purpose of reloading attempts for empty lists. So that user can click and see "poor connection message", remember the happy user. Or only option is to set a timeout to display "poor network connection" to the user.
This thing makes me think. If as @neslihanturan says we have the logic for refreshing the location when the Nearby location changes and the refresh button doesn't serve any useful purpose currently then are we doing the wrong thing by not allowing users to refresh the nearby items when the location has not changed? I think that because, currently the only use(ful) case I could think of for the "Refresh" feature would be that of a person seeing that a popular place in his locality is not listed as a Nearby location and takes immediate action to add it[1]. After successful addition he then "refreshes" the Nearby locations to see if his change has effect and the previously unknown location is currently being listed. He's then surprised on seeing the "Location has not changed" toast. So, he has to re-locate -> refresh Nearby -> re-locate back -> refresh Nearby to see if his addition was successful (or better use Special:Nearby or something). That seems to be a lot of work in place of a simple "refresh".
So, should we allow users to refresh regardless of the previous location and re-fetch the contents each time and inform them (probably during the first time) that "Nearby locations would be automatically refreshed when your location changes." when they refresh and their location hasn't changed?
I guess this scenario would happen to me rather often after Wikidata linking becomes available in the app:
The ability to refresh even if my location has not changed would, in this scenario, be very useful and also quite satisfying (I can feel that my uploads have a direct impact towards documenting the whole world)
The ability to refresh even if my location has not changed would, in this scenario, be very useful and also quite satisfying (I can feel that my uploads have a direct impact towards documenting the whole world)
Seems my theory really did meet practice. :-)
Just since we are trying to define our refresh strategy, I will share an idea comes to my mind. Actually it could be great if we can display differences between markers when user refresh without changing location. Ie. with a basic toast message "You won't be seeing x, y, and z points in the list since they have photos now."
@neslihanturan The idea of showing a difference explicitly when the user refreshes without changing the location seems to be a nice one but listing the names doesn't seem to be. It might be hard to read the names of the location in the toast and to immediately identify them. I could see 2 alternatives:
Visual distinction using animation: If the location currently visible in the screen has got an image, we could show the map marker to drop into the map and disappear or make the list item fade away and the make the items that follow it to take up it's place. This requires that we dynamically update the list rather than completely refresh it. Needs a lot of work.
Snackbar without much info: Or simply, we could show a snackbar that reads like, "3 locations got images since the last update". We could also give a secondary option that allows the user to see which locations got images. The locations that were updated could be listed in another screen or as a fragment that pops from the bottom of the screen.
@sivaraam Snackbar sounds good to me:)
Has this been solved?
Has this been solved?
I guess this has become obsolete with the new Nearby UI ??
Most helpful comment
Maybe, the commons app didn't fall to it as prey ;)