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?
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.
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!).
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.
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.
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.
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.
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.
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.
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)
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.
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 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.
> 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.
> 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.
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.
> 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)
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 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.
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.
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.
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.
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.
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!
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.
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.
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...
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 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.
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 :)
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.
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.
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.
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.”
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.
"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.
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 ;)
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.
Proper formatted text in communications is fine -- include it as a separate attachment that's not automatically loaded and displayed instead of plain text.
> 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.
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.
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.
@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!
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.
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.
Readit News
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?
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.
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.
http://azimi.me/img2html/
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.
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.
A desktop client with a thin wrapper around the websinterface would be best.
It comes to me as an empty bevel box and an unsubscribe link.
That’s what I call succinct!
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.
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.
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.
(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)
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
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.
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.
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.
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.
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.
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 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)
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.
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.
Specifically, every once in a while I send out product updates to groups of people inside my org.
"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.
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.
/s
I’ve seen some hilarious plaintext content. One of the best was the raw template with the {{ customerName }} place holders.
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/
Works quite well!
I was able to recreate our purchased template in like 15 minutes, now it’s much easier to edit.
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 :)
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).
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.
https://www.useparcel.com
https://mjml.io/
Emails need to be clear and concise. HTML facilitates far too much hidden shit.
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.
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.
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.
“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 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.
The millions of people you refer to probably (without realizing) send multipart messages with a plaintext version available. Emails without this are typically spam.
Marketing emails can be annoying but that’s what the unsubscribe button is for ;)
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.
> 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.
> 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.
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.
Are you planning to support seamless integration with ESP so that the entire lifecycle from design to sending emails is supported?
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.
Daje si go drapnah.
Imash li telefon?
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.