Joe Hewitt’s First Post-Facebook Web Gift: Inertial Scrolling For All(techcrunch.com)
techcrunch.com
Joe Hewitt’s First Post-Facebook Web Gift: Inertial Scrolling For All
http://techcrunch.com/2011/06/20/joe-hewitt-scrollability/
6 comments
I've been using iScroll (http://cubiq.org/iscroll) and it works quite well. Works on the desktop too unlike Scrollability.
The script has been superseded by iScroll 4:
http://cubiq.org/iscroll-4
Joe's photoblog, mentioned in the article as an example of inertial scrolling: http://uponahill.com.
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.)
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.)
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.
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.
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.
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".
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.
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.
Its for iPad/iPhone. The "for all" is a pretty blatant lie.
The article is by MG Siegler.
Whatever. I thought the pinning effect was clever. It lets me browse through photos in a natural way by using the scroll wheel and easily read the captions too.
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?
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.
> ... 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.
One native feature down (at least until Apple evolves it again), countless pile of more features to go. This is a losing battle.
1. It's for web applications, with all that implies: the ability to scroll only sections on the screen (not the whole page) while still having the right physics, lazy loading, snapping (the horizontal demo implements "snapping" transitions similar to iOS's springboard)
2. It implements iOS's UITableView physics, which are different (smoother) than Safari's native
2. It implements iOS's UITableView physics, which are different (smoother) than Safari's native
So by "Native scrolling for mobile web apps" he means better scrolling of iOS Safari in general and especially for elements that have overflow:scroll styling.
> So by "Native scrolling for mobile web apps" he means better scrolling of iOS Safari
Well he means what he says: scrolling which looks and feels like native (UITableView) scrolling.
Well he means what he says: scrolling which looks and feels like native (UITableView) scrolling.
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.
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?)
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?)
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.
This has already been covered here and only works in iOS whereas other solutions have worked on more platforms...
> only works in iOS
For now, he's still planning on extending it to Android when he's done with iOS.
> whereas other solutions have worked on more platforms...
What other solutions?
For now, he's still planning on extending it to Android when he's done with iOS.
> whereas other solutions have worked on more platforms...
What other solutions?
Would it be possible to mention some of these other solutions?