Hacker News Reader

Comment by MBCook | Hacker News Reader

I don't know about everyone else but I HATE AMPed pages.

The idea is good, but being Google they've done.... something. I'm on iOS and the way pages scroll means they feel like they've got a different weight, they've adjusted something. And it makes interacting with the frustrating because the Google results page feels like any page in Safari and then you click into an AMP page (which does load very fast) and it suddenly feels wrong.

I bet it feels 'normal' on Android.

I have a feeling this is going to drive me nuts.

View on HN

It's not a JS scroller—it's just a scrollable div with `-webkit-overflow-scrolling: touch` which enables momentum-based scrolling. I've done hybrid (and native) iOS apps before, and this is fairly common practice to make things feel more native in webviews.

For those who are interested: by default, iOS sets webview scrollviews to have a fast deceleration rate (UIScrollViewDecelerationRateFast). This is because old iOS devices weren't able to quickly render webpages, so they needed to set a soft limit on scrolling. I actually believe that native (AMP-like) scrolling offers a better experience now that mobile devices are fairly snappy.

> I actually believe that native (AMP-like) scrolling offers a better experience now that mobile devices are fairly snappy.

Doesn't matter. Personally I disagree, but that's not the real sin. The real sin is inconsistency with the rest of the web on Safari. If Apple thinks that's the way things should work then they'll make that change. Until then having the random page behave differently feels very strange to the user.

Presumably, Apple thinks that "the way things should work" is that the webpage author has the choice. After all, they're the one who put that CSS property into Safari. They wouldn't have done that if they thought one of the options was definitively better.

> Apple thinks that "the way things should work" is that the webpage author has the choice.

No, the way Apple thinks it should work is expressed in the defaults, the options are there if the author is trying to do something else. There are cases where it may be a good idea.

I don't see how this is one. I get Google thinks they know better (and I really do wonder what they think the benefit is), and I now avoid one of their products that I actually liked quite a bit because of it.

> The real sin is inconsistency with the rest of the web on Safari

Close, but I think it's a bit more subtle than that. AMP presents its content as a standard news article (in both function and form,) which is why scrolling should be consistent with other article-like webpages. When a site is actually a webapp, I think it's permissible to have momentum-based scrolling just to achieve parity with native apps. Perhaps I'm just being pedantic, but the real issue is that AMP's scrolling isn't consistent with a subset of other websites accessible through iOS Safari.

It's even worse than that. The search results on Google scroll with one "weight", then when you tap the AMP link and all of a sudden it scrolls differently. Keep in mind that your address bar says "google.com" the entire time - this is inconsistency within the very same site.

They mangle the URL and there is no link to the actual article.

They do have a "share" link on the previous page that does not have a copy to clipboard or a send as email. (why someone would share before reading something remains an unanswered question)

So in the share interface, you can share on Twitter, which gets the url rewritten. Then you copy it from the share text and paste it on mobile in a new browser tab to get the real url, then you can copy that to the clipboard again and actually share.

Who the heck approved this crap?

I don't see the share links, but I have noticed on Google News articles with the thumbnail on the left side, clicking the thumbnail opens the original source. This doesn't seem to work (and I can't find a workaround) for the headline stories at the top though.

Share is on the initial page before you read the article. When you tap, there's a popup that has the source in green, making it look like a link, but it's not one - it's just green text. (They've disabled the long tapping context menu btw)

There's a share on google+, facebook, and twitter. facebook and google+ is a "card" without the source URL ... only the twitter share exposes a url (a shortened one).

This doesn't sound like a big intrusive ui thing. They already have an over-sensitive "swipe left" and "swipe right" so you can read another mystery story. When you swipe back because the "send me to mystery story" isn't a feature anyone asked for, amp scrolls to the top ... losing your place.

So now you have to make sure your down and up swipes are directionally perfect otherwise you go to some other story.

Mobile ad tech on news sites is the climax of insanity, but google long ago went into the deep end of the designer dictatorship - lobbing off useful features to create fragile, unpredictable, inconsistent, error-prone interfaces with, miraculously some of the core functionality removed and really useless things triggered with no way to disable them (a poorly connected aux cable triggering google now is a personal favorite).

I tried using the native share button in Safari successfully.

For the article I was on, it sent a URL like this in the message:

    https://www.google.com/amp/{original_page_url}/amp/?client=safari

The full url is [0].

For me, that successfully redirects to the non-AMP version on desktop. Though of course it's confusing to not be able to share the original page url on Facebook / Twitter / etc.

Update 1: Actually it didn't work. Safari threw an SSL related error and redirected to the Mac Rumors homepage. Not sure if it's a quirk of that link yet.

Update 2: It breaks in Chrome on OS X too:

> Your connection is not private

> Attackers might be trying to steal your information from www.macrumors.com (for example, passwords, messages, or credit cards). NET::ERR_CERT_COMMON_NAME_INVALID

I do not encounter this error visiting the original page [1] directly in either browser on OS X.

Update 3: The SSL issue may be Mac Rumors specific. A sample article from TechCrunch [2] redirects fine for me.

[0]: https://www.google.com/amp/www.macrumors.com/how-to/macos-si...

