-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Email notifications - either digest or realtime to tell you when you've missed a bing/invite/etc. #108
Comments
This is higher priority than P3 - see also SYN-169. It's a really important way to keep people engaged with Vector. |
I won't make it block v0 though. |
Removed from v0 |
Notes from discussing this with Amandine this morning:
I wonder if this means we need the daily digest ones? Perhaps they can be implemented as an entirely separate mechanism. I find them quite annoying, and would probably prefer that we only spam people with updates when something new has actually happened (and these can contain the same overview stats as a digest would...) |
Don't forget invites in the above. I guess it can be just a single email everytime someone invites you, even if he used your mxid, and if don't join in the next 4 (?) minutes. (see table) I wouldn't want to have metrics like who joined rooms and how many unread msg there are in the notifs emails sent for highlight/sound or invites, but once a day it would be interesting. So I'm still quite keen on keeping the daily digest if something new happen only and which would include:
However I understand the spam concern, so an option would be to deploy first the notifications and see how spammy it feels and then add the digest on a second step |
(We've agreed that for now invites & messages should have the same idle timer before email notifs kick in - 2 mins for now) |
One refinement that came up when discussing with dave & erik just now: rather than sending if the user has been idle for 2 minutes, we should probably wait for 2 minutes (or whatever the retry timer is) of inactivity after seeing the event before sending the email. If the user wakes up and uses the app, we should discard any pending email notifs and probably reset the timer schedule. This stops us from spamming the user if they're actually responding to push notifs elsewhere. We could reduce the minimum timer to 0s if we know the user isn't polling and has no pushers set up, but that's a bit of an edge case. |
There are now designs for this in basecamp. |
I'd really prefer separating this from hilight/sound notifications - as a case in point, I use Vector on the bus over cellular + tethering. However, there are various dead spots, some of which last for 5min or so. The instant I exit the dead spot, I'm alerted to new messages and invites by my phone, due to exactly hilight/sound notifications - but in the mean time, Vector may have sent me emails that are really just so much spam. |
(see also https://matrix.org/jira/browse/SYN-169) |
Have tried to summarise requirements on https://docs.google.com/document/d/1ZNxBMb9zoJNRZ12T-3_OCMgrcb3KhppTDaXtls1uDYs/edit |
this is pretty much live now. |
* Use Compound close icon in favour of mishmash of x/close icons Signed-off-by: Michael Telatynski <[email protected]> * Update snapshots Signed-off-by: Michael Telatynski <[email protected]> * Remove stale CSS Signed-off-by: Michael Telatynski <[email protected]> * Iterate Signed-off-by: Michael Telatynski <[email protected]> * Update snapshot Signed-off-by: Michael Telatynski <[email protected]> --------- Signed-off-by: Michael Telatynski <[email protected]>
No description provided.
The text was updated successfully, but these errors were encountered: