Earlier quoted context omitted.
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 con…
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 p…
Pull to refresh. For the web
41–50 of 50 posts
Re: Pull to refresh. For the web
#42This 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…
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.
Re: Pull to refresh. For the web
#43Re: Pull to refresh. For the web
#44Speaking 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.
Re: Pull to refresh. For the web
#45This 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…
> 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 reddi…
Re: Pull to refresh. For the web
#46Re: Pull to refresh. For the web
#47Earlier quoted context omitted.
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 p…
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?)