Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kill Google AMP before it kills the web

theregister.co.uk

Post reply on HN
Print view View original

331–340 of 489 posts

Re: Kill Google AMP before it kills the web

#331

Post by raldi »

cramforce wrote: post #165

With respect to scrolling: We (AMP team) filed a bug with Apple about that (we didn't implement scrolling ourselves, just use a div with overflow). We asked to make the scroll inertia for that case the same as the normal scrolling. Apple's response was (surprisingly) to make the default scrolling like the overflow scrolling. So, with the next Safari release all pages will scroll like AMP pages. Hope Gruber is happy t…

Please don't "fix" the "bug" that disables the "scroll to the top of the page when the user accidentally taps the top of the screen" behavior. I loathe this behavior, have never summoned it intentionally, and can't imagine why anyone would ever want it.

Re: Kill Google AMP before it kills the web

#332

Post by kbenson »

MBCook wrote: post #258
kbenson wrote: post #252

Earlier quoted context omitted.

Well, they deployed normal HTML5, which because of how the page was defined happened to expose a weird interaction in how iOS performed some actions. They thought it was a bug in iOS and treated it as such. Getting called out as assholes for doing what they thought was the right thing (and by someone that was wrong on the facts to boot) probably rankled a bit. Calling out Gruber as both wrong and in addition so wrong…

They didn't explicitly set the behavior that way, but they deployed it knowing that WAS the behavior. And they didn't bother to change it or give anyone an option to turn it off or do something else making everyone on iOS suffer since they started pushing AMP. They could've just as easily pushed you to a new page which contain the AMP content and wasn't an iframe, thus leaving all the standard feel and gestures worki…

I don't have an iPhone, so I can't check the actual behavior to see how broken it is. Is it just not fitting the Norms of the platform, or does it really impede usage?

I think the "correct" response in a case like this, where the platform owner has a bug and has committed to a fix in the pipeline for delivery, is highly dependent on the problem. Even then, it's possible to make the wrong choice given the information available at the time.

I prefer not to call the actions of a company and a group of people arrogant without more info than present, even if one of those people expressed a less than sympathetic opinion of the problem. I extend the same courtesy to Apple often enough, it would be hypocritical of me not to.

Re: Kill Google AMP before it kills the web

#334

Post by madeofpalk »

raldi wrote: post #331
cramforce wrote: post #165

With respect to scrolling: We (AMP team) filed a bug with Apple about that (we didn't implement scrolling ourselves, just use a div with overflow). We asked to make the scroll inertia for that case the same as the normal scrolling. Apple's response was (surprisingly) to make the default scrolling like the overflow scrolling. So, with the next Safari release all pages will scroll like AMP pages. Hope Gruber is happy t…

Please don't "fix" the "bug" that disables the "scroll to the top of the page when the user accidentally taps the top of the screen" behavior. I loathe this behavior, have never summoned it intentionally, and can't imagine why anyone would ever want it.

Really? I use that all the time. How else do you get back up to the top of a long list?

Re: Kill Google AMP before it kills the web

#335

Post by emmelaich »

scott_karana wrote: post #146
ehsankia wrote: post #77

Earlier quoted context omitted.

The original content is still on the website, Google hosts a cache server, rehosting the website's content around the world closer to the users for faster access, for free. In theory, it's a win-win-win situation. Publisher gets free hosting (with analytics and ad money still coming to them obviously), users get a faster experience and Google is happier if the users browser more content. In reality, AMP is obviously…

Google has, and should, downranked slow pages in favour of fast ones. But instead of simply pushing that aspect harder, they're actively promoting their own tech.

> Google has, and should, downranked slow pages in favour of fast ones.

They do.

Re: Kill Google AMP before it kills the web

#336

Post by fenomas »

ihsw2 wrote: post #290
fenomas wrote: post #284

What kills me about AMP's UX is that not only is it a dark pattern, it's not even a new dark pattern. Back, say, 10-12 years ago it used to be really common for sites to jigger their outgoing links, such that the target site would appear in an iframe underneath a toolbar from the original site. This was widely reviled, and mostly died out, and the fact that Google is reviving it really bothers me.

How is this a dark pattern? Sites opt into it, users get a streamlined interface for content consumption, everybody wins. The only losers in this are those seeking to "curate" the user experience (UX) on their sites, and personally I lump them in with malicious ad peddlers -- to hell with them.

Sites opt in to preferential search placement. That's orthogonal to injecting a header over outgoing links being a dark UX pattern.

Re: Kill Google AMP before it kills the web

#337

Post by madeofpalk »

richdougherty wrote: post #3

In theory* I don't mind the idea of having a more standardised subset web page that has a consistent internal structure and that renders quickly. However, having Google load this structured content and host it on its own platform is a terrible idea. Content should remain on the publisher's site. Putting too much content in one place is dangerous for competition. * In practice there are implementation problems too, e.…

Right. Here's the problem and confusion with Google AMP: it's actually two seperate products.

1. There's the HTML/CSS/JS library/subset that's a good framework for building pages that load quickly

2. There's the 'CDN' that integrates with Google Search to preload and 'iFrame' the site in. Google 'has' to host/'iFrame' the content in their own google.com/amp pages because that's the only way to preload a page to make it display instantly.

Re: Kill Google AMP before it kills the web

#338

Post by JustSomeNobody »

manigandham wrote: post #90

HTML is already fast. It's the stuff that's added to the page that slows it down, and we already have plenty of standards, techniques and solutions to make sites faster. AMP is just an alternate HTML framework that prevents certain things, that's all. Not sure why everyone is so eager to opt-in to a less flexible system instead of fixing their existing web presence. All it does is increase the amount of time and reso…

Because when Google says, "We can make your page faster" management listens. But when a company's own engineers say it, management says, "Google knows better."

Re: Kill Google AMP before it kills the web

#339

Post by ihsw2 »

protomyth wrote: post #327
ihsw2 wrote: post #290

Earlier quoted context omitted.

How is this a dark pattern? Sites opt into it, users get a streamlined interface for content consumption, everybody wins. The only losers in this are those seeking to "curate" the user experience (UX) on their sites, and personally I lump them in with malicious ad peddlers -- to hell with them.

It is the same opt-in as mob protection: "nice search results you have there, be a shame if something dropped you to page 2"

The only way that would be accurate is if Google targeted content creators randomly for rent seeking, but the fact of the matter is Google has a vested interest in making sure their search results are compellingly useful to users.

Personally I'm using Google search more because AMP makes things faster for me. It's a win-win for me.

Re: Kill Google AMP before it kills the web

#340

Post by 52-6F-62 »

SL61 wrote: post #157
exergy wrote: post #70

Earlier quoted context omitted.

Duckduckgo is a lovely idea with abhorrent search results. Like, unusably bad results, at least to the extent that I'm a reasonably tech savvy user. I'm often searching for papers as a grad student, or typing things "close enough" and hoping Google figures it out for me etc. Duckduckgo cannot keep up. I love Bangs, I love the idea, but the search is nigh-useless. That said, I use StartPage, who have a contract I beli…

It has greatly improved over the years. I remember it being unusably bad when I first tried it in 2013, but today I only have to revert to Google once in a while. That being said, there are rare occasions when it fails spectacularly, bringing up totally irrelevant results for simple searches. It seems to expect more precise queries, while Google is geared toward "close enough" searches. I've found that DDG is often p…

>Google is sometimes too helpful, correcting errors that are not actually errors and failing to take some queries literally enough.

While I am still personally a huge fan of Google's work in this are and many others, sometimes I long for the days of straight boolean search queries in search engines. I could often find exactly what I'm looking for, and get the same result each time.

Are there any other major or effective engines that allow for boolean queries beyond AND/OR?

Post reply on HN