Show HN: Mail Studio – IDE for designing responsive emails | Hacker News Reader

Show HN: Mail Studio – IDE for designing responsive emails

mailstudio.app

395 pointsmartinaglv209 comments

I receive a lot of newsletters and communiqués, some of which I even signed up for.

So, I don't know what designers use to receive e-mail, but here in the non-designer / non-linux world, Outlook is pretty popular. Now, Outlook - at least all configurations I have seen, has pictures via HTML disabled. I have sampled a few IT departments only, of course, but I feel like this is probably a pretty common policy.

So let me tell you:

Your picture banners, your "rounded corner buttons", your main engagement centerpiece that's just a picture ... it all ends up being one of those nice 90's type beveled empty box we remember from surfing with IE and ISDN.

This may be a shock, but it really doesn't make your important newsletter look any better. So, if you are not specifically going for nostalgic "bad modem connection" look and feel, maybe ease off the HTML pictures a bit, okay?

People who use gmail/gsuite get html emails, the images are proxied by google. People using gmail are a huge chunk of the market.

I did not know that images get proxied. Either way, I use gmail with images turned off by default and I rarely enable images for specific senders.

Interesting. I've always thought that images within emails would also serve as a read receipt to the server that sent them when enabled or shown. Would this still apply? Google providing a proxy for this could totally pollute this data (which could be a good thing!).

My understanding is that is exactly why Google provides a proxy for that.

Last time I checked Google is proxying the external ressources right in the moment when the email is opened, so it just protects the IP address.

Someone tested [0] and the result agrees with you. And this Gmail help article [1] elaborates on the scope of protection, which is equivalent to "IP address and HTTP headers":

> Google scans images for signs of suspicious content before you receive them.

> These scans make images safer because:

> - Senders can’t use image loading to get information about your computer or location.

> - Senders can't use the image to set or read cookies in your browser.

> - Gmail checks the images for known harmful software. Sometimes, senders may know whether you've opened an email that has an image. Gmail scans every message for suspicious content. If Gmail thinks that a sender or message is suspicious, images aren’t shown and you’ll be asked if you want to see the images.".

###

Personally, I think this is quite silly, because I routinely disclose my IP address and HTTP headers without considering it particularly sensitive, but I don't want senders to know that their their email messages have been opened.

[0] https://blog.filippo.io/how-the-new-gmail-image-proxy-works-...

[1] https://support.google.com/mail/answer/145919?hl=en-GB

Wouldn't this image rewriting mess with e-mail signing?

To validate a signature, the code doing that validation needs direct access to the message prior to any rewriting. I don't think the proxy introduces any barriers to that access, assuming the validation occurs on Gmail servers, as the Gmail interface can present the results of that server-side validation.

If you wanted to validate it yourself instead of trusting Gmail to do it for you, you'd use the "Show original" feature which gives you the original (per its namesake) without any rewriting as well. I assume (but haven't tested) that connecting to your mailbox via IMAP, POP, etc. also causes you to retrieve the original, with the rewriting only coming into play when using the Gmail web interface.

Yeah most companies don't care about the IP they care that the email was opened by the target/victim and that's what happens even with proxied images.

Google proxies the requests, and makes one (and only one) upstream request. This prevents subsequent 'pings' if the user opens the email again later.

> I've always thought that images within emails would also serve as a read receipt to the server that sent them when enabled or shown

Yes, that's exactly what happens. Proxying the image only hides the user's IP address. If the images in the email load from external resources like https://example.com/fetch-resource?id=something_unique GMail has no way of knowing if something_unique uniquely identifies a user.

This is why disabling images is helpful. Of course Gmail also lets you enable images per sender, and you may find that quite acceptable for sites you have a relationship with (e.g. a shopping site which already knows your IP address and is sending you delivery notifications).

To be precise: it is not like pictures are disable, but instead 'external resources' are disabled. So if you embed the picture into the e-mail it will be shown. For small pictures that is quite reasonable.

Ding ding ding. As a sender, the upside is that virtually all GUI users will see the images without prompts or placeholders; the downside is that you don't get a read receipt. As a (GUI user) recipient, the upside is that you will see the images without prompts or placeholders while preserving your privacy; the downside is that you hit your storage quota way sooner.

Technically, embedded images are a lot like attachments, but mail clients are smart enough not to display the little has-attachment paper clip download widget because the MIME headers for the image will say "Content-disposition: inline" instead of "Content-disposition: attachment". Then the HTML img element references it using the cid: scheme instead of the https: scheme or similar. Anyway, the experience is great.

I suspect Mail Studio doesn't offer this because its MO is that "Designs are exported as standard HTML and can be imported in your email marketing platform of choice." This embedded image technique would require that Mail Studio export (or send) the entire multipart MIME message, not just the HTML part.

Here we have a newsletter which is wholly one big raster screenshot without any fancy html and no trace of text.

Heh, I get those.

It comes to me as an empty bevel box and an unsubscribe link.

That’s what I call succinct!

Earlier in my career I decided to go around this by rendering photos in HTML Tables!

http://azimi.me/img2html/

Outlook is probably the most common desktop client, but I think most people (even in corporate settings) are using webmail these days; either Google Apps Suite or Office 365. The former at least displays images by default (Google re-hosts them and rewrites the email source). Not sure if MS does the same.

Outlook for Web does have something similar now they call "Outlook service" that loads images through the service under their Privacy and data settings. I think it defaults to "Always use" and the alternative is "Don't use." It sounds like it definitely protects your home IP address from being exposed, it might not prevent a tracking pixel working as read receipt if it doesn't fetch the image until you open the message.

My messages still don't load remote images and are topped with "Some content in this message has been blocked because the sender isn't in your Safe senders list" followed by a link to add the sender's address to the trusted list and another link to show blocked content in this particular message.

I have Apple's Mail desktop and mobile apps set to not load remote content but I think the default is for them to load.

In the many companies I've seen in Germany not a single person used outlook OWA except for when outlook had problems starting up..

It probably depends on the industry.

Some of the biggest companies in Europe use Outlook the desktop client, with said external resources disabled.

May differ in technically more advanced countries, of course.

Webmail is actually better thN the desktop client, but I have to remember to keep it in the background.

A desktop client with a thin wrapper around the websinterface would be best.

Nope - https://emailclientmarketshare.com/

> Since determining the client in which an email is opened requires images to be displayed, the data for some email clients and mobile devices might be over- or under-represented due to automatic image blocking.

I wager Outlook users are less likely to have remote images enabled

I always assumed this was intentionally done this way so that people click the “display external content” warning and inadvertently activate the tracking pixels.

IIRC, that was the exact argument for disabling image loading when it was first introduced.

The responsible thing for services like gmail and o365 to do would be to eat the resource costs and just open ALL external content within a privacy sandbox, thereby polluting the data. Then you can re-enable displaying of images for everyone and the experience for designers and end users gets better.

Gmail does exactly that, I believe? It proxies the external resources to hide your IP.

What it can’t do sadly is strip out tracking functions (unique IDs and such). Dunno how that could even be solved tbh

Gmail proxies the images when you open the email.

