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.
I'd like to second @lowboy and add a bit unrelated but annoying thing I've been recently noticing:
It's enough that many popular news pages break my habit (in Firefox/Chrome) to use [Ctrl +] Shift + Left/Right to highlight the text I read with the Left/Right arrow buttons doing some magic like going to next article etc.
Never mess with the keyboard shortcuts of the browser unless you really know what and where you're doing. Keep in mind that Ctrl + .. often trigger browser native shortcuts, LeftAlt + .. is used to expand menus, and RightAlt + .. is used in some languages to type in diacritics. Unfortunately there's no much room for shortcuts considering all of that, other than complicated combos like Ctrl + Shift + .. (and some of that are also taken by the browser).
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.)
This doesn't quite replicate the pull to refresh on phones but I think the right implementation wouldn't conflict with the expected behavior on desktops.
All it takes to refresh here is to scroll past the top (however barely) whereas on a phone you have to give it a little tug to make it refresh and if you don't pass the threshold on the tug it just bounces back, effectively taking you to the top of the page. I think this is really cool idea and a good implementation but the next iteration would benefit by requiring slightly more 'pull' to activate than you would use normally when doing a simple flick on your trackpad (or scroll on your mouse) to get to the top.
> This is not a good idea because it breaks years (decades?) of expected behaviour on desktops.
I don't think thats really valid.
How long have facebook and twitter (among others) been automatically updating the page with new tweets/feed content?
It seems to me that the expectation of 'static page state' is already gone for pages where this would be useful - sites with fast moving feeds of data. I'd really love reddit among others to have this feature.
I'd also add that there is a lot going on around 'push' technologies for many apps that also destroy the concept of a static page state, and many of those applications are loved by users and developers alike.
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.
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.
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 be longer and more gradual. I hit a refresh just by scrolling up a few pixels past the top when I didn't want to trigger it.
3) I'm not sure if you already support this, but it would be nice if the reload action could support a user-specified callback function instead of always reloading the whole page. That way people could use it to make AJAX calls and reload specific <div>s instead of reloading all of the page nav and other static pieces. That's more like the behavior we see in mobile.
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.
Cool idea, but this is a total anti-pattern. People do not expect this behavior from scrolling on a desktop and without a proper ajax implementation the result is far from ideal.
Exactly, it's triggered way too easily. It should include a confirmation mechanism like the "release to refresh" on iOS. Desktop usability vs Touch/Mobile usability are quite different.
"Pull to Refresh" is a poor description for the end user. I literally clicked and pulled down as I would on the iPhone simulator to use pull to refresh.
- Why not put the actual page at something like and y=50 and scroll to y automatically? so that pull-to-refresh part would be visible while scrolling and cancellable.
- Why does it requie "scrolling down a little bit" first?
- Don't break the web please! There is no need for that on the desktops.
I don't think it's so bad as long as it's doing some ajax refresh, fetching more content. Doing a full page refresh because I accidentally scrolled over the top is, well, a bit over the top.
If I pull down on Chrome on Nexus 4 and let it refresh, it causes a continual loop of refreshing the page until I scroll down again. Was able to reproduce it a few times.
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.
I know at least Sencha Touch provides this functionality for mobile sites. But it doesn't do so with hijacking the scrollbar, it implements it just like in native webapps.
Great idea. I catch myself scrolling up before refreshing relatively often!
It would really be genius if the page didn't completely reload everytime but only if it really changed.
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.
If this was a browser extension (and of course it can be used as one), I think it would be much more sensible. As it stands, I think most users would be confused and surprised by it. If someone can make a popular site with it, maybe it will become a commonly-understood and expected feature.
Speaking more personally, this is why I use NoScript. I do not like dealing with this kind of odd, site-specific functionality. My browsers have refresh already.
This would work only on mobile-only web sites. I for one would be incredibly irritated if I were to, say, write a longass comment and then accidentally swipe up on my trackpad and lose 20 minutes of work. I've done it before in other stupid ways, it's very frustrating, and i just end up being too fed up to type up my thoughts again
This could interesting from development, but LiveReload exist, so I'm curious what the market is. As others have said, if you could scroll to the top without firing the reload immediately (and it worked on mobile) this could be a neat tool.
Clever, but doesn't behave like it does on a phone. I have a touch enabled laptop running Chrome. I visit the page. Try to Pull to Refresh. It doesn't work. It seems to be setup to watch for scrolling rather than actual Pulling to Refresh.
[+] [-] lowboy|13 years ago|reply
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.
[+] [-] jakub_g|13 years ago|reply
It's enough that many popular news pages break my habit (in Firefox/Chrome) to use [Ctrl +] Shift + Left/Right to highlight the text I read with the Left/Right arrow buttons doing some magic like going to next article etc.
Never mess with the keyboard shortcuts of the browser unless you really know what and where you're doing. Keep in mind that Ctrl + .. often trigger browser native shortcuts, LeftAlt + .. is used to expand menus, and RightAlt + .. is used in some languages to type in diacritics. Unfortunately there's no much room for shortcuts considering all of that, other than complicated combos like Ctrl + Shift + .. (and some of that are also taken by the browser).
[+] [-] gojomo|13 years ago|reply
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.)
[+] [-] trentfowler|13 years ago|reply
All it takes to refresh here is to scroll past the top (however barely) whereas on a phone you have to give it a little tug to make it refresh and if you don't pass the threshold on the tug it just bounces back, effectively taking you to the top of the page. I think this is really cool idea and a good implementation but the next iteration would benefit by requiring slightly more 'pull' to activate than you would use normally when doing a simple flick on your trackpad (or scroll on your mouse) to get to the top.
[+] [-] mbell|13 years ago|reply
I don't think thats really valid.
How long have facebook and twitter (among others) been automatically updating the page with new tweets/feed content?
It seems to me that the expectation of 'static page state' is already gone for pages where this would be useful - sites with fast moving feeds of data. I'd really love reddit among others to have this feature.
I'd also add that there is a lot going on around 'push' technologies for many apps that also destroy the concept of a static page state, and many of those applications are loved by users and developers alike.
[+] [-] grey-area|13 years ago|reply
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.
[+] [-] DavidBradbury|13 years ago|reply
[+] [-] habosa|13 years ago|reply
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 be longer and more gradual. I hit a refresh just by scrolling up a few pixels past the top when I didn't want to trigger it.
3) I'm not sure if you already support this, but it would be nice if the reload action could support a user-specified callback function instead of always reloading the whole page. That way people could use it to make AJAX calls and reload specific <div>s instead of reloading all of the page nav and other static pieces. That's more like the behavior we see in mobile.
[+] [-] return0|13 years ago|reply
http://www.guardian.co.uk/media/mind-your-language/2011/sep/...
[+] [-] afandian|13 years ago|reply
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.
[+] [-] ntaylor|13 years ago|reply
[+] [-] rothlis|13 years ago|reply
[+] [-] gte910h|13 years ago|reply
[+] [-] fuchida|13 years ago|reply
[+] [-] ErikAugust|13 years ago|reply
[+] [-] alpb|13 years ago|reply
- Why not put the actual page at something like and y=50 and scroll to y automatically? so that pull-to-refresh part would be visible while scrolling and cancellable.
- Why does it requie "scrolling down a little bit" first?
- Don't break the web please! There is no need for that on the desktops.
[+] [-] mbesto|13 years ago|reply
[+] [-] tehwebguy|13 years ago|reply
IMO the next version needs to be able to pull slightly without refreshing. This way the user can know it's an option without necessarily firing it.
[+] [-] goldfeld|13 years ago|reply
[+] [-] jblesage|13 years ago|reply
[+] [-] kevincennis|13 years ago|reply
[+] [-] aroman|13 years ago|reply
Kudos on the clever idea and well designed website.
[+] [-] city41|13 years ago|reply
[+] [-] clemsen|13 years ago|reply
[+] [-] JoshTriplett|13 years ago|reply
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.
[+] [-] oftenwrong|13 years ago|reply
Speaking more personally, this is why I use NoScript. I do not like dealing with this kind of odd, site-specific functionality. My browsers have refresh already.
[+] [-] PavlovsCat|13 years ago|reply
We do? I might prefer lots of little buttons and scroll wheels, DSLR style :P
[+] [-] taintlove|13 years ago|reply
[+] [-] aboutaaron|13 years ago|reply
[+] [-] shanselman|13 years ago|reply
[+] [-] skakri|13 years ago|reply