Also, technology companies have a real problem assigning appropriate value to maintenance tasks that just keep things stable and usable. I’ve had infrastructure responsibilities over the years and the hardest thing about it was that nobody really knows or cares how much trouble you put into having things work flawlessly for months or years on end. It was important to find lots of visible tasks to go along with the invisible ones. I guess you end up with things like 40 Google chat clients and “hey let’s screw with E-mail” when there isn’t enough promotion-worthy work left to do in those areas.
So everything is at cdn.example.com and if I change providers, it's just a dns record change and everything is ready, even if I want to just host my own content.
In theory, the maximum benefit of a CDN only comes if everyone is on 1) the same version or, similar but different, 2) an evergreen version. And the latter is a big red neon sign screaming "DANGER".
It sort of/kind of started with jQuery, and in those days including jQuery was considered somewhat bloaty. I think it was about 18kB minified back then? Today their site says it's 30kB.
Either way that's miniscule compared to having a few pictures on your webpage. Having much more JS than that, honestly seems like true bloat to me, which I don't think CDNs should facilitate anyway (so much untrusted unknown unchecked code doing very, very filthy things).
My point is, it wasn't a very good argument back then either, but it became normal because people did it for other reasons, too.
The main reason people did it, was that it was just so much easier. Just copypaste those 1.5 lines of code in your <HEAD> section to include the latest version of jQuery from Google's CDN, instead of downloading it and putting it somewhere in your source tree and now you've got to keep track that different parts of your codebase written months apart don't accidentally use slightly different versions (because it's ugly, not because it mattered a lot otherwise), etc.
And if someone asked if it was really a good idea to blindly load 3rd party code and run it in the context of your own domain? Even I told people this sometimes: Well if you can't trust Google serving you secure code, then the web is basically fucked anyway, and we got much bigger problems. Which seemed like a reasonable threat model / security trade off at the time.
And now we're here.
About a week ago Google got caught hosting hostile ads that included cryptocoin miners inefficiently wasting users' electricity for a few bucks (profit insignificant compared to the cost of energy wasted). And apparently Google's offering to blindly host 3rd party JS to all users on the entire Internet everywhere (except the adblockerati), via their fucking ad network, has been expected behaviour for over a year at least and nobody gave a peep when that malfeature appeared.
I still don't know the exact date when or if there even was an announcement when they allowed advertisers "sure do whatever you like to their browsers, run some code, compute stuff, track them in all the ways we haven't dared to deploy publicly, or yet thought of, have at it, you need this, you do you".
So yeah, the web is fucked, we got bigger problems and hell no you can't trust Google any more.
A visitor can decide to not display images to improve performance and this will not break the website, blocking the (often not useful) js on the other hand...
> And if someone asked if it was really a good idea to blindly load 3rd party code and run it in the context of your own domain? Even I told people this sometimes: Well if you can't trust Google serving you secure code,
You overlooked the privacy and personal data issue here. It's a bad idea to rely on anything google because it means that you give away the privacy of your visitor to one of the worst offender no less.
> About a week ago Google got caught hosting hostile ads ...
Google has been delivering malware, spyware and that kind of things for years. It was even considered a major vector of infection (usually someone looked for flash on google and clicked on the first results which happened to be a google ad for an infected flash installer)
Good luck updating a site that used the latest and greatest build tools that are now depricated.
People focus too much on ship fast.
They get in trouble when the product becomes a success.
If you are an e-commerce site serving hundreds of images worldwide then CDNs make a tonne of sense.
If you just have a simple site or SaaS getting decent traffic, why add a failure point by including your choosen JS with a CDN. No one batts an eyelid when you add ten images to the homepage but somehow a single, much smaller JS file is too much extra load. It doesn't stand up to reason.
Anyway, I prefer my email to remain immutable after initial transmission. I don't need another Snapbookthingie...
Which reminds me, Google: You already hosed search results with your first... or second, or third, buzzzzzz... big social, dynamic (comments) push, Plus.
And almost nobody liked Buzz, nor the way you tried to shove it down our throats.
Are you really going to take another stab at sabotaging one of your successful products -- this time, Gmail?
You HAD a successful social platform: Reader. And you nuked it.
You want "social" and "changing content"? Bring back Reader.
Buy a clue.
AMP has gotten me to finally switch to Duck Duck Go. Gmail is too difficult to leave, but AMP for gmail may finally get me over the edge.
Still wish there was an rss reader as good as G. Reader.
It was probably the single best social thing I’ve ever used. It was unique as it was actually social. Both my teams at work and family/friends used it as a way to comment on news and share stuff of interest. It was also a product of an earlier era where there was excitement over anything Google released.
Google+ tried to capture many of the good parts of reader... but it was too forced.
But we can't blast you with ads via Reader. What's the point of that?
its pretty easy to parse the content of an rss/atom feed and show targeted ads.
Whenever a service or company purports to make something "engaging" and "interactive" you just know that useability and actual, tangible usefulness are going to go out the window in favour of marketer-driven choices.
We don't 'engage more' with your software/service because you changed everything to optimise for engagement and time spent, we engaged more because it took more time/steps to get the same thing done.
Arguably what we should be doing is optimising for less time spent on an app/service for the purposes of enabling a better/more efficient/more enjoyable experience by letting users get what they want to do done quickly and easily.
Was escalation as simple as "I would like to speak to a supervisor, please," or was there a more complicated incantation?
Verizon in particular is amazing in their priorities from an operational perspective are getting rid traditional phone business at all costs and spiting the CWA.
I think it's a reasonable assumption that most people here are devs or interested in software/programming/etc. Marketers aren't going to be the ones who are actually interested in making better products, they're practically premature-optimisation-in-user-hostile-directions personified, so someone else has to at least propose these ideas.
>It all comes down a simple but very dangerous shift: the major websites of today's web are not built for the visitor, but as means of using her. Our visitor has become a data point, a customer profile, a potential lead -- a proverbial fly in the spider's web. In the guise of user-centered design, we're building an increasingly user-hostile web.
I'm not 100% sure if it's a vanity metric for Google or not.
...Google does have some of the greatest statistical minds in the world, just maybe not the best product/UX minds.
KPI's can be highly misleading when it's disconnected from raw UX. It's difficult to measure user emotional experience, especially when you have a monopoly on user attention with Google Search and total product lock-in with Gmail. When users don't have alternative options analytics stats can be deceiving.
And just because a user completes X task a hundred milliseconds faster it doesn't necessarily mean the UX was better. And just because the UX was made incrementally worse doesn't mean I'm going to use Google/Gmail any less. But enough of small cuts can build up into a serious wound.
Ubiquitous banner ads, "free" 56k if you use our browser and click links, cookie bonanza, link hijacking etc... have been part of the web since day one.
No they haven't. I definitely remember the web before those were common, and it was great.
And while yes, the web was hostile back then, we also thought about it as hostile. There's been a definite shift in how the web is presented. Back then, we taught "Don't put anything personal online, it's all shady." But now, we want users to give us everything they can, and we've changed the language to allow it. "It's OK for you to give this data to us. We're Google/Facebook/Twitter/etc. There's no way we'd be irresponsible with that data"
It's not like we've come up with some new, super-secure way to store that data. The web is even more shady nowadays, but we're training users not to think about it that way.
AMP is, to begin with, Google exerting its market power to extend its control over others’ content. Facebook is doing it, so Google has to.
Google has done a lot of exciting work on open standards like JSON-LD  and Microdata  to bring a better experience to both Google search results and Gmail. I love clicking the inline "Confirm subscription" button  instead of opening emails from Mailchimp and searching for a link. I'm not that scared of the future becoming locked into Google. I believe they'll improve upon and create better standards for emails. Most things aren't entirely altruistic, and that's OK. Gmail being an early adopter to these standards is a good enough reason for them.
Maybe they’ve fixed the bizarre scrolling and overly sensitive links by now, but I see no reason to find out, because I don’t feel like I’m missing anything.
Only if that doesn't work pleasantly, then you get to complain about the browser not doing its job properly. (this remark aimed at some other replies in this subthread)
It's probably not hard at all, it's just that Google's priorities are currently at "fuck you" especially if you try to avoid being tracked.
These days, I actively avoid AMP links on Android. It's such a hideously buggy, functionality-disabling system on my phone that it's not worth loading those pages at any speed.
If I want to load a single page with dense content, view it without scrolling much, and close the tab, AMP makes my mobile experience better. If I want to do anything else, AMP on Android starts to interfere with basic functionality.
Which is a pretty sad story for a Google CDN on a Google browser on a Google OS.
As for other work on scrolling:
Person contracted to fix some webkit issues: http://frederic-wang.fr/amp-and-igalia-working-together-to-i...
HN discussion made some news about scrolling changes made due to AMP's bug reports: https://www.macrumors.com/2017/05/22/scrolling-changes-comin...
Plain HTML+CSS is hard to do?
Google has gone to an exceptional effort to make things not work like they do by default. That it's even more effort to now get basic UX back shows just how misguided the entire team is.
Quick quiz: do you release a feature that is broken for 145M users, which brokenness they might plausibly encounter multiple times a day?
In a typical organization, the answer would probably be an unambiguous “no”.
Without passing judgment, I find the fact that Google decided to ship anyway to be a useful indicator of their beliefs, culture, and priorities.
It's the same for IE and web applications that didn't work in that browser. Luckily, people (for the most part) stopped using IE. We can only hope that iOS Safari will share that fate.
That said, it’s fair to ask why Apple hasn’t placed priority on the scrolling bug, post-AMP. What the real dynamics are I can only guess; I’d love to hear from lurking AMP or WebKit engineers.
All three of these are Google not taking into account mobile browser design. None of these can really be classified as issues in Safari, rather they are consequences of the Safari design and the design choices Google made.
The first two are due to the content being embedded within an iframe.
The scrolling issue was partly because Safari implemented custom scroll behavior (supposedly due to a Steve Jobs request) for its main web view, but scrollable iframes did not override the scrolling behavior. The fix here (I believe it was rolled out in iOS 11) was to change system-wide behavior for Safari to use the system default scrolling behavior, so that everything behaved the same.
The title bar issue is due to the content not being a scroll view, but a view the size of the screen containing one or more scroll views (the iframes). Which of these should be scrolled to the top on a tap? Changing this behavior could change it for deployed sites, so rolling out any sort of new heuristic requires testing and probably wouldn't be done outside a new major version (e.g. iOS 12).
The third issue is across all browsers - Google is the one serving the content, not the third party that wrote the content. Because of this, any attempt to change where the browser 'thinks' a page is being served to another domain runs afoul of pretty fundamental web security principles. You might be able to design some sort of call (similar to CORS) to ask if google is representing your content in order to get permission to forge the address, but that would be a new web standard that hasn't been written yet.
Definitely useful, though, why isn't that a feature in HTML5?
A WebKit engineer explained the scrolling bug and how they fixed it here: https://news.ycombinator.com/item?id=14386292
> That said, it’s fair to ask why Apple hasn’t placed priority on the scrolling bug, post-AMP
Because Apple is incapable of fixing a browser bug without an OS update. You should be asking why Apple won't let you use a non-buggy browser on your phone to begin with.
So feel free to call it names and bring up feelings, but what I care about is the actual objective experience I'm getting.
> I see no reason to find out, because I don’t feel like I’m missing anything.
The person was basically saying "I don't feel like checking how good AMP is, I'm just going to blindly dismiss it"
As a developer and a content creator? I absolutely hate it. Not only is my content hosted outside of my control but they give them a visual weighting in Google search results. So now, if I want my content to have the best chance to be seen, I have to use AMP.
I wish they would have just made AMP a framework or build system that out spit out optimized web pages. Instead they force us to use their CDN which also has multiple trust issues.
Better they completely faked dns/cert in some wat and presented me copied content from their amp cache. I don’t check sources anyway.
Or are these ”engaging, interactive, and actionable email experiences.” more limited than the current web applications? If so, what are their limitations?
Also, I guess all clicks in those experiences will go through Google’s servers.
And therein lies the motivation. Why would all these Gmail users want to be clicking on web apps that aren't hosted on and monetized by Google, when they could be doing all these things inside Gmail?
That's the main thing I mind.
Really, the UI of webmail clients suck. The point of computing is automatization; there's shit ton of things that could be better integrated with each other in search, e-mail, calendaring, etc. But for that to be good, you'd have to own that integration. When a third party owns it, you become slave to that third party.
'Click here to download Thunderbird' is what my mind inserts after reading that.
They already do, when I click a link in my GMail (Android) app, and it opens in Firefox (Android), I can sometimes quickly see a Google redirection URL flit by before loading the actual page. They basically did a similar shitty trick to what they did to the Search result pages, pretending to be direct links but inserting a tracking redirect at the onbeforeunclick event or such.
Hey, btw anyone know of a nice Firefox Add-on or something that rewrites/stops the Google Search result links from redirecting at the last moment? I've been meaning to code up something like that myself, but I bet it already exists (and I'm mostly using DDG these days any way).
I agree with the article, email is email. But it points out something which is fundamentally a problem for the industry. Some software is done as in doesn't need to change any more.
That is a scary place since all those Gmail engineers need to do something so if it isn't adding new things to Gmail what will they do?
Interesting parallel in open source, Linux especially, when you have a subsystem that works well and is well understood by lots of people. Nothing to fix right? Well that would be boring. So we get things like systemd replacing the init subsystem and we get the unholy love child of netware and windows 'net' command replacing networking infrastructure management. Did they need changing? No, the previous systems did just fine. But what else is there to do?
But, people can't just do nothing and get paid. So, they will create the need. And now spend months to make it, fix it, get busy again.
This is absolutely a thing at Google IMHO. Remember the last major version of Google Maps, ran silky smooth on low end hardware, searches went where you expected, in and out no problem.
Then someone decided to try for glory and improve on perfection by re-engineering the entire thing. Now it sets the fans off in my macbook within a few seconds of appearing and they run for the duration, searches zoom out and show results 5 miles away on the other side of the major city I live in when I just want to see restaurants or coffee shops near me, constant back and forth jank from result lists to items.
Went from an app that was a complete joy to use to something I dread to interact with.
Says enough about their priorities, IMHO.
I remember one of the earliest software features that was widespread and called "intelligent" was basically the fact that a search form would remember your previous queries and present them incrementally as you were typing your new search.
That a company that prides itself on its AI efforts simply refuses to do this, again, says enough about their priorities.
It's mostly about tracking and a form of "embrace, extend, extinguish". We're at the last end of the second phase now. Make no mistake, Google has followed through on the "extinguish" part enough in the past. See: Google Reader, and what they did to Usenet and the Deja archives.
90% of the industry isn't directly about software, rather other products that are helped by having some software around, and when it is done, it is done. Time to move along to other customer.
The underlying protocols (SMTP and IMAP) are decent, but the clients aren't. It still lacks usable end-to-end encryption found in many modern messaging protocols/apps. Outright spam is mostly solved, but marketing and other notification emails I accidentally or intentionally signed up for consume way too much mental bandwidth, even with supposedly intelligent email clients (at least the ones I've tried)
That said, AMP for email doesn't solve any of those problems either.
A lot of what it does definitely needed changing — although systemd implements that change suboptimally.
Take the logind concept:
In the past, Linux screensavers were simply a fullscreen window in front of everything else. They crashed? Your system unlocked.
With logind, you have one tiny separate daemon that spawns your original X session, and the screensaver. As long as the screensaver is active, that screensaver replaces the X sessions's display.
If the screensaver crashes, it gets restarted, or, if that fails, you get in a lovely TTY font "open a tty, login as your user, and type loginctl session-unlock".
And this is secure. If something fails, your session won't accidentally unlock.
Other features include an IPC protocol that allows per-message security — user A can send messsage type 1, but user B can only send message type 2 (although, did that verification language have to be JS? T_T)
Systemd is a lot of good intentions and ideas, turned into bad code.
AMP is one good idea (faster loading speeds) turned into not just bad code, but also lock-in and proprietary anticompetitive services.
There's no black, or white, only Greys on Greys.
(if only they would auto-fold after a fixed number of children, like Reddit, I might script that for myself one day)
This is really offtopic, but you seem to confuse KDE with systemd. There is a bit of KDE that tells you to use loginctl to tell KDE's display manager to unlock the session if KDE's screensaver doesn't work properly.
Before logind, the alternative was custom handling and detection of screensavers in your session, or simply it crashing back to the session.
In your first comment you said that screensavers were just normal windows and would crash back to an unlocked screen - that never happened. Here you're conflating KDE (started ~1997) needing logind (started in what 2010?) which it didn't. Even your comment about a 'session' makes no sense since at the X runlevel X itself is the 'session'.
In my opinion a lot of the problem has been a lack of clarity of what the actual user benefit will be, and the crazy borg-like scope expanion. I'm going to avoid commenting on the implementation of logind and brethren.
I suggest you read JWZ's On Toolkits page: (archive link due to referer shenanigans): http://archive.is/BjMfp
Gräßlin wrote a bit about that in his blog.
But you might be right, I’ve not worked on either of these projects, so my knowledge is mostly from hearsay.
Edit: to be clear, it’s not about the binary used to run the screensaver, it’s about the fact that it does not need to be a question of “all or nothing” and that a solution for this particular problem could have been adopted without replacing virtually every other component of the system services simultaneously.
logind is developed by systemd, but a separate binary. In fact, every systemd project is a separate binary, just developed by the same project. Systemd is as much a monolith as KDE is.
Second, this tiny little logind binary is separate from the screensaver. It does not contain the screensaver, nor the lock screen, nor does it link to them.
This tiny process spawns the session and screensaver, and simply switches between them based on a signal. It's the tiniest possible concept for handling this task.
In general, I'd prefer if you could be more specific about your criticism, e.g. how this separate tiny binary is a "kitchen sink" and the screensaver, which is entirely separate from logind and systemd, is "part of a megalith".
So, instead of wrapping my screensaver in a small program that manages respawns on crash, you’ve arranged to force me to either have the screensaver unlock itself (since you ripped out the old simple wrapper), or have remotely exploitable network holes.
[edit: source: https://www.jwz.org/xscreensaver/versus-xlock.html ]
Also, due to systemd, the some of the ioctls you need for rootless X are needlessly declared “root only”, so to call them, you have to launder the call through some authentication daemon that has its own (not Unix) security model, and runs as root.
Finnally, I run this mess on a machine that is also an NFS client, and it frequently times out mid login / resume session, so you need to login like three times on a bad day because nfs takes a few seconds to stat something.
It was even worse with systemd aware desktop environments. There, instead of timing out quickly, it would sometimes hang for minutes, with per-user copies of what appeared to he the whole systemd stack running, and no logs anywhere.
Some relief for frogs that make it out of the pot:
I do like he idea of encrypted-at-rest, and the desktop bridge seems like a decent solution for syncing locally, but not having search on mobile seems like it would be a major drawback for my use cases.
An app I have always wished for is something that would store an offline indexed archive of my email on mobile, protected by passphrase and independent of any provider.
As an aside, what’s the deal with Redbox? I’d never heard of them and $650/a for 25GB makes it seem like their pricing matrix hasn’t been updated since the 90s. The stock photography doesn’t help with that impression.
could you explain this a bit more?
ive been routing my gmail to protonmail since i started using it but im slowly changing accounts from using gmail to protonmail as i go
They have a 5GB free-tier if you've got a custom domain. I've been a customer for years and very happy overall.
Barely no maintenance and I can add a prefix to all of my email addresses to easily blacklist anywhere that sells my email or unsubscribe links don't work for.
> In 1869, while doing experiments searching for the location of the soul, German physiologist Friedrich Goltz demonstrated that a frog that has had its brain removed will remain in slowly heated water, but an intact frog attempted to escape the water when it reached 25 °C.
Ah, the whole brain then.
Moral of the story: conservatives in Poland live in their own delusions.
Redneck Mythbusters: put the term in search engine. Youtube works well most of the time. If you can't find multiple videos or photos showing it happening, it's probably not real. If all you can find is reports like "a bloke told me", it's probably not real.
If you're not at work, try it with "fluffer". Some stories are too good to be true.
email works and doesn't need fixing. It (nearly) transports more messages every day than is countable and just works. SNR - now that needs fixing and a good start would be enforcing plain text.
Marketers want to make money, and right now stuffing emails with images in favor of proper layout is the only easy way to do it.
Of course google also wants all of your email googling its way through their servers.
There is already a Gmail placement for AdWords ok the GDN. However for the most part, if I as a marketer send emails to my customers, I can be more or less certain they will get delivered if my deliverability is high.
What I see Google doing here is gradually exerting control until they tell brands "hey, you know those messages you used to send to customers for basically free? Now you need to pay a dynamic price we control in order to get any "organic" reach."
And just like that they will have turned one of the most valuable, scalable and cost effective marketing channels into another large revenue stream for themselves that gives them even more leverage over marketers.
Kinds of genius when you think about it.
That's already happened with GMail, hasn't it? The filters for Promotion, Social, and of course Spam already control what/where users see (and it'd be trivial for Google to charge a fee here based off visibility of Promotion-categorized messages).
It's still in a linear and usually legible way, of course, and I think it's arguably user-friendly if imperfect. Doing what facebook does with feed/status updates with email would be absolutely ludicrous, it would make GMail a ghost town overnight.
I don't think introducing ads into the feed is as ludicrous as you say from a business standpoint. If done properly, I could see Google avoiding a mass exodus while simultaneously opening up more inventory for them. In some ways, I see Inbox as a test towards this vision.
My broader concern is a fundamental shift in the ownership of a customer/user relationship and the cost of reaching them. In today's world, you pay a fixed price for your ESP, and then some CPM rate for volume typically. Your costs are known, often negligible, and entirely under your control. Likewise, as long as you follow best email practices and nurture healthy relationships with those on your email lists, you have an expectation that your email will land in their inbox if they want to receive it.
That is similar to what FB had back in the day when someone Liked your brand page. If you posted, they would see it assuming they scrolled through their feed enough.
My fear is that Google will change that dynamic such that you cannot be guarantee to reach your audience (even if you have great deliverability) without entering into an auction and paying a constantly changing price that presumably will always increase as they maintain control as the new gatekeeper of that customer communication.
That is by design. Email is not an image viewer nor is it an HTML browser. It is a plain text medium.
It's an exaggerated version of the image-heavy email newsletters - these are obviously nice for the marketer, but the messages that I want to receive are not like that, they don't need this feature, it's only useful for those who want to steal my attention.
If marketers really need it, perhaps it could be a useful way to automatically forward any messages using this technology to spam.
Somehow I expect that GMail's search box will get a "usesAMP:yes" or "content:AMP" filter or something. It has a lot of filter keywords like this, undoubtedly they'll add it.
You can easily add a filter rule to automatically mark all messages matching a filter as "spam".
If enough people do that, they might get the message. (and probably just remove the search filter option, sigh)
 come to think of it, GMail's search is a delight exactly because almost still kind of works like how Google Web Search used to work back when it was still good, a mere decade ago ...
That's a feature, not a bug.
- user receives email with a link (text or image) that points to some AMP page
- user clicks on the link
- renders the AMP page in-place, replacing email content
- keep whatever "link click" behavior they currently have
This does not render interactive content in email automatically and requires a click, but that click is important because it
- signals the user's desire to interact with the content
- follows current email security expectations, e.g. does not load third party content (other than images) just by viewing the email
I direct a lot of things to email like social notifications just so everything comes to one place. I end up doing a lot of bounces off to various sites to "respond" with a Like, +1, Retweet, etc.
But like, an interactive email should be a whitelisted opt-in behavior. "Hey, I want my Twitter notifs to be interactive so I can reply and retweet without leaving my email, so let me enable the Twitter app in my email client."
As you pointed out, that violates user's expectations about what security vulnerabilities they are initiating when they open an email. Indeed, even lay users may sense that it just feels "wrong" for an email to act dynamically without anything being clicked.
Pretty much the only task I ever want to complete from inside an email is “Unsubscribe”.
I wish clients would make it easier. Gmail does has an unsubscribe button for some emails. It would be cool if it recognized emails I consistently ignore and prompt me to unsubscribe from them.
I predict whatever Google launches will work in GMail, and GMail only.
Sure, other clients have their inconsistencies, but they’re nowhere near as bad as MSO, and they actually get fixed over time. Microsoft, on the other hand, persist in using a rather buggy engine from twenty years ago, unchanged (I don’t know that there haven’t been any functional changes or bug fixes since then, but if there have been they’re minor or obscure).
For a while in the late 90s / early 2000s we had RTF e-mail.
In 11 years of self-hosting my mail I've had one deliverability problem, which was when outlook.com users stopped receiving our mail. I wrote to outlook.com, and it was resolved within 24 hours. This is possibly because my server is located in a reputable, but relatively small, datacentre, and not on the likes of AWS.
I use the zen.spamhaus.org DNS blacklist to reject connections from spammers outright, and do SPF checks. These two methods alone (no Bayesian or similar filtering) mean I get about one spam message per two days on average, which I just delete.
I estimate that I spend about half an hour a month on keeping the server up-to-date etc.
I consider the downsides extremely small in comparison to the benefits of controlling your own email setup. I encourage anyone with even basic server administration skills to try it. Email is a fantastically decentralised system and we should take advantage of that.
Web is quite usable with or without AMP as long as you use some ad blockers.
As far as I understand, on Android, Google predominantly shows AMP pages on Chrome and not on Firefox (have not used other browsers to comment on. Will be great if someone chimes in on this).
This results in a good user experience for users of Chrome on Android.
But Android Chrome was made unusable by Google in the first place by not allowing extensions. So NoScript, AdBlockPlus, Ublock Origin etc will not work. So all the junk loads and you have an awful experience.
AMP comes in and saves the day :)
On Android Firefox, no such drama. I can just install Ublock Origin and have a great browsing experience what ever the site it is. Reader Mode is a bonus. (Though I have rarely used it).
What does it all say?
So that is what AMP is for? No wonder I've never seen the use.
Email doesn't belong to a company? Nice one. It belongs to Google and Microsoft.
And this kind of change signifies three things immediately:
1. Being terrible means it's likely to happen and not really stoppable. They've already thought about how many people won't like it and still decided to go for it.
2. They try for a long time to have this more interactive messaging experience. Thinking Google Wave and Google Plus here. They have not understood that Slack/Wechat have solved that in a much more elegant way already. So they try again and again. This one will also fail to produce the vision they have. Google simply doesn't get that Web 3.0 interactivity. For us it's okay, it just means at some points other companies will take Google's place, and it will become that old, annoying giant like IBM and Microsoft before them.
3. Touching Email in this way also means that they are becoming desparate. Maybe not about profit yet, but certainly about the visionary aspects of the company. Email is one of their core components. You don't F* with those unless you really feel desperate.
It is not at all about users. It's about survival. Therefore the arguments presented in the article aren't even close to being good. A good article would figure out why they are so desparate and suggest things that they could do in favor of their users that still will increase their survivability.
Buying Slack and integrating it with their office suite might just solve their problem. It will be super expensive but might bring them onto the next level. Just a quick, stupid suggestion as example for what the article should've been about.
I'm not holding my breath for something good to come out of this, though. This could just as easily be a terribly executed product. But I'll try to be an optimist, because what we have now is outright trash.
On the other hand, if HTML is excluded then the message gets through without scope for mischief.
If you're afraid of HTML, by all means please check your email from a sandboxed VM in the terminal. But some poor chump is still going to be toiling away to make the latest Pottery Barn newsletter look great on a Blackberry, so we'd might as well build better tools.
CSS can cause problems, too. @import could cause privacy issues, as could @font-face. If images are not pre-downloaded, @media and @page could reveal when you print a message and @supports could leak details about your mail client. `position: fixed` would need to be banned outright I'd think, if the message isn't sandboxed in an iframe.
HTML5 as a whole is designed for building applications, not for making pretty messages. You want to have a subset of HTML5, but not too strict of a subset. Some APIs (e.g., @font-face) probably can't be used as-is and need a replacement. And of course, it all needs to be somehow backwards-compatible.
1. Build a product everybody hates and shove it down their throats.
2. Find an existing product people love and fuck it up or kill it.
How not to get promoted at Google (or anywhere else):
1. Build a product people hate and quietly let it die.
2. Do absolutely nothing to an existing product that works well that people love.
If they do wield a similar influence because of the market share of Gmail, hopefully somebody challenges that under antitrust or some other consumer protection basis. Email doesn't need walled gardens. That's back to the AOL days. "You've got AMP mail!"
FTFY. I cannot wait for this cancer to die off. For now, I avoid anything by Google as much I can.
I wish my email would just stay email. Let the social networks do the fancy stuff. That's what they're for. Google could always go back a retool Google Plus. Let publishers do AMP mini-sites there.
How is this bad?
I do not understand the hate?
If you do not like the product then move on.
I can see this working well on a mobile devices, not sure how it will work on other platforms, but I'm definitely open to giving it a shot.
The best part about this is if I don't like it I can always switch.
I don't want my email client to be part of such a system. If I want to follow the advice of "if you do not like the product then move on", then it's not sufficient for me to simply not use this feature in messages I send, this requires that messages I receive don't/can't use this feature.
Oh, the hate is just the new version of the ASCII ribbon against HTML email...
I wish they implemented this as a separate MIME type so emails could specify multi-part messages with text/plain, text/html and a text/amp (just for gmail).
i think that AMP is a way to make up for the fact that Chrome will be blocking ads tomorrow. Google has to do something to give publishers a way to reach people and make money otherwise publishers will begin to start charging Google in some way or take their business else where.
When you open an email, a publisher has your direct attention and being able to interact with you in a two way direction is HUGE.
The last thing Google needs to do these days is copy Facebook. Almost everything Facebook has done in the past few years has pushed users away from the platform.
Also, if Google's goal with AMP really was to "make the web faster" how exactly will integrating AMP web pages into email make email faster? Seems to me like it would make email slower...? (at least if we discount marketing spam).
Accelerated Mobile Pages (AMP) ( https://en.wikipedia.org/wiki/Accelerated_Mobile_Pages ): They are a competing technology with Facebook's Instant Articles that restricts the page from doing practically anything that isn't performance-minded up-front. That means very little loading, and all data calls are async. That means no document.write or other blocking calls that would prevent the page from loading. As culled from the wiki article and the amp project site, pages in AMP load in a second or less and consume very little data, making them optimal for mobile devices.
It would help if the anti-AMP hysteria stays to the facts.
Would it be possible to make a filter in FastMail that automatically deletes these emails? I can imagine spammers would love to send “You need an AMP client to view this email, click here”. Plus the point about privacy above.
Edit: I’d want it to send a reply, as I can imagine anyone with a Gmail account might be blocked from sending me an email. Possibly any companies on the AMP bandwagon.
This might be the push I need to get round to writing an IMAP gateway that strips HTML and only serves text/plain to my email client. I don’t need more HTML and tracking bullshit in my emails.
Well, I like email. It does exactly what I need it to do. It doesn't have the pressures of chat or phone calls, and has the versatility to do all kinds of useful things. Best of all, it can't be broken by a single company and a stupid decision.
I also like forks, but I'm usually not telling people how great forks are. That's what the article says.
I don't want this new feature and am glad I moved away from gmail, but I think the author is mistaken if they think people don't want this. Some people don't want to leave their gmail app to click one box on a now slowly loading web page full of content/ads they don't care about. I procrastinate on some mail because I don't immediately feel like dealing with the context switch. Then the mail gets buried by others and I forget. I'm ok with that mode of operation and I can also see a lot of people not being ok with and being delighted by AMP in gmail.
>> allowing “engaging, interactive, and actionable email experiences.”
I immediately think advertisements.
If AMP ends up being natively supported inside your gmail inbox, then Microsoft will have no choice to support it also, lest people jump ship from Outlook.com to gmail. Once Microsoft add AMP support to Outlook.com, then they'll turn their attention to the Outlook client, and enable AMP there too.
Once that happens, AMP-Email will be a standard, and there will be no stopping it.
For me, if that happens, I'll be turning back on the 'plain text email only' option in my mail client.
> I'll be turning back on the 'plain text email only' option
> in my mail client.
I am with you on that. I would even go one step further. I would enable this option to only show pure text content. And to autorespond to emails without pure text with a message:
"In the spirit of the web. And in the spirit of AMP power emails (Google telling you, that these are faster) I only accept pure text emails. These are the fastest ones to send, deliver and consume.
Please, in the future refrain from sending me bloated code. And if you feel the need to include images - use the age old attachment function."
That's legally risky for Google. They're not protected by an EULA if their outgoing email has hostile code and hits a non-Google customer.
(Sometimes the idiots start replying to the automated emails!)
I really wish there was a better way to bridge that gap. I usually turn on conversation view (we use Outlook), to group all of the emails via ticket, pull request, ect. But, what I really want is my email client to just tell me what changed, and use an anchor hyperlink to take me there in the ticket, pull request, ect.
I think it's worth experimenting with viewing these tickets inside of an email client, but I'm not sure if I'd like that or not.
I really dislike ads or using my CPU cycles to mine bitcoins for unrelated entities (cough cough Salon).
Am I stealing the information these entities provide for free on open Internet connections? Maybe. I don't really care though. I also benefit similarly by gut bacteria processing my food, and also don't want them taking their "fair" share of my life by ending up in places they don't belong. This particular analogy is, of course, open for expansion.
I agree with the distinction, but I believe that websites & email belong on the same side of the moat. Websites are meant to say things and applications are meant to interact with things.
Only non-standard emails won't work with POP3 or IMAP protocols. In those cases you need to use their specific program/protocols, yes. It seems Tutanota falls in this category, as does ProtonMail.