What the parent is suggesting is for Gmail to download the images as soon as the server receives the email, thereby rendering any tracking data meaningless.

Last time I check Outlook for Windows had 4% popularity among our customers and Word as render engine. Actually everything broke what other standard mail clients could handle. We had to make a lot of idiot changes because of Outlook in the content. We still have sometimes issues but if the rendering brakes we don't treat Outlook errors as blockers anymore.

This. Plus if you pay for stuff like mobile data and receive dozens of emails a day on your phone, these high MB emails add up. Less bloat means more money saved for me at least.

This is desktop software, why is there a monthly fee?

I occasionally want to send “nice looking” emails but get asked by lots of comms people about it. Recommending a monthly fee service is a non starter, but buying some software is pretty easy to decide. “Should I pay once? Or pay forever?”

Is there anything in the functionality that takes advantage of SaaS? Other than updates and whatnot?

Of course the price/value computation is up to y’all and your customers but office365 only costs $10/month. Seems tough to value authoring email as higher value than cloud productivity suite.

It would be nice if there was a way people like me could use since our competition is an outlook template but still scale up to people who may do this all the time and be willing to pay $20+/month.

Honestly I have no problem with monthly fees for software you use every day, or frequently, for professional use. I'm fine paying monthly for things like Adobe Creative Cloud, Microsoft Office, and 1Password. Those are all desktop apps, albeit with a cloud component that I mostly don't use. I easily get my money back 10x over (likely more) based on the income I generate with the apps.

The pricing here seems targeted at media folks who do e-mail creation for a living. Assuming it works well, it's likely a bargain for them as well. But I have to imagine that market is rather small.

Adobe is shitty.

I only get lightroom in a abo which would be fine if the minimum time would be a month but it is a year.

Best if both worlds for Adobe non for the consumer

If you work with a broad range of their softwares (ps/ai/ae/premiere power user here) the subscription system is awesome. Ends up being cheaper than buying it used to be & much less upfront costs for the business.

They could do better on many aspects but it's nowhere near "shitty".

Hello Adobe marketing team.

Adobe replaced 600usd a piece software for 80usd subscription. The reason for it was because most people use like two pieces and upgraded once in 5+ years. Why? Because there are essentially no new features that have any value. Especially in print industry its basically ransom thanks to adobe's complete monopoly.

Btw it's not even monthly subscription. You can only get 1year contract that you pay of month by month. If you decide stop after two months you gotta pay rest of that 960usd. Lovely.

I would say this - 1Password has taken a real dive in quality. If the software was a single upfront cost I'd just shrug it off but the fact that my company is paying to sustain development that's actually ruined the UX for me is quite frustrating.

