Live data from Hacker News

Kill Google AMP before it kills the web

theregister.co.uk

201–210 of 489 posts

Re: Kill Google AMP before it kills the web

#201

Earlier quoted context omitted.

> "publication independence"? Really? The man who is famous among other things for supporting the most closed ecosystem there is around: iOS, where a single company decides what apps are worth publishing and wish ones doesn't. First of all, that's an ad hominem. If publication independence is important, then it remains important whether Gruber is hypocritical about it or not. Second, one might want apps to be curated…

Pointing out a seeming contradiction in an advocate's advocacy is not an ad hominem.

But it could be an argument from fallacy. https://en.wikipedia.org/wiki/Argument_from_fallacy

Re: Kill Google AMP before it kills the web

#202
post #190

Earlier quoted context omitted.

The snark at the end seems very unwarranted.

Sorry, but there is some irony there. We were as surprised as anyone. I do like the new inertia much better. Allows for much faster scrolling similar to Android.

I don't think there's any irony here. You deployed something that worked horribly on iOS, you didn't offer a way to opt out, and when someone else put in a fix for your terrible UX that just happens to change everything else to the way your stuff currently works you use it to gloat and a guy who pointed out how terrible your UX was.

Honestly this whole thing (AMP and your comment) come off arrogant as hell to me.

I like the current iOS behavior because it's what I'm used to. I don't find the slower scrolling speed to be an issue at all. But if everything really is going to change then I will probably annoyed me for a while but I'll get used to it.

I'm not complaining that the scrolling behavior on AMP is too fast specifically (although that's how it feels to me), I'm complaining that it's DIFFERENT from everything else. All my muscle memory of how to scroll things is broken on AMP pages and only AMP pages. (I don't care if it's how iframes work, you deployed it anyway)

Once it feels like the rest of the system then it's not really much of an issue anymore. I'll get over my personal preference.

But the snark was totally unnecessary.

Re: Kill Google AMP before it kills the web

#203
post #187
post #113

Earlier quoted context omitted.

I suppose Apple could modify Safari to skip through AMP pages and go to the original source.

That requires releasing new versions of iOS. Google can work around that way faster than Apple can try to play catch-up. It's a losing battle.

It doesn't require it, except that Apple has failed to decouple Safari from iOS, and so it can't be updated like regular apps.

Re: Kill Google AMP before it kills the web

#205

Earlier quoted context omitted.

> "publication independence"? Really? The man who is famous among other things for supporting the most closed ecosystem there is around: iOS, where a single company decides what apps are worth publishing and wish ones doesn't. First of all, that's an ad hominem. If publication independence is important, then it remains important whether Gruber is hypocritical about it or not. Second, one might want apps to be curated…

Pointing out a seeming contradiction in an advocate's advocacy is not an ad hominem.

You're correct, technically. It's "tu quoque", which is arguably a more forgivable fallacy.

Re: Kill Google AMP before it kills the web

#206

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.…

Google using their search monopoly to create a distribution monopoly is also extremely worrying.

Nah man, it's all good. I mean sure, we keep giving absurd amounts of power to an ad company but it's google, who doesn't love google.

If it was microsoft they already would have shut this down because of the backlash. Google does it and people are fine with it.

Re: Kill Google AMP before it kills the web

#207
post #202

Earlier quoted context omitted.

Sorry, but there is some irony there. We were as surprised as anyone. I do like the new inertia much better. Allows for much faster scrolling similar to Android.

I don't think there's any irony here. You deployed something that worked horribly on iOS, you didn't offer a way to opt out, and when someone else put in a fix for your terrible UX that just happens to change everything else to the way your stuff currently works you use it to gloat and a guy who pointed out how terrible your UX was. Honestly this whole thing (AMP and your comment) come off arrogant as hell to me. I l…

It's hardly AMP's fault that safari scrolling is inconsistent. Any complaints about that should be aimed at safari, not AMP.

