Proposal: Modern WinUI version of the TaskDialog

[mdtauk]

Proposal: Modern WinUI version of the TaskDialog

Following WinForms adding support for the Win32 Task Dialog, a twitter thread was started by @sonnemaf and contributions from myself and @niels9001 discussing a need for this kind of UI in WPF and for modern WinUI apps.

It could bring a consistent design to numerous shell and inbox app UX which at present, can appear inconsistent and at times, messy.

Summary

A task dialog is a dialog box that can be used to display information and receive simple input from the user. Like a message box, it is formatted by the operating system according to parameters you set. However, a task dialog has many more features than a message box.

Win32 Documentation

A modal dialog that presents Xaml controls, supports paging through steps, is similar to a wizard UI #2030 , has the ability to capture user input, and has various strings formatted in a consistent way.

I hope this Issue can be edited later to encompass more detail from the community, I am just making the initial proposal.

Rationale

• WinUI and Windows 10/10X does not have a consistent way of presenting this kind of UI at present.
• Presently various parts of Windows 10 present this kind of UI, but it is inconsistent,
• This kind of control could answer a few wants from the community.

Scope

Capability	Priority
Present a consistent UI with minor customisation	Must
Ensure controls hosted in the dialog	Must
Shell and Inbox app teams should adopt this control to demonstrate best practice	Must
It should be possible to create the UI without manually styling controls, placing controls, or adjusting margins and padding	Should
It could be possible to add custom Xaml, but a focus should be on the typical controls supported by the TaskDialog UI	Could

Important Notes

Below are some examples of common Windows UI that could be made more consistent by using this new control.

Winforms - Windows Task Dialog

Open Questions

Please make your voices heard about what you would need from this control, how you would see it being used, and why you would like to include it into your applications and user experiences.

Anything that was learned when the WinForms team built their wrapper around the Win32 version of this control, could be helpful, especially any aspects of the control that could be important but easily overlooked.

The design of the control should reflect WinUI and Fluent Design principles, and not slavishly match the Windows Vista/7 design. So how some of the elements get translated would be a design conversation, with approval from the Windows Design team.

[sonnemaf]

There is also a discussion on Twitter from @NullRefExc and @michael-hawker whether the TaskDialog would be a ContentDialog (or subclass).

I think this is a big issues. If it is a ContentDialog the size can not really exceed 500x500 pixels. This is the size I usually set for an UWP app. A ContentDialog is always displayed inside the app and will therefor have the same size limitation. We then should use scrollbars to allow bigger content.

If it is a (modal) Window we can have "any" size. The TaskDialog would allow a content which is bigger than the app.

I still like the idea of a ContentDialog solution. It would allow to have any content in it. It is also risky because it will probably inconsistent implementations. Maybe it should be a combo.

[mdtauk]

There is also a discussion on Twitter from @NullRefExc and @michael-hawker whether the TaskDialog would be a ContentDialog (or subclass).

I think this is a big issues. If it is a ContentDialog the size can not really exceed 500x500 pixels. This is the size I usually set for an UWP app. A ContentDialog is always displayed inside the app and will therefor have the same size limitation. We then should use scrollbars to allow bigger content.

I think it would need to generate an app window/sub window, rather than be an overlay - to be useful for both UWP and WinUI Desktop.

If it is a (modal) Window we can have "any" size. The TaskDialog would allow a content which is bigger than the app.

Ideally of course, it would be a non-resizable window, that resizes itself to fit the content, but I don't think that is possible in UWP at the moment

I still like the idea of a ContentDialog solution. It would allow to have any content in it. It is also risky because it will probably inconsistent implementations. Maybe it should be a combo.

I think if the control were to contain things like CheckBoxes, and TextBoxes, there could be a XamlContent panel for arbitrary content - but it be placed as a block among other blocks.

[sonnemaf]

I agree with @mdtauk. Not being able to set the Size of a Window is an issue. Maybe this should be placed in a separate issue.

[mdtauk]

I agree with @mdtauk. Not being able to set the Size of a Window is an issue. Maybe this should be placed in a separate issue.

I believe this is what the future Windowing APIs are planning to deal with. WinUI Desktop's Window object will support setting a size.

[sonnemaf]

I believe this is what the future Windowing APIs are planning to deal with. WinUI Desktop's Window object will support setting a size.

Will there be a UWP and a different Desktop version of WinUI? I hope not.

[mdtauk]

I believe this is what the future Windowing APIs are planning to deal with. WinUI Desktop's Window object will support setting a size.

Will there be a UWP and a different Desktop version of WinUI? I hope not.

