

Don't Spam Your Users: Batch Notifications for Rails - bradleybuda
http://blog.meldium.com/home/2013/4/22/dont-spam-your-users-batch-notifications-in-rails

======
toast76
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.

~~~
borisjabes
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.

~~~
kevinastone
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)

------
jewel
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.

~~~
rnaud
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.

------
kevinastone
I implemented a similar pattern for a django site where users redeem deals
(coupons) to prevent blasting them with multiple receipts.

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.

------
electrum
GitHub really needs to implement this for Pull Request notifications.

~~~
te_chris
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.

