Some years ago, the universtiy was considering the development of a new student environment, after the portal was retired. Notifications were to be an essential part of that new environment and were also deemed as a top priority, given the university no longer had a single online location for disseminating information. The student environment project was put on hold, but the need for a single, integrated notification system has only become more necessary in its absence.
Users (students, faculty, and staff) do not have a primary location they can access for important notifications. At present, a user may receive notifications from the university via postal service, email, or as an in-app notification or text message (if an individual service has developed that functionality). For users that rarely check their email and/or those that receive a lot of email communications, there is no easy way to identify the important messages. The user will not be able to tell if an email contains vital information specific to them or if it is just another general announcement. Likewise, in-app notifications are helpful, but only if the user logs in. If the user is not expecting anything from a service, they are very unlikely to log in just to verify there are no new messages. In all of these scenarios, users are likely to miss important information and might incur late fees, holds on their records, or miss opportunities that are time sensitive.
For service providers, any team that needs to send important notifications to their users is on their own. Each team must develop their own procedures and tackle the problem of assuring delivery. Across many teams throughout the university, this 'reinventing of the wheel' costs a lot in development time! And with each team handling the problem in their own way, the end user/recipient is left never knowing where or how a notification might be delivered.
The university needs an enterprise-wide notification system for delivering and viewing important notifications. This unified system would be available to all services that provide high priority notifications. For recipients, a Notificaiton Center will be provided - a single location the user can log in to and see important notices from all IU services. In addition, an icon will be added to the global IU header bar so that once a user has authenticated to the IU network, they will be alerted to any new notfications from any system. The user will also be able to set up preferred delivery methods. All notifications will appear in the Notification Center, but the user can also choose to have notices sent to a primary/secondary email address of their specification or to get alerts on their phones.
The notifications system must be well planned and judiciously used. Notifications must be reserved for things that have immediate importance and relevance to the student. In most cases, this will mean information associated with an action the student needs to take. For example, paying a bursar bill or the financial statement being ready to view (in preparation for payment). Other examples might include registration date and time, change in waitlist status, renewing a parking permit, view/pay parking violation, renew/request dorm room, library book overdue, requested library book available for pick up, etc. In each of these cases, the key is that the information is targeted to and relevant to the specific student – it is not just a general announcement going out to the masses. Again, what warrants the status of a notification must be carefully determined. If too many notifications are pushed to students that they deem irrelevant, the likelihood of disregarding all notifications increases dramatically. General announcements should be pushed to students in a different manner with the students having the ability to opt in or out (for example, department events, campus events, etc.).
As we contemplate how the notification system would work and what features would be available, we need to consider the various classes of information that stakeholders may choose to send and how best to refer to and present each type.
Note: The types of informational messages discussed in this document do not include emergency warnings such as campus closings, weather related emergencies, imminent threats to safety, etc. Those types of alerts are handled through Protect IU and their emergency alerts system. Likewise, this system should not be seen as a replacement for or as an additional method for presenting mass mailing list type announcements.
The most important types of notifications are those that are targeted to the individual and that may incur consequences if the recipient doesn’t receive and take action on it. For example, an unpaid parking ticket resulting in a hold on a student’s record; a bursar bill that needs to be paid; a residence hall room renewal; etc.
A step down on the scale, information is still important, but there may be no action required of the user. An example of this might be a new charge or a payment processed to a student’s account. In other cases, the information might require an action, but the consequences for not following through are minimal. An example of this might including alerting students in a department to a special speaker or other events pertinent to their major or class work.
In other cases, information is valuable, but it is not directly targeted at a specific user. And, if the user doesn’t see it or decides not to act on the information, consequences would be little to none. For example, an upcoming event at the user’s campus, not associated with user’s degree, housing, employment, etc.. This type of mass communication, while good to know, is not imperative, and some user will have no interest in certain categories.
Internally, we need to identify the various categories of information, agree on terminology, and determine how to handle disseminating each type.
Potential terminology
A clear distinction between targeted information passed to the students that they must see or that is related to an action the student took or needs to take and that of general information (widely dispersed to large, relatively undifferentiated groups), is vital if we are to make sure recipients see their most important notices. Identifying and setting standards for the use of the notifications system is needed to keep the service from being overrun with lower priority announcements. If users are inundated with information that is not pertinent to them, they will become frustrated with the service and are likely to end up disregarding all notices. Without control, we remove the very utility we are trying to achieve.
The possiblities for notifications are vast. However, as described above, keeping notifications pertinent to the receiver is the goal. Below is a list of possible notifications (not in priority order) for consideration. As the project continues, user feedback should be obtained to determine what notifications to provide in the future and to verify that any included in the initial release are relevant and of the type users want to receive.
Notification Options
Initial wireframes were developed in Axure and are meant to be rough approximations to illustrate basic ideas for the system inlcuding:
The initial version of the Notifications system is currently in development with plans for release in summer 2019.