Microsoft-ui-xaml: Proposal: Remove Button Tilt

[kikisaints]

Proposal: Remove Button Tilt

Summary

Remove the Button tilt animation in the control's default template.

Rationale

Internal analysis of first party and third party apps have shown that the majority of re-templates for button are made simply to remove the button tilt behavior. In a large study of our internal apps - which consisted of: calculator, alarms, camera, settings, messaging, photos, voice recorder - 65% of them had re-templated buttons and all had removed the tilt - even on buttons that were not altered in any other way besides the animation removal.
The utility apps in many ways are an example of default design system at work, however these apps are opting out of the tilt animation as they don't feel it add anything to their apps' overall experience.

Re-templating can incur a lot of extra overhead for a developer when they have to take ownership of a control that they largely do not wish to maintain outside of this one animation change. Not to mention the fact that re-templated controls add-up in terms of performance on load.

[mrlacey]

Is there any knowledge of why the tilt is being removed? Is it just a developer preference?
Is there any similarity between the apps that remove it and those that don't? Is it just one designer/team who prefers to see it removed?
Why was the tilt originally added to the default template?

"notable study of internal apps"
???

Has there been any analysis of apps in the store?

Just because 46% of a small sample do something isn't reason on its own to change the default. Is it?

[kikisaints]

Is there any knowledge of why the tilt is being removed? Is it just a developer preference?

As far as the knowledge to why tilt is being removed - it's mostly because of both a developer and a designer preference. In many cases these design choices are made to imitate their web versions. Of which many buttons are more "flat" and don't involve animations.

Is there any similarity between the apps that remove it and those that don't? Is it just one designer/team who prefers to see it removed?

Apps that do not remove tilt tend to have a less branded experience.

Why was the tilt originally added to the default template?

It was originally added as a cosmetic statement for our design system at the time.

Has there been any analysis of apps in the store?

Just because 46% of a small sample do something isn't reason on its own to change the default. Is it?

The analysis was done on apps in the store. I pulled out a small example for the sake of keeping the rational section concise - that one app itself had re-templated buttons for the sole purpose of removing tilt and had done so to 46% of the buttons in their app. This is a pattern we've seen elsewhere, though.

The same study also looked at our "utility" apps - which consist of: calculator, alarms, camera, settings, messaging, photos, voice recorder - of which 65% of them had re-templated buttons and all removed the tilt. Aside from that, the only additional changes made to the template were color alterations. However, this study was done before the introduction of Lightweight styling so availability to more easily customize colors was limited.

I have also personally conducted sit-downs with our internal teams about the reasoning to why they removed tilt and most responded with either it did not fit their brand, or design did not want it.

That being said, it could be that our internal reviews do not reflect what the community and our general developer base wants. Hence the desire to proposal a removal to everyone for debate.

Edit: Added more info from the study mentioned here to the main feature proposal post.

[mdtauk]

Tilt first appeared in the Windows Phone UI, and came about because of the IRIS UI they used in that, which was in 3D space, so tilt and tile flipping all worked with a scene camera.

There were tutorials at the time for devs to implement the same tilting in their XAML silverlight apps.

I guess it was some time in Windows 8 or early Windows 10 that they introduced theme animations to WinRT.

Rather than remove the effect, you could always add a property to override the effect on Pressed state

[JustinXinLiu]

I have been a big fan of the tilt effect since the Windows Phone days. When done right (e.g. dribbble & Timeline design), it just feels so alive and futuristic.

However, I no longer use it on buttons in any of my new projects. Here's why:

1. The current tilt animation feels sluggish and disconnected. The text within the button even gets blurry during the animation. The overall experience just isn't great.

2. Tilt doesn't make much sense on circular icon buttons, and I want all my buttons to have a consistent interaction effect (e.g. I use _scale_ most of the time).

3. Given that controls are more compact than ever, tilt simply doesn't give me the 2.5D feel when the button is small.

Having said this, I think it's probably much safer to disable it by default, but offer an option to enable it. After all, just like the ripple effect in Material Design, it does remind people that this design comes from Windows, which to me is a good thing.

[jevansaks]

Is the proposal to just remove tilt?

I was under the impression design wanted to refresh the animation -- do away with tilt but still have some kind of press effect? We've talked about removing tilt for a while but we never did it because there wasn't a proposal to replace it with and it feels worse to remove it and have nothing (even though it feels dated as other commenters mentioned).

