Closed hunvreus closed 8 years ago
Just a couple examples of newsletter (rather than just the transactional email for Dropbox):
Tiny letter has a very simple and clean email for features announcement
Mapbox send updates about recent blog posts:
@1272729223 Go ahead!
@erqiudao Help if you can/want.
Looked into this further yesterday. I would like to start working on this; maybe use Ink as a starting point but strip it of everything we don't need (we don't need grids basically since we have always only one column).
I'd like this to be some kind of gulp
based tool, having the style as SCSS and a build step to inline it in the page, rather than the approach of Ink.
@quentinberder to clarify what he things is possible w/ Intercom. I went through some of their documentation and what I understand is the following:
Type | Description | Platform |
---|---|---|
Transactional | System information delivered to the user (account creation, new repository, alerts...). Purely informational and potentially even legally required. | Direct email/Mandrill |
Notification | User-centric email triggered on certain events; information filled in, inactivity on account, account renewal... | Intercom |
Marketing | Regular, bulk campaigns (new features, new releases, ...) | Mailchimp + Intercom |
A couple things:
@quentinberder thoughts? We're likely gonna use the same on SweepBoard, so I'd like us to agree.
That looks like a sound approach to me, I agree with the breakdown. I will look into Mandrill as I am not familiar at all with it. I will move this to the wiki.
Transactional
I do not really like it. We should display more branding for devo.ps and have more actionables in the email such as Twitter, website and such. @erqiudao
It's Transactional not newsletter "Transactional emails should be efficient: they need to have a limited branding (just the logotype part of our logo without the name "devo.ps") and a simpler layout (no color, almost raw text)." - Ronan
"Twitter, website and such." is in the newsletter which i'm working on.
I do not agree with it, perhaps we can leave out the actionables but branding should still be prominent. Users forget and will remember seeing name, logo and colors. @hunvreus
newsletter
No need for a separate repo when this is related to the content and marketing that is developed here. I moved things in a subfolder: https://github.com/devo-ps/devo-ps.github.io/tree/master/email
My feedback;
I don't think the current layout/style is working:
Code at https://gist.github.com/hunvreus/8aa8e6d756075df19f60
You can do another round of design with @erqiudao if you want; I'd focus on getting the notification/transactional template done and then "maybe" tweak a tiny little bit the design to make it work for the newsletter (basically supporting a list of announcements/blog posts or something).
ok =^● ⋏ ●^=
Doodle time:
Also, use the colors defined on the website: $line
, $light
, body has a color too (I think tint($black, 25%)
), $blue
, etc.
Mailgun just published some of their own templates: http://blog.mailgun.com/transactional-html-email-templates/
May be worth checking their approach and see if we should steal of their ideas. Their templates seem simpler/cleaner than the other ones we had seen.
We intend to send emails to our users:
The newsletter will obviously have a stronger/more obvious branding (larger logo maybe) with a more appealing design.
Transactional emails should be efficient: they need to have a limited branding (just the logotype part of our logo without the name "devo.ps") and a simpler layout (no color, almost raw text).
I think Dropbox does a good job at this with minimal branding:
For implementing this, I recommend we stick to the simplest layout we can get away with. I've used successfully various approaches in the past:
@erqiudao has access to all the assets needed here. The simpler the better. I'd like to see two prototypes (no need to overdo it on the design side of things) for:
More than a prototype for these two things, I'd like to see as well a series of recommendations/explanations as to why and how we build these. We'll likely standardize this across all our products.