Hacker News Reader

Comment by oftenwrong | Hacker News Reader

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.

View on HN

(I'm one of the creators of ptr.js)

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.

> 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

How about putting a refresh button somewhere?

Several reasons:

- 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

> 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

Don’t you need to refresh on desktop as well?

There's already one, next to your location bar.

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?

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.

That's a good point. How do native apps that offer pull-to-refresh handle this?

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

According to our user research, yes. But YMMV.

Basically whatever Facebook does is the most discoverable for the older generations.

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

Nicely packaged for easy use.

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.

Unfortunately most consumers want behavior like this.

I’d disagree strongly. I’d argue that “Pull down to refresh” is still a bit of a geeky trick. Either way, you’d want a lot of user testing.

Reply on news.ycombinator.com