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?
- 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.
- 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).
- 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.
- 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).
- 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.