(Hey 1Password, don't have your "App" open as a little window in the corner of the screen for password entry that instantly closes as soon as I alt-tab anywhere. It takes too many ms for you to render a blank window with a text box to keep my focus on you so I'm going to context switch while you're loading all the libraries you need to support your text box entry form)

Consider Bitwarden as a replacement.

Like anything, this is a matter of perspective. The right team would find value in it. I used to manage a marketing team at a large e-commerce company and we spent tens of thousands a month in email design fees. We rotated through a group of freelancers to design emails. Even an email that was simply following one of our "tried-and-true" templates still would cost us $400 - $500 or so for a single email. That is just updating message content on an existing email.

So when you think about this for $20 a month. It's a no-brainer in that scenario. We already have on-staff copywriters, marketing devs, social media managers, and so on that could have taken over some of the emails using this.

I might still out-source major custom email designs for huge promotions and stuff. But we could easily handle smaller flash sale and other simple emails internally, using a tool like this. So $20 could be justified even if it saved us from outsourcing one email a month.

For the average blogger, $20 a month could still be worth it if it they have a decent email lists and are converting profit from that list.

If you are just running a personal blog and want to send out fun emails to your list of 100 people, it probably isn't worth it. But most ESPs also have WYSIWYG designers that would be "good enough". If you are somewhat-technical then a tool like MJML would probably offer even more than the above tool offers, while being free.

I don't think Microsoft365 is a fair comparison. One is a mass-market product, the other is a niche indie product. $20/mo isn't for everyone. But at $240 a year, that's less than the cost of out-sourcing a single email every year. So if you can make 1 email a month from it, then you are clearly coming out far ahead.

$500 to update the content of an email is downright robbery. Unless it's not actually "updating content" but is changing what side the images are on, tweaks layouts, adding a graph that wasn't there before, etc.

I've executed my own email programs for small projects before, and had the same reaction when I started working at an agency and saw how much we charged for that type of work.

Interestingly enough, it's actually not as padded as it seems. While the update itself may only take an hour or so of time, there's a few hours of communication/procedural overhead baked into these things:

- Receive a project brief - Align with client on the contents of the brief - Provide estimate and get sign off (potentially before the brief, if this is repeat work for an existing client) - Do actual work - Client review of work - Revisions. Usually incredibly minor nitpicking, but virtually always requested. - Final client review and acceptance

Whether the work takes 30 minutes or 30 hours, that procedural overhead is standard in BigCo marketing departments, and creates a price floor of about $500 since even the tiniest requests end up taking several hours of total effort (communication/procedural stuff + actual work). If you're engaging an agency instead of a freelancer, that floor jumps to about $1,000 as the entire process gets facilitated by an account manager + PM, so you have to add in a couple hours of their time as well for the procedural/communication overhead.

---

Not to say that's a particularly efficient process, or that it should be that way. But figured I'd share that perspective, since I initially reacted the same way you did when I saw those estimates for stuff that should have taken a trivially small amount of time to accomplish.

$500 would include a few images or something. But it definitely wasn't a crazy amount of work. Swapping out text and messaging probably came in closer to the $300 mark. We mostly were paying for expertise of email developers that we trusted.

We rotated through a team of freelancers that specialize in email development. All the freelancers we worked with did email development full-time. They didn't make websites, they didn't do SEO, they just knew email inside and out. They specialize in email, and we paid a premium to them for that expertise. This is important because you want the emails to work on all platforms. So while it might seem easy to just swap out text, it can sometimes cause layout issues (email is very finicky) and we didn't want any of those glitches negatively effecting the brand. The emails generated tens of thousands to hundreds of thousands of dollars of revenue per email on average. So no one batted an eye at $500 to make the email. You are paying for the right person to do the job, not micro-analyzing their hours.

We made a lot more money from those emails than the freelancers made by making the emails. So you also want to make them happy, because good email developers are a dying breed. They are hard to find.

I should say that part of process was testing the emails. We ran email device and litmus tests for every email that had to be done as part of the development process. So when I got the finished email from the freelancer, they always submitted a link to a full litmus test result page which showed the email presented in about 30 different device, resolution, and email client combinations. That's what was required for me to approve the email and for the freelancer to get paid.

So the freelancer wasn't just swapping text, but testing the email for us and making any fixes so it worked consistently. They would also add variables for things like %%firstname%% or whatever. We would also run "conditional emails" several times a month that were customized to a customer's location (for example New York customers got a different email than California customers) or some other segment. But conditional emails were more advanced and would run closer to the $2,000 mark. Again, conditional emails out-performed blast emails (uncustomized), so they would consistently bring in 6-figure revenues on those days from the email, so no one thought twice about the $2,000 bill from the email developer.

Because if it's a one time fee, there will be no recurring income and the developer will have to stop development.

The alternative is to do what older desktop apps did: release a new paid version / upgrade, often with a load of fluff added or a redesign to try and sell that an upgrade is worthwhile to the customers.

> Because if it's a one time fee, there will be no recurring income

That doesn't have to be true - a lot of desktop software uses a perpetual license plus optional annual maintenance. It's pretty much the standard for non-SaaS apps.

> Because if it's a one time fee, there will be no recurring income and the developer will have to stop development.

I’ve bought software for decades and reality disagrees with you.

There’s software that I’ve bought as a one time fee years ago that still releases small maintenance patches. I don’t want to run your business for you, but there’s typically multiple products and the work developing new paid major updates or other products allows for some small amount of maintenance.

A really niche product called Moneydance has done this well, I think, and I’ve used them since 2009. I think I’ve paid $50-100 once or twice but would never pay a monthly fee. It’s software that runs on my desktop.

It’s certainly possible, but some companies think they make more money with monthly subs. And they might.

Agreed, selling non-subscription desktop software in a retail segment is crazy crazy hard. Not to mention that people want everything for free these days, so even SaaS is super-hard for desktop s/w.

I used to be pretty anti-sub, but I just don't see any alternative and I do want talented devs to continue working on their passions.

> Because if it's a one time fee, there will be no recurring income and the developer will have to stop development.

Here's a crazy idea in 2020: That's totally fine. There's a point where adding more features becomes a negative ROI. That's when you know you need to move on solving a different problem. That's the alternative.

The problem in 2021 (and 2022 and 2023, etc) is that the app will break over time.

OS updates will break a small piece of functionality. Critical security vulnerabilities will be discovered that need to be patched. If the developer abandons the application because it isn't earning new revenue, the application will eventually degrade over time.

I don't have a good answer here, because I also don't like the SASS billing model for desktop software, but I recognize that a "one-time purchase" rarely actually terminates the relationship at the time of purchase. People expect ongoing bug-fixes, and security patches even for desktop software.

In my experience, Windows applications very rarely break, Mac OS apps only break with major changes, and Linux isn't worth supporting in the first place. Setting aside a little bit of money to keep the app working and patched is possible. Charging for the occasional update to make that happen is acceptable too, especially with Apple users.

You think those issues began in 2021?

It works for Adobe.

It's what Adobe does. That's not the same as saying it works for them, and it definitely isn't the same as saying it's the optimal pricing model for them. You have no way of knowing whether they'd make more or less money by moving to a different strategy. Copying what someone does without understanding how it works for them or why they did it is literally the definition of cargo cult behaviour. That's usually a bad idea.

Adobe made a very successful switch from one off payments to SaaS for their creative suite, there's a pretty clear before and after to look at. https://producthabits.com/adobe-95-billion-saas-company/

Photoshop is a legendary piece of software when it comes to things of a visual nature, so legendary that they essentially had an annual subscription to use it since there were frequent new releases that a lot of folks felt compelled to grab to keep with the curb.

I think they tend to get a little too much credit for the subscription switch since their users were already being abused in such a manner. Office to Office360 is the one that's always astounded me. Very few people upgraded office outside of getting a new machine and most businesses tried to pin all of their users to a particular version of office (it was more important that everyone used the same version rather than everyone using the latest version) and, additionally, people weren't actually used to "paying" for microsoft stuff with actual cash. Generally the software you got from MSFT was bundled into the system when you purchased it, and while your money certainly ended up in MSFT's pockets you didn't directly interact with them.

I use my pirated copy of photoshop5 (I think) from 20 years ago for my infrequent uses of photoshop. But I have friends who use photoshop every day and pay their monthly fee, and are pretty happy.

I don't get it either. I mean yes, I understand that making people pay regularly is nicer for daily users(sometimes) and the developer. But it completely cuts out the users who are willing to pay for products that go beyond "demo version" or "Spyware As A Service" but don't get paid for using it.

In many cases it would be absolutely possible to offer a middle tier that lacks some advanced features but also doesn't greet me with a "Get the Pro version now!"..."Sure you don't want to pay cloud storage for the 2 files you create per month?"

Or offer the full product for a one-year subscription but limited to one year of updates unless I pay again.

> cloud storage for the 2 files you create per month?

This is particularly frustrating because I already pay for cloud storage and don’t want another cloud store. I liked the old days when companies would layer on top of Dropbox instead of trying to sell me a “value not upsell.”

I liked the old ynab where my desktop and phone pushed files to Dropbox. When they switched to saas with their own storage they sucked so much I stopped using them.

> This is desktop software, why is there a monthly fee?

Because keeping track with the boatload of variety that email clients have and their updates is hard. You have MS Outlook in three different flavors (Windows, OS X, Android), Thunderbird on three major platforms (Windows, OS X, Linux), the various Android clients (Gmail, Samsung's custom thing they IIRC ditched for Googlemail somewhere over the last years, the custom clients by various mail providers like web.de and other), Apple Mail, iOS Mail on iPhones of various sizes and iPads of various sizes, the web clients every major provider has, I have no idea what Lotus Notes and Blackberry are offering these days... and then you have the hardcore nerds and privacy activists who have html mail turned off entirely and use commandline clients.

And literally every single client variation has a different subset of features they support or don't support, with the addition of spam filters and virus scanners randomly breaking things by injecting HTML somewhere in the message.

And then you also want your email to be forward-able without Outlook taking half a minute to think about each character.

Email is hard, cross-platform emailing is a nightmare and keeping up with all the stuff I just mentioned takes a massive amount of time to develop and to regression-test.

(In case it isn't obvious, I occasionally have to dabble in this area, and I hate it with a passion)

It free for non-commercial use, so it only costs money if the emails will make you money. https://mailstudio.app/pricing

I would use it in a commercial setting, but the emails don’t make me money. So I don’t think this license is ok for me.

Specifically, every once in a while I send out product updates to groups of people inside my org.

I agree with this - for desktop software, a perpetual license and optional annual maintenance is the expected model. Moreover, this seems to me to be a tool you'd use once to create a template, and then your content gets slotted dynamically into.

As some pricing feedback, I'd personally prefer to pay something like $75-85 as a one-time fee, with $20-30 optional maintenance to get access to the latest version and continued support - $20/month is way too high; yes, creating nice emails that work across clients is a PITA, but there are some very popular OSS templates out there that work great.

This is directly from Martin (developer of Bootstrap Studio and Mail Studio):

"You will notice that Mail Studio has a different pricing model - it is subscription based. This is necessary because the app depends on a lot of cloud features like cloud saves, sending email previews and syncing with email providers, which are not possible to provide with a one-time purchase."

I bought and paid for a lifetime license to Bootstrap Studio and I absolutely LOVE that product.

HTML in email is legacy hell. I wonder if someone wants to create a new MIME-type like text/html+css, and clients who want can implement it.

In theory you could have representations of the message like video/mpeg4 and text/plain, and depending on the client capabilities and configuration, the receiver could watch a video or read plain text. The information content of the 2 (or more) don't even have to be the same! Found this out when trying to parse text out of emails into a CRM system, another system sent information in the HTML part, but an empty plaintext part.

I guess that's sort of what AMP is.

I didn't even know that was a thing until the other day where I saw someone post on Twitter that they got an email that had basically a web storefront within the email. It was selling some product and it had a color selector and cart, the whole thing. I assume the checkout process would kick you to their actual website but it's still kinda crazy.

HTML in email is relatively uncomplicated once you understand the main limitations. The bigger challenge I find is setting the right expectation for what one can do in email, vs what certain stakeholders want to include in an email.

It boggles my mind that Microsoft hasn't updated the Outlook desktop app to use the rendering engine from Edge rather than the 10+-year-old IE engine. That would resolve so many e-mail rendering issues. I imagine it must be due to security concerns.

Outlook comes with MS Office, so it's must render HTML with MS Word. Super logical ;)

I imagine it has less to do with security, and more with backward-incompatible changes.

Yea it’s bec you can send emails directly from word which I do all the time.

If they go that route I hope they explicitly ban non-inline content.

I’ve seen some hilarious plaintext content. One of the best was the raw template with the {{ customerName }} place holders.

Emails are pretty simple once you realize you just have to stick to HTML <table>. Forget everything you know about the last 20 years of webdev improvements, like the ability to center something painlessly via flexbox, and you're good to go!

Who needs flexbox when you can simply use <center>!

Outlook on Windows is such a pain in the ass. Who ever thought using Word to render HTML emails was a good idea should be pink bellied.

The developer is super smart , it's Bootstrap Studio[0] rebranded as something new.

I remember Michael Seibel talking about YC company "launching multiple times" because you shouldn't be stopping until you find your product market fit.

This time it's seems like the right shot , but the pricing is quite high for what is it...

[0]https://bootstrapstudio.io/

I had your same intuition and went on to find out more. They also produced https://epicbootstrap.com which is probably a nice way to get some SEO juice. Good for them.

MJML deserves a mention. We use it, together with mustache, to let users create their own mailings from some building blocks we offer.

Works quite well!

Curious, is this an in internal product?

https://mjml.io/

I haven't worked with it, but others on my team have used it to support high-visibility magazine newsletters, etc. Works great.

MJML is great. We’ve developed a few hundred emails with it at this point and trained non-developers quite successfully. They use the MJML-provided editor or the Visual Studio plugin, and their visual Git tool of choice to make it easy to share components.

I love MJML. Though the output delivers on the promise only 95% of times (I had to bend it a bit because of Gmail on iPhones), the experience for me as a developer is 100x better than working with visual builders.

I was able to recreate our purchased template in like 15 minutes, now it’s much easier to edit.

95% is an excellent number compared with hand crafted templates. I'm going to look into this, thank you for the suggestion!

There's also Parcel which is a dedicated email code editor.

https://www.useparcel.com

We use mjml as well, together with nunjucks. It's awesome :). No more HTML wrestling for all the different clients.

Any chance you could share some more details around how you integrated mustache with MJML? I did a project almost 3 years ago now where we used MJML and Handlebars, but I was never happy with the end result and have been thinking about going back and taking another stab.

Did MJML add any support for templating engines as part of the rendering process? That didn't seem to be an option when I did the original process so we had a 2 pass solution (MJML -> HTML w/Handlebars -> HTML).

The solution we have is quite complex, as it also includes a builder where client can drag-drop blocks to create template (with text variables) for mailings.

Mustache is used for color/font substitutions and also for text variable (like $recipient_name) substitutions.

So: JSON representation of an email -> HTML+Mustache -> HTML+Mustache (only variables) -> HTML

For (live during email building) previews we skip the last step and show the Mustache syntax.

which builder are you using? i hav ea similar mjml + mustache setup, and am using blocksedit.com for client drag/drop. would love to see your setup!

In house developed builder in Reacts + Typescipt + JSON schema, we buildt is to be part of our SaaS offering to our clients.

I haven't seen blockedits.com before, it looks really cool. What are your thoughts on it? Is it worth taking a deeper look at or would you choose something else if you were starting from scratch?

MJML is insanely cool. I've just switched over to it and saved myself a ton of pain in creating consistent HTML emails.

Huge fan of MJML! I've been using it to send out my [shameless plug]weekly nerd-focused newsletter (see bio)[/shameless plug] and I've got a nice workflow going with it.

I'm using a workflow of Pug (nice and short syntax to save on keystrokes) -> MJML (via Pug mixins) -> HTML.

MJML has a really nice Visual Studio Code plugin that has live reload on edit, so it's all a super nice locally-hosted way to develop rich text emails.

Happy to answer any questions or share my workflow/code with anyone. Still refining it but it's a nice system and has gotten my time to build and send a newsletter down from many hours to several hours :)

would love to know about your workflow & link to the code :)

Any HTML email that arrives to my inbox is usually marked as spam and phishing.

Emails need to be clear and concise. HTML facilitates far too much hidden shit.

Interesting take given that they are used by millions of people every day.

"Free" antivirus software, Windows 10 telemetry, Javascript, WeChat, WhatsApp, Google Chrome, Gmail, Facebook, and countless other software choices are used by millions of people today; that doesn't mean that feeling uncomfortable conforming to the norm is unwarranted.

The millions of people you refer to probably (without realizing) send multipart messages with a plaintext version available. Emails without this are typically spam.

This perspective is just as silly as turning off JavaScript in browsers.

Why is turning off javascript silly?

Not that I personally disable all JS in my browser, but I'd say if your website can not be displayed without Javascript, then it is silly.

At one point I might have agreed with you, but after working on a few sites of my own I found that Javascript just enables a vastly better user experience. No need to refresh the page every time the user does something like liking a post or sending a comment, can load content more seamlessly with pre-loading or lazy loading, enables expandable menu bars to maximize space for content when the menu's not in use, things can be loaded faster and with less data usage if you send page diffs instead of full pages of markup, etc.

Javascript's terrible when it's used to generate pages from bloated frameworks that create 5000 DOM elements, add listeners to everything, load a dozen external scripts, and so on, but it's really valuable when used to actually improve the user experience.

Like you can probably guess, people tend to disable JS not because it can technically enable a good user experience.

Rather, they do so because it enables a majority of websites, and this includes big names like news websites, to create an absolutely horrible user experience - even if, or seemingly because, the content profits in no way from JS.

If you have ever tried to surf on an older laptop recently, you will get what I mean.

Everything you described can be done with progressive enhancement.

Only three engines exist that work well with JS; if we want our sites to not be dependent on behemoths like Google and Apple (Google is Mozilla's income source), we need to build sites that don't depend on their software (Blink, Webkit, and Gecko). That typically means not requiring JS.

People who block JS do so for good reason: when they open your site, they have no reason to believe that the JS being served isn't malware. If they disable and inspect it, they have no reason to believe that the scripts won't change the next time they open your page. It's safer to just leave it disabled.

Funny enough... I turn off javascript in browsers.

Elaborate please.

I have Javascript off by default and only turn it on (using NoScript extension) whenever it's actually needed.

Most pages load just fine without and with those that don't it's a 50/50 between me enabling JS for it or deciding I didn't wanna view the content anyways and closing the tab.

As someone else mentioned it's not to deprive myself of functionality, but to deprive the vultures (trackers and other shady stuff) of it.

Email clients that for whatever reason allow sending HTML email typically default to sending multipart messages with a normal plain text version as well. Emails that are HTML-only are typically marketing or unsolicited noreply junk.

I normally browse with a browser that doesn't even support JS (Lynx, NetSurf, or Dillo). Glad to know that anyone who doesn't use a browser developed by a company running on billions of dollars a year is just being "silly".

If I am compelled to use a "modern" browser, I turn off JS, cookies, remote fonts, WebGL, and any third-party resources and enable them on a case-by-case basis if the website is important enough (it usually isn't). Most sites worth visiting work much better when I do this.

As someone who lies in Excel, Outlook and too many different chat apps I think it’s far too useful to have proper formatted text in communications - Even very simple things like highlighting, tables, screenshots just don’t work or are unclear if you limit yourself to plain text.

Marketing emails can be annoying but that’s what the unsubscribe button is for ;)

Proper formatted text in communications is fine -- include it as a separate attachment that's not automatically loaded and displayed instead of plain text.

Cynically, the unsubscribe button is so phishing operations spamming every possible permutation of {<plausible name>, <separator>}@<popular_service>.com can confirm they hit a real email address and spam it out to all the various constant contact subscribers that pay them for leads.

We have asterisks for emphasis , attachments for screenshots, and bulleted lists for a subset of tables. More complex tables and formatting probably work better in an attachment; the message body should be clear, concise, and render correctly in the recipient's mail client. When the body contains complex HTML, there's a good chance it'll render incorrectly in someone else's client.

Allowing fewer features is a feature in itself: when we try to allow everything without thinking about the consequences, we end up with something like the modern Web or Electron apps.

For security plain text is best. US Federal Government Recommendation is to disable html:

“Organizations should ensure that they have disabled HTML from being used in emails, as well as disabling links. Everything should be forced to plain text. This will reduce the likelihood of potentially dangerous scripts or links being sent in the body of the email, and also will reduce the likelihood of a user just clicking something without thinking about it. With plain text, the user would have to go through the process of either typing in the link or copying and pasting. This additional step will allow the user an extra opportunity for thought and analysis before clicking on the link.”

https://theconversation.com/the-only-safe-email-is-text-only...

That said theres another post on the front page about an Apple mail zero click exploit involving attachments so even plain text can’t dodge everything.

I think this is, aside from the security concerns, why many chat applications, forums and tools like Github/Gitlab have switched to standards like Markdown for text formatting.

I can see the value in linking, embedding images, highlighting through bold and italic text, and underlining. Even code can be useful inside an email. Markdown or a similar language would serve most people very well, much better than HTML. Non-automated and fully automated emails can do with a strong simplification.

Of course, marketing companies will always prefer full HTML because it allows for making their spam more gaudy and for making their emails follow their brand, usually through terrible abuse of tables and CSS that in the end only make emails unreadable on mobile, with dark mode enabled, or massively confuse screen readers.

If emails were written and parsed as markdown, I might (!) change my opinion about it. But HTML is vastly too feature-rich to be sane. I think showing images inline (such as in Github-flavored Markdown) is still too feature-rich. But lists, tables, monospaced blocks, italic, bold ... these are fine. Embedded images aren't conducive to being parsed by a script.

Inline images are very useful for diagrams, sharing screenshots and more. I can do without the stupid company logo underneath every email, but I'd much rather have to put up with those than be unable to use them. The resources need to be small enough to embed inside the email, though, and external resources should be made aa difficult as possible (always hidden by default, per rfc, with at least two clicks before they're displayed).

My perfect world email markdown will probably be different from yours. For productivity, anything more than slightly stylised text is just unnecessary, but in practice, most email isn't used for productivity anymore. Instant messaging has replaced email as a means of conversation in all workspaces I know.

Hey! I am one of Mail Studio's authors. Will be happy to answer any questions.

Electron or React Native? Why?

Are you planning to support seamless integration with ESP so that the entire lifecycle from design to sending emails is supported?

The application is built on Electron. I think that visual editors like Mail Studio are one of the cases where this choice makes sense, since you are editing a live HTML page. You would need some a webview regardless of platform, but Electron makes the implementation easier.

At the moment, we support ESP syncing, which create/update a template on the linked platform. You can then use it as the basis of a campaign.

Why not a web app then?

This is just a guess but if it were a web app then they'd have to support multiple browsers.

But they have to support multiple mail clients anyway: macOS Mail is based on Webkit, Thunderbird on Gecko (Firefox), I guess it's Blink for many Android clients, and then there's a hundred versions of Outlook.

If you spend all your time making the output work cross-platform, I could definitely see not wanting to go on to spend a lot of time working on making the editor cross-platform. It's the same kind of tedium, but without much possibility for code-sharing.

It looks really useful and the rationale behind using Electron makes sense, but I really dislike using non-native macOS apps. Still, I suppose it's better than not being able to run it at all. Good luck with the project!

Honestly using VS Code and Teams every day has convinced me that Electron apps are a net good. It's incredibly convenient that both of those apps work essentially identically on Mac & PC, and the Mac OS apps maintain feature parity with the PC versions.

This is such a nice change, after years and years of bizarro-world Mac apps that have slowly become out-of-date, weird, or slow compared to the PC versions (ahem, Microsoft Office).

Yes, there is a ton of overhead, but this feels like the way of the (near) future for cross-platform software. I'd love to see cross-platform Electron-based versions of apps like OmniOutliner, which is an incredible program that is held back by the lack of a PC version, meaning you can't share outlines or use it professionally.

I can understand the sentiment that they’re a net good but our experiences and workflows with Teams is vastly different.

When I use Teams I have to pretty much close every other open app I have; then I use Teams; then I close Teams and go back to work. If I don’t do this my keystrokes lag by about 2 seconds.

My computer isn’t even that old, it’s from 2016.

Personally I think it would be a tragedy for macOS users if Omni went non native but I suspect we’re going to see more native software in the future not less.

I mean, I've used Teams on a few Macs and never had that problem. I wouldn't assume that applies to every user. Also, millions of people seem to be using VS Code just fine.

I don't assume that it does, but the performance issues with Electron are widely acknowledged, as is the the fact that MS seems to have done a great job with VSC despite that.

Yeah. It sounds like we can at least agree that VS code shows that with enough effort a company can make a performant cross-platform app with a consistent UI and near-perfect feature parity. It's basically cross-platform nirvana.

Do you help users ensure your emails degrade gracefully when remote images aren't loaded or HTML email is disabled?

Also interested in this question

Designs created in Mail Studio behave pretty much the same way as regular emails do if images are disabled. You should add alt text to your images and plan your design so that a missing graphic doesn't cause problems. Still, we're at version 1.0 so I imagine we can do more about this.

The app handles the HTML part of the email, while the plaintext is entered by the user when preparing their campaign. We won't be of much help there.

As a suggestion, you might consider recommending where missing alt text is, especially on call to action buttons, and perhaps providing a preview of what the email looks like with remote images disabled.

Good mail providers will block remote images by default, and that's a trend I'd expect to become more prevalent over time.

@martinaglv Sorry if this is a silly question: my day job is at a non-profit, would that be considered commercial or non-commercial use? Your tool seems very neat, so I would like to ensure compliance with your licensing/pricing. Thanks!

It will be better to reach out to our support so we can better evaluate the case.

Your features page says this:

> Email Previews

> Quickly preview your design on real devices or share it with your team by sending it as an email message.

But when I read the documentation, it seems like you just assume the user has a Litmus account. Is that correct?

Given your paid plans start at $19.99/mo, I think it would be wise to be upfront about the fact that you need a $99/mo Litmus account for this feature to work. Mail client compatibility is the most complex and difficult thing to get right with HTML email design. If you need an external service to get this right, this needs to be clearer. Right now it seems you’re selling Litmus as if it’s your own functionality then expecting your customers to then go and pay much more to Litmus to actually get that functionality.

Apologies for any confusion that this line might have caused.

> Quickly preview your design on real devices or share it with your team by sending it as an email message.

This refers to the ability to send the design you are working on as an email message. When I wrote it I didn't even consider that it might be interpreted to state that we offer device testing. We don't. You can choose to send to a real device, or Litmus, or a colleague. But we don't offer testing on real devices.

Still Mail Studio takes a lot of care to generate code that works cross-device so if you stick to visual editing (without writing custom HTML or CSS), your designs should work well everywhere even if you forgo real device testing.

When I read "Email Designer IDE", the first question that came to mind is whether it can show me renders of my email draft in all the popular clients (various versions of Outlook, web-based platforms like GMail, etc). When I found out it doesn't do that I simply stopped reading.

Words of advice. Most businesses are using in-browser email composers (eg. Mailchimp) to create content rich messages. As nice as it may be to have the additional feature set, I suspect the push back on your pricing is going to kill your project. Highly recommend you rethink your revenue model. At most I would pay $7/month for this. If you want additional recurring charges you will have to integrate with my sender(s) and fit painlessly into my weekly marketing flow. Great idea, dangerous territory from a business perspective.

Mnogo dobre Martin!

Daje si go drapnah.

Imash li telefon?

Is this the same with Bootstrap Studio and just rebranded it?

As someone who has been through the creation and maintenance of an in house email design system and builder, I’ll leave this link here: https://litmus.com/community/discussions/4990-outlook-2016-1...

It is the latest of many issues we’re facing caused by the despicable lack of consistency, especially in Microsoft’s email clients.

As for an email designing software, what my organization needed was a set of predesigned components with predefined variations - to form a somewhat flexible but disciplined email design system.

A design studio wouldn’t really work for us- the same way a website CMS should not allow complete freedom to its editors. Design decisions should be separate from content decisions.

Best of the Fool's Day. Next we need IDE for designing DMCA notices.

This looks really neat. I've spent _way_ too long on custom HTML for email signatures and email content without any tooling.. just an editor, some inline styles and a whole lot of pain. Looking forward to trying it out. No idea how y'all were able to figure out how to compile the dev-written code down to email-compliance for renderers as far back as you have, but kudos if it all works well. I could never get over how many different renderers and versions there are in the wild. Email is a TOUGH place for styling and it seems like Litmus just dominates everything else in the marketplace.

Still kinda useless, because most users still block (and should block) remote content including images by default.

I'm tired of companies(and users) sending emails with trackers to check if someone has read your email or not.

Do most users block images? I doubt it (but I have no data). I'd assume that most users use web clients, and very few if any web clients block images by default.

trocker chrome extension is built for those who want to keep images and avoid pixel tracking.

i would appreciate if they only could send meaningful plain text messages BESIDES the text/html bloat they send, not garbage. or do not add text/plain at all.

i often ancounter emails with multipart/alternative containing text/html and text/plain too but the plain part is

1) the HTML source, or

2) exists but empty, or in the best case

