Carl,
I'm aware of this. Another example is if you're assigned to a bug in this bug-tracker, you want notification via SMS (if supported), but you also want the email, so you have it in your files.
There are basically 3 options we can choose:
- Always multiple notifications (status quo)
- Application decides between multiple or one (my solution)
- User decides
I decided against letting the user decide, because coming up with the data model and user interface to make that happen would be too large a task for our engagement.
I decided on the application-determined one-notification approach, because that's basically how the old bboard worked (if you had thread notifications, you wouldn't also get the forum notification, though I suspect you might actually still get the batch notification if you had that ...).
It's still not perfect, but I think that if we want to ensure that people get notified when they're assigned to something, we don't want them to get overloaded with spam.
What it seems is that notifications have play two different roles, only one of which was really designed into the system. One is "notify", the other is "archive".
The first is "let me know when something happens". Once you've been notified/alerted/let know, good, now you know.
The other is "I want to keep a record in my files of this". This goes somewhere where you don't read it very often, all you want is to make sure that everything gets stored away safely there.
Makes sense?
/Lars
