[Proposal] Centralized Multi-Channel Notification Settings + Persistent Mobile Notifications / Inbox

Status

READY FOR REVIEW

Contributing Team

@Marco Morales , @Sam Daitzman, TBD

Earlier Discovery

[Proposal] Centralized Multi-Channel Notification Settings + Persistent Mobile Notifications / Inbox

Linked Initiatives

https://github.com/openedx/platform-roadmap/issues/381

Overview

The platform should provide persistent web and mobile notifications to drive engagement and retention, with centralized learner settings for all notification types. This work builds on previous edX-ace work and more recently edX / 2U work on web notifications and settings.

Overview

The platform should provide persistent web and mobile notifications to drive engagement and retention, with centralized learner settings for all notification types. This work builds on previous edX-ace work and more recently edX / 2U work on web notifications and settings.

Key Use Cases / Users

  • Learners:

    • Updates and reminders to learn on the go using the Open edX mobile apps to drive engagement and retention.

    • Learners should be able to easily control notifications across all channels (web, email, mobile, etc) centrally in their account settings for both web and mobile apps.

    • A similar notification inbox experience should also be available on the desktop for all open edX instances.

  • Educators:

    • Will be able to reconnect with learners off-platform through mobile applications as other modern tools drive much of their engagement.

  • Operator / Developer:

    • We should align on a singular path for the platform’s notification architecture to benefit from shared velocity, benefitting from existing work in edX-ACE and recent work edX / 2U has developed in the notifications djangoapp in edx-platform.

Deliverables

  • 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.

  • 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.

  • Stage 3 - Notification Settings (Web)

    • Platform notification settings in the account settings area that will scale to support all subsequent stages as new notification categories + types are added.

  • Stage 4 - Web Inbox

    • A web notification inbox should be accessible from the header of the platform for learners and educators, echoing the experience today powered by the notifications django app in edx-platform.

  • Stage 4 - Notification Settings (Mobile)

    • The iOS and Android mobile apps should have a similar native notification settings experience with the ability to fallback to a mobile web view embed for settings as well.

  • Stage 5 - Mobile Inbox

    • The mobile apps should have both push and persistent inbox notifications that can be configured and rendered in the mobile apps.

  • Stage 6 - Notification Category: Discussion

    • Web and Mobile notifications for Discussion updates, across various message types. Mobile push notifications configuration to be aligned as well to these.

  • Stage 7 - Notification Category: Course Dates

    • Web and Mobile notifications for course dates spanning assignment message types and course milestone (end / start / etc). Considerations for how this overlaps with Course Dates / Calendar Syncing included.

  • Stage 8 - Notification Category: Platform / Account

    • Basic messaging for account level updates including account activation or other system updates to be included here.

  • Stage 9 - Notification Category: Other

In Scope / Out of Scope

Based on the above use cases, we are breaking down on high-level scope as follows:

In Scope

Out of Scope

In Scope

Out of Scope

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

 

Channels: Mobile, Push, Web, Email

Channel: Text

MVP Specs

Features & Requirements

In order to realize this MVP, we believe the following features will be required. Refer to the following flow chart for more details:

Feature

Requirements

Feature

Requirements

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

  • Course Updates

  • Site Updates

  • (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.

image-20240905-230240.png
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

 

 

Technical Open Questions

Stage 1 is full of technical questions about how to further the platform’s notification work while leveraging existing work.

  • Q1:

Product Shifts from Django Notifications App

The django app in edx-platform developed by edX / 2U for Notifications has a few product requirement differences between this proposal and what exists today. This section exists to make a short summarized list of the differences for cross-team review and input.

Currently this djangoapp powers the course notifications inbox tool on edx.org’s web experience, as well as notification settings.

  1. Notification Settings by Course - The proposal outlines learner-level settings across channels (Web, Email, Mobile (includes Push)) for various notification categories (ex: Discussion, Dates, Updates, etc) with message types in each category. The existing tool has all this complexity but allows for per-course differences in settings which we believe overcomplicates the setting needs for most learners.

  2. Notifications Settings Page Location - In the notifications djangoapp this page is a freestanding page outside of account settings, with a new tab link shown in account settings. This proposal plans to embed notification settings in account settings directly for both web and mobile. The shift away from per-course settings should also make this settings area more usable and smaller in size.

  3. Inactive Courses -Newly introduced in this proposal is the idea of having Inactive courses (any course a learner hasn’t accessed in over 4 weeks) be excluded from the default “Active Courses” view of notifications, with some way to still get to notifications for Inactive Courses. This is done as a way to reduce the need for notification settings being manually adjusted for inactive /non primary courses. This approach instead relies on student engagement to drive where we focus notification unread counts and visibility.

  4. Category Name: Grading - (Details coming soon)

  5. (Other differences to be documented soon)

Open Tasks

  • Migrate all documented Notification Categories + Message Types to Confluence page, reference here

  • Technology review across teams for Stage 1 feasibility and ideas

  • Link Figma WIP For notifications work in progress

  • Identify list of product requirements that deviate currently from the edx web notifications beta to identify alignment (Ex: notification settings at learner level not course level, use of inactive + active course rules to limit notification volume, etc)

Product & UX/UI FAQ

The following represent our Product view of key questions. However, we look to the UX/UI and technical teams to validate these as needed.

Q: No questions yet!

A:

Future Direction

No notes included for this project.

UI Examples

Updated designs coming soon!