Pull to refresh. For the web(usehook.com)
usehook.com
Pull to refresh. For the web
http://usehook.com
The feature you know and love on your phones and tablets, now for the web.Super easy to implement on your sites!
49 comments
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.
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).
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).
I'd like to third @lowboy and second jakub_g. That next/previous article control with left/right arrow buttons is so annoying! Especially when using up and down to navigate a page, I often accidentally hit left or right, resulting in my suddenly viewing an article I never wanted to read.
Similarly annoying are the "Overlay" scrollbars in Ubuntu's Unity desktop. They might be clean and out-of-the-way on touchscreen devices, where screen real-estate is often much more valuable, but they're just plain annoying on the desktop.
Swiping left and right, pull-to-refresh and smaller scrollbars might work on touchscreen devices, but they don't belong on the desktop, where there is expected behaviour derived from years of experience.
Similarly annoying are the "Overlay" scrollbars in Ubuntu's Unity desktop. They might be clean and out-of-the-way on touchscreen devices, where screen real-estate is often much more valuable, but they're just plain annoying on the desktop.
Swiping left and right, pull-to-refresh and smaller scrollbars might work on touchscreen devices, but they don't belong on the desktop, where there is expected behaviour derived from years of experience.
Twitter's been horrible for this recently. They've had the bright idea to map F5 to retweet. (Because no one uses F5 otherwise, right?) "-" also gets repurposed, as apparently it's more intuitive as a direct message shortcut rather than letting the browser use it for zooming or anything else. Slash has also been victimized as noted by choult. What a brave new world...
My current pet hate with a number of sites is the fact that a number have started capturing / for focussing on their site search - where in Firefox it's been Quick Find for ages. Slows me down something rotten.
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 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.)
Unfortunately, there aren't any events to track overscroll with regular mouse wheel or trackpad scrolling. I looked into it for a bit, wanting to create something exactly like Hook, but with the expected UX. Once the viewport hits the top of the window, scroll and mousewheel events stop firing even if the fruitless user input continues.
Touch is different, because you continue receiving touchmove events even if the page is scrolled to the top and the touchmove events don't have any visible effect.
Touch is different, because you continue receiving touchmove events even if the page is scrolled to the top and the touchmove events don't have any visible effect.
I'd guess desktop browsers will eventually get around to supplying similar overscroll-events. (Looks like Chrome already offers an elastic overscroll visual effect... so maybe there are events there, if you know what to look for?)
I'd defer to someone on the Chromium team if they have any input, but Chrome is what I was using at the time (not too long ago) and there definitely weren't any events firing for overscroll. It would be nice if they'd add notification about that, but it would be very difficult at this point to disambiguate between true overscroll and the animations that some browser/os combinations are displaying now. For such a niche use case (that really doesn't provide much benefit on non-touch pages anyway), I wouldn't be surprised if we never see it added.
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.
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.
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.
Twitter on my desktop has a notification that there are new tweets, and I haven't seen if FB automatically loads more content on the top or follows a similar approach. The point isn't that sites need to be static for the life cycle of a page reload, it's that the site shouldn't trigger a browser-level reload on an unrelated user action such as scrolling to the top of the page. It's confusing, and should be considered an anti-pattern as others here have said.
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.
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.
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.
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/...
http://www.guardian.co.uk/media/mind-your-language/2011/sep/...
God, I abhor this sort of peevery. But especially here, when the linguistic innovation is so damn useful.
The "trendy" meaning of trope, is, as far as I can tell, not one easily replaced by another word. It's not a motif so much as a kind of generalization of what archetype is to a character. In its narrative sense it refers to the sort of "tools" and "parts" the story teller uses to construct their tale, and I absolutely love the extension of meaning to refer to UX... tropes (what word would you use here? Motif? That suggests to me more aesthetic design elements than things like pull-to-refresh)
The "trendy" meaning of trope, is, as far as I can tell, not one easily replaced by another word. It's not a motif so much as a kind of generalization of what archetype is to a character. In its narrative sense it refers to the sort of "tools" and "parts" the story teller uses to construct their tale, and I absolutely love the extension of meaning to refer to UX... tropes (what word would you use here? Motif? That suggests to me more aesthetic design elements than things like pull-to-refresh)
> to refer to UX... tropes (what word would you use here? Motif?
Probably 'pattern', I guess. I agree, I think it's a very practical new usage which doesn't introduce much ambiguity elsewhere, so I'm all for it.
Probably 'pattern', I guess. I agree, I think it's a very practical new usage which doesn't introduce much ambiguity elsewhere, so I'm all for it.
Prescriptivist peevery (often with weak support) is by this point an HN-Trope.
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".
> 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".
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.
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.
Ha ha spot on. The was the first thing I did, clicked at the top of the page and tried to "pull" down the page to refresh. And nothing happened.....
You could add Hammer.js and achieve this.
I prefer how this works, honestly, but just thought the description poor
- Does not work well on iPhone, not at all.
- 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.
- 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.
Cool hack, but you're going to confuse the hell out of my mom... "why did the screen just twirl?!? Did I just lose all of my information?!"
Awesome! I was looking for something like this that works on mobile.
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.
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.
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.
It's a bad idea to link to jquery.latest in a production site. $.browser is breaking.
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.
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.
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.
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.
We love that neat little "pull to refresh" feature on our devices
We do? I might prefer lots of little buttons and scroll wheels, DSLR style :P
We do? I might prefer lots of little buttons and scroll wheels, DSLR style :P
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.
Unfortunately this plugin makes Home/Page up buttons unusable.
Why not make it an actual "pull down" with the mouse rather than simply scrolling down? This is not the same as the mobile implementation.
You should be able to pull-to-refresh when at the top of the page.
I'd love something like this for HN / Reddit / etc -- great work!
Is this not open source?
Scroll to the top to refresh
[deleted]