Group-income-simple: List all emails that the app needs to send out, design them

Created on 21 Feb 2020  ·  23Comments  ·  Source: okTurtles/group-income-simple

Problem

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.

Solution

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.

Frontend UUX Low

All 23 comments

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:

  1. Users who use text-based email clients cannot see the amazing HTML you designed. It is true, emails can be sent in two forms (a plaintext version and an HTML version), but this is something a big company has the resources to do. We are not a big company.
  2. Many users, including myself, disable image loading in email, because it is used to track users, and can also be used to hack users with maliciously crafted images. It is good practice to disable image loading for emails.
  3. There is little real-world payoff for sending a fancy HTML email. Users are not going to magically love you more for this. Some of them will dislike you for it. And many email spam blockers will block your email outright for it.

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:

  • Create a list of emails that needs to be sent;
  • Their copy;
  • When they are sent;
  • Their UI (even if it's plain text).

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?

  • Fixed grammar and typos (thank you @dotmacro!);
  • Added notes explaining the requirements for an email to be sent and when to send it;
  • Added “Monthly balance” email;
  • Added “Monthly payments” email;

The feedback I need at this stage:

  • Tone of voice, words used - I tried to use a very neutral speech. We can change this to a more friendly/loving tone if you want to. I think it would make sense with the Group Income “brand” to have a friendlier tone, but I also don’t mind the neutral. Let me know what you think;
  • The actual emails being sent - to do this task, I placed myself in the shoes of someone that is very busy and does not remember that GI exists EVER. I believe it is useful to think in these terms because it means that people can in fact forget that GI exists until action is required from them (this may sound bad but it’s actually a good thing). So, do you think there is any critical information or email missing? Or, is it possible to reduce this list further without damaging the cohesion of the group?
  • Technical questions - please let me know if the requirements I left on the document are not enough for you (whoever it may be) to successfully implement this or if there are any technical limitations I should be aware of.

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)

  • can you add an example of a non-monetary contribution?

Monthly payments (contribution sender)

  • can you add an example of a non-monetary contribution?
  • 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!"

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:

  • Can we structure notes the same way as for proposal emails?
    "This is the note that [member_name] left on the payment. If there's no note, we can remove this paragraph entirely" - [member_name]
  • Everyone is a "contribution receiver" :)
    Hmm... it would be neat if all contributors could send notes to their recipients, whether in a separate email or included with 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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

sandrina-p picture sandrina-p  ·  8Comments

mmbotelho picture mmbotelho  ·  6Comments

taoeffect picture taoeffect  ·  3Comments

sandrina-p picture sandrina-p  ·  5Comments

mmbotelho picture mmbotelho  ·  8Comments