Kore
Kore copied to clipboard
Too easy to refresh local list of artists, albums, etc. by mistake
Hi there,
Context: I have a rather large collection of music, so the Kore's local list of artists takes quite some time to build/refresh.
Issue: While the material design concept of pulling from the top of the list to refresh a list is aesthetically pleasing, and makes a lot of sense for lists of entries that are often updated and are in chronological order (ie: Twitter feed), it doesn't make so much sense in our context: we don't really browse to the top of the list and then want to see if there's anything new. Worse, it's happened to me twice recently as I was scrolling up and down my list of artists to involuntarily refresh the list. (This also puts Kore in that weird in-between state where it takes a long time to finish, but if I go into an artist and interrupt the update, I end up with missing artists and/or empty artists, so I'm just left waiting)
Proposed solution: I think it would be better to have the refresh option as a dedicated button. Two options I can think of for that:
- put the refresh icon (set of revolving arrows or whatever) next to the magnifying glass and remote icon, top right of the music screen
- or put refresh icon directly next to the word Music, in the side pull menu, so that 90% of the button goes to the Music screen and 10 % refreshes the content of the Music screen.
Sorry for the lengthy explanation and thanks for considering this issue :)
cheers
axe
+1 Happens to me too very often.
I don't think you need a separate button. The way to pull down as currently implemented is awkward and not best practice in mobile apps. In standard controls that provide this with a pull to update, a flick for scrolling should not activate it, only a drag. In addition, it should show a visual indication of the end being reached and start to "stretch" and not invoke the reload until it is "stretched" some distance. This allows the user to let go and not have it refresh/reload. The current private implementation does neither and so going to the top and not being sure whether one is at the top can easily result in invoking the reload.
I agree and I created an implementation I am currently still testing and cleaning up. If you are familiar with building an android app from source you can get it at https://github.com/poisdeux/Kore/tree/issue%23103 Would be nice if you could test it as well. It adds a refresh icon to the toolbar and animates it while a sync process is in progress.
After playing with the refresh icon in the toolbar I must say I do not really like it. Especially the animation draws too much attention away from the actual app. My proposal: adding a Refresh option to the overflow menu and disable the slide refresh option. When user selects refresh from the menu it will start the refresh animation in the list just like with the current slide refresh action.
@axelsimon I see your point. I'm not totally convinced but i agree that it can be a nuisance. I didn't understand your second option, but it doesn't look like it is something standard and usual in Android. Putting an option in the top right menu is the easiest and standard way to do it, but, like i said, i'm not convinced that it is better than the pull to refresh.
Furthermore, if we put the refresh icon on the top right menu, the remote icon would probably need to be hidden in an overflow menu (putting 3 icons in the top row is too much - search, refresh, remote).
BTW, if during the update you go into an artist/album/whatever, the update should continue to run, and should end. You won't see the success message, but it won't stop and the list will be updated afterwards (if you exit the list screen and reenter).
@gvkt Not sure what you're talking about, as the pull to refresh control being used is the standard one, so if you have any complaints about it, you might redirect them to Google.
If you are using the standard Android control SwipeRefreshLayout, the later versions of this library has the
setDistanceToTriggerSync(int distance)
method that allows you to set how much the layout has to be pulled down before it triggers the refresh. Best practices suggest that the greater the cost of refresh and more infrequent the usage, the longer you set this distance, not just the default since applications for this control vary a lot in requirements some of which require it to be very sensitive (lazy scrolling of an endless list, for example)
The above method was not available in earlier versions of the control and made it useless for many applications including this one.
Just experiment with different values for the distance and the feedback icon/color scheme settings and you will find a reasonable range for that value where it prevents almost all of the inadvertent refreshes from swiping to scroll and not painful when you really want to refresh.
A separate button on the toolbar makes this function more obvious (discoverable) because as OP pointed above pull to refresh is not the intuitive action for this type of list (not chronological and not continuously updated at the top). So, it might be OK to leave this in the overflow menu (as it is not used very frequently) for discovery reasons but also have the pull to refresh with sufficiently large distance for the "power users" that prevents inadvertent refreshes.