I can see why this would be annoying when a project is first being set up, but once things are underway I much prefer having individual emails for each event. The advantage comes when you only scan the subject line for each notification.
For example, we use trello at my day job to track projects and tasks. They offer to send emails either "periodically (once an hour)" or "instantly". Nevertheless, they still fold multiple actions into a single email if they happen in rapid succession, and send an email that says something like "2 new notifications on the board Development". I would much rather see each notification as a separate email since sometimes they are relevant to me and sometimes they aren't.
I'm on the same boat. I'd rather get each permission notification individually, aside from the notifications when you add a new user to the organization.
I'm assuming when a new user gets added to the org, they probably received one notification saying they've been added to so and so. If that's the case couldn't you just stick all those allowed permissions within the same email?
That is also the approach that we used. Only the "like" action on our platform is bound to happened ten times or more in a row, so it is the only email delayed.
Coding wise, it is a simple as setting a run_at on our Delayed::Job and a custom queue for this user notification. For every new notification we check if there is another delayed job to be procesed in that queue, if it is the case we just edit the run_at to add a few more minutes.
Amusingly, we (BugHerd) have exactly this sort of system in place. Almost universally our users prefer to get individual messages. For a lot of these notification emails, just the subject line is enough for most people to know whether an action is required or not. Grouping the notifications means you _must_ open to the email to see what's going on = more work.
Possibly the biggest complaint is that if you're collaborating on a project, you never quite know when someone knows what you want them to know...meaning you have to pick up the phone to notify them yourself.
We're removing the feature and defaulting to instant notifications. We'll also offer the users the ability to skip instant notifications in favour of weekly, daily or twice daily summaries depending on what is appropriate for their role in the project.
My similar implementation offers these emailing options (every, digest or none). The nice thing about this approach is you can just add logic in the post_commit handler to route the notifications appropriately (instant email, digest queue or /dev/null appropriately based on user preferences)
It also greatly depends on the context. Something like BugHerd (we use and love BugHerd btw!) I definitely want individual notifications for my errors, because as you already mentioned, looking at just the subject lets me know its priority.
However, for something else that is less important, and likely more noisy, aggregated notifications are ideal.
On our platform, our big feature is forms with routing and approvals. When a form is generated and sent to the organization's users, whoever is assigned to approve the forms would be inundated with submissions if they were not aggregated. They're not time sensitive, so acting upon each submission as they happen is never a concern.
GitHub really needs a clearer way to see all the emails that are going to bug you. I'm the admin on an organisation that's quite disconnected so has lots of repos that I don't have anything to do with, the amount of email bs that comes through is unbelievable, but what's worse is having to go to each repository and manually unfollow it.
11 comments
[ 3.2 ms ] story [ 26.8 ms ] threadFor example, we use trello at my day job to track projects and tasks. They offer to send emails either "periodically (once an hour)" or "instantly". Nevertheless, they still fold multiple actions into a single email if they happen in rapid succession, and send an email that says something like "2 new notifications on the board Development". I would much rather see each notification as a separate email since sometimes they are relevant to me and sometimes they aren't.
I'm assuming when a new user gets added to the org, they probably received one notification saying they've been added to so and so. If that's the case couldn't you just stick all those allowed permissions within the same email?
Coding wise, it is a simple as setting a run_at on our Delayed::Job and a custom queue for this user notification. For every new notification we check if there is another delayed job to be procesed in that queue, if it is the case we just edit the run_at to add a few more minutes.
Possibly the biggest complaint is that if you're collaborating on a project, you never quite know when someone knows what you want them to know...meaning you have to pick up the phone to notify them yourself.
We're removing the feature and defaulting to instant notifications. We'll also offer the users the ability to skip instant notifications in favour of weekly, daily or twice daily summaries depending on what is appropriate for their role in the project.
For now Meldium uses a heuristic to batch so if only one event occurs then you still get the subject line brevity that you mention.
However, for something else that is less important, and likely more noisy, aggregated notifications are ideal.
On our platform, our big feature is forms with routing and approvals. When a form is generated and sent to the organization's users, whoever is assigned to approve the forms would be inundated with submissions if they were not aggregated. They're not time sensitive, so acting upon each submission as they happen is never a concern.
In our use case, the emails were just records of the transaction, so an hour or two delay to allow for batching of the emails was acceptable.