I dislike when actions that are typically built into a web browser or OS are re-implemented by individual sites in javascript. It creates an inconsistent experience. I don't want a scrolling behaviour that is unique to your site, even if it's cool. I want all pages to scroll the same way. If I "pull" on your site, I am trying to scroll up a little bit. That is what a "pull" means on every other site when viewed in my browser, so that is what I expect to happen, not a refresh. If I wanted to refresh, I would have used my browser's built-in refresh button.
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.
If it makes sense to your users, it makes sense to use it. In any case, I have no problem with the creation a library, even if I may not like the functionality it provides.
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.
on mobile chrome, pull to refresh is already a thing. I turned it off, since i don't want to accidentally refresh a page i didn't intend to, just because i scrolled up too fast.
The refresh button is there for a reason. Web devs need to stop making gestures mean different things in different contexts.
I love pull to refresh in Chrome. Considering I usually hold the bottom of my phone with one hand, if I had to move my hand to open the menu and click refresh every time, I would use a different browser.
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).
> 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
- 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
> 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)
Wait, so pull to refresh is more discoverable than a circular arrow?
There's also accessibility. If I'm using a screen reader on Mobile such as VoiceOver or TalkBack, how do I pull to refresh? It would way easier if there was a button.
> 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
Everyone knows how to refresh a webpage on mobile as well though? Why not add in websockets if users need to refresh that often inside a mobile browser?
iOS’ Safari has a refresh button at the right of the location bar too, but I guess you’d prefer to "refresh" only the relevant parts of the application; not the full page. Am I missing something?
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...
The worst offender I've found is websites that hijack the swipe gesture, either on a touchpad or on a touch device. Instead of going back in the browser, it'll go to another page on the site as if you wanted to swipe to the next article.
I actually disagree. But with a caveat. That is, this introduces atypical behavior to desktop. However this would make a great shortcut to a standardized button on the screen. This has application in certain web-apps.
Pull to refresh is standard behavior in chrome, but not in firefox. It's very handy on mobile, so I install an extension to provide it on FF. But I can understand you may want to provide it to your user to make the experience better.
However, unless you can detect that the feature is available or not, this may very well be buggy on browsers that have it already.
Agreed. One of the worst things that websites implement is overriding the history. In particular, "listicles" are doing that. When you go back, it goes back to the previous list item in the text even all the content lies in a single page app.
Wouldn't this only work once you get to the top of the page? I don't imagine it would be implemented in such an awkward way that just by scrolling up it would refresh, usually you need to be at the top of the element
I get the sentiment, but I would say that scroll jacking is a lot worse than pull to refresh jacking. Also just realized I'm not sure this script would work too differently if your talking about a desktop Webapp.
These articles are talking about the reward loop of getting new content every time you refresh, and you're misrepresenting that to presumably make a point about pull-to-refresh, which is completely unrelated.
Article [1] doesn't mention pull to refresh; Article [2] mentions pull to refresh in the context of email;
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.
In a bank robbery, if you are driving the getaway car you are not techinically the cause of the robbery, but you sure as hell enabled the robber to get away clean.
Wow, hadn't realized it was a dark pattern. After thinking it through though, is it really a bad way to update a page? I realize we have the tech to easily dynamically update content without user consideration, but that ends up leading to people clicking on the wrong thing (the order suddenly changed on them as the finger went down).
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?
It's a pretty big misrepresentation to claim that pull to refresh is a problem, when the core of the issue the "dynamic content" as you put it. It's like blaming weight problems on good cutlery.
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.
I guess I'm the only one that absolutely loathes pull to refresh. I try to scroll back to the top to reference something and loose my work whatever comment I was in the middle of typing, or I lose my place, because i didn't want to refresh and now the old content is gone. happens several times a week on iOS chrome >:(
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.
You're not alone - I hate it too. I always think this problem is easily solved as well. Since touch gestures can already account for "one finger or two". A two finger vertical gesture should refresh (because horizontal zooms), a one finger gesture should scroll.
Counter-Counter-Argument: Refreshing a page is probably as or less common as needing to zoom a page. Scrolling is far more common than needing to refresh a page. Breaking one-handed scrolling in order to allow for one-handed refreshing seems like a poor choice. Especially when my browser already has a built in refresh button that's easily accessible with one hand. My mobile browser does not, however, have a built in scroll-bar for one handed scrolling in the event a site breaks scrolling in favor of refreshing. In fact, since the scroll gesture is such a standard websites are often designed around not having a vertical scrollbar for mobile because it's pointless... that is, unless they break scrolling.
I find the concept convenient. I find the execution terrible.
You're mentioning something about zooming with two hands. I exclusively use one hand to browse, and I use double tap drag to zoom. The thing I find most annoying is moving my hand from the bottom of the screen up a bit to reach the navbar, whether to swipe to move to a newly opened tab, to close a tab, or to enter something in the url. Usually though, those actions only take place when I am "done" on a site, not in the middle of using the site, like refresh.
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 exclusively use one hand to browse, and I use double tap drag to zoom.
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 scrolling up with shorter, faster flicks then. In iOS Chrome you have to already be at the top of the page and then pull fairly far to cause a refresh.
Hey! One of the main devs behind pulltorefresh.js here. Initially we created a small script to simulate the pull to refresh gesture because in one of our user experience sessions, the users were having trouble with how to reload the information shown.
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.
An improvement to your demo would to explain this touch emulator and maybe have a checkbox toggle it. My first impression was "this is breaking desktop browsers, I'll never be able to use this".
It might be losing favor amongst people that care about design and functionality. But it is implemented for another purpose; to create an addictive habit that keeps you on a social media platform.
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. :-)
I think my own preference would be to make a web app that doesn't need to be manually refreshed at all in normal operation, via some simple polling heuristics (and careful use of 304s on the server to minimize the total traffic).
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.
do a search on thingiverse.com and then scroll down. if you search a big enough topic every 20 or 30 seconds as your scrolling it jumps up and you lose your place.. i'm not sure how to avoid this feature, but it is truly annoying
Yeah that's one of my biggest gripes with Quora, you can totally lose content that you wanted to read or respond to through any act of carelessness that leads to a page load or even the page bugging out.