Re: Kill Google AMP before it kills the web

#208
I suspect whoever made that executive decision at Google to use "AMP" was too young to remember Frontpage and so many years fighting with MSIE. How soon we forget. AMP is bad news. Keep your hands off my design. It's not your Internet, Google. PS: I'm on Linux, not an Apple fanboy :-D

Re: Kill Google AMP before it kills the web

#209
post #96

The complaint about AMP's strange UX paradigms is valid: it works very hard to pretend like every AMP article is a standalone website, but it actually behaves like a viewport-wrapping iframe, where Google Search is on the outside and the article is on the inside [1]. But it's not a personal affront to iOS; it's more of an artifact of Google's confusing market strategy and conflicting requirements for AMP's deployment…

Is Apple news more than a feed spec like RSS / is the content hosted by Apple directly, like how AMP pages actually live on google.com?

AMP pages don't intrinsically live on google.com. Rather, when you use Google Search on mobile, some results may have AMP equivalents, they're often prioritized on or closer to the top [1] or otherwise highlighted (like in a carousel). As of writing, these results are marked with the lightningbolt-in-circle logo and the text 'AMP' somewhere in the result's most immediate box [2].

Clicking on one of these AMP results in Google Search will lead to a Google-hosted page with the base URL of "google.com/amp/", which loads an iframe (or equivalent) of the AMP article content. This whole thing takes up the entire viewport, save for a small grey horizontal bar up top, which collapses (hides) with JS if you scroll down far enough, but is otherwise pinned to the top, staying adjacent to the browser chrome.

This AMP navbar, as of time of writing, has the original publisher's domain name in the middle (which isn't a link, just informational text); then on the right side is a link ("chain-link") icon which will produce a small overlay containing the article's original (non-AMP, non-google.com/amp/ link), and a vertical triple-dot button with a link to 'More info'. This 'More info' link takes you to a Google Search Help article [3] (along with a really, really long visit_id as a tracking parameter), which talks about AMP and the Google AMP Cache, says that "The Viewer is a hybrid environment where Google and the third-party webmaster may each collect data about you", links to a few FAQs and the Google privacy policy, and the like. In the past, the navbar was different [4], and its deficiencies where a frequent source of criticism.

In short, Google Search on Mobile serves AMP results out of Google's own AMP Cache in a not-completely-obvious in-place wrapping viewer that tracks your visits, but it's now possible to get original URL [4]. Meanwhile, Cloudflare, currently the only other operator of an AMP cache, offers auto-AMP links [5] for customer domains, and offers an SDK to customize the wrapper-viewer [6] that will surround the articles surfaced for that domain.

Apple News is a client application that combines a feed-reader with articles delivered from Apple News' servers; these latter types of articles are always hosted by Apple [7], and in the beginning the only way to publish to it was to use Apple's APIs to post to Apple News directly [8][9]. Now there's integrations that will consume content out of your CMS and post it to Apple News on your behalf, which makes it easier to use, but doesn't change the fact that the the content is published into Apple's ecosystem.

[1] https://www.wired.com/2016/02/google-will-now-favor-pages-us... [2] http://imgur.com/a/rggVe [3] https://support.google.com/websearch/answer/7220196 [4] https://news.ycombinator.com/item?id=13582844 [5] https://www.cloudflare.com/website-optimization/accelerated-... [6] https://www.cloudflare.com/website-optimization/amp-viewer-s... [7] https://www.wired.com/2015/06/apple-builds-content-business-... [8] https://help.apple.com/newspublisher/icloud/#/ [9] https://developer.apple.com/library/content/documentation/Ge...

Re: Kill Google AMP before it kills the web

#210
post #113
post #92

Earlier quoted context omitted.

Then Apple should make their own search engine...

I suppose Apple could modify Safari to skip through AMP pages and go to the original source.

I think encrypted.google.com doesn't use AMP yet, so they could make that the default search
Post reply on HN