3) something like "see the html part", or in the worst case

4) a seemingly valid text but actually an earlier version of that in the html, or

4/b) valid text but with template variables not substituted with actual data.

3) is funny because I have preference to view text/plain if it's present, and this just breaks it for the sender

For webapps I develop I make sure text/plain part is actually nice, not just passable. It's good for me too, because I can query the emails sent by the app from a database, and just see their content, and not the convoluted bloated garbage that mjml and friends spit out.

I’ve been using Bootstrap Studio[1] for a while now from the same company and I have to say I’m very satisfied. Updates are frequent, support is responsive and it’s easy to use.

Of course tools like this aren’t necessary to work with Bootstrap or create emails, but it has saved me a lot of time which is valuable in itself.

1. https://bootstrapstudio.io

I'm watching to see if this takes off, and how the developer does. It's already at the top of HN, so that's a great start.

The developer has positioned this as a much needed solution to an age-old problem: how to make Outlook-compatible email look great. But $19 per month for a specialized HTML editor is expensive to say the least.

Noticed that the video borrows New York Columbo family capo's, Michael Franzese, theme music from his YouTube channel.

https://www.youtube.com/results?search_query=michael+franzes...

Is there even a standard for rich email?

For me it feels like we need one and it should say e-mail must be UTF-8 Markdown.

