Re: Request for Comments: Proposal for Touch-Based Animation Scrubbing

On 01/12/2012, at 2:12 AM, Tobie Langel <tobie@fb.com> wrote:

> On 11/30/12 1:13 PM, "Dean Jackson" <dino@apple.com> wrote:
> 
>> But mostly, I really don't think this is important to the Web and
>> the CSS community right now. We're having to conduct polls of the CSS WG
>> members to decide which small subset of the huge amount of work that
>> needs to be done will actually get any attention. Is this more important
>> than everything we won't get to?
>> 
>> I'd like this group to focus on
>> 
>> (a) things that can't be done but are necessary/highly-desired (responsive
>>   gradients is a good example), or
>> (b) fixing the existing things that people are using
>> 
>> Compare your proposal to the position:sticky one. This is something
>> related
>> to scrolling that was addressing a clear need and helped both users and
>> developers.
> 
> We haven't looked at the proposal deeply enough to see if it a proper fit
> for the use cases we (Facebook) are mostly interested in (momentum and
> infinite scrolling on touch devices), nor whether it is indeed the most
> appropriate solution. However, I would like to react to your statement
> that solving these use cases is not important for the Web and the CSS
> community right now.
> 
> Momentum scrolling is a key part of the user experience on touch devices,
> in both native and web applications. Internal experiments we carried out
> show a direct correlation between smoothness of scrolling and user
> engagement. Not only did users who suffered a degraded scrolling
> experience engage less with the app during the experiment. Once the
> experiment was finished and their scrolling performance re-established, it
> took weeks for them to get back to their initial engagement levels.
> 
> Poor scrolling performance is the first stated reasons why we
> reimplemented our iOS app to use native technology rather than embedded
> Web views[1]:

I think all this is supporting my point (and Simon's). We, like you,
consider scrolling performance to be *EXTREMELY* important. I don't think
this proposal from Tab is going to address the problems you had.

So, to clarify, I think we should concentrate on solving the issues
that caused you to drop a Web-based solution, and not on adding features
to the platform.

>    "One of the biggest advantages we've gained from building on
>     native iOS has been the ability to make the app fast. Now,
>     when you scroll through your news feed on the new Facebook
>     for iOS, you'll notice that it feels much faster than
>     before."
> 
> Not surprisingly, it is one of the key issues I mentioned in my email to
> the Coremob mailing list[2].
> 
> The performance enhancements made to our mobile app improved our App Store
> rating from 1.5 stars to 4 stars in three weeks, with user engagement
> approximately doubling[3]. While a number of perf issues were improved in
> that release, scrolling performance (while browsing the feed) is
> prominently mentioned in that article:
> 
>    "But until the relaunch, the HTML5 slowness of launching
>     the native iOS app, browsing the feed, and viewing photos
>     was dragging down its review [Š]"
> 
> Currently, the lack of events on which to prefetch and append new content
> while scrolling makes it impossible to implement infinite scrolling
> without re-implementing everything in JavaScript. Other UI refinements
> (pull to refresh, etc.) suffer from similar issues. Re-implementing
> scrolling in JavaScript prevents the browsers from carrying adequate perf
> optimization, yields sub-optimal experiences for the users and is
> extremely costly in engineering resources.

Without going into details of the iOS implementation, the main reason your
scrolling performance improved when you went to a native app is because
it's more deterministic that the anything-goes Web scrolling, even though
it may not seem that way.

Tab's proposal attempts to make some things more deterministic, but not
the types of things you needed for the Facebook app.

What you need is some way to do some (quite advanced) layout during scroll
without interrupting the main UI thread. Also, that layout should be constrained
to some parts of the tree, and not affect other parts. That's the magic
behind the fast scrolling in a native app.

> This is why I applaud this effort and hope it will help enable the smooth
> scrolling experience users have come to expect on touch devices.
> 
> Sorry for the sales pitch, folks, but this is important. Please bump it up
> your priority lists. :)

I can assure you that scrolling performance is at the top of Apple's
priority list! And that we paid a lot of attention to your coremob email.

Dean

> 
> --tobie
> 
> ---
> [1]: 
> https://www.facebook.com/notes/facebook-engineering/under-the-hood-rebuildi
> ng-facebook-for-ios/10151036091753920
> [2]: http://lists.w3.org/Archives/Public/public-coremob/2012Sep/0021.html
> [3]: http://techcrunch.com/2012/09/13/facebook-for-ios-review/
>

Received on Friday, 30 November 2012 17:41:50 UTC