4 ms·
> 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 re
by 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 agoI 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 agoWhere 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 agoNow you have an inconsistent ux which is also frustrating and a frustrating confirm question that keeps appearing