Hacker News Reader

Comment by lowboy | Hacker News Reader

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.

View on HN

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).

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.

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.)

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.

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.

> 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.

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.

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.

Reply on news.ycombinator.com