[1]: http://www.macrumors.com/how-to/macos-sierra-apple-watch-unl...

[2]: https://www.google.com/amp/s/techcrunch.com/2016/09/20/macos...

I call these "I'm so great" interfaces. When the creator thinks their thingy is so awesome that all the users will drop any other way of doing things and so they are free to generously cannibalize and dismember everything.

Google had another 'im-so-great' interface with hangouts a while back - trying to deprecate the separation of carrier sms, carrier mms, voip sms, and hangouts messages and combine them in some way where you don't know where things are coming from or where they are going ... so things hit carrier sms sometimes ... thus not being combined on all devices as before.

They took a working thing and made it broken in the name of making it work in the way they broke it.

I call things that make goals they set out to achieve less achievable a "car without wheels". The idea is that they are asking you to swap your wheeled vehicle for one without wheels that will just sit there on blocks.

---

another car without wheels, mobile reddit.

They've removed the "share a link" feature. On wikipedia reddit is described as "a social media, social news aggregation, web content rating, and discussion website".

They've removed the first 3 of those 5 goals in their mobile interface.

This is distinct from a 'no you can't' interface such as the soundcloud app and mobile site where you can't delete tracks on your profile. If you only have a phone (many people do), you'd have to "view as desktop" to delete and even then, it barely works...

I'm sure it's a single web request and a single menu item ... this isn't a huge development effort - they already have a hamburger menu for your tracks ... it could just be tacked on there. Really easy ...

I should go off and make a list of these mobile design anti-patterns.

I appreciate the effort to define a fast subset of HTML, but the AMP loader on google.com makes the whole page-loading experience different and worse in many ways. Several times today while trying to visit different sites, the AMP JS loader has broken down, displaying only the Google address bar, a fake AMP address bar below it with the intended URL, and a multicolored Android-style circle spinning endlessly (on an iPhone). All the native browser controls for page lifecycle (including timeouts and Reload button) were completely ineffective. It's important for the loader to get its replacement for these things right if it's going to try to supplant the browser's built-in functionality, and it currently doesn't succeed at that.

I've noticed it just straight up doesn't work with Purify enabled, refreshing the page with content blockers disabled has fixed it every time.

This happens to me fairly frequently in a desktop web browser after typing a search query in chrome.

Obviously not optimised for poor internet

