Google knows nothing about Special Toasts... Do you?
, but I am also not "toast capable":http://msdn.microsof...s/hh779727.aspx
There are two types of toast notification:
Standard toast: Most developers should use the standard toast notification. This toast remains on the screen for seven seconds, playing a brief sound to alert the user when it appears. The standard toast is best for notifications such as an IM contact sign-in, or a social media update.
Long-duration toast: This notification looks the same as a standard toast but stays on the screen for 25 seconds and optionally can play longer, looping audio. This type of toast is used in situations where you want to grab the user's attention because there is a human waiting on the other end of the connection. This is appropriate for person-to-person communication like instant messages and VOIP calls. This type of toast can also be used for calendar reminders.
It wouldn't surprise me if there were Special toasts and Short-duration toasts (obviously UNdocumented) and since the Special ones might create a problem with common people and Short-duration ones with people suffering from ejaculatio precox, the new politically correct term will be Non-standard toast and Quick toast.
But more probably it's negative logic (engineers do love that):
Is this a Special Toast? false.
Is this a Standard Toast? true.
Since they weren't really sure, they checked again
Was this a Special Toast? false.
Was this a Standard Toast? true.
Inappropriate use of toast notifications
- Don't use toast notifications to notify the user of something that must be seen, such as a critical alert. To ensure that the user has seen your message, notify them in the context of your app with a Flyout, dialog, app bar, or other inline element.
- Don't include text telling the user to "click here to..." It is assumed that all toast notifications have a click or tap action with a result that is made clear by the context of the notification.
- Don't use toast notifications to notify the user of transient failures or network events, such as a dropped connection.
- Don't notify the user of something they didn't ask to be notified about. For instance, don't assume that all users want to be notified each time one of their contacts appears online.
- Don't use toast notifications for anything with a high volume of notifications, such as stock price information.
- Don't use toast notifications to notify the user of routine maintenance events, such as the completion of an anti-virus scan.
- Don't raise a toast notification when your app is in the foreground and a more contextual surface such as an inline element, Flyout, dialog, or app bar is available. For example, additional instant messages that are related to an ongoing conversation that is in view should update the conversation inline rather than continue to raise a toast with each new message. Listen for the PushNotificationReceived event to intercept push notifications when your application is running.
- Don't add generic images such as icons or your app logo in the image field of a notification.
- Don't place your app's name in the text of the notification. Users will identify your application by your app's logo, which is automatically included in the toast notification.
- Don't use your app to ask users to enable toast notifications if they have chosen to disable them. Your app is expected to work without toast notifications.
- Don't automatically migrate your balloon notification scenarios to toast—consider that it may be more appropriate to notify the user when they aren't immersed in a full-screen experience (desktop style apps only).
- Don't use toast notifications for non-real-time information, such as a picture of the day.
- Don't hide toast notifications unless absolutely necessary.
it does seem like Toasts should be rarely used.....
Of course in the old times there would have been only:
toast.exe [/s n]
is the duration in seconds of the thingy (n
=7 if omitted ) and no check whatever afterwards, let alone writing in it in the event log....
Edited by jaclaz, 29 August 2012 - 12:31 PM.