[mdtauk]

If Buttons are going to be given depth and a shadow - the tilt effect would ruin that illusion. I guess Microsoft Design internally have plans which are not discussed publically.

[kikisaints]

Is the proposal to just remove tilt?

I was under the impression design wanted to refresh the animation -- do away with tilt but still have >some kind of press effect? We've talked about removing tilt for a while but we never did it because >there wasn't a proposal to replace it with and it feels worse to remove it and have nothing (even >though it feels dated as other commenters mentioned).

Yes the proposal is to simply remove it. Last we spoke to design they had some plans around a different animation, but nothing concrete. They did agree that it needed to be removed altogether because of the outdated-ness of it's appearance. However, there was no better solution proposed since, so we've let the animation sit.

Another way/alternate solution we could do, is to allow disabling it without completely getting rid of it. We could template bind that animation so an app-developer can toggle it outside of the template:

<VisualState x:Name="Normal">
     <Storyboard>
        <PointerUpThemeAnimation Storyboard.TargetName="RootGrid" IsEnabled="{TemplateBinding TiltOnPress}" />
     </Storyboard>
</VisualState>

A result to the effect of what @mdtauk was referring to.

[mrlacey]

Ha, reminds me of early WP7 days when I spent ages adding the tilt effect to controls because it didn't get added by default.

[chigy]

@kikisaints - I have not received official request to remove the tilt from the design team. As far as I understand, some button retemplate was due to the lack of flexibility to turn off tilt without retemplate and some buttons like title bar buttons did not make sense to have tilt. Today, tilt is used as a press state equivalent on Xbox where the button depresses so we cannot just remove it without considering what the removal means to the press and hover state on all the platforms we support.

[bschoepke]

I'd suggest making it easy to opt-out of tilt via "lightweight styling" on a global, per-control-type, or per-control-instance basis:

https://docs.microsoft.com/en-us/windows/uwp/design/controls-and-patterns/xaml-styles#lightweight-styling

the more we can do to prevent the need for re-templating the better. I'd also maybe take the opportunity to allow devs to use lightweight styling to supply custom theme animations.

[stmoy]

@kikisaints - the tilt animation is provided as a visual affordance that is specified by PointerDownThemeAnimation. I agree with @chigy that we'll need some sort of press feedback by default, so we could consider modifying the animation provided by PointerDownThemeAnimation.

[kikisaints]

@stmoy and @chigy - I'm somewhere in the middle. I don't believe we should replace the animation with another, unchangeable/un-customizable animation. That feels odd.

@bschoepke - I like this line of thinking, my only worry is that lightweight styling relies heavily on your knowledge of resource keys and names. Which can become cumbersome and explodes generic.xaml considerably.

My reason for complete removal is that if the majority do not use tilt, maybe it's causing more issues than it's solving.

That being said, perhaps the crux of the issue here isn't the tilt itself, but how we've structured our styling system all-up...

[JustinXinLiu]

I think we still need a _signature_ visual feedback on pressed state for most our interactive controls (e.g. Button, AppBarToggleButton, ComboBoxItem, ListViewItem, etc.) that could instantly differentiate themselves from other design languages.

It's like whenever I click a button and see the ripple, I know it's from Material.

Currently, we have reveal and tilt. But the former is not turned on by default and only works well with dark background. The tilt just doesn't look good anymore.

However, I am just concerned that if we removed it completely without a replacement, the controls could lose their Fluent design identity. I did some experiment in the past and would love to see if our design team can come up with something that embraces Fluent features like light, depth, material and motion. ;)

[mrlacey]

Most importantly, if I'm "pressing down" on a button, how do I know it's recognizing that touch or identifying that the thing I think I'm touching is the one that's actually going to respond, if there is no visual indication?

[JustinXinLiu]

@mrlacey there will still be some color changes on the background, foreground and border, but I don't think they are enough...

[JohnnyWestlake]

I'm going to chip in and say I don't see a need for removing it, but an easy TemplateBinding or even global toggle for it for those who want it wouldn't go amiss. One thing I will say when I've done client projects is they generally preferred it if the animation only affected the content of the button and not the border / background, so I usually ended up retemplating for it to affect the ContentPresenter instead. Still obvious depression, but a little nice.

