4 ms·

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 d

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.

rsoto 10y ago
> 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.
- kaishiro 10y ago
  I actually agree with most of what you're saying, except for the part about it being the same argument for reload, etc. Nobody is overloading the reload button to accomplish some other featurette. But pull to reload is overloading an existing paradigm - scrolling down - and implementing an entirely unrelated piece of functionality - loading new content.
  - systoll 10y ago
    Where it's appropriate, pull-to-refresh isn't unrelated functionality. In a reverse chronological listing, 'new' stuff is always at the top. Pull-to-refresh refreshes the listing, grabbing whatever could be placed 'above' the page, when you scroll past the top of what's currently loaded. it's just the other end of 'infinite scrolling'. Triggering `location.reload()` when you scroll past the top is a bad idea -- about as appropriate as triggering `location = nextPage`, when you get to the bottom. But most pull-to-refreshes don't do that.
- greggman 10y ago
  Now you have an inconsistent ux which is also frustrating and a frustrating confirm question that keeps appearing
ww520 10y ago
There are times and places for different functionality. Pull to refresh is great for a read-only page.
josho 10y ago
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.
- greggman 10y ago
  Wrong. If the page is long I want to scroll up not go to the top. I don't know where the top is so I'll scroll scroll scroll refresh !;$@&!?$&!

rsoto 10y ago

> 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.

kaishiro 10y ago
I actually agree with most of what you're saying, except for the part about it being the same argument for reload, etc. Nobody is overloading the reload button to accomplish some other featurette. But pull to reload is overloading an existing paradigm - scrolling down - and implementing an entirely unrelated piece of functionality - loading new content.
- systoll 10y ago
  Where it's appropriate, pull-to-refresh isn't unrelated functionality. In a reverse chronological listing, 'new' stuff is always at the top. Pull-to-refresh refreshes the listing, grabbing whatever could be placed 'above' the page, when you scroll past the top of what's currently loaded. it's just the other end of 'infinite scrolling'. Triggering `location.reload()` when you scroll past the top is a bad idea -- about as appropriate as triggering `location = nextPage`, when you get to the bottom. But most pull-to-refreshes don't do that.
greggman 10y ago
Now you have an inconsistent ux which is also frustrating and a frustrating confirm question that keeps appearing

ww520 10y ago

There are times and places for different functionality. Pull to refresh is great for a read-only page.

josho 10y ago

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.

greggman 10y ago
Wrong. If the page is long I want to scroll up not go to the top. I don't know where the top is so I'll scroll scroll scroll refresh !;$@&!?$&!