Don't Spam Your Users: Batch Notifications for Rails
blog.meldium.com
Don't Spam Your Users: Batch Notifications for Rails
1–10 of 12 posts
Re: Don't Spam Your Users: Batch Notifications for Rails
#2I 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.
Re: Don't Spam Your Users: Batch Notifications for Rails
#3I 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 mul…
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?
Re: Don't Spam Your Users: Batch Notifications for Rails
#4Too many stories from meldium.com. Annoying.
Re: Don't Spam Your Users: Batch Notifications for Rails
#5I 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 mul…
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.
Re: Don't Spam Your Users: Batch Notifications for Rails
#6Amusingly, 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.
Re: Don't Spam Your Users: Batch Notifications for Rails
#7GitHub really needs to implement this for Pull Request notifications.
Re: Don't Spam Your Users: Batch Notifications for Rails
#8GitHub really needs to implement this for Pull Request notifications.
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.
Re: Don't Spam Your Users: Batch Notifications for Rails
#9Amusingly, 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 collabor…
Interesting. I think ultimately user control is what you want here. For example, Trello offers a choice between Instant, Hourly, and Never.
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.
Re: Don't Spam Your Users: Batch Notifications for Rails
#10Amusingly, 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 collabor…
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.