I’m not sure I’d go with the IDE angle, even if it meets the definition. Looks like you support css and html, but an IDE really makes you think of software for primarily writing code and you’re trying to appeal to non-coders. This is a wysiwyg editor like Adobe Dreamweaver. Dreamweaver is now $20.99 a month, and also supports newsletters. You have added features specific to email services, but I think a lower price might be needed.

At first I wasn't going to run a Bash script for installation, but wow, this one is nice. It's just an AppImage, and the script just adds .desktop files and such, and only for the local user.

The only suggestion I would make, would be to use/make an Applications folder. I think that's the recommended place to put AppImages. Having it's own dotfolder in my home dir is a bit... cluttering.

Its very ninche tbh. I think more needs to be done to empower marketers who don't really care about HTML.

I know the web and email and different but its just crazy how slow email is. Its still 10 years behind stuck using <table> layouts. Just insane.

Microsoft for starters should stop with actionable emails and start supportingbasic semantic HTML and CSS3 in all their clients.

100% of carefully formatted HTML email is spam. There’s no client side demand for better spam renderers.

The only reason web browsers are on the surveillance capitalism treadmill is that people are essentially forced to continually upgrade to the newest, shiniest version, since stuff like banking and shopping break otherwise.

If anything, I want my email client to support less of HTML. I already have images (and, I hope, javascript — better check) disabled. Nuking custom fonts would be nice too.

