Flick based scrolling in javascript | Hacker News Reader

Flick based scrolling in javascript

simurai.com

45 pointscleverjake8 comments

Please don't mess with scrolling.

I'm not trying to be one of the neckbeards who complain about edge cases (it doesn't work with my emacs scroll bindings on my custom build of Lynx, etc), but:

It doesn't work. Trying to override native behavior with custom behavior is always risky, because you not only have to fight with edge cases and undocumented unsupported APIs, but because you run the risk of falling into the uncanny valley (http://en.wikipedia.org/wiki/Uncanny_valley).

I pulled the demo up on my laptop first (macbook with momentum scrolling). Everything worked normally, except not quite. The scrolling lagged a tad bit, flicking didn't scroll it quite as far as normal, something was off. It was a slightly unsettling experience, not one that I would choose to replicate.

I then tried on the intended (I assume) platform: iOS.

I don't know what went wrong, but it didn't work. After a few flicks I got scrolled to the bottom of the page and stuck there. The flicks were incongruent and did not assist in the reading at all.

It's a great idea, and I wish scrolling worked like this. However breaking native functionality is a dangerous game, and if you fuck up you go the way of www.onswipe.com/ which is pretty much universally hated for making perfectly good content unreadable on mobile with the pretense of making it more readable.

I completely disagree with your comment. Please mess with scrolling. Make it better, try new things. The idea here has a ton of merit, and while you're complaining about the experience, the poster says "Warning: I’m not really a programmer so the demo is just a hack to demonstrate how it could work...."

This is nothing but a quick hack demo to show his idea.

If people don't 'mess' with things, they're never going to improve. I think this is a great step to something that could be very functional and easy to understand.

There are more integrated, more universal, and in fact I will claim easier ways of accomplishing that: jailbreak the device and hook the scrolling algorithm.

I agree with both of you in some fashion. On one hand, to stop investigating and pushing is to stop breaking new ground. On the other, nearly good ideas can be just as bad or even more so then ones that seem automatically catastrophic. The minute I saw the diagram that showed the difference between the two types of scrolling, the "Oh, no" was already forming in my mind and working it's way through my synapses.

The reason gestures work so well is because they are so greatly different than each other. The flick, the pinch-to-zoom, the tap, all easily discernible gestures. The short flick vs. the long flick? When does it stop being a short flick and start being a long flick?

The idea of a bring to top of page gesture, however, is genius. Now we just need to find a gesture that would be best utilized for it.

Great job! Just a minor note, I have a multi-touch display which I'm using for a project, and this library doesn't work as intended when using such a multi-touch device, the behavior is a bit erratic and inconsistent. [I'm using Chrome btw on a regular PC]

It makes scrolling feel horribly slow. What would be potentially interesting, though, would be to ensure that scrolling on the timeline stops at the top of the next picture.

Very interesting, it seems like a good hybrid of using pagination and continuous scrolling. It would be nice to have something like this in Instapaper.

very nice interaction, great work - I also agree with keeping the indicator, it's a nice touch.

Reply on news.ycombinator.com