Proposal: Adding a Expander Control to the set of WinUI controls.

[ejserna]

Proposal: WinUI Expander Control

A spec has been opened with a PR for this issue. Feel free to continue general discussion in this proposal!

Summary

Throughout Windows, different expander controls are used by Windows Security, Settings, Photos, Paint 3D, the Notification Center, 3D Viewer, Toasts and the UWP Onedrive app. There’s currently no consistent "Windows" way of addressing this common UX pattern. An Expander control is motivated by both its use in many app scenarios and achieving parity with WPF.

Rationale

• There should be a built-in and consistent Fluent way to expand and collapse content.
• Expander scenarios exist across many surfaces that are not aligned in behavior and style, including being Narrator-friendly, keyboard controls, animations, designs, and high contrast changes.

Scope

Capability	Priority
Provide consistent expander behavior across WinUI apps	Must
Expand in size (pushing other content) and collapse based on user interaction with the control	Must
Support controls like Button, ToggleSwitch in the unexpanded and expanded content	Must
Support Expanding in all 4 directions	Should*
Support modifying all content (including the header) in expanded state	Could
Support expanding an InfoBar (open question on implementation)	Could
Include "accordion behavior" logic between Expanders	Won't
Be light dismissible	Won't

*The v1 Expander could be scoped to only expand in the downwards direction, with default down and ExpandDirection added later.

Important Notes

Proposed API

Public enum ExpandDirection 
{ 
Down = 0 
Up = 1 
Left = 2 
Right = 3 
} 

public class Expander : ContentControl 
{ 
Expander(); 

public object Header {get;set;} 
public DataTemplate HeaderTemplate { get;set; } 
public DataTemplate HeaderTemplateSelector {get;set;} 

public static readonly DependencyProperty HeaderProperty; 
public static readonly DependencyProperty HeaderTemplateProperty; 
public static readonly DependencyProperty HeaderTemplateSelectorProperty {get;} 

public bool IsExpanded { get;set} 
public ExpandDirection ExpandDirection { get;set;} 

protected virtual void OnExpanded(); 
protected virtual void OnCollapsed();

public event Expanded; 
public event Collapsed; 

public static readonly DependencyProperty IsExpandedProperty; 
public static readonly DependencyProperty ExpandDirectionProperty; 
} 

Visual States:  
ExpandStates: Expanded/Collapsed 

Accessibility: 
Support Expand/Collapse pattern (IExpandCollapseProvider) 

Expander Controls Elsewhere

• WPF
• Windows Community Toolkit
• Telerik UI
• Xamarin.Forms
• Syncfusion.XForms.Expander
• Avalonia UI

Examples of Expander Scenarios

Open Questions

• In discussion with the WinUI team, it was brought up that a V1 scoped to expand downward would shorten development time and make Expander available for developers sooner (as the scenarios for Expander thus far have all been downward), and a planned V2 could add ExpandDirection soon after. In your apps, are there any scenarios where Expander would need to expand in directions other than downward?

• How should Expander work with InfoBar? Adding expanding functionality to InfoBar? Putting InfoBar as the content of an Expander? The reverse?

[robloo]

Expander is very useful and I've been using the Windows Community Toolkit version since it was added. I wouldn't re-invent the wheel too much though, just porting over the code from the toolkit would be perfect for version 1.0 in my opinion.

Another example: the ColorPicker with it's 'MoreButton' could use this.

[kat-y]

Thanks so much for submitting this proposal! I'm going to make some edits, including differentiating between what I think are true Expander scenarios and what are more like Flyout/MenuFlyout uses.

[kat-y]

I've updated this proposal to include more details on the scope, a proposed API, and the following open question.

• Do we need to support ExpandDirection in a v1 Expander? Are there common app scenarios where Expander would need to expand in directions other than downward?

Would love feedback on how these fit or don't fit with your use cases for Expander!

[mdtauk]

I've updated this proposal to include more details on the scope, a proposed API, and the following open question.

• Do we need to support ExpandDirection in a v1 Expander? Are there common app scenarios where Expander would need to expand in directions other than downward?

Would love feedback on how these fit or don't fit with your use cases for Expander!

It does seem like a basic function of the control

[kat-y]

It does seem like a basic function of the control

@mdtauk do you see ExpandDirection other than downward being a common app scenario? The examples of Expander behaviors that I see are far more often expanding downwards - I would definitely like Expander to have ExpandDirection but is it necessary in a v1?