WinUI is used for both, but some APIs and elements will behave differently. WinUI will have a Window element, but in UWP this is wrapping around the CoreWindow, but with WinUI Desktop, it wraps around a HWND window.

Threading behaves differently with each, and so this causes some issues with parity between both lifecycles of WinUI

The same single UI thread limitations of CoreWindow will continue to apply

[shaheedmalik]

I think these should show in full screen when in a Tablet UI environment.

[mdtauk]

I think these should show in full screen when in a Tablet UI environment.

What is your reasoning for this? I think centred on the tablet screen makes sense, but not sure why the window should be larger than it needs to be.

• The UI would not stretch well;
• Body text blocks would have longer lines than is ideal for readability;
• You lose the visual indication that this is a modal UI;

This TaskDialog would need to be either followed through with, or dismissed, before you go back to the app which summoned it.

---

ContentDialog is for showing information or content of the developer's choosing.

MessageBox is for displaying a text message.

TaskDialog would be for completing a task more complicated than tapping a ToggleSwitch, Button, CheckBox etc, or requires multiple steps or inputs from the user.

[niels9001]

@mdtauk Thanks for the write-up. Excellent examples. I would really welcome a more standardized and easy to use dialog control for OOBE/connection related tasks!

[shaheedmalik]

What is your reasoning for this? I think centred on the tablet screen makes sense, but not sure why the window should be larger than it needs to be.

Bad experience with open & dialogue boxes. The ones in Tablet Mode where great in Windows 8.1 for usability and then in Windows 10, they took away them away. Because of that, any type of dialog like above bother me. They are never designed to scale for tablets. I have all of this screen real estate and the boxes are 500x500.

Why?

[michael-hawker]

@shaheedmalik that sounds like a DPI issue?

Though that's the point of having a consistent control/paradigm in place here for modern applications. Then if there is something that can be addressed when in Tablet mode, then all the apps using this new Dialog can behave the same way and receive the same fixes/benefits of developing a solution for your issue on top of this control/platform.

[mdtauk]

What is your reasoning for this? I think centred on the tablet screen makes sense, but not sure why the window should be larger than it needs to be.

Bad experience with open & dialogue boxes. The ones in Tablet Mode where great in Windows 8.1 for usability and then in Windows 10, they took away them away. Because of that, any type of dialog like above bother me. They are never designed to scale for tablets. I have all of this screen real estate and the boxes are 500x500.

Why?

Task Dialogs appear to stack the controls vertically, so the width encompasses the controls required, but the height adjusts to contain what is in them.

On Tablets, there will probably need to be support for vertical scrolling if the developer has put too many stacked controls in a Dialog - and has chosen not to paginate the task into steps.

So if the width is say as wide as a textbox with icon beside it, like in the examples I posted, that would look a little silly centred in the full screen window. If you want to do things like columns, then that would make more sense as a Form Control, as proposed here #82, and could be placed in a ContentDialog or custom control ( with or without pagination #60 )

[shaheedmalik]

So if the width is say as wide as a textbox with icon beside it, like in the examples I posted, that would look a little silly centred in the full screen window. If you want to do things like columns, then that would make more sense as a Form Control, as proposed here #82, and could be placed in a ContentDialog or custom control ( with or without pagination #60 )

I'm asking for it to scale to the device it is on. What you are suggesting is what happened to the open file dialog going from Windows 8 -> Windows 10. On Windows 8 they scaled to the device, on Windows 10 they no longer did that.

[mdtauk]

@shaheedmalik by default, this task dialog would be in Xaml, so would support the same touch target sizing, and DPI scaling as other Xaml controls.

If you mean scaling as in making CheckBoxes, Buttons and TextBoxes larger than usual, and using massive Font sizes - why should these UI elements be scaled differently to others?

This would not be like a win32 UI, which refuses to be moved about the screen, or feels out of place in a modern UI and touch screen device

[sonnemaf]

Windows Hello also uses a TaskDialog interface.

[shaheedmalik]

Windows Hello also uses a TaskDialog interface.

The difference for this is, it takes over the whole screen.

[shaheedmalik]

@shaheedmalik by default, this task dialog would be in Xaml, so would support the same touch target sizing, and DPI scaling as other Xaml controls.

If you mean scaling as in making CheckBoxes, Buttons and TextBoxes larger than usual, and using massive Font sizes - why should these UI elements be scaled differently to others?

This would not be like a win32 UI, which refuses to be moved about the screen, or feels out of place in a modern UI and touch screen device

I'm talking about avoiding stuff like this:

This type of thing is annoying as hell to me. If I, for what ever reason, miss pressing it, it will take me to the Start Screen.

