Learner Facing Notifications

A web inbox shown from the learner dashboard level for all your courses, as well as a mobile apps inbox experience.

Educator Facing Notifications
(ex: Studio Notifications, Discussion Moderation, Staff Grading Queue, Upcoming Course Publishing, etc)

Centralized Notification Architecture / OEPs

Notification Settings - Web + Mobile + Email

Channels: Mobile, Push, Web, Email

Channel: Text

Stage 1 - Platform Technology Alignment for Notification Infrastructure

• We would like to continue to build our notifications infrastructure centrally in edx-ACE, but we should identify a path for reuse or migration for much of the valuable work done in the notifications djangoapp in edx-platform developed by edX / 2U in 2023 / 2024.

Technical Architecture

We are proposing the extension and continued development of edx-ace for centralized notification channel configuration and routing. Where / how to build the front-end views for notification settings and the web inbox is TBD.

We expect to collaborate with a few edX / 2U teams to learn from the work they have done via the notifications djangoapp in edx-platform, as they have a working beta for web notifications and settings already live in production they have been learning from in 2023 / 2024.

Interested Parties: @Aamir Ayub, @Kelly Buchanan , @​Moiz Alam , @Khanan Grauer, @Volodymyr Chekyrta , + ____

Communication / Proposal Plan

We should work toward a platform OEP for notifications building on what exists to support all stages of this product proposal, but that can’t be started until the technical architecture proposal gets input and is drafted.

Migration Plan

The recommendation to adopt and extend edX-ACE will necessarily mean that we will need a migration plan for the notifications djangoapp in edx-platform. This is TBD based on team review and input.

Stage 2 - Alignment on Product Concept Model for Notifications

• We should get product alignment on the complex layers and concepts in notifications to ensure we are building a scalable and long term solution for learners and a wide range of open edx instances, including appropriate consideration of extension / customization.

Concept Model Visual Summary

Each of the main concepts for product / ux consideration as it relates to notifications will be drafted below.

A single visual summary, echoing previous technology diagrams may also be generated in the future.

Centralized Notification Settings

We plan to add centralized notification settings to the Account MFE (possibly as a plugin?) to embed these settings centrally where learners expect. The mobile apps will have an account settings area that should allow for similar full configuration of notification settings across channels.

It should be possible to configure the mobile apps to embed webviews of the web notification settings in the event an instance with customization wants to only maintain 1 source of platform customization.

Notification Categories

A notification category is the high level type of notification that a user can easily toggle on or off using terms they can identify from their learner experience:

• Discussions

• Dates

• Updates - Course level announcements / instructor messages

• Account - Basic account notifications and other items

• Catalog - Envisioned as a learner facing discovery mechanism for new courses, recommendations, etc.

• Publishing - Envisioned as an educator facing category for content authoring notifications or course publishing details.

• Grading - This exists today in edX’s web inbox experience, as an educator facing category for ORA staff grading needs. Should this be expanded to Operations / Course Operations? The category itself would be course educator facing only, but it seems distinct from Publishing.

• (Others TBD - ex Catalog / Discovery)

Message Types

Each notification category would have its own message types, with the ability for learners to optionally have fine grained control over messages within a given category.

For example with Course Dates, you might have the following Message Types:

• Important Course Milestones

• Upcoming Assignments

• Overdue Assignments

• Shift Deadlines

Notification Frequencies

Some channels may benefit from frequency adjustments to messages, spanning: Immediate, Daily, Weekly.

For example with the Email channel you may want sensible low-volume defaults like Daily or Weekly to avoid the deluge of Immediate notifications as a default.

Notification Channels

Notification Channels are where you might receive a notification, and learners would have the ability to turn off or on notification categories / message types for each category. A list of platform categories is shown below:

• Web

  • Default on, shown in web notification inbox, may not has as many controls to disable as other outbound channels)

• Email

  • Default on, sent to your account inbox, full control as an outbound channel)

• Push

  • Default on (if app installed), settings control for all messages that map 1:1 with a Mobile channel update.

  • It would be possible for platforms to have custom ephemeral messages not controlled by notification settings , or we find a message type to allow for control of ‘Push message announcements’

• Mobile

  • Default on (if app installed), maps 1:1 with a push channel message.

• Text

  • Not included in the scope of this, but another example channel that others could build into the existing infrastructure echoing the same category, message type, and settings controls.

Notification Roles

Our current focus is to support learner facing notifications but it should be possible to have role driven notifications. For example on the web, an educator only notification might remind an educator that there are Staff Grading needs, or Discussion moderation needs, etc.

For now we are not considering Web notifications into the Studio / Educator experience, but this could be envisioned as a future update that builds on the role distinction. Similarly the mobile apps have no educator focused tools.

Notification Plugins / Customization

Details TBD on how other platform users might extend the notification system to have their own notification types, or adjust which messages are turned off / on at the site or instance levels.

Notification Grouping

Notifications should be able to be grouped whenever a learner has more than 1 of a given message type, reducing the noise in the notification experience and increasing the likelihood that someone engages with a message.

Open

Quick Concept Sketch for Levels 1 → 3 of upcoming assignments message type, not representative of final visual design or content.

Grouping Levels:

An example of a grouped course assignment notification is detailed blow along with a concept sketch for the notifications.

• Level 1 - Due in 3 hours: Homework 2 - Forum Introduction in History 101.

• Level 2 - You have 3 upcoming assignments due this week in History 101.

• Level 3 - You have 6 assignments due this week across 5 courses.

In the first level you have updates within 1 learning context (1 update in 1 course). At the next level you can group similar message types across 1 learning context ( 3 updates in 1 course). Finally you can group multiple updates across multiple learning contexts (15 updates across 6 courses).

Grouped Message Routing:

Whenever messages are grouped, we must consider where the notification will route a learner. For example, in the mobile application the example above would do the following:

• Level 1 - take the learner right into the content, the first incomplete graded unit within the assignment / subsection.

• Level 2 - take the learner to the course dates page since that shows the full assignment list

• Level 3 - take the learner to the app level dates page.

Feature / Configuration Dependency for Grouping

Note that if a given feature like “All Level Dates” is not enabled and thus not somewhere we can route learners in the mobile app example above, we can still group messages of that kind as a Level 3 message, but when learners click that message is should go to a nested view (or expand the list of Level 2 messages within that set). This way we have a fallback but can still group messages to reduce the inbox volume of messages.

Alternative Grouping Options - Inactive Course Grouping

There are other options for grouping notifications that we are considering, such as grouping all notifications for each inactive course into 1 message. If we were to move forward with this, we would have all notifications for each inactive course be grouped into 1 message as shown below.

• Inactive Level 1: You have 52 updates in the inactive course History of Europe.

• Inactive Level 2: You have 168 updates across your 5 inactive courses.

Read / Unread / Unseen + Counts

Details TBD on how notifications are can be read / unread / unseen / counted

Notification Removal / Filtering

Details TBD on how notifications are cleared / reset / hidden over time

To include - Inactive vs Active courses & Notifications dropped after audit access expires