MyUW Notifications Overview
MyUW displays targeted and action oriented notifications to users when they log in. Campus units or services that want to take advantage of this capacity can contact the MyUW Service Team to discuss being a notification producer. MyUW notifications are generally not intended to be the sole mechanism of relaying important information. News announcements, email, or notifications in other systems may also play a role.
- Notifications need to be targeted to the relevant audience, generally identified as a group in Manifest, the campus grouping and authorization system (see Manifest - Service Description), or indicated by a data source flag.
- Notifications should have a short, action-oriented message that includes a link to the online system for completing the action.
- The notification should be displayed when the action can be taken and removed once the action has been taken or can no longer be taken.
Types of Notifications
Priority (banner and bell)
These are reserved for notifications that are very important to the targeted group. Individuals would typically see at most one at any point in time, although more than one could be accommodated. Users should be able to dismiss these notifications unless they disappear automatically when no longer relevant.
Examples: HRS upgrade outage currently underway
This is the most typical notification. Individuals may have more than one at any given point in time. Clicking on the bell displays the active notifications. The bell is accessible across all MyUW frame apps.
Examples: Request to complete NSEE survey, availability of WRS benefit statements, City of Madison snow emergency, notice of pending removal of access to particular O365 features
App-specific messages may best be delivered within the app itself. This segregates app notifications so they don't clutter the general notification feed and are more effectively displayed in-context at point of interaction.
Examples: Pre-announcement of upcoming HRS outage
Units interested in using MyUW Notifications should contact the MyUW Service Team. We will work with you to discuss your needs and determine the appropriate options. This process can take time, especially for the first engagement, so please reach out to us with as much advance notice as possible. Notifications and feature announcements are manually processed by the MyUW Service Team. Processing of in-app messages may be delegated to the appropriate administrator or app team.
1. Contact MyUW
Contact the MyUW Service Team Lead or email@example.com with the details of the notification at least 30 days before your desired date of publication. Someone from the team will get back to you for clarification or to advance the request.
2. Review and confirmation
The MyUW Service Team will review proposed notification and channel. The review of the notification includes:
- When does it need to go out?
- How broad is the target audience?
- Is it closely associated with a particular course/app/system?
- Is it action-oriented or strictly informational?
- Is it a repeated or a one-time message?
- Is it something users must see or act on?
3. Preparation and verification
The team will be in contact with you prior to the publication date to ensure that the message information is accurate, the link works, and any necessary target preparations are in place. This helps us avoid false, inaccurate, or otherwise faulty notifications.
The team can meet with you to review any available click through statistics and opportunities for improvement.
- Target group(s): The group(s) to whom the notification should be displayed. Ex: Students eligible for NSSE
- Short message: The notification to be displayed. Example: “You are eligible to complete the National Survey of Student Engagement”
- Action/info link: An URL or relative link for action or where to get more information. Example: Take survey https://my.wisc.edu/go/nsse
- Start/end date: The date the notification should be added to the portal, and that on which it should be removed, typically during the Tuesday morning maintenance window. Example: Post on Tuesday October 4, 2016. Remove on Tuesday October 25, 2016.
- Source: The individual or system from which the notification originated. Example: UW-Madison Academic Planning and Institutional Research
- Dismissable: Whether or not the notification can be dismissed by the end user. Example: Dismissable
- Data Source: Notifications have the capability to only be visible to a user when the user has certain data available via a JSON data feed. Example: A JSON data feed from SIS/CAOS could indicate that a student has an enrollment hold.
More detailed information is available in the MyUW Notifications Guidelines document (https://goo.gl/sYfTNF), including a table summarizing the characteristics of each type of notification.