[niels9001]

We could catch that by drawing a backdrop, similiar to the default content dialog? Having a dialog full screen looks pretty bad, this would resolve both issues 👍.

[wjk]

My 2¢ on this issue: The main reason I still use the Vista-era TaskDialog is because it conforms to Vista-era design principles; namely, minimizing wasted white space. Just because WinUI 3 is designed as a "touch-first" toolkit, it doesn't mean that supporting touch as a first-class design feature is a good idea for every project. The example in the OP, while fine from a touchscreen perspective, has stupid large text and lots of pointless white space when viewed from the perspective of a user (or developer) used to Windows 7-style apps intended to be used with keyboard and mouse. The bulk of the apps I write fall into this category.

What I would recommend doing for this issue is ensuring there is a way (even if it involves re-templating the control, I'm not afraid of having to do that) to make the WinUI task dialog laid out roughly like the Win32 equivalent, using 9-point Segoe UI text and margins of only a few pixels at 100% DPI. Other than that, all the rest of the UI (fonts, background colors, Dark Mode support, button chrome, etc.) would look exactly like it does in the OP's mockup.

Also, the idea about making a touch-opaque backdrop when showing a small window in Tablet Mode is something the OS should do automatically for every app IMHO. Being catapulted out of the app and back to the Start screen on a missed tap would become extremely aggravating the 642nd time it happens. Hope this helps!

[mdtauk]

My 2¢ on this issue: The main reason I still use the Vista-era TaskDialog is because it conforms to Vista-era design principles; namely, minimizing wasted white space. Just because WinUI 3 is designed as a "touch-first" toolkit, it doesn't mean that supporting touch as a first-class design feature is a good idea for every project. The example in the OP, while fine from a touchscreen perspective, has stupid large text and lots of pointless white space when viewed from the perspective of a user (or developer) used to Windows 7-style apps intended to be used with keyboard and mouse. The bulk of the apps I write fall into this category.

What I would recommend doing for this issue is ensuring there is a way (even if it involves re-templating the control, I'm not afraid of having to do that) to make the WinUI task dialog laid out roughly like the Win32 equivalent, using 9-point Segoe UI text and margins of only a few pixels at 100% DPI. Other than that, all the rest of the UI (fonts, background colors, Dark Mode support, button chrome, etc.) would look exactly like it does in the OP's mockup.

Winforms has added a wrapper for the Windows 7/8/10 style control - so this doesn't totally replace it.

This proposal is about providing a similar UI for Windows 10 native looking apps, which can be called from WinUI apps, without looking vastly different from the new modern design.

If you do not want to support touch screens, and do not want to make your app look like a modern Windows 10 app - why would you be using WinUI at all?

[wjk]

@mdtauk: Because I want the app to look like a modern Windows 10 app. That does not necessarily imply first-class touchscreen support as far as I am concerned. I'm sorry if I didn't make this more clear.

[mdtauk]

We could catch that by drawing a backdrop, similiar to the default content dialog? Having a dialog full screen looks pretty bad, this would resolve both issues 👍.

There was discussion about this kind of thing in another issue #2122 and how you may introduce a visual style to suit modal dialogs and content dialogs. Any "smoke" layer should be consistent with other modal UIs, but whether this is on the whole screen, or just for the window that summoned the TaskDialog - is possibly a discussion to be had.

[mdtauk]

@mdtauk: Because I want the app to look like a modern Windows 10 app. That does not necessarily imply first-class touchscreen support as far as I am concerned. I'm sorry if I didn't make this more clear.

Text Size for Windows 10 UI is 14pt for most body text with 12 for captions. It is for modern accessibility, the WinUI anti-aliasing, that this is as it is.

Touch targets for buttons are a minimum of 32 px for touch targets, so to deviate from these standards, would make the UI not fit the new Shell design that Microsoft are moving towards.

I would suggest that if you wish to make Legacy looking TaskDialogs, doing them as WinForms would probably be the better idea moving forwards.

This proposal is about creating a new UI concept, that fits the Windows 10 design, accessibility, touch support, etc - where there currently are various different attempts at making this kind of UI, but with no consistency.

[shaheedmalik]

I don't understand why people say a big control is wasting space. It's a dialog box. You can't do anything past it. It if is small like the Win32 example I posted, you can't do anything with that "saved" space.

I'm posting this message on my phone and I can't read what it even says from here.

[michael-hawker]

There's also the notion of the Compact Styling option, so that should be the option available for this (like any other WinUI control) for targeting desktop only scenarios compared to touch-friendly defaults.