Pull to refresh is an anti-feature IMO. It makes me lose work all the time.
I'm entering something. I need to reference something else off the screen. I drag down to see the thing off the screen. I pull too hard and ... the page is refreshed and I've lost my work
Please do not use pull to refresh on your site. And, if you're a browser ux designer please remove it. It's arguably as bad as using backspace for "previous". Possibly worse since most people have no need to refresh and those that do have other ways to do it.
> I'm entering something. I need to reference something else off the screen. I drag down to see the thing off the screen. I pull too hard and ... the page is refreshed and I've lost my work
That's not an anti-feature, that's poor UX. If you're entering data into a form that might get lost, the UX team should add an event that checks if you're trying to go somewhere else (or reload), to confirm whether that's the action you want to do.
Your argument against pull to refresh could be the same for the reload, back and forward buttons in your web browser. Also, against the URL/search bar, because it might lose your progress.
And all is fixed with a confirm() on the unload event, and it has nothing to do with the pull to reload feature.
By 'pull too hard' I assume that you mean scrolling back to the top. At least on iOS tapping at the top of the screen performs a scroll to top. Knowing that you'll likely never accidentally pull too hard again.
While it works quite nicely, it's maybe not a good idea UX-wise to use it on general websites, as it overrides native browser behaviour (at least for some mobile browsers). For example, I hate when websites (on desktop) override keyboard shortcuts like Ctrl+F or F5, or prevent the default right-click context menu in order to keep me from downloading an image.
For HTML/JS apps though it's a whole different story and might help giving it much more native look and feel.
I agree with you, I also hate when websites hijack standard keyboard shortcuts. Altough I don't see this being the case: as it requires touch events, and even if you're on a touch-capable laptop or desktop PC, it won't override much (maybe the native pull to refresh from Chrome, at most).
Also, what I said in a previous comment: maybe you want consistency across browsers/platforms or branding, customizing how it looks. And maybe you don't want to refresh the whole page, maybe just one section calling a JSON API, or perhaps you have a heavy job that requires a worker.
This library was born due to other existing libraries requiring to modify the layout's markup. Since we mostly use the flexbox trick to create a sticky footer, this would have required quite a rewrite.
The focus on PullToRefresh.js is to manipulate the DOM and add the elements programatically, and allow its own proportions to push down the content.
i was hoping this was a library that would help me to disable pull to refresh. Anyone know of a good library that can help to disable this in browsers?
Pull to refresh on mobile chrome or safari is really terrible ux for web apps. It's ok for content sites but if you have an app that you want to behave like a native app it's really terrible. A good example is maps.google.com. Even if you install it as a home screen app it still has the stupid pull to refresh gesture in chrome.
I wish there was some way to disable it in browsers. I have tried many things like position: fixed or overflow-y:hidden but these have other side effects like preventing the keyboard from repositioning the window in chrome or safari.
In general if a web browser overrides any touch gestures they should be able to be disabled by the page without having to handle every touchmove yourself.
I don't think you need a library for that, it's just a few lines. I'm currently a little busy, but there's one touch event that disables those «features» (can't remember which).
I'd suggest you to download the library and delete some of the lines for the callbacks on the touch events, maybe you can isolate it and figure out what is achieving that result.
Does anyone work with Ionic framework? Would something like this be a good replacement for their 1.x pull to refresh implementation? The one that comes with Ionic is a bit buggy and I'm looking to swap it out with another option.
I'm not familiar with Ionic, but thanks for the compliment! (Implying it's less buggy haha). I'd love it if the library can be in it. Maybe open a PR/issue?
That's actually a feature, at least on mobile. Chrome has its native pull to refresh.
The use case we're aiming with this library is that not always you want to refresh the whole page; sometimes you want to update just one section of the app (think Gmail), do something deferred with a worker, or set a timeout.
Also, you want to be consistent across all browsers/platforms, and maybe add a little touch of personality or branding [1].
So, while I agree with you it should be standard, and maybe it should have an API, it has to be flexible enough for every and each thing you want to achieve... so you'll need a library, and we're full circle.
Thanks! Yeah, it's the same with the native pull to refresh feature on Chrome; it is overridden when the site has certain touch events, as there's no standard to prevent the default behaviors. I guess it's the same with Safari, which I imply you're referring to.
[+] [-] greggman|9 years ago|reply
I'm entering something. I need to reference something else off the screen. I drag down to see the thing off the screen. I pull too hard and ... the page is refreshed and I've lost my work
Please do not use pull to refresh on your site. And, if you're a browser ux designer please remove it. It's arguably as bad as using backspace for "previous". Possibly worse since most people have no need to refresh and those that do have other ways to do it.
[+] [-] rsoto|9 years ago|reply
That's not an anti-feature, that's poor UX. If you're entering data into a form that might get lost, the UX team should add an event that checks if you're trying to go somewhere else (or reload), to confirm whether that's the action you want to do.
Your argument against pull to refresh could be the same for the reload, back and forward buttons in your web browser. Also, against the URL/search bar, because it might lose your progress.
And all is fixed with a confirm() on the unload event, and it has nothing to do with the pull to reload feature.
[+] [-] ww520|9 years ago|reply
[+] [-] josho|9 years ago|reply
[+] [-] blauditore|9 years ago|reply
For HTML/JS apps though it's a whole different story and might help giving it much more native look and feel.
[+] [-] rsoto|9 years ago|reply
Also, what I said in a previous comment: maybe you want consistency across browsers/platforms or branding, customizing how it looks. And maybe you don't want to refresh the whole page, maybe just one section calling a JSON API, or perhaps you have a heavy job that requires a worker.
[+] [-] rsoto|9 years ago|reply
The focus on PullToRefresh.js is to manipulate the DOM and add the elements programatically, and allow its own proportions to push down the content.
[+] [-] artursapek|9 years ago|reply
EDIT: point taken. Non-touch device
[+] [-] rfolstad|9 years ago|reply
Pull to refresh on mobile chrome or safari is really terrible ux for web apps. It's ok for content sites but if you have an app that you want to behave like a native app it's really terrible. A good example is maps.google.com. Even if you install it as a home screen app it still has the stupid pull to refresh gesture in chrome.
I wish there was some way to disable it in browsers. I have tried many things like position: fixed or overflow-y:hidden but these have other side effects like preventing the keyboard from repositioning the window in chrome or safari.
In general if a web browser overrides any touch gestures they should be able to be disabled by the page without having to handle every touchmove yourself.
[+] [-] rsoto|9 years ago|reply
I'd suggest you to download the library and delete some of the lines for the callbacks on the touch events, maybe you can isolate it and figure out what is achieving that result.
Or, you could try something like this:
[+] [-] MichaelApproved|9 years ago|reply
[+] [-] rsoto|9 years ago|reply
[+] [-] kinduff|9 years ago|reply
Very well done, looking forward for more products from you two.
[+] [-] rsoto|9 years ago|reply
[+] [-] ldom22|9 years ago|reply
[+] [-] rsoto|9 years ago|reply
[+] [-] evo_9|9 years ago|reply
Edit: typo
[+] [-] rsoto|9 years ago|reply
The use case we're aiming with this library is that not always you want to refresh the whole page; sometimes you want to update just one section of the app (think Gmail), do something deferred with a worker, or set a timeout.
Also, you want to be consistent across all browsers/platforms, and maybe add a little touch of personality or branding [1].
So, while I agree with you it should be standard, and maybe it should have an API, it has to be flexible enough for every and each thing you want to achieve... so you'll need a library, and we're full circle.
1: https://muz.li/blog/refresh-inspiration/
[+] [-] underdown|9 years ago|reply
[+] [-] donjh|9 years ago|reply
[+] [-] grav|9 years ago|reply
[+] [-] rsoto|9 years ago|reply
[+] [-] MichaelApproved|9 years ago|reply
What does that mean?
[+] [-] k__|9 years ago|reply
[+] [-] rsoto|9 years ago|reply
[+] [-] ChrisArchitect|9 years ago|reply
[+] [-] jamiesonbecker|9 years ago|reply
http://www.ipwatchdog.com/2015/02/25/the-road-forward-for-so...
[+] [-] Kwpolska|9 years ago|reply