Incorrect velocity when flinging drawer closed

[slightlyoff]

If you manually fling the drawer closed, the velocity isn't taken from the finger, it reverts to the default speed, causing an apparent "bump" or "slow down" in closing when flinging the drawer. This is a poor, inconsistent experience with native drawers.

Also, are these animations using the correct default curves for Android? ISTM they might not be (experientially).

/cc @ebidel

[WoodyWoodsta]

See here. This can be fixed by using ease-out which is only possible when they expose the mixins for the transitions.

I stand to be corrected, but catching the user's finger velocity and then using that to animate the panel is too clunky for what it is worth, at least in a browser.

[blasten]

@slightlyoff we have thought about fixing this. I think it's worth experimenting with it, at least in the new app layout system: https://github.com/PolymerLabs/app-layout

To achieve this behavior property, the easing function and transition-time might need to be dynamically computed based on the velocity vector.
cc @keanulee @frankiefu

[frankiefu]

@keanulee is working on getting this fixed in app-layout (PolymerElements/app-layout#51)

[slightlyoff]

Glad to see it's getting fixed. Will it also be repaired in <paper-drawer-panel>?

[ebidel]

+1 on fixing it here too. The majority of users will be using this element
for the near future.

On Mon, Feb 8, 2016, 3:23 AM Alex Russell [email protected] wrote:

Glad to see it's getting fixed. Will it also be repaired in
?

—
Reply to this email directly or view it on GitHub
#129 (comment)
.

[keanulee]

I'm currently working on having the drawer slide at a constant velocity when you "flick" the drawer open or closed (i.e. when swiping above a certain velocity threshold). Not sure if this matches the Android curves though - if someone could link to them that would be appreciated :)

Once this is in app-layout, we will consider adding it to paper-drawer-panel as well. (e.g. Is it possible to add this without breaking API/DOM structure? Do we want to deprecate paper-drawer-panel in favor of app-drawer?)

[ebidel]

@keanulee @blasten @frankiefu we're using this element for the I/O site. is it possible to add the velocity changes here?

[blasten]

@ebidel yup. we will!

[frankiefu]

@ebidel, yeah we were just talking about this earlier today. @keanulee mentioned it should be pretty straight forward to port the change over. I'd suggest to also consider using app-layout. The app-layout defaults to use document scroll and should provide a better mobile user experience.

[ebidel]

Do we think it's ready for production site? Don't want to bleed too hard on
the edge this year :)

On Tue, Feb 16, 2016, 9:52 PM Frankie Fu [email protected] wrote:

@ebidel https://github.com/ebidel, yeah we were just talking about this
earlier today. @keanulee https://github.com/keanulee mentioned it
should be pretty straight forward to port the change over. I'd suggest to
also consider using app-layout https://github.com/PolymerLabs/app-layout.
The app-layout defaults to use document scroll and should provide a
better mobile user experience.

—
Reply to this email directly or view it on GitHub
#129 (comment)
.

[frankiefu]

There are already a few production sites that I know which are using app-layout elements: Chrome Dev Summit, Polymer Polytechnic, and of course Polymer Summit. paper-drawer-panel and its counterparts have been out for a while so they are probably a bit more stable. But app-layout is better in terms of mobile user experience and performance in general. But I also understand if we're just trying to update last year's I/O site and simply fill in the new content then is probably easier to just keep using the same elements. I don't want to create more work for you :-)

[ebidel]

Yea exactly :) We have a few places now that hook into the element's scroller. That would need changing. I can investigate moving over to app-layout if there's time.

[dominikIncibit]

I just saw that the app-drawer element got used in the new IO website.
@ebidel How much work is it to introduce the new app-layout elements in an old project? As you used it for the IO site I suppose its stable and worth the switch? And will the change still get applied on this element?

[keanulee]

The app-layout elements are still versioned as experimental, meaning we still might change the API if we think it's worth it, but I feel it's mostly stable now (e.g. we might change the name of a public method, but the DOM structure is probably not going to change). As far as migration, it's usually just as simple as rearranging the DOM structure.

<paper-drawer-panel>
  <div drawer>Drawer</div>
  <div main>
    <button drawer-toggle>Toggle</button>
    Content
  </div>
</paper-drawer-panel>

to either:

<app-drawer>Drawer</app-drawer>
<div>Content</div>

or:

<app-drawer-layout>
  <app-drawer>Drawer</app-drawer>
  <div>
    <button drawer-toggle>Toggle</button>
    Content
  </div>
</app-drawer-layout>

Note that app-drawer-layout comes with built in support for responsive layout (i.e. split panes on wider viewports) and drawer-toggle, which may or may not be needed depending on your use case.

We may port the changes back to paper-drawer-panel later, but we're more focused on improving app-layout at this point.

[dominikIncibit]

Thanks for the advice!
I just did the transition and although it was a bit more work its definitely worth it!