Pull to Refresh.js
boxfactura.com
boxfactura.com
I have to agree with you on most cases: please don't touch my scroll behavior. However, this tool was created because on user testing, we found that for our app, users were having trouble figuring out how to refresh for new information (which isn't a feed, it's just a list of invoices they have received).
Even when most of web users know that clicking the logo will take them to home, interestingly this pattern was not translated to mobile. And even when you have Chrome mobile with a native pull to refresh feature, you have a bunch more that doesn't have that. So we wanted to create a standard: regardless of what browser you choose, it will work the same. And we chose pull to refresh because it's very familiar for our users: we simply say "it's just like facebook" and they get it.
We released this library because even if all browsers had the same gesture, the look and feel would be different, and also, because you might not need to do the default action (reloading the web page), as you might have a SPA that needs to poll the server, while keeping the current page state.
How about putting a refresh button somewhere?
- Screen real estate: we simply don't have enough space to put everything
- It's a responsive webapp: if we create a new button just for mobile, then we'll have to hide it for desktops, which means more complexity and testing
- Icon discoverability: our users aren't tech-savvy, so we'd have to create a new button with the word «Refresh» on it, because they could easily miss it if we use an icon (also: screen real estate)
- Familiarity: pull to refresh is a familiar gesture we can take advantage on, and it's easy to disable on desktop
Don’t you need to refresh on desktop as well?
Wait, so pull to refresh is more discoverable than a circular arrow?
For me, it would still be an annoyance on the web, as it is something that applies to a minority of sites I use. In an app, I would be more open to it.
For older people I know, who have not fully internalised common UI conventions, this sort of thing is confusing. They would only really trigger this accidentally, and then not understand why it happened. The more dynamic and/or non-visible a UI element is, the less they understand it. I do not expect UI designers to accommodate non-tech-literate people in most cases, but it is interesting to observe.
The refresh button is there for a reason. Web devs need to stop making gestures mean different things in different contexts.
Also the refresh doesn't happen unless you pull at the top of the page (easy to avoid if you're looking at the scroll bar).
I initially thought this a bad idea for reasons that others mentioned (primarily re-implementing an existing gesture).
However, it occurred to me that much of SPA development involves doing exactly this, particularly where nav (i.e. routing URLs and handling back/forward buttons) is concerned. Managing these involves hijacking existing browser behavior to supply our app-specific behavior instead. So, overriding pull-to-refresh is consistent with this hi-jacking as you generally do not want the full page to refresh in a SPA any more than you want the back button to take the user out of your app to a previously visited site.
But, I don't think it's a good idea for non-SPA webapps.
All of that said, it also does seem like a notification-type paradigm would be a better UX for the particular use case you shared. But, hey, if your users are happy...
However, unless you can detect that the feature is available or not, this may very well be buggy on browsers that have it already.
Over the years it's grown to become quite satisfying.
Mmm.. dopamine.
[0] https://thebrag.com/truth-facebook-pull-refresh-feature/
[1] https://www.vice.com/en_us/article/vv5jkb/the-secret-ways-so...
[2] http://www.businessinsider.com/ex-googler-slams-designers-fo...
Yes, it's a tool that can be abused in the right (or more aptly, wrong, I guess) circumstances, that doesn't make it a dark pattern in other situations.
There is no dark pattern here; yes social media itself is made to be addicting. Pull to refresh is an intuitive UX pattern that can either assist in enabling the addictive behavior, but it is not the cause of it, not only to be used in that kind of scenario.
So given that an explicit refresh button either takes up screen space or is another action (say full page refresh?) should this really be considered a dark pattern if you're say, in your own inbox?
I find the concept convenient. I find the execution terrible.
I have never accidently refreshed a page using Chrome's pull to refresh, and so I love it. Having said that, if a developer wanted to refresh part of a page using pull to refresh, they would have to be very careful that it is implemented well. This library seems to do it pretty well, and does not conflict with Chrome's pull to refresh.
Anyway, you made the argument that pull to refresh breaks scrolling. I strongly disagree.
I've seen some pretty shocking broken scrolling, but modals that prevent scrolling (and have js errors which prevent closing) are usually the cause. I've never see a "pull to anything" gesture break scrolling what-so-ever.
I also browse exclusively one handed, but not necessarily "one fingered". I grip my phone between my thumb and other three digits and use my index finger for any two finger gestures while my thumb is stationary. This allows me to pinch zoom with one hand. I do this because sites so frequently break one fingered gestures - not really "by choice" but "as a workaround".
Try doing the double tap zoom on the Reddit home page. You need to be highly selective of where you double tap, otherwise it treats it like a normal click and you're taken to a comments section, an article, or an external image/video. This is either a bug in Android's double tap timeout or with Reddit breaking the functionality. I can only double tap zoom if I'm very careful to tap in white space which effectively only exists after a title or between the "comments" and "..." (more options) items beneath each post.
>I've seen some pretty shocking broken scrolling, but modals that prevent scrolling (and have js errors which prevent closing) are usually the cause. I've never see a "pull to anything" gesture break scrolling what-so-ever.
I was frequently unable to scroll on Reddit mobile (not the app) because Reddit thinks I wanted to do a page refresh. It's enough of a problem that I simply didn't scroll back up anymore when browsing. It must have been a common enough issue because the gesture had been removed at some point.
Try tapping top middle of the screen.
Where appropriate [eg: Tweetie, where it started; mail; youtube; facebook], you've got a reverse chronological listing, and 'pull-to-refresh' is more explicitly 'pull-to-put-new-content-above-the-current-page'. It's the other side of an infinite scroll.
If it destroys the current page, it shouldn't be on a scroll-up.
A few months later we decided to open source it and on december 2016 it hit HN front page, glad to see it again!
I'm here to answers some questions, if you have any.
I guess it just injects the script in every page, but it works nicely, just like Pull to Refresh in Chrome.
Just giving an honest first impression :)
Or as stated before, try opening the demos.
It may not be apple's fault, but many apple fans incorrectly think features originated at apple, like mobile fingerprint scanning. My daughter thinks apple invented everything. :-)
If something is continually refreshing you would lose your context without doing anything. It would be disorienting if you scrolled down a little, scrolled back up and found the thing you were looking at was no longer there.
You could then refresh to remove the grayed-out items, but in practice you wouldn't need to.
Another approach is to use a "hold" button, which suspends all external updates.
Talk about a bug being called a feature. This drives me crazy.