Live data from Hacker News

Pull to refresh. For the web

usehook.com

11–20 of 50 posts

Re: Pull to refresh. For the web

#11
post #5

This is nice for those who like the pull-to-refresh trope (I'm not among them, but that's not relevant here). Some suggestions: 1) Wouldn't it be better to have some initialization function like $('body').hook('Reloading...') to create the necessary markup instead of requiring the developer to put it on each page? 2) I'm not sure how hard this would be, but I think it would be better for the pull to refresh action to…

Tangengially, people should stop using the trendy word "trope" to mean 'recurring thing'. It's only valid in a metaphorical sense.

http://www.guardian.co.uk/media/mind-your-language/2011/sep/...

Re: Pull to refresh. For the web

#13
Interesting, but more sensible for web apps than web pages; web pages have a "refresh" button already. And as other comments have said, this doesn't actually work as "pull to refresh", but as "scroll back to top to refresh".

Web apps do this because they don't want to look like a web browser, and having back/forward/refresh buttons looks like a web browser (and takes up space that could show content instead). Web pages, though, display in a browser.

Re: Pull to refresh. For the web

#14
I would definitely not want to use this for my desktop (or my laptop really), but this seems like it would be a great way to make mobile sites feel a little bit more mobile-y.

Kudos on the clever idea and well designed website.

Re: Pull to refresh. For the web

#15
This is not a good idea because it breaks years (decades?) of expected behaviour on desktops.

When a user scrolls a page back to the top, the expectation is that they'll see the top of the current page from the most recent pageload. With this, there's no way to revisit the top of the page in its current state and it's just gone when you scroll back to the top.

This doesn't save much time/effort as a refresh is a common and well-supported function of browsers.

This conflates two user intentions: 1) scroll to the top of the page, and 2) refresh the page to get new content. This makes #1 impossible without automatically triggering #2.

Re: Pull to refresh. For the web

#16
post #11
post #5

This is nice for those who like the pull-to-refresh trope (I'm not among them, but that's not relevant here). Some suggestions: 1) Wouldn't it be better to have some initialization function like $('body').hook('Reloading...') to create the necessary markup instead of requiring the developer to put it on each page? 2) I'm not sure how hard this would be, but I think it would be better for the pull to refresh action to…

Tangengially, people should stop using the trendy word "trope" to mean 'recurring thing'. It's only valid in a metaphorical sense. http://www.guardian.co.uk/media/mind-your-language/2011/sep/...

From the article to which you linked:

> But wait: Oxford Dictionaries online, while giving a similar definition – "a figurative or metaphorical use of a word or expression" – adds a second: "a significant or recurrent theme; a motif: she uses the Eucharist as a pictorial trope".

Re: Pull to refresh. For the web

#17
post #15

This is not a good idea because it breaks years (decades?) of expected behaviour on desktops. When a user scrolls a page back to the top, the expectation is that they'll see the top of the current page from the most recent pageload. With this, there's no way to revisit the top of the page in its current state and it's just gone when you scroll back to the top. This doesn't save much time/effort as a refresh is a comm…

Completely agree. One way to 'solve' this might be for it to stop when you hit the top, then wait for say, a half-second (prevent all scroll up events during this half-second if you're at the top of the page). If the user scrolls up after that, do the refresh. Maybe someone will think of an issue with that, I haven't really thought it through.

Re: Pull to refresh. For the web

#18
post #15

This is not a good idea because it breaks years (decades?) of expected behaviour on desktops. When a user scrolls a page back to the top, the expectation is that they'll see the top of the current page from the most recent pageload. With this, there's no way to revisit the top of the page in its current state and it's just gone when you scroll back to the top. This doesn't save much time/effort as a refresh is a comm…

In the best touchscreen implementations, you have to overscroll past the top by a certain amount to get the reload behavior. Further, while overscrolling less than the threshold amount, you get a visual hint that further pulling will reload, while letting go will avoid a reload.

This Hook.js implementation doesn't yet seem to have that level of refinement... but if it could, I don't think the user expectations or conflated-functionality issues you raise would be fatal usability problems. You could have the benefits of cross-training with touch, and easy reload access via the already-under-finger scrolling-controls, without much confusion.

(Though, truly seamless operation might require in-browser implementation, to trigger without interfering with the usual DOM-coordinates Y-zero.)

Re: Pull to refresh. For the web

#19
As skakri said, this breaks the 'scroll to top' shortcut (whether it's Home or cmd-up). The behaviour in the twitter app for android is making the best of a bad situation (screen real-estate in short supply but touch gestures are available). It also requires you to deliberately scroll beyond the zero position into extra space, so you can't accidentally scroll too far.

usehoook feels like a gimmick for the sake of it, and it lets you do things, possibly destructive things, accidentally and without meaning to to.

Re: Pull to refresh. For the web

#20
post #15

This is not a good idea because it breaks years (decades?) of expected behaviour on desktops. When a user scrolls a page back to the top, the expectation is that they'll see the top of the current page from the most recent pageload. With this, there's no way to revisit the top of the page in its current state and it's just gone when you scroll back to the top. This doesn't save much time/effort as a refresh is a comm…

To deal with this, the author needs to clearly separate the two actions. If a little arrow appeared when pulling down (to indicate further action is required) and a pull to refresh meant pulling down by say 1/3 window height, the two actions could not be confused. As it is if you scroll near the top of the page you can trigger it by mistake, I agree this is confusing.

Still, for certain web apps like gmail (which already does this), it's a neat shortcut for those using gestures. Possibly works better when confined to a list as well, so I'm not sure about applying it to an entire page.

Post reply on HN