We can't rely on users remembering to send their contributions or to keep going back to the app to see what's happening in their group.
Create a list with the emails that the app will need to send (e.g.: send your contributions; you have a new message; there's a new open proposal, someone sent you a contribution, etc...) and come up with a layout for the emails.
This is to design/implement the "User Settings -> Notifications" part or only the e-mails itself that the user will receive?
It sounds to me like this issue is focusing on the actual emails received.
TBH I would make this low-priority ... emails can be designed to look like web pages, but ... there are downsides to that:
So I'm assigning "Low priority" tag to this. Plaintext messages are fine. I think KISS applies here.
I think there's a large range between "design pages like web pages" and just raw text e-mails.
The purpose of this issue is to list the emails that need to be sent out, when they need to be sent, their copy and what actions / links will be in each one. All of that is part of "designing" them, not just their appearance. I don't think it should be low-priority, because users need these emails in order to use GI properly - we can't expect that people will remember to check the app periodically, on their own.
The user settings / notifications is not part of this @sandrina-p
So, @mmbotelho should we create an issue to reflect the UI outcome of this list of e-mails? Because somewhere in the App, the user would need to select what e-mails they want to subscribe. (ex: receive e-mails for late payments, but not when there's a new proposal".
That's what I meant by "(email) notifications". You may have confuse it with #663
No @sandrina-p, I just think the Notification settings should be addressed somewhere else, because it will include more than just emails. Does that make sense?
Long story short, the tasks for this issue are:
The way the user enables / disables these things should be a separate issue, but it can be created later, because it's dependant on this one being done first.
Okay, thanks for the clarification @mmbotelho!
Update on this task:
Here are the templates I have created so far. Some of you have already seen this document because I shared it on our last Monday call (May 11th). So, what changed since Monday?
The feedback I need at this stage:
For now it's easier if you can leave comments directly on Notion (I believe you need a Notion account for that). If you don't want to create an account, you can just leave the comments on this GH thread 😄, that works too!
When we are all in agreement I will transfer these templates from Notion to Github so it is properly documented - it's just easier for me at this stage to gather feedback with that document.
Thank you!
Great job @mmbotelho! These are very well done. Here's what I noticed that needs adjusting:
If you don't vote before the [expiry_date], your vote will automatically cast as "indifferent".
Indifferent votes are explicit votes. Votes that aren't cast are treated differently from them (have a look at the math in rules.js). So this sentence should be removed.
And that's about all the feedback that I have for now. Besides that, just want you to know that this feature is unlikely to happen before the prototype, and will likely come out well after.
Excellent @mmbotelho! I hit a snag when trying to create a Notion account, so leaving comments here:
Monthly "balance" (contribution receiver)
Monthly payments (contribution sender)
If we remove the "your vote will automatically be cast as 'indifferent'" sentence, let's replace it with "Voting will close on [expiry_date]."
@taoeffect:
Indifferent votes are explicit votes. Votes that aren't cast are treated differently from them (have a look at the math in rules.js). So this sentence should be removed.
Replaced the sentence with "Voting will close on [expiry_date]." as @dotmacro suggested.
Besides that, I just want you to know that this feature is unlikely to happen before the prototype, and will likely come out well after.
I believe this is a very important feature. I think it is crucial to ensure that people use GI to its full potential. If this is not implemented, we risk having members not vote on proposals, for example, because they simply don't know they exist. The worst scenario is people forgetting to go to the app to check their monthly payments - that renders our entire efforts worthless. We can't expect our users to go check the app daily or even weekly to see if there are any updates.
Can you explain why you are not planning on including this for the prototype?
@dotmacro :
can you add an example of a non-monetary contribution?
Yes! I added an email template for that just now. Let me know what you think.
To me, the sbj and first sentence of both emails sounds like "Your money is ready!" but they mean "Your group's needs for [month] have been calculated." What about e.g.
"[Month_name]'s Contribution Dashboard is now available!"
I would prefer something more clear and actionable. I understand what you are saying though. Can you help me make that suggestion more clear? I'll be thinking about it as well (can't think of anything right now).
If we remove the "your vote will automatically be cast as 'indifferent'" sentence, let's replace it with "Voting will close on [expiry_date]."
Done! Thank you for the suggestion!
And that's about all the feedback that I have for now. Besides that, just want you to know that this feature is unlikely to happen before the prototype, and will likely come out well after.
I agree with @mmbotelho here. If we don't have any kind of Notifications or Email, we are risking damaging the whole experience around GI.
I think people without an account (@taoeffect and @dotmacro) can't see comments in Notion, so I'll leave mine here:
Monthly "balance" (contribution receiver)
Subject: Your balance for [month name]
The month summary is nice, but personally I'd like to also be notified immediately after someone sends me payment. Like it happens with any app such as Paypal, Revolut, MBWay, etc...
I do agree notifications and emails are important for the app. To answer your question though:
Can you explain why you are not planning on including this for the prototype?
Well, we need to get the prototype out as soon as possible since people need it, and it's been delayed long enough.
Based on the current pace of development, I think a functional prototype will be ready before email features will be ready.
One thing we *might be able to get for the prototype is push notifications from chat messages. That too though is uncertain. We'll see!
Be aware that push notifications do not work properly everywhere and as efficient as e-mails.
What is the main challenge of adding a system of e-mail notifications?
Regarding the chat - in my opinion, a chat system that does not have a solid notification system in place is useless - he can people communicate effectively if they have to proactively check if someone sent them a message?
a chat system that does not have a solid notification system in place is useless
What makes you say that we won't have a solid notification system?
The 2 ways we have for notifying users on a non-native app are push notifications and email - am I missing one here?
Summary of what we discussed on today's call:
Emails are tricky to implement and it would take us quite some time to get there. The priority instead is to have GI as a native app and use push notifications.
Correct @taoeffect ?
Yup! 😄 👍
personally I'd like to also be notified immediately after someone sends me payment. Like it happens with any app such as Paypal, Revolut, MBWay, etc...
Ah, right. Even though PayPal et al. notify the recipient when payments are received, that doesn't cover other payment methods for GIS, like crypto, putting a check in the mail, or leaving cash under the doormat.
For the payment balance email:
Yes! I added an email template for [non-monetary contribution] just now. Let me know what you think.
Yay! I like the idea of a delay so users have a time to adjust/correct their entries.
I'm closing this issue. Please check #990 for the updated information on this.