Proposal: Taskbar progress for UWP Apps

[JaiganeshKumaran]

Proposal: Taskbar progress for UWP Apps

Summary

Many Win32 apps use the Windows Taskbar for displaying progress in the background. This enables users to view the progress of a running task without switching to the app. UWP apps currently don't support this feature.

Rationale

Project Reunion is supposed to provide unified Windows experience to end users. Progess bar on the taskbar is currently not possible in a UWP App.

Scope

Capability	Priority
This proposal will allow UWP apps to show an indeterminate progress bar on the taskbar.	Must
This proposal will allow UWP apps to show and update a determinate progress bar via a background task when the app is open but suspended.	Must
This proposal will allow UWP apps to show and update determinate progress bar without a background task when the app is in foreground.	Must
This proposal will allow users to disable showing taskbar progress by apps including existing Win32 apps which use this feature.	Could

[jonwis]

Help me think through an API design here, based on ITaskBarList3. What would you want to see on the object?

What states would you want to use this in? Minimized? Minimized with background operations running?

[JaiganeshKumaran]

@jonwis All of the methods in ITaskBarList3 can be added to Windows.UI.Shell.TaskbarManager. As long as the app window is open and not suspended, these APIs should work regardless of the state. Only SetProgressValue and SetProgressState should be called from a background task if the window is suspended.

[Felix-Dev]

@JaiganeshKumaran In case you weren't aware of this yet, you can use a win32 full-trust helper process (as an app service) to show progress on a UWP app's taskbar button.

[JaiganeshKumaran]

@Felix-Dev I know that but that isn't the point. Using a Win32 helper process for simple stuff like this is not intuitive. Full trust should be only used for stuff that require privileges which are not given to an UWP app. Features like taskbar progress don't require extra privileges and thus you should be able to use them without a Win32 full-trust component.

[Felix-Dev]

@JaiganeshKumaran I agree with you. I just mentioned it so you could use that as a workaround until these APIs will be added to the UWP.

[mdtauk]

Microsoft.UI.Shell could be a useful namespace for exposing current and future Shell surfaces an App will encompass.

Microsoft.UI.Shell.Taskbar would handle the Icon, Badge, Attention Flash, Window/Tab Previews, Progress Indicators.

• Apps could set the icon or update the icon either when running or as a background process;
• Control the Badge Icon or Number Value;
• Flash to get the user's attention;
• Display Progress Indicator for an ongoing process;
• Display Media Controls or other preview buttons;

These would essentially be wrappers for the existing interfaces - but could be added to depending on the Windows Shell or device shell, for Hololens and Xbox.

[Felix-Dev]