If this breaks the rendering of a message, 99% of the time, that’s a feature, not a bug.

Heck, I wish there was an open, simplified HTML news renderer where there is no JavaScript or tracking, and publishers target it directly (I pay for access to a closed app like this, but it is a walled garden.)

> Heck, I wish there was an open, simplified HTML news renderer where there is no JavaScript or tracking, and publishers target it directly

Sounds like you want an RSS reader.

Very nice, however:

> The designs that you create in Mail Studio are compatible with everything from iOS Mail to Outlook 2007

and

> If you like writing code, you will love Mail Studio’s CSS editor. You get autocomplete, support for CSS variables (custom props) and media queries.

are mutually exclusive.

Way I interpret it is that that you write down your markup/CSS, and the app spits out compliant HTML that will render properly regardless of email client.

Might be wrong, though.

Sounds like a bit like Emogrifier [0] or other "inliners" but media queries seem a bit suspect.

[0] https://www.myintervals.com/emogrifier.php

I don't mean to be harsh but that video is awful. You're moving the screencast around while I'm trying to watch what is happening on the screen. And for no reason other than to just move the screencast around.

Isn't this just Bootstrap Studio, but with less features? The UI is identical.

Same company: Zine EOOD

I've been using Zurb's Foundation email stuff. Works great.

