Windowstemplatestudio: Notification Improvements

[crutkas]

Add in a Action Center notification.

[mrlacey]

What should this do/be?

[ralarcon]

@crutkas which features we would like to ilustrate with in this? Actionable Notifications? Workflows? a sample would help to define the scope.

[crutkas]

i was brainstorming here. Let me sync with Thomas Fennel's amazing team and see how they feel we can best integrate support.

[crutkas]

From Notification Team: One thing we should absolutely hands-down add to the WTS is make the sample toast interactive, so that devs instantly have an example of how to handle background activation toasts (like a quick reply toast). And should probably have the background task activation update something in the foreground app UI too (using Single Process Model), since that’s one of the biggest pain points in implementing background activation toasts (when you reply to a message, you also have to make sure your foreground UI updates correctly with the new message you sent).

We also should add snippets for removing the toast via Tag/Group and clearing all toasts, since apps often forget that they have to clear/remove toasts themselves. Apps that forget to do that leave the user’s Action Center cluttered with old toasts even though the user already viewed the conversation/content inside the app!

Also add in Hero image.

[mrlacey]

I think we should change the current notification sample to reflect something more realistic.
raising a toast when the app starts isn't realistic of any scenario I've seen.
Instead, I propose that when adding the toast notification feature it adds a periodic background task that displays a toast. The toast raised could be richer and include examples of how to display in different ways and be interactive.

X-Ref #326

[andrewleader]

Agreed with @mrlacey that we ought to have a more realistic scenario. I'm not sure periodic background task would be ideal though, because there's no way to "try it now".

One idea could be to have a dummy chat conversation inside the app, where it starts off saying "Send a message to start the conversation", and then once you send one it'll reply with lorem-ipsum content randomly with 5-10 second delays...

When the message arrives, the template app would contain logic to check "Am I the current active foreground window? If not, don't show a toast since the user is already inside my app. Otherwise notify them with a toast that'll bring them back to my app." That's a common scenario for messaging apps at least, and having some sort of easy method for "IsAppInForeground()" would be awesome for toast devs.

When the user returns to the app, the app would clear all toast notifications for that conversation (using RemoveGroup), so that the user's Action Center isn't cluttered with content they already saw.

The toast would also include a quick reply text box, so that you can reply right from the toast. And that quick reply text box would fire a single-process background task which then correctly updates the UI if the app is still running with the new message (a common scenario that was extremely difficult before single-process model).

In summary...

• Add dummy chat client
• If app not in foreground when message received, show toast with message
• Toast has quick reply text box that, when you reply, updates the foreground UI (if app running) with response
• When user switches back to app ("viewing conversation"), clear all those toasts from the conversation

Assuming the dummy chat client code is isolated, it would be a very compelling template. Everything else would be very useful to devs (being able to check if foreground app, being able to know when app switched back to, being able to know how to clear toasts, being able to know how to handle background activations and update foreground UI).

[mrlacey]

@anbare that's potentially a lot of code to remove if not what a person wants.
It'd be good to know what other people are already doing and/or what people are asking how to do so that we can find a balance between example, helping with the repetitive code, and getting out the way.

[andrewleader]

Knowing whether the app is the foreground window or not is a common pain point, here's MSDN threads about it (they include code snippets of how to do it too)...

• Suppress Toast Notification when app is in the foreground
• Not show Toast Notification when application is in foreground

Every chat app needs to implement that. Email apps need to implement that. Social media apps need to implement that. Basically anything that shows a toast while the app is open. Things like calendar apps and games likely don't need it, so it's not anywhere near 100% of apps, but it's a good portion.

Updating foreground UI from a background task activation is almost always a critical required piece for anyone using interactive toasts. If you're a messaging app and you have quick reply in the toast, you definitely need your UI to be updated in response to the user sending a message via the toast. If you're a todo task manager, when the user clicks "Mark Complete", the task inside your app needs to become completed. If you're a social media app and the user clicks "Like" on the photo in the toast, the foreground UI needs to reflect that like status. This used to be extremely complex to support back in the multi process background task world, which is explicitly why I didn't add a "Mark Complete" button to my own app's toast notifications - it's just way too hard to implement. With single process model, it becomes much easier, although there might need to be some logic to determine "If UI thread is available, dispatch to UI thread (so that data-bound view models can correctly update the UI when change is executed), otherwise stay on background thread, foreground app is closed". It'd be excellent to have this logic baked in, nearly everyone who uses interactive toasts will need it.

Clearing irrelevant toasts is hands down something nearly every developer needs to do, but we have plenty of data (from API usage) showing that they do NOT. Clearing toasts is an after thought. It's a polish feature. By explicitly adding it (and helping with the logic of "User switched back to my app, check if there's any toasts I should clear"), we'll help greatly improve the experience of UWP apps for end users by hopefully encouraging developers to clean up their notifications by making it simple.

[ralarcon]

@mrlacey, @crutkas, @anbare Do you think that implementing a "Chat Page" which depends on "notification feature" would be valuable... I agree with @mrlacey that implement all this stuff just for the notification infrastructure would be overwhelming...

In the other hand, how we can improve our current Notification feature to include best practices including the handling of notifications in foreground and cleaning up the notifications once? Would make sense that the "Notification Feature" includes a page with some buttons to guide the process and enable the showcase? Considering what we have discused for #403, we can try to generate the page if the user "opt in" for sample data...

[mrlacey]

For the sake of showing best practices, can we not point to an existing sample? Or if there isn't one maybe we could contribute one to the docs.

I don't think we should be adding code that serves only to be an example of how to do something well. We should really only be including something that will help everyone who adds a page/feature.

