Nicer emails

[fellhorn]

HTML mails and also confirmation of user input data

[fellhorn]

We should also add some basic information about the event:
Date & time when it starts, timeslots of the dishes, ...

[marcelklehr]

Where in the code base is the code that sends mails?

[marcelklehr]

Nevermind. grep ftw! ;)

[marcelklehr]

Is there a reason the confirmation email is not sent to both participants of a house in one go?

[danielrenninghoff]

No :D. You can change that. But what I will do is send the sepa lastschriftmandat only to email1 (in a separate mail).

[danielrenninghoff]

Actually, we use the name of the person in the email-text, so it needs to be separate.

[marcelklehr]

Great. We could write "Hello {name1} and {name2}", though.

[danielrenninghoff]

Ok, that sounds like a good idea :)! btw, I just commited a change to the email_senden function.

[marcelklehr]

In a68cd76...master I introduced mail templates. I haven't tested actually sending the mail as I don't have a mail server, though.

[marcelklehr]

Also, The about-us section would benefit from being placed into a separate, reusable template, so both mails and frontend can use it...

[danielrenninghoff]

The problem with html emails is that you can't be sure how they will get rendered and that is a big problem. A lot of email clients don't load external sources by default and then your emails will look really bad. Another problem is HTML5 support. The current templates you developed use bootstrap and HTML5. Most email clients don't even render divs correctly and that is why email templates often still use tables and inline styles.

For more information:
https://stackoverflow.com/questions/127498/what-guidelines-for-html-email-design-are-there
https://stackoverflow.com/questions/4829254/best-practices-for-styling-html-emails
http://foundation.zurb.com/emails.html

The last link shows an alternative to bootstrap that is specifically optimized for emails.

So in total, crafting email templates is a complicated process that imho is not worth it for our use case. It is especially not feasible to share code between the main site and the html template.

I'm of the opinion that we should remove the html mails in their current form, because having a simple plaintext email that everybody can read is better than having a html email that looks like **** because the client is rendering it wrong.

On the other hand I think your plaintext templates are really nice and we should continue using them.

Any opinions about this topic?

[marcelklehr]

Fuu, didn't know about that... That sucks. Then I agree that we should avoid HTML mails.

[fellhorn]

Yeah I know about this issue. I used the zurb templates for a customer once. They provide something like a very basic common understanding for almost all mail clients. I personally like the welcome template from this site:
http://foundation.zurb.com/emails/email-templates.html

We should definitely spend not more effort than using a copy & paste template. In my opinion it would be already enough using only some table layouting and putting the logo in the mail. Just to make it a bit nicer. (Says the guy reading mails only in plaintext...)

[marcelklehr]

Do we need to confirm emails, btw, to make sure the people actually signed up?