I've been looking for something like this for a very long time.

Can it be integrated with systems such as SendGrid? or will it be integrated in the future?

I fantasize about using this for one or two of the (many) emails I send per day.

I was pleasantly surprised to see that there is a Linux version available :-)

Any thoughts on integrations with Litmus or Emails on Acid?

This looks like an exact copy of Bootstrap studio.

I wonder who the target consumer for this would be. I mean, I get that the target users are probably marketing departments / communications people across the world’s companies.

But genuinely curious who’s the end-customer who reads these emails.

Email is a strange technology that is only used for _reading words_ more than anything else — office work, receipts, itineraries, bills etc etc. Even the best newsletters, imo, tend to be word-heavy than imagery (such as Candor or Levels.fyi or Chairman Mom).

Would be cool if a Mail IDE had a way to tell if the email I’m writing is _engaging_ enough simply by the words alone. Some day perhaps.

This is just a rebranded Bootstrap Studio

Pingendo is that you?

Is this GrapesJS ;) ?

Bring me Dreamweaver back

An email user's viewpoint: pretty emails formatted like web pages (e.g., like what GOG.com sends) may provide a sense of accomplishment to the designer, and their employer a warm, fuzzy, Brand-CompliantTM feeling -- but as a user I kind of like emails that are just... messages. With hyperlinks if it's appropriate. Images aren't always a great idea -- lots of clients block them by default.

Why not have just text in paragraphs with hyperlinks? It'd force you to write good copy, sure, but also it's more likely it'll get read.

A complex layout often detracts from your message. Especially now with web-based clients implementing 'dark mode' and darkening your layouts, meaning you have less control over what the end-user sees.

(Apologies if this is off-topic. I don't mean to denigrate the work designers do, I just feel it's more appropriate on the actual web rather than in email.)

You're talking about optimization. In your opinion emails with fancy layout and "on-brand" design will get a lower level of engagement than plain text with well-written copy. You may well be right (in a lot of cases.)

But you don't know that.

It's a guess based on your biases and assumptions. This is why it's critically important to measure things when you optimize them. Believing that you should engage with your customers in a way that you like because "they're just like me, so they'll like what I like" is an easy way to kill your messaging dead. Optimization of something like email is a matter of constantly measuring, refining, and measuring again.

What I do know from measuring my marketing and transactional emails is that the least possible formatting results in the lowest probability that I end up in the spam folder.

The hypothesis I had here (unverified) is that using a tool to produce email makes your email look like spam produced by that tool (by other people). My hypothesis more specifically is that spam detection software weighs similarity in the structure equally to similarity in content.

My HTML emails have since been modified to be absolutely minimal HTML as hints to the layout and nothing else. They are more like plain text emails that have been polished with just the lightest sprinkle of HTML and CSS but nothing more.

The result of keeping things simple is that my deliverability is over 99% and the open rate also phenomenally high.

Are you aware of any studies verifying this hypothesis? Would be very useful in my team’s roadmap.

Spammers sometimes (often enough to bother) are trying to fool spam filters by adding invisible or hard to see text copied from ham messages (e. g. it allows to bypass Bayes). To counter this spamfilters are trying detect and penalize invisible text in HTML emails e. g. <span style="font-size: 0px;">....</span>, display:none, text with the same color as background, e. t. c.

Running something like headless browser (Chrome) to parse HTML emails would require too much resources so spam filters use either simple ad-hock HTML parsers or just regexps. If you use complex HTML markup, e. g. lots of nested div/span tags, different CSS styles on different levels and global <style> block on top of all, they can be confused and will detect invisible text in a message where all text is visible (when CSS/HTML is rendered in Google Chrome; who knows how it would look in different mail clients).

If you use clean and simple HTML, there will be no leftovers like <span style="font-size: 0px;"> and you will not confuse spam filters.

Ironically <span style="font-size: 0px;"> is a must for spacing tables if you want outlook compatibility.

Ironically this technique was used in phishing for MS Office 365 credentials (users of which often use MS Outlook): https://www.avanan.com/blog/zerofont-phishing-attack

Rendering in Outlooks changes from time to time - it is worth to check if this workaround is still required.

When I receive an html email, I default to thinking there is nothing of value in it, and I don't read it. I use email as a more formal text messaging, or often group text messaging, system. Marketing newsletters, etc are just a clutter. But I do get a lot of them, so maybe they work for others.

As someone who spent a very long time in a text-only mail client, on purpose, and then switched to Thunderbird and set it to the "show the text version if at all possible" mode, I'll say that I've become ambivalent about it.

Now actually appreciate being able to scan emails based on the 10,000 ft view. Sometimes, images can convey a lot in a glance, the overall graphical layout can convey a lot too.

Normally you'd think the burden of proof would be on the side requesting considerable resources and infrastructure to send something that doesn't render properly under the most basic privacy settings and cannot be displayed text-only (like in notifications).

I would assume that side has, in fact, established that proof.

They certainly haven’t proven its efficacy to the people whose resources are being consumed.

It's a common assumption, but also a dangerous assumption when the people who you assume have established the proof are the same people who stand to profit a from it being proven.

I'm not sure I follow - if marketers proved that plain text emails are more profitable, they would use plain text emails.

I'm also going to make a pretty big assumption, which is that a lot of people using mailing tools that give them stats such as MailChimp do not think about how privacy settings affect their metrics. If I have images disabled by default I will almost certainly never show up in an "opened" metric.

Images off by default is becoming more common.

Normally I would agree with this sentiment, but what kind of proof are you looking for here? We're not discussing logical absolutes or claims of absolute fact! We're discussing peoples preferences - what they like and/or expect an engaging email to look like. This area is highly subjective and contextual (culture, region, age, demo, etc). Neither your nor OPs experiences invalidate each other. Both of you can be correct at the same time.

Personally, I've seen engagement metrics increase when marketing added more "fluff" to their emails. Its no different than those obnoxious thumbnails people use on YT - it works - maybe accidentally, but it does, for now. That may change at any time in the future, just like what people like to see in emails/magazines/brochures is bound to change in the future.

Sure if you just prefer if your emails look a certain way then there's no point in discussing proof, just do the thing you like.

However if the discussion is whether you should just send plaintext emails or use a complicated and/or expensive tool to send out fancy emails then the more time/money consuming side has more to prove.