Also, in terms of a chat page, it wouldn't be complete without a server part and that's well outside our scope. I think this makes a strong argument for pointing to an external sample.

[crutkas]

Sure let's whip up a page. If the existing docs page is wonky on docs.msft, we should help out and get stuff fixed there in parallel

[crutkas]

• page being github page :)

[andrewleader]

Three out of the four things I mentioned were code that serves a purpose for most/all notification senders. The dummy chat client was just to serve as an example of how it would actually be used. Which is important so that devs can easily put break points when they quick reply to the notification, or when they view the conversation and the app clears notifications, etc.

The dummy chat client can easily be just a single XAML/CS page that literally all they have to do is delete the page later on.

We can just put in the code for the remaining 3 out of the 4 items, but I thought part of the point was to have an example that illustrates its usage.

The 4 items I mentioned were

• Add dummy chat client
• If app not in foreground when message received, show toast with message
• Toast has quick reply text box that, when you reply, updates the foreground UI (if app running) with response
• When user switches back to app ("viewing conversation"), clear all those toasts from the conversation

So essentially the last three translate into

• Static method to ask "Am I in foreground?"
• Code already written that configures the toast background task and ready to handle background activation
• Code that constructs an example quick reply toast wired up to use background activation (and also uses foreground activation on the toast body to illustrate deep linking to a specific page, logic for handing that foreground activation and page navigation needs to be there too, maybe that's already there not sure)
• Code example of clearing all toasts for that specific group of toasts related to the conversation

We can just put those individual code pieces in, but it definitely makes a whole lot more sense if someone can play around with the toast in a dummy chat conversation and see all the various behaviors and learn how their app should properly behave when it's in the foreground vs background, how to clear toasts when the content is navigated to, etc. I believe the value gained from adding the dummy chat sample outweighs having devs delete a single page.

Agreed though that there should also be documentation on all of this. But the original thread is about improvements to the Windows Template Studio's notification template, and these are the things that are most commonly frustrating about implementing notifications.

[ralarcon]

I have in mind an approach that can fit:

1. Include in the "Notification Feature" all the required infrastructure.
2. Create a sample (like we did with the Activation Handler) to ilustrate the usage. This sample can be a "fake chat page" or a more simple page. This sample can combine both the Notification feature and the Background Task to enable the scenarios we want.
3. Create a documentation explaining the process remarking important concepts. This is what we did with the Activation Handler doc
4. Include a link to this doc within the "Notification Feature" generated code.

Does this work for all?

[mrlacey]

@anbare

• How to test a message being received when not in the foreground? If the only way to send messages is with the app, you need a BGTask or something else external to send it.
• Actionable toasts require a separate process (BG task) to handle the processing of the interaction with the notification when the app isn't running. This means a full example needs more than just a single page. Or has this changed in the latest update and I'm not aware? (Remember we target latest and previous version.)

@ralarcon
My concern is that with a sample chat page a lot more is being added to the generated app compared with other features.

• Do we have to have this sample?
• Do we need this level of sample for all features?
• Do we set a precedent for adding samples for other features?
• In doing this do we risk breaking one of the original goals for WTS which was to not have generated projects which contain a lot of code that needs to be changed or removed by the developer? This is starting to feel quite specialized as chat isn't the only reason to have actionable toasts. Do we risk turning this into a chat sample feature and not just a general purpose toast notifications feature?

For reference, full notification samples are at https://github.com/Microsoft/Windows-universal-samples/tree/master/Samples/Notifications

[ralarcon]

@mrlacey I agree, this should not be added as part of the "Feature". Because of that I was think that a way to better showcase the Notification feature in combination with the Background Task would be a sample project.

My point of view is the following: If we think having a more complex sample is valuable (chat page or other page which ilustrate all the important things regarding the notifications), then, we can create a sample usage, that is, a project sample which uses our Notification Featrure and the Background Task Feature to ilustrate this scenario + a guide through doc. In that case, this will not be part of the WTS, it would be an aside sample project reference (a link in the generated code).

I don't think we need to do this for every feature. The only thing I'm not sure is if the Notification Feature, as it is now, lacks of some code infrastructure to allow users to proper implement all the scenarios pointed by @anbare. If we are good, then I'll let the feature as it is right now.

[mrlacey]

Yep, making a separate sample is good.
Developing such a sample is also a good way to test the coverage of what WTS outputs.

[crutkas]

this can be done out of band as this is a sample

[mvegaca]

At this point, we have already created samples for activation / suspend and resume / navigation. Maybe to create a full chat sample as a showcase of toast notification and background execution looks out of scope considering the other samples we have. Do you think we still need this?
Looks this is already covered by the official sample.

[andrewleader]

There's a Traffic App sample which seems to utilize notifications, maybe we could make sure that the Traffic app is using advanced notification scenarios like buttons and quick actions so that we have a real sample app illustrating notification usage.

The Notifications sample itself isn't a "real" app that illustrates real functionality, like the user performing a quick action on the toast resulting in the app's UI being updated... that's where the trickier part comes in, where a "real" sample app like Traffic or chat can illustrate best practices.

[crutkas]

@mvegaca, i want to limit our app sample creation, any minor change forces us to reauthor that sample.

When in doubt, we should point to official samples or create smaller doc pages that tell where to add code / what to do and have a todo in the code.

[mvegaca]

I can create WindowsTemplateStudio/docs/features/notifications.md explaing about notifications configuration, activation handling, including references to those samples and MSDN docs? How do you think about that @crutkas ?

[crutkas]

@mvegaca, love it

[mvegaca]

Doc added on #1238

Documentation adds explanations about how to extend the generated notifications feature code and adds some useful links about notifications.
IMO this issue could be considered as done.

[ralarcon]

Doc merged