Scrollability(joehewitt.github.com)
joehewitt.github.com
Scrollability
http://joehewitt.github.com/scrollability/
11 comments
While improving the web application experience is commendable, there is still simply no replacement for the native components. Broadly speaking, investment in mobile webapps largely seems to be about improving the entrenched web developer's experience, rather than the actual user's experience.
Insofar as Apple continues to invest in UI R&D, a clone of their UI's look and feel will always lack fidelity to the original, sit in the uncanny valley when approached by users, and require ongoing maintenance to track upstream changes as best as possible.
Additionally, fluid scrolling on iOS devices is resource intensive and requires a very careful attention to performance details; I've yet to see HTML5 UIs scroll as smoothly as a tuned native UI.
Insofar as Apple continues to invest in UI R&D, a clone of their UI's look and feel will always lack fidelity to the original, sit in the uncanny valley when approached by users, and require ongoing maintenance to track upstream changes as best as possible.
Additionally, fluid scrolling on iOS devices is resource intensive and requires a very careful attention to performance details; I've yet to see HTML5 UIs scroll as smoothly as a tuned native UI.
Apple actually fell down on this one; it should be possible to create natively scrolling divs without resorting to JS trickery. (In fairness, Android only acquired this feature very recently.)
> Broadly speaking, investment in mobile webapps largely seems to be about improving the entrenched web developer's experience, rather than the actual user's experience.
While there is some truth to this, it doesn't tell the whole story. Most developers don't have the time or desire to maintain multiple native codebases, and so using web tools improves user experience by allowing the app to exist on their platform at all. Also, sometimes these things come in handy on actual websites (personally, I consider "Click here to download our mobile app!" terrible UX).
> Broadly speaking, investment in mobile webapps largely seems to be about improving the entrenched web developer's experience, rather than the actual user's experience.
While there is some truth to this, it doesn't tell the whole story. Most developers don't have the time or desire to maintain multiple native codebases, and so using web tools improves user experience by allowing the app to exist on their platform at all. Also, sometimes these things come in handy on actual websites (personally, I consider "Click here to download our mobile app!" terrible UX).
Mobile processing power is doubling annually, GPU speed at an even faster rate. Hardware acceleration for CSS transforms is only starting to get good. (No negative values on cubic-bezier timing functions!)
No, web components haven't met native ones yet, but they only need to achieve 60 fps. They will get there, it's a safe bet.
No, web components haven't met native ones yet, but they only need to achieve 60 fps. They will get there, it's a safe bet.
By the time HTML is as good as native is, native will have moved on to something else, like holograms. Look what happened on the desktop: after 10 years webtech finally became usable as a UI, just in time for everyone to jump to mobile and set performance back another 10 years.
[deleted]
Given Apple's App Store restrictions, the choice is often between cloned UI in web apps or no iOS support at all.
Wow, I can't believe this is the top comment on HN. It's the kind of shortsighted sentiment that you look back on two years later and have a good chuckle.
I don't want to pick too much on this project since it's in very early development, but this repeats a mistake that's also found in more mature libraries like iscroll.js: https://github.com/cubiq/iscroll
The problem is that it uses CSS that works only in WebKit, but does not fall back gracefully in any other browser. It depends on CSS3 2D Transforms. Because the 2D Transforms spec is not yet a Candidate Recommendation, browser vendors currently implement it with vendor prefixes in case the spec changes before it's finalized. 2D Transforms are implemented in recent versions of IE (-ms-transform), Opera (-o-transform), Gecko (-moz-transform), and WebKit (-webkit-transform). However, the library uses only -webkit-transform.
That wouldn't be so bad, except that it does this in a way that potentially breaks the page in other browsers. For example, mobile Firefox supports overflow scrolling without any need for libraries. In the latest nightly builds of mobile Firefox 6 (which support touch events), adding iscroll.js to your page will actually break scrollable elements that work fine without the library.
The solution is two-fold: (1) If you are using vendor-prefixed APIs you can easily support more implementations, and (2) do feature detection to fail gracefully on implementations that you don't support. And yes, I plan to submit patches to these projects to address these problems.
(disclosure: I am a mobile Firefox developer)
The problem is that it uses CSS that works only in WebKit, but does not fall back gracefully in any other browser. It depends on CSS3 2D Transforms. Because the 2D Transforms spec is not yet a Candidate Recommendation, browser vendors currently implement it with vendor prefixes in case the spec changes before it's finalized. 2D Transforms are implemented in recent versions of IE (-ms-transform), Opera (-o-transform), Gecko (-moz-transform), and WebKit (-webkit-transform). However, the library uses only -webkit-transform.
That wouldn't be so bad, except that it does this in a way that potentially breaks the page in other browsers. For example, mobile Firefox supports overflow scrolling without any need for libraries. In the latest nightly builds of mobile Firefox 6 (which support touch events), adding iscroll.js to your page will actually break scrollable elements that work fine without the library.
The solution is two-fold: (1) If you are using vendor-prefixed APIs you can easily support more implementations, and (2) do feature detection to fail gracefully on implementations that you don't support. And yes, I plan to submit patches to these projects to address these problems.
(disclosure: I am a mobile Firefox developer)
Its easy to detect these features, ideally one would only load this lib if the features are supported.
The -webkit-transform: translate3d(0,x,y) (3D, not 2D transforms) property forces the element to be hardware accelerated under mobile safari, without this, the redraw would be around 10 times slower. This is the whole point of the library (hacking around a known issue in mobile safari)
Besides, he states that the code requires iOS. It is not a mistake to include vendor specific code in this way when targeting a specific platform for optimisation.
The -webkit-transform: translate3d(0,x,y) (3D, not 2D transforms) property forces the element to be hardware accelerated under mobile safari, without this, the redraw would be around 10 times slower. This is the whole point of the library (hacking around a known issue in mobile safari)
Besides, he states that the code requires iOS. It is not a mistake to include vendor specific code in this way when targeting a specific platform for optimisation.
Previous coments about re inventing the wheel are correct, but not because this has been done natively, but because this has been done before, and in a multiple platform way.
The best thing he could do is work with others. Not go all lone wolf on the very people he said he wanted to help.
The best thing he could do is work with others. Not go all lone wolf on the very people he said he wanted to help.
I agree, as a user of iScroll I'm puzzled as to why he didn't just fork iScroll. He mentioned that he didn't like how it "felt" on twitter but I would imagine the formulas used to calculate momentum are, relatively speaking, a _very small_ part of the iScroll code.
As an aside, I think that github might be able to help a lot with encouraging collaboration in light of so many duplicate projects by working on better ways to discover projects (either by better search indexing, better SEO or otherwise). And as a disclaimer: I think github is one of the most innovative companies today, so this is by no means an attempt to point fingers, rather an observation that they have a huge opportunity to really change how OSS works.
As an aside, I think that github might be able to help a lot with encouraging collaboration in light of so many duplicate projects by working on better ways to discover projects (either by better search indexing, better SEO or otherwise). And as a disclaimer: I think github is one of the most innovative companies today, so this is by no means an attempt to point fingers, rather an observation that they have a huge opportunity to really change how OSS works.
this is awesome! it's really very close to a native experience (on iphone 4 at least). my hat's off to mr hewitt. for a comparable experience check out gmail in mobile safari, it's also very convincing.
apologizing for my ignorance, does anyone know for sure why these libraries are necessary? it seems like it wouldn't be hard to offer a standard way (or even a meta tag, i appreciate that pinch zooming is a reasonable default) to get smooth accelerated scrolling of fixed and/or overflow:auto containers.
apologizing for my ignorance, does anyone know for sure why these libraries are necessary? it seems like it wouldn't be hard to offer a standard way (or even a meta tag, i appreciate that pinch zooming is a reasonable default) to get smooth accelerated scrolling of fixed and/or overflow:auto containers.
Libraries like these should not be necessary, but since Apple has not implemented proper scrolling of elements and iframes, we're left to do it ourselves. Perhaps iOS 5 (just two weeks until wwdc!) will solve the problem and make this project obsolete (I hope so).
Even if they do, libraries like these may still be necessary for more advanced scrolling mechanisms like those that snap to page boundaries or involve scrolling/zooming hybrids (like photo viewers common to many apps).
Even if they do, libraries like these may still be necessary for more advanced scrolling mechanisms like those that snap to page boundaries or involve scrolling/zooming hybrids (like photo viewers common to many apps).
fantastic work and thanks for the quick reply. i'm eager to show this to some of the guys i work with as they're working on similar stuff. http://www.npr.org/webapp loaded on an ipad 2 is pretty slick, particularly in terms of multi-finger scrolling.
i'm sure i speak for a lot of people when i say thanks for working to advance the prospect of truly first-class web applications on mobile. these are exciting times!
i'm sure i speak for a lot of people when i say thanks for working to advance the prospect of truly first-class web applications on mobile. these are exciting times!
Yeah. That is really smooth and fast on the iPhone 3G. It's a great job.
This is what overflow-scrollable areas on webpages should have been in iOS Safari. At the moment you have to mash two fingers into the screen and slowly drag it around; real clunky.
Fingers crossed (badum-tish) for an update next month.
This is what overflow-scrollable areas on webpages should have been in iOS Safari. At the moment you have to mash two fingers into the screen and slowly drag it around; real clunky.
Fingers crossed (badum-tish) for an update next month.
I must admit I'm impressed. Barring a very slight jerkiness at some random times it actually feels native: fluid, fast, and the "physics" is very, very close. In comparison iScroll 4 is better on general smoothness but feels strangely alien to iOS (notably the inertia bounce at list ends).
With the swarm of crappy alternatives - barely mimicking the native behaviour - I saw before I was giving up on the hope that something like this could even remotely exist.
With the swarm of crappy alternatives - barely mimicking the native behaviour - I saw before I was giving up on the hope that something like this could even remotely exist.
Apple has a patent on momentum-based touch scrolling that looks like it covers this:
http://reviews.cnet.com/8301-19512_7-20015237-233.html
http://reviews.cnet.com/8301-19512_7-20015237-233.html
Given that momentum based mouse scrolling existed in the prior art, I doubt that the addition of touch would pass the non-obviousness test in court.
Sounds like a good thing. iScroll is another option too, however if this is simple and small, it could be a winner.
Looks promising! It doesn't work properly yet on the Droid Incredible, but I'm sure he'll work out the kinks.
it is supposed to be for iOS.
He updated it to say that after I made my comment: https://github.com/joehewitt/scrollability/commit/a7eac85ad3...
Doesn't seem to work on a desktop, in Chrome.
its not supposed to. its for mobile devices that lack the ability to scroll inner divs
You can scroll inner divs on iOS, with 2 fingers.
Of course you can. But the fact that you have to know the sentence "you can with two fingers" in order to use it can, at least in my mind, be making the point that that is unintuitive to people. The average user doesn't know anddoesnt care, they just want it to be consistent regardless of whether or not you have a footer on your page.
Joe has done some amazing development in his time. But, honestly, that page was a real eye sore on my phone. It ran like crap.
If such a notable engineer can only develop an app of lacking caliber with the html/javascript, what does that say for web development on mobile?
PS, yes, I'm that Koush of Android. I'm a little opinionated when it comes to mobile development. :)
PS, yes, I'm that Koush of Android. I'm a little opinionated when it comes to mobile development. :)
I assume you're testing on an Android device then... I don't have one to test (but I will soon), so I'm not surprised it doesn't perform well there.
Anyway, the current code is trying to replicate the feel of iOS scrolling. An Android implementation should try to replicate the feel of Android scrolling, which is much different. I will get around to it...
Anyway, the current code is trying to replicate the feel of iOS scrolling. An Android implementation should try to replicate the feel of Android scrolling, which is much different. I will get around to it...
This is some impressive work, but at the end of the day it's just another unecessary attempt to reinvent the wheel, a wheel that will always lag behind the original. The time he spent reverse engineering UITableView could have been spent doing useful things with actual UITableViews.
Web apps are hacks.
Web apps are hacks.
That is incredibly short sighted. The web is universal, iOS is not.
Is it not?
Please, tell me where to find these mobile web apps that are superior to their native iOS counterparts.
I'll second that "incredibly short sighted" judgement. It's efforts like Hewitts, which works exceptionally well for a days work, that lead to superior mobile web apps.
Monoculture is seldom a good thing. Though native apps have strong advantages, web apps also have advantages in terms of deployment, compatibility on multiple platforms, and (possibly) freedom from Apple's walled garden.
Just like everything else: use the right tool for the job, and choose your trade-offs.
Just like everything else: use the right tool for the job, and choose your trade-offs.
Being able to develop one simple web app that make the page so much more accessible on a smartphone without the need to develop 3 native apps (iOS, Android and perhaps Windows Phone 7?) is pretty nice and cost effective.
There are a lot of native apps that are easily reproduced in pure HTML, CSS and Javascript.
There are a lot of native apps that are easily reproduced in pure HTML, CSS and Javascript.
while i agree that there are ways in which native user interface controls are currently more compelling than their web alternatives, shouldn't we all be diligent in hoping for and working towards the end of that situation? it might not be as impossible as it once seemed, they're doing angry birds in a browser now!
either way i can't imagine that an iOS monoculture in high-end mobile applications really serves anyone but apple in the long run. i think there's a general consensus that it didn't work out that well with windows, and there's arguably a lot more at stake this time.
either way i can't imagine that an iOS monoculture in high-end mobile applications really serves anyone but apple in the long run. i think there's a general consensus that it didn't work out that well with windows, and there's arguably a lot more at stake this time.
11:55 AM: "I feel suddenly motivated to write a tiny JS library that does scrolling right, or at least as close as possible."
10:20 PM: "I think we're ready to demo."
Now that's gumption.