
Joe Hewitt’s First Post-Facebook Web Gift: Inertial Scrolling For All - sahillavingia
http://techcrunch.com/2011/06/20/joe-hewitt-scrollability/
======
RobbieStats
I've been using iScroll (<http://cubiq.org/iscroll>) and it works quite well.
Works on the desktop too unlike Scrollability.

~~~
wolfhumble
The script has been superseded by iScroll 4: <http://cubiq.org/iscroll-4>

------
kyleslattery
Joe's photoblog, mentioned in the article as an example of inertial scrolling:
<http://uponahill.com>.

~~~
lobster_johnson
Not sure why he calls it inertial scrolling. There's no "inertia" here. It's
just pinning the background image as long as you are scrolling the text.

Which, incidentally, is a pretty stupid idea. Look at his photoblog -- to
scroll past a photo which has a very short text block, you have to scroll
until little text block disappears off the page. It's pretty silly, and goes
against the idea of the _purpose_ of scrolling, which is to navigate past
information that does not fit within the viewable area of your device/window.

For a truly innovative scrolling concept, take a look at <http://bloom.io/>.
(Give it some time to load all its assets. The effect isn't activated until it
has everything.)

~~~
joehewitt
The goal here is not to be "truly innovative", but to emulate scrolling
behavior which should ideally be performed by mobile WebKit, but isn't. But I
must have done a good job since you only notice the background image being
pinned, and not the fact that (at least on an iPad) the entire page is being
scrolled with JavaScript. Also, try scrolling horizontally.

~~~
lobster_johnson
I wasn't commenting on the technical underpinnings -- I'm sure it solves an
implementation problem well, but as a user, the fact that the entire page is
being scrolled with JavaScript does not matter. I was commenting on the user
interface, which does not make sense to me.

There are essentially two use cases here, conflated into one experience. The
first use case is when a photo has a long body text which needs to be
scrolled. Clearly, your scrolling mechanism solves that problem, although I
was unnerved by the fact that it does not visually indicate how long the
scrolled text was (something traditionally solved with a scroll bar).

Unfortunately, this same UI solution is forced upon the second use case, when
the photo has a short body text which does _not_ need to be scrolled. In this
case, your system provides scrolling even when it's not needed; moving the
tiny text box up or down does offer anything in terms of functionality. It
merely delays the scrolling, and forces me to swipe several times to get
anywhere.

As for the horizontal scrolling, it does not integrate well with the text box.
The text box disappears (abruptly and confusingly) when you side-swipe. Then
it appears again (equally abruptly) if you touch the screen. And here's where
it gets super weird:

If you side-swipe, and then swipe down (as in, "I'm done with looking at this
series of photos, now I'd like to navigate downwards to the _next_ series of
photos", the text box appears (again, abruptly) and hijacks the scrolling
mechanism. The text box wasn't there when I _decided_ to start scrolling, but
it appears and then forces me to scroll the box. Sorry, that's just bad UI
design.

These UI issues exist because you've conflated _text scrolling_ with _photo
navigation_. It would be a lot nicer if the text box stayed in place, always.
When the text exceeds the boundaries of the box, provide a scrollbar to let
the box scroll.

Finally: The reason I used the phrase "truly innovative" is because your
scrolling mechanism apparently tries to innovate something, by introducing a
new kind of UI for photo navigation, something I think it fails to do. I was
merely comparing it to something that actually works.

~~~
joehewitt
When you scroll horizontally, you're indicating that you want to see more
photos, so naturally the text should disappear. When you scroll vertically
again, you're indicating that you want to move to the next post, so naturally
the text should appear again. You're free to scroll horizontally or vertically
at any time, and the result is pretty consistent if you do. What you call
"forcing the user" I call "making educated guesses about the user's
intentions".

~~~
lobster_johnson
No. You're _misguessing_ the user's intentions.

Look, scrolling needs to have a _purpose_. Either (a) it's because you want to
read more text than is visible, or (2) it's because you want to view more
photos that are not currently visible. It's never both at the same time, in
your case, simply because multiple photos cannot exist on the same screen as
an overflowing text box.

In the case where no text box is being shown, the intention (1) does not
exist, because there is nothing to scroll. So when viewing photo A1 (being the
first photo in series A), by sliding horizontally I am expressing the
intention: "Let me view photo A2". When viewing photo A2, which does show any
text box yet, by sliding vertically I am expressing the intention: "Let me
view photo B1".

There is no text box yet. Therefore, by scrolling down the app cannot possible
perceive my action as intending to scroll the text. And yet your app decides
that's what it means, and shows the text box out of the blue. It's simple
causality. If vertical scrolling is to fullfill the intention "Let me view
more text than is currently on screen", then the text box _needs_ to be
visible _at all times_. Simple as that.

Your scrolling thing is still equally broken for the other reason I stated in
the previous comment.

------
hpaavola
I don't get this. From <http://joehewitt.github.com/scrollability/>: "Native
scrolling for mobile web apps... or at least the closest thing to it!" How
does my Android phone lack "native scrolling" and what does that mean?

~~~
ZeroGravitas
On iPhone, scrolling in an app, and a web page/app, are different in terms of
speed and inertia. There's been several attempts to emulate the "native"
scroll response via javascript so that web apps can more seamlessly replace
alternatives.

~~~
nupark2
_> ... so that web apps can more seamlessly replace alternatives._

One native feature down (at least until Apple evolves it again), countless
pile of more features to go. This is a losing battle.

------
nupark2
The animation is glitchy on an iPad 1, and it doesn't feel anything like the
native UIScrollView's paging support. It's sort of acceptable enough for a web
page, but it's not a replacement for a native UIScrollView.

------
smickie
This is how overflow:scroll should have worked on iOS a long time ago.

At the moment you have to mash two fingers in a webpage and scrape the content
across that page. (Not sure if this is updated in iOS5?)

~~~
antimatter15
It is. Overflow:scroll works with one finger, but it's often very slow and
laggy (like two finger) and has no inertial scroll. Maybe they'll fix it.

------
drivebyacct2
This has already been covered here and _only_ works in iOS whereas other
solutions have worked on more platforms...

~~~
joehewitt
It will work on Android as soon as I get some Android devices to test with. It
should currently "work" on Android, but probably not well.

~~~
snitko
I tried it on a Honeycomb tablet, works pretty smoothly, but "not for ios5"
notification shows up for some reason.