Depression is also quite nice when using physical keys (like keyboard, media remotes, gamepads).

Or, even if it is removed, as long as PointerDownThemeAnimation still exists at least I can still put it back in easily - so in that case I'd like to chuck in a vote for not changing the default PointerDown/UpThemeAnimation but replacing it with a new one?

[mdtauk]

Whether you keep the tilt or remove it/replace it

I think there is something to be said for adding a ThemeAnimation property, which is changable in XAML or codebehind - without a need for re-templating - would suffice until the Fluent Team know exactly what they want to do for button pressed animations across all MUX controls.

[kikisaints]

@JohnnyWestlake interesting that there is a desire to have tilt on the presenter but not the border, it would seem that even if we had a toggle for the animation (either through lightweight styling or a property) it wouldn't really solve your scenario where you need to alter what the animation affects, not whether or not it's there... thanks for the insight!

[lukasf]

@kikisaints This could be solved by having an enum TiltMode: { Disabled, Control, Content } ;) Not sure if it is a relevant scenario though.

Personally, I'd prefer a clean "move down/shrink, move up/grow" animation instead of tilt. Having a ThemeAnimation property would make it easy to change that animation.

[mdtauk]

If all the tilting is in the State Transition - simply replacing that with an empty transition would turn off the effect.

That means the ButtonBase could have a Transition property for each state, allowing easy ways to override them?

Probably not until WinUI 3.0, when the source code for the Button and ButtonBase primitives are in the repository.

[Poopooracoocoo]

I really dislike the tilt effect in menus but I'm fine with it on buttons

[sylveon]

With the advent of XAML Islands, I am now in a state where I need to implement a close button in XAML for my XAML Island windows. The tilt animation is the last remaining thing before I get consistent with the normal system controls, so adding the possibility to opt-out via a single property would be nice, instead of having to retemplate the whole control (which I'd really like to avoid)

[Felix-Dev]

@kikisaints @chigy @YuliKl Experimental work https://github.com/microsoft/microsoft-ui-xaml/pull/3514 removed the button tilt effect for now without a replacement. Can we expect more design evaluations about the tilt effect (i.e. replacing it with a different animation, making it opt-in,....) or should we expect only foreground/background button color changes from now when pressing a button?

The new XAML re-design stresses that it wants to keep the new UI familiar to Windows users and reading through some of the comments here, the tilt effect seems have become part of the Windows UI DNA since its introduction. This sounds like a case to modify the tilt effect/replace it with a different animation (for example to cover the Depth aspect of Fluent Design) instead of just outright removing it.

[chigy]

@Felix-Dev , we are not currently looking at replacing tilt with another effect, but it doesn't mean we might not introduce something in the future. New design is not built to rely on tilt, so adding additional effect later will only strengthen, but not weaken it, IMO.

Tilt effect was a carry over of Metro design but it does not have a place in the current design language. It has issues such as the text scaling made things look fuzzy, over tilting, etc. and does not fit in our cleaner UI model.

If anyone is very sad to see tilt gone, it would be some of us who worked on phone to introduce it in the first place including myself. :) But we all understand why our design is better without it.

[Jaiganeshkumaran]

@chigy Please don't remove this. It may not have a place in the current design language however combining with reveal makes it better so it could be an optional thing. Also, the issues that you mention can be fixed like text scaling instead. Please don't do this because the web and other platforms don't have it. I'm worried that Fluent is becoming more material day by day. You first removed Acrylic from NavigationView, then broke reveal in the button control and now you have the dumb flat old look. Please don't say that makes it consistent with other platforms. macOS has acrylic everywhere but you removed it from NavigationView.

[Poopooracoocoo]

Tilt effect was a carry over of Metro design

The square/tile aesthetic is still unique as both Google and Apple have very round elements. There are some elements in some new designs that have a pill/stadium shape and it makes me think about unique elements in Microsoft's design. The tilt isn't one of them anymore. Office's new logo still has the angle that was consistent with the button tilt and the animation for opening apps in Windows 8. Windows 8 and Windows 10 did quite a bit to remove rounded corners, so if MS decides to implement them (like window borders), it'll be quite the task.

