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