For now let's keep the fade. We could start a bit earlier if we want, but I don't feel strongly.

We'll go with the fading option in M54. Keep current fade point. This is currently implemented.

Peter - this doesn't seem to work as intended on yesterday's trunk build. You can ask pke@.

Sorry, what do you mean by 'this is currently implemented, but doesn't work'?

+pke to clarify

Attached two screenshots.

The first shows the snapping position, where the box is still fully visible. The second shows a few pixels above, where the box is fading away.
The position where it snaps / starts fading is way too high.

Deleted: Screenshot_20160810-162724.png 128 KB

	Screenshot_20160810-162724.png 128 KB View Download

Deleted: Screenshot_20160810-162809.png 134 KB

	Screenshot_20160810-162809.png 134 KB View Download

Hi Peter,

did this make the M54 BP?

Thanks

Patrick

This has not made the branch point, I am hoping to get it merged though.

How does this look?

Deleted: 2016-08-29_14-07-51.mp4 8.0 MB

	2016-08-29_14-07-51.mp4 8.0 MB View Download

Hm - this feels like the transition is happening too close to the omnibox. Let's discuss in the weekly.

Documenting our discussion in the weekly. Pete will try starting the animation a second before reaching the top of the screen.

Thanks for the update, Rachel! :)

Pete, what's the status here?

I had discussed the desired result with Rachel, I've not got around to implementing it.

Rachel, how do these before and after videos look?

Deleted: 625145-before.mp4 2.3 MB

	625145-before.mp4 2.3 MB View Download

Deleted: 625145-after.mp4 3.7 MB

	625145-after.mp4 3.7 MB View Download

Thanks Pete!

Now it feels just a little early. Could you possibly tweak it to be somewhere between the two timing-wise?

How about this?

The other important question is how this will change NTP interaction. Do we want to snap scroll out of the entire animation region (so users cannot come to rest midway through the transition).

Deleted: 2016-09-16_10-16-15.mp4 6.4 MB

	2016-09-16_10-16-15.mp4 6.4 MB View Download

That looks good. 

//The other important question is how this will change NTP interaction. Do we want to snap scroll out of the entire animation region (so users cannot come to rest midway through the transition).

No, I think we should leave it as is for now. We'll do more work in this space a bit later on.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c68e23208ff63d1e6562443618a5310883d0efae

commit c68e23208ff63d1e6562443618a5310883d0efae
Author: peconn <peconn@chromium.org>
Date: Fri Sep 16 10:23:04 2016

[NewTabPage] Refine fakebox scrolling transition on tablets.

- Add the tab strip height factor into the transition equation to make sure the
transition is anchored to the top of the tab.
- Override ntp_search_box_transition_length to make the transition take longer
on tablets.

BUG= 625145 

Review-Url: https://codereview.chromium.org/2345673002
Cr-Commit-Position: refs/heads/master@{#419137}

[modify] https://crrev.com/c68e23208ff63d1e6562443618a5310883d0efae/chrome/android/java/res/values-sw600dp/dimens.xml
[modify] https://crrev.com/c68e23208ff63d1e6562443618a5310883d0efae/chrome/android/java/src/org/chromium/chrome/browser/ntp/NewTabPageView.java

Reopening this for even more refinement :)

Specifically, do we want to snap away from a state where the fakebox is partially transparent? It does look a bit strange to have that as a steady state.

OK to spend time experimenting.

How do we want to proceed here? Who is going to make the first step? :-)

What was the decision? I was not present on Nov 2.

I can't find any mention of this bug in the Zine UX meeting minutes from 2nd Nov (it was mentioned the week before, but no comments were made).

Rachel, what do you believe the next step is (can you expand on comment #25)?

I believe we agreed that it would be ok for eng to prototype changes to motion, but that we don't want to invest in this work on the ux side.

This will no longer apply with Chrome Home.