[robloo]

Yes, we need expand direction. There are many cases for using it and it would be an unnecessary breaking change to the control template after a v1 release to add it. The Expander API hasn't changed much since WPF and the proposal here has all the necessary properties/events/methods already. I would just implement it all in one shot and we can be done with this control. Design-wise the UWP Community Toolkit made the necessary changes to better work with touch. I think we have all the pieces and there is no need to re-invent anything.

Edit: The community toolkit also has a ContentOverlay property. That might be something to skip in a V1.

[kat-y]

Yes, we need expand direction. There are many cases for using it and it would be an unnecessary breaking change to the control template after a v1 release to add it.

@robloo Could you elaborate on how this would be a breaking change? My understanding is we could avoid it being breaking with V1 having downward expansion, and V2 could add ExpandDirection and default to downward.

[mdtauk]

It does seem like a basic function of the control

@mdtauk do you see ExpandDirection other than downward being a common app scenario? The examples of Expander behaviors that I see are far more often expanding downwards - I would definitely like Expander to have ExpandDirection but is it necessary in a v1?

Chat apps which load new list content from the bottom up being one of them maybe.

Beyond the very basic essential:

• IsCollapsed
• IsExpanding
• IsExpanded
• IsCollapsing

As well as IsEnabled

The next core thing is where to expand to.

• ExpandUp
• ExpandDown
• ExpandLeft
• ExpandRight

[kat-y]

Chat apps which load new list content from the bottom up being one of them maybe.

@mdtauk I don't fully understand what you mean with this chat apps example - could you elaborate? As for the properties - the proposed API is based off the WPF Expander so I think IsExpanded and ExpandDirection would cover them. What would IsEnabled be used for - is there an app scenario where you'd want to disable an Expander?

[robloo]

Another example I've used in the past are secondary, editable properties that should usually be hidden. These are shown at the bottom of an editor only when clicking an 'options' button and the expander opens upwards. It's really just up to the design you are going for. There are many useful cases for expanding different directions and it seems unnecessary to artificially restrict this especially when past convention is so strong. I don't think any of this would be too difficult in a V1 of the control especially since all the problems have already been solved in the community toolkit and WPF.

@robloo Could you elaborate on how this would be a breaking change? My understanding is we could avoid it being breaking with V1 having downward expansion, and V2 could add ExpandDirection and default to downward.

https://github.com/windows-toolkit/WindowsCommunityToolkit/blob/master/Microsoft.Toolkit.Uwp.UI.Controls/Expander/Expander.xaml

I suppose if you are very careful in designing the template and visual states it is possible to make it non-breaking. However, to do that you really need to design the functionality anyway so you might as well implement it. This is all fairly basic and there is no reason for a V2 plan from the get-go on this control.

I know its enticing to re-invent the wheel. But please keep it so people porting apps from WPF to WinUI can do it without anything but absolutely necessary code changes. WinUI needs to start correcting some of the mistakes with UWP.

[robloo]

What would IsEnabled be used for - is there an app scenario where you'd want to disable an Expander?

@mdtauk Is correct, this needs to support IsEnabled as well. Disabling controls is pretty strong convention anytime there is the possibility of input or state change. Please don't make us defend that.

[JustABearOz]

In the screenshots above, windows security has an expander for the antivirus section as well as the left navigation menu. This shows a very realistic use of the expander in more than one direction that a lot of apps would need to support. My vote is for supporting multiple directions in V1.

[kat-y]

@robloo

Another example I've used in the past are secondary, editable properties that should usually be hidden. These are shown at the bottom of an editor only when clicking an 'options' button and the expander opens upwards.

Could you elaborate with a screenshot or specific app where this happens so I can understand the scenario more? I can think of editors where a options button opens a popup with more buttons, but in the ones I'm familiar with the other content isn't pushed upwards - a popup/flyout behavior rather than an expansion.

I suppose if you are very careful in designing the template and visual states it is possible to make it non-breaking. However, to do that you really need to design the functionality anyway so you might as well implement it. This is all fairly basic and there is no reason for a V2 plan from the get-go on this control. I know its enticing to re-invent the wheel. But please keep it so people porting apps from WPF to WinUI can do it without anything but absolutely necessary code changes.

