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

On 11/30/12 6:41 PM, "Dean Jackson" <dino@apple.com> wrote:

>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.

As confirmed by Tab in his previous email, I opened my mouth a bit too
soon. Sorry about that. :-/

I completely agree focus on fixing current problems is key.

>>    "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.

Yes, I'm aware some of the constraints enforced by UITableViews are key to
its perf.

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

Understood.

>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.

Thanks for these insights. Can we bring this to the web? (Pretty please.)

>> 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.

Awesome. Again, sorry for mis-targeting my rant.

--tobie

Received on Friday, 30 November 2012 17:56:24 UTC