[HN Gopher] Show HN: Mail Studio - IDE for designing responsive ...
___________________________________________________________________
Show HN: Mail Studio - IDE for designing responsive emails
Author : martinaglv
Score : 312 points
Date : 2021-04-01 12:26 UTC (10 hours ago)
(HTM) web link (mailstudio.app)
(TXT) w3m dump (mailstudio.app)
| williesleg wrote:
| Finally some hacker news and not political bullshit on my hacker
| news website.
| miga wrote:
| Best of the Fool's Day. Next we need IDE for designing DMCA
| notices.
| supermatt wrote:
| 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.
| sensanaty wrote:
| 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.
| hunter2_ wrote:
| Sounds like a bit like Emogrifier [0] or other "inliners" but
| media queries seem a bit suspect.
|
| [0] https://www.myintervals.com/emogrifier.php
| qwerty456127 wrote:
| 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.
| ddevault wrote:
| HTML emails are a blight on the internet. If you send me this
| crap, I will mark it as spam.
|
| https://useplaintext.email
| bitmapbrother wrote:
| We've now reached the intersection of Photoshop and Email.
| cies wrote:
| 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!
| 1123581321 wrote:
| 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.
| robertlacok wrote:
| 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.
| spicybright wrote:
| 95% is an excellent number compared with hand crafted
| templates. I'm going to look into this, thank you for the
| suggestion!
| ericcholis wrote:
| Curious, is this an in internal product?
| leetrout wrote:
| No
|
| https://mjml.io/
| bowlingx wrote:
| We use mjml as well, together with nunjucks. It's awesome :).
| No more HTML wrestling for all the different clients.
| lyptt wrote:
| MJML is insanely cool. I've just switched over to it and saved
| myself a ton of pain in creating consistent HTML emails.
| nlh wrote:
| 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 :)
| 52-6F-62 wrote:
| I haven't worked with it, but others on my team have used it to
| support high-visibility magazine newsletters, etc. Works great.
| iamacyborg wrote:
| There's also Parcel which is a dedicated email code editor.
|
| https://www.useparcel.com
| patrickserrano wrote:
| 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).
| cies wrote:
| 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.
| crixlet wrote:
| 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!
| cies wrote:
| In house developed builder in Reacts + Typescipt + JSON
| schema, we buildt is to be part of our SaaS offering to
| our clients.
| andrei_says_ wrote:
| 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.
| prepend wrote:
| 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.
| alpaca128 wrote:
| 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.
| prepend wrote:
| > 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.
| Cthulhu_ wrote:
| 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.
| incrudible wrote:
| > 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.
| ncallaway wrote:
| 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.
| incrudible wrote:
| 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.
| GordonS wrote:
| > 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.
| passivate wrote:
| 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.
| prepend wrote:
| > 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.
| GordonS wrote:
| 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.
| PaulHoule wrote:
| It works for Adobe.
| onion2k wrote:
| 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.
| nsp wrote:
| 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/
| munk-a wrote:
| 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.
| prepend wrote:
| 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.
| mschuster91 wrote:
| > 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)
| ihuman wrote:
| It free for non-commercial use, so it only costs money if the
| emails will make you money. https://mailstudio.app/pricing
| prepend wrote:
| 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.
| D13Fd wrote:
| 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.
| bdathi wrote:
| 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
| krsdcbl wrote:
| 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".
| omnimus wrote:
| 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.
| munk-a wrote:
| 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)
| bitlevel wrote:
| Consider Bitwarden as a replacement.
| jacurtis wrote:
| 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.
| pc86 wrote:
| $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.
| jacurtis wrote:
| $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.
| cosmie wrote:
| 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.
| zwaps wrote:
| I receive a lot of newsletters and communiques, 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?
| dijit wrote:
| I always assumed this was intentionally done this way so that
| people click the "display external content" warning and
| inadvertently activate the tracking pixels.
| WrathOfJay wrote:
| 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.
| GoblinSlayer wrote:
| Here we have a newsletter which is wholly one big raster
| screenshot without any fancy html and no trace of text.
| zwaps wrote:
| Heh, I get those.
|
| It comes to me as an empty bevel box and an unsubscribe link.
|
| That's what I call succinct!
| arendtio wrote:
| 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.
| hunter2_ wrote:
| 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.
| mohsen1 wrote:
| Earlier in my career I decided to go around this by rendering
| photos in HTML Tables!
|
| http://azimi.me/img2html/
| colechristensen wrote:
| People who use gmail/gsuite get html emails, the images are
| proxied by google. People using gmail are a huge chunk of the
| market.
| uberswe wrote:
| 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.
| Humdeee wrote:
| 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!).
| ncallaway wrote:
| My understanding is that is exactly why Google provides a
| proxy for that.
| tomschwiha wrote:
| 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.
| hunter2_ wrote:
| 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
| signal11 wrote:
| > 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).
| lucideer wrote:
| 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.
| zwaps wrote:
| 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.
| extra88 wrote:
| 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.
| skipnup wrote:
| In the many companies I've seen in Germany not a single
| person used outlook OWA except for when outlook had problems
| starting up..
| Aeolun wrote:
| 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.
| IceWreck wrote:
| 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.
| yoz-y wrote:
| 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.
| jerrygoyal wrote:
| trocker chrome extension is built for those who want to keep
| images and avoid pixel tracking.
| rmason wrote:
| 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...
| xbar wrote:
| I fantasize about using this for one or two of the (many) emails
| I send per day.
| selfishgene wrote:
| Best open source alternative?
| trutannus wrote:
| Isn't this just Bootstrap Studio, but with less features? The UI
| is identical.
| deadbyte wrote:
| Same company: Zine EOOD
| clarge1120 wrote:
| 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.
| cafed00d wrote:
| 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.
| smilbandit wrote:
| Any thoughts on integrations with Litmus or Emails on Acid?
| inetknght wrote:
| 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.
| andylynch wrote:
| 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 ;)
| nonameiguess wrote:
| 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.
| inetknght wrote:
| Proper formatted text in communications is fine -- include it
| as a separate attachment that's not automatically loaded and
| displayed _instead of_ plain text.
| D13Fd wrote:
| Interesting take given that they are used by millions of people
| every day.
| twobitshifter wrote:
| 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.
| cpursley wrote:
| This perspective is just as silly as turning off JavaScript in
| browsers.
| inetknght wrote:
| Funny enough... I turn off javascript in browsers.
| zwaps wrote:
| 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.
| rhines wrote:
| 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.
| zwaps wrote:
| 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.
| arendtio wrote:
| I was pleasantly surprised to see that there is a Linux version
| available :-)
| geniium wrote:
| Bring me Dreamweaver back
| ct520 wrote:
| Pingendo is that you?
| jonsully wrote:
| 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.
| saos wrote:
| 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.
| hedora wrote:
| 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.)
| bandie91 wrote:
| 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.
| megous wrote:
| 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.
| stefanvdw1 wrote:
| 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
| comeonseriously wrote:
| 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.
| blahyawnblah wrote:
| I've been using Zurb's Foundation email stuff. Works great.
| smalltalks wrote:
| 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/
| ihaveajob wrote:
| 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.
| Mooty wrote:
| Is this GrapesJS ;) ?
| AlphaGeekZulu wrote:
| 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...
| bellyfullofbac wrote:
| 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.
| sensanaty wrote:
| 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!
| iamacyborg wrote:
| Who needs flexbox when you can simply use <center>!
|
| /s
| dubcanada wrote:
| I guess that's sort of what AMP is.
| Ashanmaril wrote:
| 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.
| iamacyborg wrote:
| 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.
| koolba wrote:
| 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.
| smilbandit wrote:
| 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.
| D13Fd wrote:
| 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.
| meehow wrote:
| Outlook comes with MS Office, so it's must render HTML with
| MS Word. Super logical ;)
| vxNsr wrote:
| Yea it's bec you can send emails directly from word which I
| do all the time.
| guitarbill wrote:
| I imagine it has less to do with security, and more with
| backward-incompatible changes.
| martinaglv wrote:
| Hey! I am one of Mail Studio's authors. Will be happy to answer
| any questions.
| mobilio wrote:
| Mnogo dobre Martin!
|
| Daje si go drapnah.
|
| Imash li telefon?
| JimDabell wrote:
| 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.
| martinaglv wrote:
| 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.
| rkagerer wrote:
| 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.
| arkitaip wrote:
| 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?
| martinaglv wrote:
| 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.
| dnh44 wrote:
| 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!
| D13Fd wrote:
| 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.
| ponytech wrote:
| Why not a web app then?
| dnh44 wrote:
| This is just a guess but if it were a web app then they'd
| have to support multiple browsers.
| tgv wrote:
| 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.
| iudqnolq wrote:
| 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.
| ocdtrekkie wrote:
| Do you help users ensure your emails degrade gracefully when
| remote images aren't loaded or HTML email is disabled?
| martinaglv wrote:
| 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.
| ocdtrekkie wrote:
| 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.
| jonsully wrote:
| Also interested in this question
| howmayiannoyyou wrote:
| 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.
| mxuribe wrote:
| @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!
| martinaglv wrote:
| It will be better to reach out to our support so we can
| better evaluate the case.
| kleiba wrote:
| You have been tempted by the dark side. But it might not be too
| late to turn around and walk away.
| maydemir wrote:
| 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?
| twobitshifter wrote:
| 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.
| signal11 wrote:
| 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.)
| woodruffw wrote:
| 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.
| tootie wrote:
| You're not the average consumer probably. That or you don't
| even realize how a well-deaigned email can grab your attention.
| Nextgrid wrote:
| 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.
| tootie wrote:
| 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.
| alpaca128 wrote:
| 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?
| Cederfjard wrote:
| 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.
| munk-a wrote:
| > 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.
| angry-tempest wrote:
| 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.
| boffinism wrote:
| They did: https://www.litmus.com/blog/the-results-are-in-a-b-
| testing-h...
| adkadskhj wrote:
| 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.
| heroic wrote:
| 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.
| amitheonlyone wrote:
| 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.
| mrtksn wrote:
| 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.
| krsdcbl wrote:
| 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.
| onion2k wrote:
| 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.
| buro9 wrote:
| 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.
| andrei_says_ wrote:
| Are you aware of any studies verifying this hypothesis?
| Would be very useful in my team's roadmap.
| citrin_ru wrote:
| 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.
| andrei_says_ wrote:
| Ironically <span style="font-size: 0px;"> is a must for
| spacing tables if you want outlook compatibility.
| citrin_ru wrote:
| 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.
| aarondia wrote:
| 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.
| linsomniac wrote:
| 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.
| contravariant wrote:
| 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).
| passivate wrote:
| 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.
| contravariant wrote:
| 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
| passivate wrote:
| >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. :)
| anamexis wrote:
| I would assume that side has, in fact, established that
| proof.
| TrueDuality wrote:
| 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.
| hedora wrote:
| They certainly haven't proven its efficacy to the people
| whose resources are being consumed.
| contravariant wrote:
| 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.
| anamexis wrote:
| I'm not sure I follow - if marketers proved that plain
| text emails are more profitable, they would use plain
| text emails.
___________________________________________________________________
(page generated 2021-04-01 23:01 UTC)