Show HN: Mail Studio – IDE for designing responsive emails(mailstudio.app) |
Show HN: Mail Studio – IDE for designing responsive emails(mailstudio.app) |
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.
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.)
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.
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.
Besides, guess what, many times, “engagement” is precisely what I don’t want to be coerced or manipulated into doing.
Cursing while clicking around your funneling website to find a place to do a GDPR data delete request and eventually giving up while filing your sender as spam also counts as engagement. Whereas plaintext email is way less likely to trigger that response.
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.
Our understanding for this has been that people are not very email savvy, and for them the visual imagery works more like story telling.
Did your findings that email-savvy users were insignificant account for the fact that this subset of users probably disabled any email tracking in the first place?
I'm finding that technical users are excluded by corporate interests increasingly often. I suppose this might be a good thing, but I still find the underlying attitudes towards them frustrating.
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.
I typically recommend all my friends to do the same, and many of them already do. How do you think most people react when they see a banner saying "Would you like to load remote images? [yes] [no]"?
Most emails i view these days look like garbage.
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?
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.
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.
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...
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.
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.
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.
Rendering in Outlooks changes from time to time - it is worth to check if this workaround is still required.
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.
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
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. :)
Images off by default is becoming more common.
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.
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.
In theory you could have representations of the message like video/mpeg4 and text/plain, and depending on the client capabilities and configuration, the receiver could watch a video or read plain text. The information content of the 2 (or more) don't even have to be the same! Found this out when trying to parse text out of emails into a CRM system, another system sent information in the HTML part, but an empty plaintext part.
I 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...
Works quite well!
Emails need to be clear and concise. HTML facilitates far too much hidden shit.
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.
I'm tired of companies(and users) sending emails with trackers to check if someone has read your email or not.
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.
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.
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.
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.
https://www.youtube.com/results?search_query=michael+franzes...
For me it feels like we need one and it should say e-mail must be UTF-8 Markdown.
The only suggestion I would make, would be to use/make an Applications folder. I think that's the recommended place to put AppImages. Having it's own dotfolder in my home dir is a bit... cluttering.
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.
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.)
Sounds like you want an RSS reader.
> 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.
Might be wrong, though.
Can it be integrated with systems such as SendGrid? or will it be integrated in the future?
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.
/s
I’ve seen some hilarious plaintext content. One of the best was the raw template with the {{ customerName }} place holders.
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.
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?
I wager Outlook users are less likely to have remote images enabled
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.
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.
My perfect world email markdown will probably be different from yours. For productivity, anything more than slightly stylised text is just unnecessary, but in practice, most email isn't used for productivity anymore. Instant messaging has replaced email as a means of conversation in all workspaces I know.
Good mail providers will block remote images by default, and that's a trend I'd expect to become more prevalent over time.
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.
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.
Only three engines exist that work well with JS; if we want our sites to not be dependent on behemoths like Google and Apple (Google is Mozilla's income source), we need to build sites that don't depend on their software (Blink, Webkit, and Gecko). That typically means not requiring JS.
People who block JS do so for good reason: when they open your site, they have no reason to believe that the JS being served isn't malware. If they disable and inspect it, they have no reason to believe that the scripts won't change the next time they open your page. It's safer to just leave it disabled.
They could do better on many aspects but it's nowhere near "shitty".
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.
What it can’t do sadly is strip out tracking functions (unique IDs and such). Dunno how that could even be solved tbh
What the parent is suggesting is for Gmail to download the images as soon as the server receives the email, thereby rendering any tracking data meaningless.
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.
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.
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).
> 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-...
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.
When I use Teams I have to pretty much close every other open app I have; then I use Teams; then I close Teams and go back to work. If I don’t do this my keystrokes lag by about 2 seconds.
My computer isn’t even that old, it’s from 2016.
Personally I think it would be a tragedy for macOS users if Omni went non native but I suspect we’re going to see more native software in the future not less.
If you wanted to validate it yourself instead of trusting Gmail to do it for you, you'd use the "Show original" feature which gives you the original (per its namesake) without any rewriting as well. I assume (but haven't tested) that connecting to your mailbox via IMAP, POP, etc. also causes you to retrieve the original, with the rewriting only coming into play when using the Gmail web interface.