I agree with you that porting apps from WPF to WinUI should be as smooth as possible! In discussion with the WinUI team, it was brought up that a V1 scoped to expand downward would shorten development time and make Expander available for developers sooner (as the scenarios for Expander thus far have all been downward), and a planned V2 could add ExpandDirection soon after. (I'll edit the open question to have this additional context) This is why I'm hoping to understand if there are specific use cases developers have for non-downward Expander! 😄

Disabling controls is pretty strong convention anytime there is the possibility of input or state change. Please don't make us defend that.

Thanks for explaining this, it totally makes sense that disabling the state change is a desired feature for this kind of control!

[kat-y]

In the screenshots above, windows security has an expander for the antivirus section as well as the left navigation menu. This shows a very realistic use of the expander in more than one direction that a lot of apps would need to support. My vote is for supporting multiple directions in V1.

@JustABearOz I think the left navigation menu is a NavigationView, actually. 😃 I agree that the antivirus section is an Expander scenario, in this case expanding downwards. Would love to know any specific use cases you have for non-downward Expander!

[JustABearOz]

@kat-y Ok, that takes away a need for left/right, but 2 examples in windows that seem to expand up that could easily apply to apps: 1: The screenshot above with the quick actions menu. Pretty sure that expands up. 2: In windows, the popup calendar form the system tray has a section which expand up to show agenda/appointments.

Is it possible to support Up/Down for V1 instead of just Down?

[kat-y]

1: The screenshot above with the quick actions menu. Pretty sure that expands up.

@JustABearOz thanks so much for bringing up these examples! For 1: I think this is an interesting edge case - the expansion is 'downwards' from the 'header' (the expand button), but the control itself is positioned at the bottom of the surface so the header (and the expanded content) has to 'shift' upwards (otherwise it would run off the screen!). Seems like a good way to handle having an expanding item at the 'bottom' of an app, do you agree?

2: In windows, the popup calendar form the system tray has a section which expand up to show agenda/appointments. Is it possible to support Up/Down for V1 instead of just Down?

I agree with you, this is a scenario where the header is at the bottom of the area and expands up! In this case the calendar's expander (and the popup as a whole) is tied to the taskbar - have you encountered scenarios in apps where expanders have a similar tied positioning that necessitates upward expansion?

[robloo]

@kat-y I mean no offense but I feel like we are having to re-explain things that were known 15 years ago. I don't understand why you are asking us to give examples of expand direction in real-world usage. I expect internally you have to take this to spec review and defend it to management. But the explanation can simply be (1) you need to empower users to achieve their design targets, it's not up to Microsoft to say what is/is-not possible to do with controls it's up to app developers/designers to discover what is best for their use-case (a critical concept for look-less controls) (2) Most importantly, this is not a new idea at all. You are copying over an existing API in this area and need to maintain app compatiblity. Again, if this was a new idea I would understand more why we have to defend it -- it's good to make sure features are useful before investing the time in them.

Aside from the header there are literally two properties in this control and if it was C# I could write it in a few hours using the WCT base. We will spend more man-hours just talking about it than implementing it as it exists today in WPF/WCT.

[michael-hawker]

Thanks @robloo for the input, I'm reaching out to the WinUI team to discuss how we can make these proposals more robust initially when they exist in other third-party libraries like the Toolkit. I definitely think it should be something part of the issue template to call out existing examples.

FYI @ranjeshj @ryandemopoulos @stmoy

[kat-y]

@robloo Thank you for being honest with me! I understand that app developers should be able to determine what fits their use-case best, and that app compatibility is important. I'm hoping that discussion with @michael-hawker and the WinUI team will help us move forward productively in scoping Expander!

Previously I didn't have any concrete examples of Expanders being used in non-downward direction. I will bring any examples from the WinUI community (including the calendar flyout that @justABearOz pointed out) and any that I learn from Michael to discussions with the WinUI Team as evidence for keeping ExpandDirection in v1 of Expander.

I've updated the proposal with a list of Expander controls I'm aware of - let me know if I've missed something.

• WPF
• Windows Community Toolkit
• Telerik UI
• Xamarin.Forms
• Syncfusion.XForms.Expander

[robloo]

I've taken a look at both the WPF source code and WCT source code. I'm confident this can be implemented in WinUI in a few hours as well. The control should follow the WCT implementation from what I've seen although the ContentOverlay property probably should be renamed or left out of V1.

WPF: https://github.com/dotnet/wpf/blob/master/src/Microsoft.DotNet.Wpf/src/Themes/XAML/Expander.xaml https://github.com/dotnet/wpf/blob/master/src/Microsoft.DotNet.Wpf/src/PresentationFramework/System/Windows/Controls/Expander.cs

WCT: https://github.com/windows-toolkit/WindowsCommunityToolkit/tree/master/Microsoft.Toolkit.Uwp.UI.Controls/Expander

As both of these sources are from Microsoft and licensed MIT they should be the base, don't start from zero. Xamarin Forms does not align with the concepts of WPF->WinUI so should probably be disregarded (there is no additional functionality either). The 3rd party solutions also don't have any groundbreaking new ideas from what I've seen. This control has largely stood the test of time.

[robloo]

@robloo Thank you for being honest with me! I understand that app developers should be able to determine what fits their use-case best, and that app compatibility is important. I'm hoping that discussion with @michael-hawker and the WinUI team will help us move forward productively in scoping Expander!

Previously I didn't have any concrete examples of Expanders being used in non-downward direction. I will bring any examples from the WinUI community (including the calendar flyout that @JustABearOz pointed out) and any that I learn from Michael to discussions with the WinUI Team as evidence for keeping ExpandDirection in v1 of Expander.

Well, my point is there really shouldn't be too many discussions about this. I'm choosing to voice my frustrations here as this control is a perfect example. The new pager control or bread crumb controls do need more oversight and it's important to follow the process. However, the overhead of a large process is showing through here and again, you will spend far more man-hours doing non value-added paperwork and discussions that just implementing the control from WCT. I've also yet to see the WinUI team use other, prior work which is somewhat of a concern. There is no need to re-engineer the XAML control template.

[mdtauk]

Welcome to the WinUI project @kat-y - Xaml has a long history but can be a little quirky to those new to it. While WinUI is an opportunity to rethink how things work, in this case, expander is a relatively simple control and so a simple move from WPF to WinUI should suffice.

@robloo I disagree with your assertion that there is no need to re-engineer the XAML control template. WPF AFAIR has a number of chrome like elements which would be out of place in WinUI/Fluent.

Handling the Chevron and touch target sizes, as well as using the font scaling sizes. The Chevron should be easy to remove, or to add.

This example has a chevron in line with the text.

This example has no chevron at all

This example has a preceding side facing chevron

---

As for the implementation, there should be an animated transition when opening and closing, unless the user has turned off animations, then it just switches states.

[marcelwgn]

As for the implementation, there should be an animated transition when opening and closing, unless the user has turned off animations, then it just switches states.

I was just about to ask about animations. Should there be a way to disable them for the control, e.g. in scenarios where animating layouts would be too expensive? Not all users/developers want animations for such things as it might feel a bit to unresponsive or just not wanted (e.g. TreeView). Having to not retemplate the control to customize that point might be better. Another thing that could be customizable is the animation duration, in some cases short animations are better then longer ones.

[ranjeshj]

Thanks for all the great discussions. some thoughts

• We will need to update the template as @mdtauk mentions to account for new design as well as opportunities to reduce the elements/improve performance if possible.
• IsEnabled is inherited from Control, so I would expect that to work.

[mdtauk]

As for the implementation, there should be an animated transition when opening and closing, unless the user has turned off animations, then it just switches states.

I was just about to ask about animations. Should there be a way to disable them for the control, e.g. in scenarios where animating layouts would be too expensive? Not all users/developers want animations for such things as it might feel a bit to unresponsive or just not wanted (e.g. TreeView). Having to not retemplate the control to customize that point might be better. Another thing that could be customizable is the animation duration, in some cases short animations are better then longer ones.

I believe some controls have a Transition property that could be assigned to. So if a non-animated storyboard was included as a resource, it could be applied and that handles that without any retemplating.

You would have to override the transition when the system setting turns animations off.

UIElement.Transitions? https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.uielement.transitions?view=winrt-19041

Also with the IsEnabled property, there needs to be a Disabled state. Should there be a Disabled Expanded, and Disabled Collapsed, or is Disabled always collapsed?

[ranjeshj]

Interesting point about animations. We turn off all animations with the system setting, but I don't think we expose knobs to turn off animations other than by re-templating currently.

[stmoy]

Interesting point about animations. We turn off all animations with the system setting, but I don't think we expose knobs to turn off animations other than by re-templating currently.

I believe you could add a Style that overwrites the Transition collection with null in the case that you want to turn animations off, assuming there is a Transition collection to overwrite.

[mdtauk]

Including an ExpandTransition and CollapseTransition, that can use the direction set by the control's property - which could allow the dev to set the transition for each.

I like the idea, but I don't think there is a way today to create custom theme transitions which would limit the ability to customize. This would allow easily disable it though by removing it.

[Felix-Dev]

Also with the IsEnabled property, there needs to be a Disabled state. Should there be a Disabled Expanded, and Disabled Collapsed, or is Disabled always collapsed?

Why not mirror the TreeView control where you can use the IsExpanded and IsEnabled properties to create whatever combination you need of the two? If disabled expanded works best in some case, that can be done. If you need disabled collapsed, that is possible too this way.

[robloo]

@robloo I disagree with your assertion that there is no need to re-engineer the XAML control template. WPF AFAIR has a number of chrome like elements which would be out of place in WinUI/Fluent.

@mdtauk Well, my recommendation was we "should follow the WCT implementation" here: https://docs.microsoft.com/en-us/windows/communitytoolkit/controls/expander. The design changes to adapt to touch and a more modern interface were already made. Of course no one can do designs as good as you so I'm sure there is room for improvement. Still changing the 'design' wouldn't require re-engineering the template to support all expand directions. WCT should be the base and then if we have new styling to apply, very well, it can be done quickly but not from scratch.

[mdtauk]

@robloo I disagree with your assertion that there is no need to re-engineer the XAML control template. WPF AFAIR has a number of chrome like elements which would be out of place in WinUI/Fluent.

@mdtauk Well, my recommendation was we "should follow the WCT implementation" here... I assumed you meant no changes from the WPF version's XAML

But I still think the WinUI design team will need to okay it and its variants - if only to confirm the spec to include in the figma toolkits

[robloo]

@kat-y If you are new to the project I apologize if I was sounding harsh. I do stand by my points above on how the project speed can be improved in some areas which is surely needs. Also, how we should use what has already been done in the past and heavily battle tested over the last 15 years. Of course none of this is directed personally to you or to anyone. It is a general 'bloat' problem I've seen with Microsoft for years where the teams need to be more streamlined and rebalanced in favor of more coding/less project management. As good as plans are nothing beats trial and error so speed of iteration wins in the end.

@ranjeshj @michael-hawker Why not use what is already done in the community toolkit? This isn't the first time the WinUI team seems to be taking a fresh approach. That needlessly duplicates work and causes fragmentation in the worst case. The WCT version was already based on the WPF ideas and made necessary 'modern' changes.

[mdtauk]

@ranjeshj @michael-hawker Why not use what is already done in the community toolkit? This isn't the first time the WinUI team seems to be taking a fresh approach. That needlessly duplicates work and causes fragmentation in the worst case. The WCT version was already based on the WPF ideas and made necessary 'modern' changes.

The Community Toolkit is in C# I believe, and WinUI requires C/C++ code.

Also the WinUI design team had no say AFAIK with the Toolkit version, and so the needs of the Windows and App design teams may have specific needs if they are to adopt the control, over their custom solutions.

[robloo]

The Community Toolkit is in C# I believe, and WinUI requires C/C++ code.

Translating code to/from C# & C++/WinRT is relatively trivial. Especially for the Expander where I already looked at the code https://github.com/windows-toolkit/WindowsCommunityToolkit/tree/master/Microsoft.Toolkit.Uwp.UI.Controls/Expander. The vast majority of complexity is in the XAML which is 1:1 usable in WinUI as long as no WCT extensions were used. I could port this code to C++ myself if it is needed.

Also the WinUI design team had no say AFAIK with the Toolkit version, and so the needs of the Windows and App design teams may have specific needs if they are to adopt the control, over their custom solutions.

For specific points, yes. However, for general control functionality I must disagree. The WCT would get us 95% complete already and 100% complete in functionality. Any design changes applied on top would be trivial.

[ranjeshj]

@robloo Could you elaborate on which pieces of functionality are different ? The API proposed above matches very closely to WPF/WCT while trying to keep consistency with existing patterns in WinUI.

[robloo]

@ranjeshj We may not be on the same page. I wasn't suggesting that the proposed API was significantly different from WCT or WPF.

It was mentioned ExpandDirection may not be supported in the first version of this control. That seems like a problem for an Expander which has a long history with this functionality. Then it seemed like we have to justify why this feature is needed at all.

I suggested to use the WCT as base to quickly implement this with expand direction. There is no need to re-invent the wheel as only a port of C# -> C++ is needed (and code-behind is very small for this) while copy-pasting the XAML template. That would implement all functionality we would need and avoid concerns that there isn't enough time to add ExpandDirection. This approach would give us a fully functional control. Then any design/styling changes could be done on top based on @mdtauk or anyone else's suggestion. I don't understand (1) Why ExpandDirection is potentially on the chopping block for V1 (2) Why if time is a limitation we don't use existing code.

Yes my frustrations for WinUI 3 development in general are spilling into this a few places and I do apologize for that.

[mdtauk]

@robloo Its not about something being on the chopping block - but I believe the new people joining the team are there to offer a fresh look at these controls and APIs to see which are the greatest priorities - and potentially remove cruft when bringing new controls, or porting controls to WinUI.

When prioritising what features are essential to be included in a V1, and then in a V2, only the core and essential properties and behaviours will be there, and not legacy stuff that is not commonly used.

Microsoft seems to determine which features to add based on customer needs and wants - not just reaching parity with older frameworks.

So its not justifying, but just trying to understand what devs actually do with these control patterns in their UI.
The fact the Windows Shell alone has several versions of an expander control pattern, would be a clear enough reason why to include it. And the fact each implementation looks different, if not behaving different - is reason enough for the design team to consolidate the control design to meet the needs of the internal teams.

[robloo]

@mdtauk As always you make good points. However, I must disagree with this philosophy in one key way if it's truly the approach Microsoft is taking. For WinUI to be successful it must make sense for existing app developers. I'm trying to avoid another UWP scenario as we all know UWP never took off. The developers Microsoft needs to convince to come over to WinUI, just as UWP before, are WPF developers. One of the reasons WPF apps never made the jump to UWP is because UWP, especially when it was first released, was a very poor equivalent in several key areas of functionality. It's why when I saw rounded corners missing on the roadmap I started recalling the UWP nightmare (rounded corners fundamental to WPF were left out of UWP for the longest time). The number #1 priority should be for a smooth porting experience coming from BOTH WPF and UWP and honestly WPF should probably be a higher priority as there are far more apps there and Microsoft is clearly focusing on desktop cases with WinUI first. So again, we have to be very careful about, and actively avoid, reinventing the wheel.

And the fact each implementation looks different, if not behaving different - is reason enough for the design team to consolidate the control design to meet the needs of the internal teams.

I've always understood the design may need to be modified. Using lookless-control concepts this is a separate problem than ExpandDirection though. If we need to modernize the design more or make it more useful in some cases, great - it should be relatively trivial. At the end of the day it also may be fully re-templated for those that need fine control.

[marcelwgn]

Interesting point about animations. We turn off all animations with the system setting, but I don't think we expose knobs to turn off animations other than by re-templating currently.

To be fair though, almost no controls use animations. TreeView and NavigationView essentially use a Expander but both don't use animations for expanding/collapsing. Most controls that use animations usually rely on them, e.g. ProgressBar or ProgressRing. Expander however does not rely on it, it would be more of a "nice to have". Another case in point is that some people didn't use the WCT Expander control because they disliked the animation. If we want to include as many people as possible, having an easy way to disable unwanted animations would make that easier.

I believe you could add a Style that overwrites the Transition collection with null in the case that you want to turn animations off, assuming there is a Transition collection to overwrite.

But would this be a common way of disabling/enabling that? Most of the time, when we provide multiple styles they differ more drastically than just one animation, e.g. AccentColorButtonStyle or RevealButtonStyle.

Including an ExpandTransition and CollapseTransition, that can use the direction set by the control's property - which could allow the dev to set the transition for each.

I really like this idea!

I like the idea, but I don't think there is a way today to create custom theme transitions which would limit the ability to customize. This would allow easily disable it though by removing it.

I am also concerned about that. with the ExpandTransition and CollapseTransition API without any custom theme transitions, this is close to just having a "ExpendTransitionEnabled" and "CollapseTransitionEnabled".

[SavoySchuler]

@robloo If you would like to chat about frustrations regarding WinUI 3 development, I welcome you to write me (my Twitter and work email are on my GitHub profile). I'm not fully aware of your current frustrations, but I'm generally a good person to start with for topics related to customer or community engagement/development as well as I've run a significant number of our focus groups over the last year that covered the considerations you've listed around tooling, feature parity, etc.

I'll note that our roadmap is extremely tight, so I can't promise I'll have the ability to make the changes you want to see, but it is always helpful for me to know what could be done to better support you as customer and/or contributor of WinUI, so the worst case outcome is that at least your needs are well considered by our team moving forward. For the best case, I suppose that will depend on what you're looking for. Let's chat? 😄

@mdtauk Thanks for your support in clarifying- you're always well in tune! I'll say that there is clearly a LOT on our plate and the teams is committed to being as lean and effective as possible in trying to deliver the most meaningful, impactful progress in all areas. To continue investing in new controls/features among all other areas of continued progress, it necessitates our team members like @kat-y developing very sharp requirement specs as the worst thing for us would be throwing a portion of our limited resources at a knob or API that doesn't actually see broad use as there's not just the development cost upfront but also the continued maintenance cost after. I've only just parsed this thread lightly, but it is righteous for @kat-y, especially as a new team member, to want to be perfectly crisp in ensuring that there's a real scenario in a real app that needs the functionality requested (both for the reason stated and also to ensure we have Preview validation partners that are able to help ensure all the features developed perform as required in production environments that provide edge case coverage). Compliance with this aspiration may not always be publicly broadcast such as in cases where validating partners are private (and you're welcome to reach out to @kat-y directly if your needs are ones that aren't fit to be publicly posted about here at this time), but this has been a precedent in all of our WinUI 2+ control releases.

I hope this helped? It's my goal to turn this thread back over to @kat-y and the Expander topics at hand, but please reach out directly if there's more I can answer or if there's feedback you'd like to see considered. Thanks to both of you for all the work, passion, and energy you've put into this thread and into WinUI! 😄

[mdtauk]

@mdtauk As always you make good points. However, I must disagree with this philosophy in one key way if it's truly the approach Microsoft is taking..

I was not commenting on whether or not I agree with the approach, only that from my time on here and watching how repos are evaluated, it is how I believe the team is working on this.

(both for the reason stated and also to ensure we have Preview validation partners that are able to help ensure all the features developed perform as required in production environments that provide edge case coverage). Compliance with this aspiration may not always be publicly broadcast such as in cases where validating partners are private (and you're welcome to reach out to @kat-y directly if your needs are ones that aren't fit to be publicly posted about here at this time), but this has been a precedent in all of our WinUI 2+ control releases.

I believe using Microsoft's own apps, and Shell as examples are more likely to elicit recognition, as it shows where there was an internal need for something, which didn't exist, or was not fit for purpose, to the point they had to "roll their own" - but of course the big beasts like Netflix, Facebook, etc who build apps for Windows - will also ask for controls and other bits.

WinUI is not just about reaching parity with WPF, MFC, CommonControls, WinForms etc - (but the more commonly used of these legacy controls without a modern equivalent, should seriously be looked at)

The fact Breadcrumb Bars and Expanders are being proposed is a sign that this is starting to happen IMO. And every control or API addition should be evaluated and "justified" in an ideal environment, just as app designers should always be re-evaluating their UIs and UX to ensure they are fit for purpose. - In this case it may seem obvious, but we should still present examples where this pattern and these APIs are used - to strengthen the case for inclusion.

[Felix-Dev]

About the animations: How about using an ElementAnimator approach like the ItemsRepeater offers? The ElementAnimator API with its StartShowAnimation() and StartHideAnimation() looks promising ("show" to be used for expansion, "hide" used for collapsing). An ElementAnimator property could be offered on the control with a default animation implementation. If no animation is desired, the property could be set to null or if more fine-grained control is needed, only a Show or Hide animation could be supplied to the ElementAnimator.

I'm not too familiar with the ElementAnimator API and it seems it might not yet be usable in all scenarios as issue https://github.com/microsoft/microsoft-ui-xaml/issues/166 exists. However, if there is still a functionality gap, perhaps these work items (Expander control & ElementAnimator work to make it usable by the Expander control) could be synchronized and engineered together.

[marcelwgn]

Hmm the ElementAnimator idea is really interesting. My concern here is that this might be too complicated or overengineered. After all, for the ExpanderControl, we would then need to provide a custom ElementAnimator while we otherwise could reuse existing theme animations. Also, ElementAnimator provides more methods than the expander control actually needs so it seems a bit like an awkward fit.

[mdtauk]

Am I right in thinking the ElementAnimator is for handling offsets for child or contained elements appearing on screen?

It may be overkill depending on what is within the panel that is shown as the expander, expands. But if there was a way to connect it somehow, so if the expanding panel containing elements - could drive child animations if the dev appends something onto the element.

So the Expander doesn't directly control the child element transitions, but could enable them if the dev wants to

[Felix-Dev]

Yes, if we could create re-usable aniamtions here, while still giving customers some satisfying level of customization options, then this would be worth exploring. For example, we have already seen asks to add animations to the TreeView control when an item expands/collapses (https://github.com/microsoft/microsoft-ui-xaml/issues/208). I imagine a case can be made here that one set of animations could be built to look great for both the Expander and the TreeView control. Which will automatically come with a level of consistency then among different controls. creating visual familiarity to the user which is also a compelling argument.

[marcelwgn]

I think ideally, TreeView and hierachical NavigationView should just switch to Expander control when the control is ready. After all, currently both controls need to handle the exact same problem which would be solved by ExpanderControl. So a shared animation wouldn't make a big difference for TreeView.

The thing with ElementAnimator (how I understood it) is that we would have to write a new animation. However there are already built in animations we could leverage for Expander.

It may be overkill depending on what is within the panel that is shown as the expander, expands. But if there was a way to connect it somehow, so if the expanding panel containing elements - could drive child animations if the dev appends something onto the element.

I think one of the main points for ElementAnimator was to allow adding animations to panels and collections, e.g. ItemsRepeater. In the case of Expander, this isn't really the case though, expander is not a panel rendering a collection of items.

[mdtauk]

Off the top of my head, a resize for the parent panel with easing. Then a slide and fade for the containing object(s) would feel right.

If it were to become a generalised OS wide transition with the proper easing determined by the Fluent Design motion team - that would be good.

[ranjeshj]

Tagging @stmoy since we are talking about animations.

[kat-y]

Thank you @SavoySchuler for joining in and providing more context on our team's commitments - I hope this helps to explain why I'm specifically looking for examples of apps where the functionality of ExpandDirection is needed! To echo what Savoy said, please reach out to me directly (Twitter DMs if you need privacy) if your Expander needs are ones that can't be shared here.

@robloo Thank you for your apology, I completely understand your intentions and definitely want WinUI controls to be scoped and developed in a meaningful and efficient way. I am new to the team and really appreciate that the WinUI community is so friendly and enthusiastic in discussing the scope and implementation of Expander!

On that note, I'm excited to read through these more recent comments about animations!

[kat-y]

After reading through the animations-related comments, it sounds like there are 3 possible routes, in order of increasing amount of work:

Not including a set animation - this has the benefit as @chingucoding pointed out of not deterring developers when their scenario doesn't work or look good with the set animation. The risk here is possible inconsistency, though there doesn't really seem to be a lot of 'room' for inconsistency in this route.

@mdtauk proposed Including an ExpandTransition and CollapseTransition,

that can use the direction set by the control's property - which could allow the dev to set the transition for each.

Sounds like a smaller scope than using ElementAnimator. Would this give developers complete flexibility in setting the transitions?

Off the top of my head, a resize for the parent panel with easing. Then a slide and fade for the containing object(s) would feel right.

I understand parts of this, but its hard for me to visualize without, well, a visual 😄. Does "resize for the parent panel" mean the header would change in size? Could you elaborate on what you mean by "a slide and fade for the containing object(s)"?

@Felix-Dev proposed using ElementAnimator

The ElementAnimator API with its StartShowAnimation() and StartHideAnimation() looks promising ("show" to be used for expansion, "hide" used for collapsing). An ElementAnimator property could be offered on the control with a default animation implementation. If no animation is desired, the property could be set to null or if more fine-grained control is needed, only a Show or Hide animation could be supplied to the ElementAnimator.

@chingucoding noted that

we would then need to provide a custom ElementAnimator while we otherwise could reuse existing theme animations. Also, ElementAnimator provides more methods than the expander control actually needs so it seems a bit like an awkward fit.

one of the main points for ElementAnimator was to allow adding animations to panels and collections, e.g. ItemsRepeater. In the case of Expander, this isn't really the case though, expander is not a panel rendering a collection of items.

TreeView and hierachical NavigationView should just switch to Expander control when the control is ready. After all, currently both controls need to handle the exact same problem which would be solved by ExpanderControl. So a shared animation wouldn't make a big difference for TreeView.

I'm not sure that TreeView and hierachical NavigationView have the exact same animation scenario as Expander, what about when Expander will push whatever content (not necessarily text/buttons) nearby and the scenarios when Expanders are 'accordion'-ed with each other and potentially have logic to close/open depending on each others' expansion.

Is ElementAnimator overkill for Expander animations given that it's intended for panel/collection animations?