It should be very carefully thought about whether some concepts like taskbar button flashing should be brought back to UWP (taskbar button flashing doesn't even work when using a win32 full-trust process). I have heard quite a few voices over the years (both users of my apps and others) that taskbar button flashing is generally perceived as both outdated and unwelcomed. Besides, the UWP Badge API seems perfectly capable of replacing the taskbar button flashing which is used to draw user attention.

Note that for now, the UWP Badge API does not work on Win32 apps on Windows 10 for drawing a badge overlay on the app's taskbar button (it works already on Windows 10X for Win32 apps). Issue microsoft/microsoft-ui-xaml#1919 is tracking the request to bring this over to Win32 apps for Windows 10.

Assuming the UWP Badge API is available to Win32 apps too:
Those who want to use taskbar button flashing instead: Why would you prefer that over the far more modern and powerful Badge API? What should be added to the Badge API so you will use it instead?

[JaiganeshKumaran]

@mdtauk Apps shouldn't be able to change their taskbar icons. Having such a capability will confuse users.

[jonwis]

Right - we wouldn't want apps to replace their icons with something else. Expanding beyond the current badging (and making badging available to all apps) into attention-seeking (progress bars, flashes) is interesting. As others have pointed out not all shells support these affordances so if they're part of Project Reunion it'd be up to apps to use an .IsSupported check before use.

[mdtauk]

Right - we wouldn't want apps to replace their icons with something else. Expanding beyond the current badging (and making badging available to all apps) into attention-seeking (progress bars, flashes) is interesting. As others have pointed out not all shells support these affordances so if they're part of Project Reunion it'd be up to apps to use an .IsSupported check before use.

Yes there should be a graceful fallback or translation depending on what the device's shell supports.

The Progress Indication may work on the taskbar, but for Shells without a taskbar, there could be other ways to indicate a "working" state for the app

[Felix-Dev]

The Progress Indication may work on the taskbar, but for Shells without a taskbar, there could be other ways to indicate a "working" state for the app

Toast notifications can be used to displayed progress for an operation: https://docs.microsoft.com/en-us/windows/uwp/design/shell/tiles-and-notifications/adaptive-interactive-toasts#progress-bar
I believe the MS store is using those too for its downloads and this can easily be envisioned for any type of operation which will take (some) time to complete.

[JaiganeshKumaran]

@Felix-Dev However, progress in toast notification isn't suitable for all applications. It's intended for background tasks which run regardless of the window status and which don't connect to the foreground UI. Taskbar progress in the other hand are used by apps to show progress of foreground tasks or background tasks that are connected to the foreground UI.

[mdtauk]

Visual Studio compiling is a canonical use case. You could imagine a media app maybe displaying the current track's progress,

The ability exists in the Win32 APIs, and this progress could be added to Tiles, Task Switcher, App Icons in 10X's Launcher or other shells - which would use the Reunion wrapped API to make it consistent for the developer to implement - and apply that concept to the various shells.

[Gavin-Williams]

I have heard quite a few voices over the years (both users of my apps and others) that taskbar button flashing is generally perceived as both outdated and unwelcomed.

Task bar button flashing is a requirement for games, particularly multiplayer games where we are waiting for a match to start and may be doing something on the desktop. The flashing task bar icon is a clear indicator that the match is ready. I literally relied on that functionality last night. Because match-making was 3-6 minutes.

Those who want to use taskbar button flashing instead: Why would you prefer that over the far more modern and powerful Badge API

You say far more modern and powerful. I'm yet to see it used by anybody to let me know that the match is loading. So until it's being used and we can fairly judge it against the existing mechanism, maybe we should have both.

[Felix-Dev]

@Gavin-Williams Why not send a toast notification in this case then? Clicking on the notification "Get Ready! The multiplayer game is starting in x seconds" would bring you directly into the game, for example. It would also clearly communicate what just happened in the game it thinks it should inform you about. Taskbar flashing just tells the user "something" happened. It doesn't tell the user what exactly happened without them having to open the app. For example, in a multiplayer game scenario, taskbar flashing could be used to mean multipe things: Start of the game, cancellation of the match-making, Internet connection lost, messaged by another player in the waiting lobby,.... Not all of these "events" might require immediate user attention. But since the user doesn't know what exactly happened which caused the flashing, they will have to open the app. Toast notifications appear much more superior to me here as they can tell the user directly what happened, letting them decide if they want to switch app context now or not.

Another point about taskbar flashing: If you have enabled "automatically hiding the taskbar" in Windows Settings, taskbar flashing will block the taskbar from shrinking back until you've opened the app. In other words, it basically forces you to open the app as soon as possible. Now, in some cases that might be useful but not in others. Take Visual Studio for example. When you start VS by loading a project and then minimize it, VS will flash the taskbar once it's done loading the project and "ready to go":

While that's all fine and good, VS's taskbar icon now blocks my taskbar from automatically hiding again. It will now constantly occupy screen real-estate until I've opened VS - which could be in this moment or 5 minutes later. The user might not always want to jump into VS as soon as it is done loading. However, thanks to preventing the taskbar from hiding now, the user is quite forced to open the VS instance and minimize it again if the user is not ready to use it yet,

You say far more modern and powerful. I'm yet to see it used by anybody to let me know that the match is loading. So until it's being used and we can fairly judge it against the existing mechanism, maybe we should have both.

Assume taskbar flashing won't be added to UWP and you would have to "make do" with what the UWP Shell APIs currently have to offer (notifications, badges, live tiles). What would you like to see added to those notification systems to provide a good user experience (in cases where currently taskbar flashing is used). What are the current cases of taskbar flashing where you think the existing UWP notification APIs would be "insufficient" to use?

[contextfree]

Do people here (or not here ...) experience taskbar progress similarly to how they experience taskbar flashing? Personally I wouldn't lump them together - I always find the green taskbar progress bars feel like a pleasant, helpful touch I'm happy to see, that saves me from having to periodically open the window and check on it, while the orange flash is generally a bit irritating though sometimes it's a necessary evil.

[Gavin-Williams]

@Felix-Dev I'm not disagreeing with you. I think it's great this is being thought through. Because I do think the flashing icon mechanism feels a bit janky in the way you are suggesting.

"It doesn't tell the user what exactly happened without them having to open the app." - I'm always going to open the app in that case, because I'll have a few seconds before the match starts. But I totally agree there are other things that can happen as you mention. So there seems to be a distinction between regular notifications and these 'urgent' notification. Whatever UWP provides would hopefully be able to show them differently. There's probably a lot of freedom with how that could be done.

I used the BurntToast powershell script to quickly generate a toast notification for a game..

I'm not sure if toasts have more capabilities, I think they do so I'll look into whether they can effectively replace the flashing behavior. But in respect to the toast notification I generated here, there are a couple of things missing

1. A sense of urgency - the panel should flash or be colored.
2. There is no way to switch to the game from the toast.

Does Windows have a way to add a button to the toast?

[JaiganeshKumaran]

@Gavin-Williams Windows does support adding buttons to a toast notification and even input boxes: https://docs.microsoft.com/en-us/windows/uwp/design/shell/tiles-and-notifications/adaptive-interactive-toasts

[Felix-Dev]

Does Windows have a way to add a button to the toast?

@Gavin-Williams Yes! See the documentation here: https://docs.microsoft.com/en-us/windows/uwp/design/shell/tiles-and-notifications/adaptive-interactive-toasts#buttons

There is no way to switch to the game from the toast.

For UWP apps, clicking on a toast activates the app in the foreground when using a ToastContent.ActivationType of ToastActivationType.Foreground. I would expect that for UWP games to be the same. See more info about app activation when clicking on a toast here.

For Win32 apps, app foreground activation via a toast click is also available. See the documentation here. Toast foreground app activation for .NET Core 3 apps was also made easy with the recent Windows Community Toolkit 6.1 update.

A sense of urgency - the panel should flash or be colored.

There is an option to have a toast notification be accompanied by an alarm sound: https://docs.microsoft.com/en-us/windows/uwp/design/shell/tiles-and-notifications/adaptive-interactive-toasts#alarms-reminders-and-incoming-calls

Of course, notifications might still not be perfectly suited for a specific scenario of yours, but in that case a specific toast notification proposal could be created here in this repo to improve toast notifications for these specific scenarios.

[Gavin-Williams]

Here's a rough mockup for a different concept for apps to notify the user about app events, an IconToast...

Pros
* Emphasizes the app icon itself as the source of the notification (The current toasts are by design disjoint from the app visually).
* Visually binds the message with the icon, the whole IconToast region could be clickable to bring it the foreground.

Cons
* A new UI concept for Windows.

[Gavin-Williams]

"There is an option to have a toast notification be accompanied by an alarm sound" - Headphones will often be plugged in making an audio alarm ineffective. This is why the flashing icon is so useful, it's visually striking and attention seeking. So the toast needs to have some way to visually grab the users attention for urgent notifications, having it all gray and blending in with the existing desktop is going to be frustrating if it doesn't grab my attention.

[JaiganeshKumaran]

@Gavin-Williams Your idea's great however I don't really know whether this is the right place for proposing new features for Windows. Could you open a Feedback Hub post?

[Gavin-Williams]

@JaiganeshKumaran Understood!

[JaiganeshKumaran]

If Microsoft adds taskbar progress to UWP apps using a new WinRT APIs, those APIs should be converged and should work in desktop apps too. Win32 developers shouldn't require the old flat C API to do that

[ghost]

@andrewleader @btueffers this issue should be closed for the same reason (CoreWindow) #159 #173 #302 got closed.

[Gavin-Williams]

OK. But aren't you painting yourself into a corner? The same corner you found yourself in at the beginning of the UWP journey? I'm referring to the term 'desktop based'.

If I turn my head around, my eyes pass over 2 different Windows devices that are not desktop, my XBox and my tablet. We also have laptops, including touch screen laptops in the house that run Windows. And I'm pretty sure I've got some Windows code on a raspberry pie. I've got an old Lumia Windows phone sitting in a draw. And I would have a Windows phone again, if you ever made one. I've got a VR headset too.

I just think, you say 'desktop based', but have you got tunnel vision, and forgotten about the world you live in?

I absolutely agree, that we couldn't have continued with UWP without further development. That was your choice, to refuse to finance and develop UWP, a much loved platform by the people who actually used it. A terrible choice I think. But it was a choice and you're making the best of it in some ways. But I don't think a 'desktop based' mindset is the right way to go.

I love my desktop, it's my work machine, it's where I play some of my favorite games, it's an important connection to the internet. And it needs to be fit for purpose, but it's certainly not the only device that I use in the house, or the car, or when I'm walking. UWP's was the closest you got to a universal platform. It was like 90% there, but it needed to go the rest of the way. I don't see how you can do that now. And if you don't do, someone else will.