They've had them in Google News for ages. I've been using them for a while, work great (I'm on Android). So well in fact even though I am on the 0.1% of the population that's consciously aware of their tactics, they have already trained me to subconsciously prefer clicking on websites that have their AMP logo, compared to the rest, because I subconsciously know they load much faster.

When I first saw it (in the 'News' section of results) I was happy to see it. After clicking 2 or 3 of the links I quickly learned to avoid it and either go to another site or find the non-AMP link in the results below.

I really wish sites (AMP isn't the only thing to do this) would stop deciding they know how to implement scrolling better than my browser/OS does it. Here's a hint: YOU DON'T. Let the user have what they're used to. Sudden behavior changes for tenuous-at-best benefits ("It scrolls faster!") are obnoxious.

AMP doesn't implement scrolling in software. It is native GPU accelerated scrolling. iOS does have 2 modes and it might be that AMP hits the one some people don't like.

Edit: Filed https://github.com/ampproject/amphtml/issues/5125 to see if AMP can switch to other GPU scrolling mode.

I'm with touche. Why in the world is AMP telling iOS to do scrolling different from other pages? What's the benefit? Why bother?

Everything scroll related is in CSS. The long explanation is here https://medium.com/@dvoytenko/amp-ios-scrolling-and-position...

I'm well aware of how janky position: fixed on mobile. The solution is not to use position: fixed, not to try to "fix" it and make the experience bad.

IIRC the iOS UIScrollView has a different scroll behaviour when it's inside a UIWebView. So they might have reset that difference.

Why does AMP do anything with scrolling at all?

Knowing where the viewport is relative to the document is pretty valuable; It means that AMP can defer loading potentially sluggish content until the viewport lands on a particular position.

Sounds like a premature optimization to me. The websites I tried did not have such requirements but the scrolling was just as janky nonetheless.

It's not premature optimization. It's optimization for ad revenue; they can charge more if they can prove an advertisement is visible on screen.

For surveillance and user tracking.

Even if this would be correct (which it is not), it would only require to observe, not influence scrolling.

Maybe not in version 1. Think bigger, you'll get that promotion!

This is just CSS which exists for unrelated reasons.

It would be so nice if there was a knob to disable whatever JavaScript API (or part thereof) enables this yet keep everything else.

Of course, it would have to work seamlessly without breaking anything, so it might be asking a little much.

Unfortunately, blocking that API (listening for 'wheel' events) will entirely break large portions of many sites -- any element where they've manually implemented the scrollbar or have fancy stuff or whatever won't work. I tried writing a Greasemonkey script that killed smooth scrolling, but it broke way too many sites.

One thing that does work though, at least in a lot of cases, is using an adblocker to block the URLs of common smooth scroll scripts. My adblock filter rules are in a comment in this gist if you want them (actually, this gist is my aforementioned Greasemonkey script): https://gist.github.com/oxguy3/ebd9fe692518c7f7a1e9

Wow, you've complained about scrolling in a lot of different threads on this page.

so? That just means he's right multiple times

They do not work as well on iOS. Two examples of this are "scroll to top" by tapping the title bar is completely broken under AMP. The other is that Safari Reader is mostly broken under AMP. That said, the experience with super fast, virtually instant loads, is great, and I think these are definitely kinks that can be worked out.

I'm just confused why they made it through to consumer release without someone else questioning them. These are major features of the most popular browser on [one of the two] most popular mobile OS that Google is choosing to break.

Edit: Added "[one of the two]"

> "scroll to top" by tapping the title bar is completely broken

This is because the scrolling is in a container rather than the body. It's a tough problem on many mobile pages using sliding drawers for example, which rely on overflow based scrolling. There's no event, that I'm aware of, for a web app to listen for for tapping that UI element on iOS.

Ultimately, it's a non-standard convenience introduced on iOS only. Maybe someone else here has solved this :)

I'm not sure how this is non-standard.

On iOS, there are various conventions that apps generally follow. On a list item you can swipe from right-to-left to bring up a Delete option. On a list of stuff you can tap at the top of the screen to scroll to the top. These are standard things in the iOS ecosystem.

A good parallel outside of iOS would be the pervasive use of right-click to bring up a context menu in Windows or the convention of having "--help" show help text in Linux.

Non-standard with respect to what? It's used in every Apple app, as well as tons of third party apps — Facebook, Instagram, and Gmail to name a few.

" the most popular mobile OS "

iOS at 23% and falling...

http://bgr.com/2016/06/02/apples-mobile-market-share-sees-bi...

A cursory look at those stats should tell you they're bogus. Going from 32% to 23% market share (about a 30% decline) in two months is not even remotely likely.

I just edited it to say one of the two most popular to avoid going there. I don't think it changes my point.

Doesn't it? I think it straight up answers your question.

The point I was trying to make was that iOS, and Safari on iOS, has a massive, massive user base. Throwing #1 vs #2 into the mix is distracting from that point.

As far as the scrolling goes, I'm fairly certain they're just using native scrolling (as in, not using a JS implementation that doesn't get the weighting right). The AMP Runtime needs to know scroll position, and they seem to just be capturing scroll information on the scroll event

See https://github.com/ampproject/amphtml/blob/master/src/servic...

I may be wrong on this, as I don't know enough about the codebase. However, I'm pretty sure it's just native scrolling.

> The AMP Runtime needs to know scroll position

Just querying the existing position shouldn't cause it to feel faster. What do they need to know that for anyway?

I promise you 100% that it doesn't feel right. I'm not saying they invented their own page renderer in JS and are using a canvas element for output, but they've done something that changes the feel. I've seen it on other sites too, I assume it's some JS/CSS thing.

>Just querying the existing position shouldn't cause it to feel faster. What do they need to know that for anyway?

tracking.

It's a simple CSS overflow property that Apple has included in Safari.

Do you find that it feels like the page is a lot "lighter"?

It seems like a flick of the thumb moves it a lot further than any other page. It's especially jarring since the search results page is just as "heavy" as any other page, then the AMP'd page feels like you're moving a feather.

Exactly.

I wouldn't start complaining about Google providing a good experience on Android while making users suffer on iOS.

Traditionally the Google services experience has been better on iOS than on Android. iOS had the most amazing Google Maps long before Android got that update... Even after so much time and updates, I still prefer the Google experience on iOS to the one on Android.

Is it (1) the home page news.google.com that exhibits the problem, or is it (2) the individual AMP news pages?

If #1 then the problem is completely unrelated to AMP it's just a subpar js scrolling engine that they decided to use on Google News. If #2 then that would indeed be an iOS-specific issue because on Android AMP pages are just using native scrolling to my knowledge.

I don't remember the last time I went to news.google.com, I see it on news results suggested at the top of the page after I do a normal Google search.

As I said, I wouldn't be surprised if Google was adjusting scrolling settings on iOS (using CSS or JS or something) to make it 'feel' more like Android, since that seems to be their MO recently: make everything feel like Android, not the native platform. Same way they apply material design to all their iOS apps instead of doing things the iOS way.

I hate it. All you did is make your software feel wrong and thus broken.

I know all the "It's more consistent if you switch between platforms" stuff. Switching between OS X and Windows never bothered me, and I don't use other platforms much so that benefit doesn't apply to me. I only get the downsides.

news.google.com used to work fine, but some time ago they broken scrolling on mobile firefox and it is completly unusable.

Could you link to an example page? I don't even know how to find out if a page is using AMP on iOS. Is the main AMP site AMPed? It doesn't feel any different from any other site to me.

> I bet it feels 'normal' on Android. > I have a feeling this is going to drive me nuts.

You can rely on this not being entirely accidental.

I was wondering what 'AMP' meant.

I found it great for searching breaking news events and scanning quickly through reports from different sources.

Yes this is exactly what turns me off on android too. The scrolling is different! Also, no js means no page at all. Not even text.

Reply on news.ycombinator.com