MenuFlyout and CommandBarFlyout have different opening animation

[roxk]

Describe the bug

A menu flyout opens by sliding in, whereas a command bar flyout opens by fading in.

Steps to reproduce the bug

1. Create MenuFlyout and CommandBarFlyout
2. Open them.
3. Observe different opening animation

Expected behavior

The animation should be the same?
Also, it seems the command bar flyout isn't aligned to the mouse cursor, whereas menu flyout is aligning perfectly.

It' be great if WinUI's figma can specify these kinds of animation as well.

Screenshots

2022-03-22_11-38-27.mp4

NuGet package version

Microsoft.UI.Xaml 2.7.0

Windows app type

• UWP
• Win32

Device form factor

Desktop

Windows version

Windows 11 (21H2): Build 22000

Additional context

No response

[github-actions]

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[DmitriyKomin]

@roxk, thank you for reporting this. The animations are different by design, there are no plans to make changes here.

[yaira2]

@DmitriyKomin can you please explain the rationale for this design choice? Depending on the item that's right clicked, we'll sometimes display a MenuFlyout and other times a CommandBarFlyout.

Having different animations appears to our users as a bug so it'll help if this issue is resolved or if there is an official explanation we can pass on to users.

[RichardLuo0]

Plz change this. I always feel the fade-in animation is very awkward

[codendone]

As the names of these flyout types may imply, their origins are in supporting different control contexts with different expected usage patterns. Each animation was chosen for that specific context. Using them directly side by side wasn't part of that design. While I can see the experience being a bit jarring in the way shown here, changing the animations would have other repercussions and likely require added customization that just isn't a priority at this moment relative to the severity.

[yaira2]

Animations can significantly impact the user experience, so this response is disappointing to me. I understand that the controls are independent, but there should still be consistency between them. While I agree that there are higher priority items, it would be beneficial for the community to keep this issue open for tracking.

It’s also worth noting that File Explorer uses them side by side, similar to how we do in Files. Given this, along with user feedback, it seems to me that it's necessary to reconsider this approach.

[0x5bfa]

Every flyout (Flyout, MenuFlyout, CommandBarFlyout) has each different transition. When you want to put some custom controls you have to use Flyout but sometimes you'd like to keep consisntency. Also, we don't expect different transition to the similar control types for different usecase (left click or right click).

[p3rid0t]

I think this issue should be reopened and reconsidered, even if just to provide a space for discussion.

The CommandBarFlyout animation feels sluggish. It takes too long to open, and often suffers from stuttering or disappearing altogether. Plus it adds even more unnecessary inconsistencies into the Windows UI ecosystem...

My two cents: I'd consider replacing the custom fade animation with the Flyout animation. Why?
The MenuFlyout animation wouldn't fit as it would be too fast (and CommandBarFlyouts are usually bigger than MenuFlyouts)
Meanwhile, normal Flyouts have a smoother animation that is more appropriate and optimized for larger surfaces.