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.
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).
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.
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.)
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.
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.
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.
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.
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.
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)
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.
> 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".
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.
- 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.
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.
Kudos on the clever idea and well designed website.
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.
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 do? I might prefer lots of little buttons and scroll wheels, DSLR style :P