Notifications

[krusynth]

We've got a few tickets open for tweaks to the Notification system, but I wanted to start pulling some ideas together in one place.

• We should have a visual display of notifications that the user hasn't read in the navbar. See how Facebook, LinkedIn, etc do this.
• We should allow users to "follow" a specific document.
• Maybe we should allow users to follow a specific comment thread, such as one they've commented in or started. Maybe we should allow them to follow arbitrary threads.
• Ideally we would use the same notification system for all of these, but we don't want to use polymorphic relations again if we can avoid it.
• We should allow users to customize their notifications: by email, on-site notice, or email digest daily(weekly?); unfollow documents/threads from one place.
• Maybe documents that are closed for comment that the user is following should send one last notification and then not show up in their "following" list anymore.

[sethetter]

Sounds like we should have some kind of "subscriptions" list that they receive notifications about. Some would be automatically created (documents they own, comments they've made, etc) with the ability to add more within context of the thing they're subscribing to. Also a single interface for seeing all things they are subscribed to and being able to control them.

All in all, this sounds good to me.

[doshitan]

Yes, we should have a simple on-site/internal notification system (e.g., GitHub) and the user should be able to choose which kinds of notifications go where (email and/or on-site). This is especially true now that we allow users to sign up and use the system without verifying their email.

Being able to follow/subscribe and unfollow/unsubscribe to documents and maybe discussion threads seems good. We need to define what exactly a follow/subscribe means though. Like on a user's own comments, they might want be notified when someone likes it or flags it, but if they are following another comment/thread should they be notified of likes/flags for those? Only new comments? Edits (if/when we support this)? If we present them in the same interface as the same "kind" of subscription, but they behave differently that wouldn't be good. Same for a document follow. Are they following for new comments/discussion or for supports and opposes as well? Should all these options be configurable?

I imagine folks only currently care about new comments when subscribing to these things and that's probably a fine place to start. Adding a bunch of knobs to be able to say "I want to be notified of this, this and this on this thing and only this and that on this other thing" doesn't seem worth it to me at this point.

The exact meaning of a follow is of course going to evolve in time, like if/when we add support for version/updating a document or for "update"/sponsor comments (e.g., Kickstarter), but I just want to be sure we have clearly defined what events trigger what kinds of notifications even if we don't have a knob for the user to configure their preferences for each of those events.

The current Madison 3.0 notification setup is closely tied to our set of Laravel Events. The notification preferences and user interface use the event names as keys and the current events are kinda general and will need some tweaking for a better system. For instance, we currently have a CommentCreated event that we fire, this is presented in the user notification preferences as "When a new comment is made on something related to you". That description doesn't exactly match the intent of the event. The CommentCreatedNotification listener takes the CommentCreated event and if the comment has a parent, sends a notification to the user who made the parent comment, but the notification preferences uses the general CommentCreated event id to determine if the parent wants to be notified of these things. This setup obviously doesn't work when we want multiple different kinds of notifications that could be triggered by a comment being created (e.g., document activity, replies). So we'll need to make more and more specific event classes (e.g., a CommentReplyCreated that the CommentCreatedNotification listener and the notification preferences could use instead) if we wanna keep the same system. We could also break apart the events from notifications and have some way of mapping what events trigger what kind of notifications in the back end, but I lean towards making distinct event classes for any kind of thing that a user might want to be notified about.

That approach can kinda get into overload for the user if they can/need to configure preferences for every possible kind of thing that could happen in the system. We could of course expose simpler/more general categories on the client side that ultimately just set the specific event preferences and maybe have and "Advanced" view wherever the user can set preferences if they want to pick and choose the exact events to subscribe to. I guess that doesn't sound too bad.

Anyway, that was kind of a rambling stream of consciousness. I think I'll stop typing now (^_^).

TL;DR, yes, let's start simple, implement internal notification system w/ delivery preferences (maybe no digest to start) for the notifications we already have, then add document "following", see where to go from there