Given that the first few replies I got were essentially "Well I assume somebody checked this", I'm not sure the assumption that fancier emails are necessarily better has been questioned enough.

I'm also reminded of several articles where online marketing itself turned out to be nowhere near as effective as people think. [1,2]

[1]: https://thecorrespondent.com/100/the-new-dot-com-bubble-is-h... [2]: https://news.ycombinator.com/item?id=21465873

>However if the discussion is whether you should just send plaintext emails or use a complicated and/or expensive tool to send out fancy emails then the more time/money consuming side has more to prove.

I am curious, how many plaintext emails do you receive as a percentage? I don't receive any so maybe my opinion is colored by that fact.

>Given that the first few replies I got were essentially "Well I assume somebody checked this", I'm not sure the assumption that fancier emails are necessarily better has been questioned enough.

I'm 100% with you that conventional wisdom should attract scrutiny from time to time, and I don't mean to discourage that. My only point was that there is nothing to "prove" here. Marketing styles/trends/methods are not linked so neatly and linearly that we can test individual elements by scientific method. There are far too many variables. I think it is natural that each company wants to be able to choose the font, add graphics to make the email attractive, add tracking pixels to measure performance, etc. Its sort of become the default. So maybe the question really is what do you stand to gain by removing all that?

>I'm also reminded of several articles where online marketing itself turned out to be nowhere near as effective as people think. [1,2]

Heh, maybe marketing was never as effective as people claimed, its that now we have the tools & metrics to detect just how bad it is. :)

I hope you’re not suggesting inserting and relying on tracking pixels and other unreliable junk into outgoing emails in order to measure.

Besides, guess what, many times, “engagement” is precisely what I don’t want to be coerced or manipulated into doing.

Cursing while clicking around your funneling website to find a place to do a GDPR data delete request and eventually giving up while filing your sender as spam also counts as engagement. Whereas plaintext email is way less likely to trigger that response.

You're not the average consumer probably. That or you don't even realize how a well-deaigned email can grab your attention.

You're probably not a user of the average PC and internet connection out there. On low-tier equipment well-designed can turn very quickly into utterly frustrating.

But you are right about the last part...when the user's UI locks up for a few seconds your email is certain to grab their attention. Just not in the way your carefully designed newsletter was intended to be remembered, though.

Plain text mails work better in every possible situation and are guaranteed to be formatted in a readable way. Meanwhile your average marketing newsletter is almost guaranteed to not be displayed in the correct manner as most decent email clients will just outright block any image content by default, and if your designer had the bright idea to also embed all text in images so their carefully selected font looks nice everywhere, well, I can't see anything without manually enabling pictures and then waiting 5+ seconds to see what the email is even about. And why would I do that?

Not to be overly cynical, but are people with low-tier equipment the ones that marketers usually care about?

It’s not really about what ”works best” for the average recipient, because these emails are not sent out of the goodness of the senders’ hearts. If data show that fancy HTML emails translate into more paying customers, then that’s what drives these decisions.

It’s of course possible that this is not the case, however to be convinced of that I’d like to see the stats rather than speculation based on individual people’s subjective experience. And naturally it can depend on the product and target demographics, too.

> Not to be overly cynical, but are people with low-tier equipment the ones that marketers usually care about?

Yes - they generally are. Sure the newest SV ETL pipeline might be catered towards folks with up-to-date hardware, but most marketing is directed toward having a large reach and you'll find that the distribution of gullible people is pretty even society wide - and so those low performance having folk actually do compose a fair chunk of the intended audience.

I don't like the argument about not being the "average consumer". Just because you're smarter at detecting & filtering out marketer's bullshit doesn't make it okay to keep perpetuating the problem because others aren't.

If you deem the behavior nefarious or annoying it's not fair to justify inflicting it on someone else because they're not savvy enough to recognize/filter it.

It does though. Email marketing is all about crafting a message that gets the highest conversion rate and the rates are already pretty low. So if a blinking gif annoys most of your users, but the response rate goes from 3% to 4% it's a win for the sender.

Heh, even further than that, they're broken right out of the gate for some people - like me. I don't display any images in my emails. I don't want them using that to track my view of the content. Yea some email providers work around this, but some don't - i have it fully disabled.

Most emails i view these days look like garbage.

I'm definitely not the intended audience for these emails, but as anecdata: whenever I get a flashy HTML email, a breaker trips in my brain and I immediately switch to "hunt for the unsubscribe button" mode. It's a good thing that I can't unsubscribe from my power company's alert emails, because I would have.

Don't think transactional e-mail like "your order has been dispatched", imagine "You are invited to our annual conference", "We miss you, here is a %50 discount coupon for your next order!", "You have been accepted to our beta program" or "Unfortunately your application has been rejected" kind of e-mails.

When there's an e-mail about something special(in a sense that it's not happening all the time), I tend find it suspicious if it is not well formatted. If it's going to make me happy, better be formatted happy and if it is going to make me sad better looks like making me sad was taken seriously.

Great points but email is the easiest thing to A/B test in the world. If you were correct, somebody would have figured it out by now.

They did: https://www.litmus.com/blog/the-results-are-in-a-b-testing-h...

I believe the truth lies somewhere in the middle. Personally I very much share your purist view here, BUT i also find barely formatted plain text marketing emails highly suspicious and tend to filter them out as scam subconsciously.

Don't overload your communication, that is right. But also don't neglect your design and branding.

It's easy to think plain text is better when coming from a technical background with probably well maintained inbox, but your average customer has likely an inbox overflowing with marketing stuff already and will need visual hooks, proper presentation and coherence in appearance to decide if something is trustworthy and worth being read.

Plain text or unformatted email, in my experience, is more likely to have come from an actual person who genuinely wants to send me something. Heavily formatted emails optimized for user manipulation ("engagement") are typically sent by marketing departments who want to sell me something and can be safely discarded and added to my killfile.

I typically recommend all my friends to do the same, and many of them already do. How do you think most people react when they see a banner saying "Would you like to load remote images? [yes] [no]"?

Almost always, for such emails, you are not the audience. We've done multiple tests to check which emails perform better for our customers, and always ones with a lot more visual imagery, heavily HTMLized emails work better than just text and links.

Our understanding for this has been that people are not very email savvy, and for them the visual imagery works more like story telling.

What were the privacy implications of these tests?

Did your findings that email-savvy users were insignificant account for the fact that this subset of users probably disabled any email tracking in the first place?

I'm finding that technical users are excluded by corporate interests increasingly often. I suppose this might be a good thing, but I still find the underlying attitudes towards them frustrating.

I don't completely agree with your opinion. It's true that emails that are crowded with styled elements are not ideal. But I feel that there is a sweet spot where you have nicely formatted and designed emails that look and communicate pretty well.

It's not just web-based clients that implement dark mode, macOS Mail also does this. That's why I was a bit disappointed to see "background-color: #ffffff" in the screenshot.

Best open source alternative?

No.

On the other hand: if there is still any living person out there voluntarily displaying HTML mail as such, they probably want to suffer. So, ok.

I won't see any of it anyways. HTML-designed mails go straight to my bin...

Reply on news.ycombinator.com