I honestly never liked the reveal effect and I expected that to get the chop first. The button tilt's text issues got on my nerves but those were bugs where the effect got stuck. As I said a year ago, I really dislike the effect in menu items. Holy cow, where has the time gone? A whole year. darn 😢

[Jaiganeshkumaran]

The tilt effect provides visual feedback, especially on touch devices. Please don't remove it.

[dragonDScript]

I think exactly the same @Jaiganeshkumaran
The tilt effect provides visual feedback, which improves user experience. And as @Jaiganeshkumaran, especially on touch screens where you don't have a mouse and don't feel that.

[chigy]

@Jaiganeshkumaran , @dragonDScript , @Poopooracoocoo , @Felix-Dev ,
Thank you for your comments. As someone who was part of the team that introduced tilt back in phone days as well as brought it to Windows, tilt removal is somewhat personal so I understand your feeling. So I can assure you that this decision was not made in a vacuum. That said, tilt as in today's form no longer fits within our design language and rather than trying to reuse what is no longer working (let alone it has many issues that makes this animation not super desirable), we decided to snap to a clean design that we can improve on top of.

[Jaiganeshkumaran]

@chigy Why? Because the Windows team is increasingly going towards using web components in their OS. Since web frameworks don't have such effects, if they remove it they can have a consistent UI with the new web stuff and they don't need to update their framework.

[mdtauk]

@chigy Why? Because the Windows team is increasingly going towards using web components in their OS. Since web frameworks don't have such effects, if they remove it they can have a consistent UI with the new web stuff and they don't need to update their framework.

With CSS Perspective and Perspective-Origin - the tilt effect could be replicated on the web, but its not about replicating, an effect the design team no longer wishes to use. Also web technologies have been built into windows since Windows 98. Those rich folder views and control panel UI was done with HTML code built into the File Explorer code.

The blending/merging/melding of WinUI Xaml control designs and web, is a recognition that many more apps will choose to create apps on different frameworks.

One of the major complaints about Windows apps, is a lack of design consistency.

So, with a set of controls which look as identical as possible, use Fluent Designs, and a set of FluentUI components that are cross platform - this is how you begin to fix an inconsistent UI.

All windows native frameworks should eventually use a unified design IMO Project Reunion Proposal

And then the new frameworks like Flutter which is web based, should have a FluentUI theme available, and ReactNative uses WinUI to render XAML UIs - so widening the amount of frameworks devs can pick for making Windows Apps

[Jaiganeshkumaran]

@mdtauk Those web stuff ran in IE which was really lightweight. Although Chromium is better, loading it in every process multiple times like Electron causes huge performance issues. Also, Fluent UI should be styled to add WinUI styles like Reveal etc... and not the other way around. Tilt effect can go away but they should consider making Fluent UI more like WinUI as well. Fluent UI is just a rebrand of Office UI Fabric that they are calling Fluent. If designers want to remove this effect, let them remove it but overall WinUI is just becoming like Fluent UI and not the other way around.

[mdtauk]

@mdtauk Those web stuff ran in IE which was really lightweight. Although Chromium is better, loading it in every process multiple times like Electron causes huge performance issues. Also, Fluent UI should be styled to add WinUI styles like Reveal etc... and not the other way around. Tilt effect can go away but they should consider making Fluent UI more like WinUI as well. Fluent UI is just a rebrand of Office UI Fabric that they are calling Fluent. If designers want to remove this effect, let them remove it but overall WinUI is just becoming like Fluent UI and not the other way around.

... Fluent UI should be styled to add WinUI styles like Reveal etc...
Acrylic within the browser window is being experimented with I believe.

Reveal may well be changing, so possibly in a way that can work on the web too, but @chigy would know more about that. I made my thoughts clear in the discussion thread #1126 _Proposal: Improve reveal visual_

... loading it in every process multiple times like Electron causes huge performance issues ...

Electron is not a great experience, hopefully Microsoft can transition away from it to PWAs and even better React Native for their web based apps

... they should consider making Fluent UI more like WinUI ...

I very much agree with this. FluentUI 8.0 is looking to add Design Tokens, and so is WinUI - so hopefully the designs for both will match.

... Fluent UI is just a rebrand of Office UI Fabric ...
When the name changed, the controls all received a design refresh to adopt more Fluent Design looks and styles. It started as an opt in, and became the default.

https://github.com/microsoft/fluentui/issues/8038