Customizable Notification Preference Panel

Question

This is certainly not a new idea, and could be improved into a bigger pref pane, but here it is:

            Global Inbox     Site Summary    E-mail    RSS *
reputation  [ ]              [x]             [ ]       [x]
revisions   [ ]              [x]             [ ]       [x]
favorites   [ ]              [x]             [ ]       [x]
responses   [x]              [x]             [x]       [x]
flags       [ ]              [ ]             [ ]       [x]

copy those preferences to related accounts

^{*** As I see it, RSS shouldn't be needed here - it should simply be all "marked" by default. The rest is marked according to the way I believe the notification system works today. And I'm pretty sure this example could be improved by someone with more experience.}

Now, I'm not a fan of a big list of preferences too, but I do like Secrets and all the analogy it can represent here, if you use a Mac and know what I mean - OS X also avoids having too many tweaks and options, sometimes way too much. But there are lots of tweaks are hidden within the OS. Just sayin'... What Secrets do is bring way too many preferences together and an easy way to search what you need. On top of that, each pref doesn't need to exist in one place only. It should blend in where it's needed.

There is no "one Q&A to rule them all" and they're separated in many, many topics, but we do have "one preference to rule them all" for quite a long time now. Let us tweak! :P

Answer 1

The aversion to adding too many preferences isn't only because it would clutter the Preferences page. We have a few preferences that aren't on that page but are separated off onto their own or in altogether different places. But, you have to store those preferences somewhere, and that somewhere is usually in the database. Adding tons and tons of preferences, even if integrated well into the UI, muddles the database a lot because they need to be stored in a way that makes them easy to access and update in a fast-paced environment. This complicated of a structure for notifications just cannot be justified in that regard.

To summarize that last statement:

• We would probably never implement per-site preferences for the global inbox. If we ever did add settings for which ones you see, they'd be global to all sites.
• We would never add options that let you choose which things go to you on-site inbox, get emailed, or show up in your RSS feed. They'd always appear in all locations based on the existing conventions.

However, there is an incredibly simple situation that I don't think anybody considers often enough: store all these preferences on the user side. Not every situation requires storing the preferences in the database, so we shouldn't be afraid to... not do that. How would this work, you might ask?

1. Essentially, we wouldn't make any changes to the way the global inbox works at all. We'd continue sending all inbox notifications to the user.
2. Add some other types of notifications that can be sent to the user (such as notifications of rejected edits, notifications of questions you've closed being edited, whatever).
3. Add an "options" link directly in the global inbox that opens up a sub-panel of all the things users can choose to be notified about. Let the user choose.
4. Store a more detailed composition of those selections in the user's local storage so their options can be easily accessed and applied on-site. Then store a compressed version of those selections into the database for the user in a single field (so they can be grabbed in other browser sessions or on other devices - this might get a bit complicated).
5. Filter the list of all inbox notifications the user gets to just the ones currently allowed in their client-side options, rather than doing it server-side. If the new notification sent to the user doesn't match any of their filters, just ignore it.

Benefits

This kind of system puts the burden of filtering and selecting notifications onto the user and keeps the system behind the scenes cleaner. By not completely disabling inbox items from being created in certain situations, users would also still be free to go back and find past notifications that were hidden from them when changing their filters.

This feature could also be easily expanded to include other filtering options for the inbox that could also be applied client-side and don't need the server to actually parse them.

Drawbacks

As mentioned before, making this work across multiple browsers and devices could get tricky and would probably be a bit buggy.

Making this change would also require API and app updates before it is ever pushed out to the public, to make sure users don't get irritated by tons of unwanted notifications ending up on the app because they wouldn't have the same filtering options (devTime++). This certainly wouldn't be something that would happen quickly.

Answer 2

Even with animuson's answer, I still think customizable notifications is worth looking into.

While the implementation might take some of work, customizable notifications would help alleviate the multiple "get notifications for X" questions.

For instance, a lot of my contributions on SE tend to be edit suggestions. Personally, I'd love the option to be immediately notified when one of my edits is rejected. Yes, I get a generic prompt that one of my edits was rejected when I go to submit an edit, but a more specific notification would be helpful.

Meanwhile, some have asked for notifications when one of their posts has been edited in case it may have deviated from their original intent. While I know I'd appreciate notifications when my post is edited, I assume the the majority of SE users would find it annoying. It wouldn't make sense to spam every SE user with notifications for this.

TL;DR: Not every user wants notifications when an edit is rejected, but some users might like to have the option.