Custom Notification System Research & Implementation Plan
MVP shipped in v2.6.16. Phase 2 (chat, calendar, activity notifications) was attempted but dropped — notifications worked on the maintainer's machine but the user reported receiving no notifications at all. It remains unclear whether the implementation failed in their environment or whether the user's expectations differed from what was delivered. See #2108, #2039.
Status: MVP Complete (v2.6.16) | Phase 2 Dropped Date: November 2025 Issue: Investigation for alternative notification modal system Author: Claude AI Assistant Dependencies: Incremental Refactoring Plan Phase 1 (Completed)
Executive Summary
This document tracks the development of a custom notification modal system for Teams for Linux as an alternative to OS-level notifications. The MVP (toast notifications) has been successfully implemented and released in v2.6.16.
Current Status
- ✅ MVP Complete (v2.6.16): Toast notifications with auto-dismiss and click-to-focus
- ✅ Documentation: Configuration and usage guides updated
- ❌ Phase 2 Dropped: Chat/calendar/activity notification routing did not work for the requesting user
Key Findings
- Custom BrowserWindow approach works well following the
IncomingCallToastpattern for meeting notifications - Phase 2 notification routing worked reliably on the maintainer's machine during development and testing
- The requesting user (#2039) reported receiving no notifications, or their expectations may have differed from what the implementation delivered
- Root cause is unclear: could be environment-specific (desktop environment, notification daemon, Teams account type) or a mismatch between what was built and what the user needed
- Issue #2039 closed as not feasible given the ambiguity
1. MVP Implementation Summary (Completed)
What Was Implemented
The MVP delivered toast notifications as an opt-in alternative (notificationMethod: "custom"):
Files Created:
app/notificationSystem/
├── index.js # CustomNotificationManager class + IPC handlers
├── NotificationToast.js # Toast BrowserWindow class
├── notificationToast.html # Toast UI (Teams design)
├── notificationToastPreload.js # Toast preload script
└── README.md # Module documentation
Features Delivered:
- Toast notifications appear for Teams notifications
- Auto-dismiss after configurable duration (default 5 seconds)
- Click toast to focus main window
- Teams design language applied
- Cross-platform compatibility (Linux, Windows, macOS)
- Secure implementation (contextIsolation, IPC validation)
Configuration:
{
"notificationMethod": "custom",
"customNotification": {
"toastDuration": 5000
}
}
2. Next Steps Investigation
2.1 Recommended Next Phase: Notification Center (Session-Based)
Based on the original research and common user needs, the most valuable next enhancement would be a Notification Center - a drawer showing current session's notifications.
Why This Phase:
- Users cannot review missed notifications with toast-only system
- Provides context when returning to the application
- Follows established patterns (Teams, Slack, Discord all have notification panels)
- Session-based (no persistence) keeps implementation simple
Proposed Features:
- Slide-in drawer showing current session's notifications
- Mark as read/unread status
- Badge count on tray icon
- Clear all functionality
- In-memory storage (NotificationStore class)
Estimated Effort: 1-2 weeks
2.2 Alternative: Enhanced Toast Features
If user feedback indicates toast improvements are more valuable than a notification center:
Potential Enhancements:
- Toast queue management (limit visible toasts, e.g., max 3)
- Action buttons (View, Dismiss, Reply)
- Hover to pause auto-dismiss
- Notification stacking (vertical arrangement)
Estimated Effort: 3-5 days
2.3 Integration Options
These could be done alongside either phase:
- Tray integration - Badge count showing unread notifications
- DND mode - Respect user availability status
- Keyboard shortcut - Toggle notification center (e.g.,
Ctrl+Shift+N)
3. Decision Criteria for Next Phase
User Feedback Signals
Before proceeding with Phase 2, evaluate:
- Feature requests: Are users asking for notification history/center?
- Toast issues: Are there reports of problems with current implementation?
- Adoption rate: How many users have switched to
notificationMethod: "custom"?
Technical Considerations
- Complexity vs Value: Notification center adds significant complexity
- Maintenance burden: More code to maintain and test
- Integration points: Tray icon, main window focus handling
Recommendation
Wait for user feedback before implementing Phase 2. The MVP provides a working alternative for users with notification issues. Additional features should be driven by actual user needs rather than speculative development.
Suggested approach:
- Monitor GitHub issues for 2-4 weeks post-release
- Create a discussion or issue asking users what they'd find most valuable
- Prioritize based on actual feedback
4. Phase 2 Implementation Plan (When Ready)
4.1 Notification Center Architecture
┌──────────────────────────────────────────────────┐
│ Main Process │
│ │
│ ┌─────────────────────────────────────────┐ │
│ │ CustomNotificationManager │ │
│ │ ├── NotificationToast (existing) │ │
│ │ ├── NotificationCenter (new) │ │
│ │ └── NotificationStore (new) │ │
│ └─────────────────────────────────────────┘ │
└──────────────────────────────────────────────────┘
4.2 New Files Required
app/notificationSystem/
├── center/
│ ├── NotificationCenter.js # Center BrowserWindow
│ ├── notificationCenter.html # Center UI
│ └── notificationCenterPreload.js
├── store/
│ └── NotificationStore.js # In-memory storage
4.3 New IPC Channels
notification-open-center- Open notification center drawernotification-close-center- Close notification centernotification-mark-read- Mark notification as readnotification-clear-all- Clear all notificationsnotification-get-all- Get all notifications for display
4.4 Configuration Additions
customNotification: {
toastDuration: 5000,
// New Phase 2 options:
centerEnabled: true,
maxStoredNotifications: 100,
showBadgeCount: true
}
5. Long-Term Roadmap
Phase 3: Enhanced Toast Features
- Toast queue management
- Action buttons
- Hover to pause
Phase 4: Integration & Polish
- Incoming call toast integration
- Unified notification system
- Performance optimizations
Phase 5: Advanced Features (If Requested)
- Persistent storage (IndexedDB)
- Search & filter
- Custom sounds per type
- Reply actions
- Snooze functionality
Philosophy: Each phase should be validated before proceeding to the next. Add features only when users request them.
6. Background & Context
Problem Statement
Users reported OS-level notifications don't work reliably, especially on Linux:
- Application freezes when no notification daemon is running
- Inconsistent behavior across desktop environments
- No notification history or actionable notifications
Why Custom BrowserWindow Approach
- No viable third-party libraries - All existing packages are 5-9 years old
- React libraries incompatible - Teams for Linux is an Electron wrapper, not a React app
- Proven pattern -
IncomingCallToastdemonstrates this approach works - Full control - Consistent experience across all platforms
Architectural Constraints
- Cannot modify Teams DOM directly
- Must use separate BrowserWindows for custom UI
- Security requirements: contextIsolation, nodeIntegration disabled
- All IPC channels must be allowlisted
7. Related Documentation
Internal References
- Module README (
app/notificationSystem/README.md) - Implementation details - Contributing Guide - Architecture overview
- IPC API Documentation - IPC channel reference
- Configuration Reference - Config options
External References
Related Issues
- #1979 - Implement notifications modal MVP
- #1981 - Add custom notification system to docs
- #1935 - Build notification modal component research
8. Conclusion
The custom notification system MVP is complete and provides a working alternative for users experiencing OS notification issues.
Lessons Learned:
Phase 2 highlighted the difficulty of testing notification routing end-to-end. The implementation worked on the maintainer's machine but failed (or appeared to fail) for the requesting user. Possible explanations include differences in desktop environment notification handling, Teams account type affecting DOM mutation behaviour, or a gap between the user's expectations and the feature's scope. Without clearer diagnostics or more users requesting the feature, further investment is not justified.
Next Actions:
If custom notifications beyond meeting toasts are requested again by a different user, the recommended approach would be to first establish a shared understanding of what notifications the user expects, then provide a debug build with diagnostic logging so the user can report exactly what events fire in their environment before writing any routing logic.
Document Status: ✅ MVP Complete | ❌ Phase 2 Dropped Current Version: v2.7.6 Last Updated: 2026-02-18