I don't think "we haven't seen confusion around this" is a good answer. Most users will not even understand what is happening, they will just have an ambient level of uncomfortability with the UI that they don't know how to explain (not only due to this, but to many other factors as well, all of which contribute).

Don't tell me that your users don't have an ambient level of uncomfortability with the UI, because we all know that is the case (it is even the case on iOS, now much more than it was with iOS 6!)

If I were the UI lead for Android, I would be scouring the system from top to bottom, looking for ways to simplify and streamline, to increase predictability. All kinds of current UI actions would get thrown away (hint to Google Maps people: Shake is not an intentional UI action, it is what happens accidentally 5 times per minute when I am using your software. It should not be bound to anything, ever. [Apple is just as bad for binding shake to Undo, but at least theirs has a higher threshold now]. It is nice that at least now you can finally turn it off after it activates a few times, but haven't you noticed how everyone turns it off all the time, and nobody ever uses it for the intended action ["leave feedback"]? Get rid of it.)

Anyway, all I can say to this response: "This is why we have the beta, to test this stuff."

Is that if this attitude were actually solving all the problems that need to be solved, Android would have an amazing UI that everybody raves about. That is not the case! Why is it not the case?

You're scattergunning. What exactly about the 300ms tap delay removal do you disagree with?

I disagree with the fact that it happens inconsistently and creates a more-complicated situation for me to internalize; and even if I know the rules (which most users don't), it may not always be clear which are happening unless I engage in experimentation -- can I tell just by looking which pages are going to have delay and which aren't? Sometimes it will be obvious, but will it always? Of course not. So sometimes I have to tap before I know. And that is if I am an extremely experienced and knowledgeable user, which most people are not. For most people this will be just one more small piece of inconsistency in the pile of confusion that is Android.

Removing the delay 100% of the time, always, would be a big win.

This assumes that if we leave things as they were before, every interaction takes the same amount of time. Because of the network, and JavaScript processing beyond our control, this is not true. Not true on any mobile device.

... And what about the actual action of double-tapping? On some pages it zooms, and on some pages it does nothing, and in fact the first tap fires off a link. How is that simple, predictable, or solid-feeling? It isn't.

This is why we have the beta, we're interested in cases where the user expects double-tap to work, but it doesn't.

However, with non-zoomable pages, this isn't a new problem at all.

So you're objecting to the idea of non-scalable mobile web pages? Because the behaviour all stems from that.

I agree (a) inconsistency is bad and (b) latency is bad, but double-click-to-zoom is very useful (for operating the phone with your thumb when your other hand isn't free), and I think removing it would be bad overall.

Perhaps people will be more inclined to write mobile-optimized sites that don't need to be zoomed if they can get reduced latency as a bonus.

Double-click-to-zoom is useful, but not on mobile-optimised sites, which is why we only disabled it there. Although, if you know of a mobile-optimised site it's useful on, let us know, it'll affect how the feature lands in stable.

Yes it is useful on mobile-"optimized"-sites.

The fact that mobile sites somehow assume that zooming is bad is the exact reason for why they are useless and most people, that know what they are doing, are not browsing mobile sites at all but going to great lengths to get the full blown version that lets you get an overview and zoom in on the interesting parts instead of endless scrolling to find what you are looking for.

I've yet to experience a mobile site I prefer to the real thing, on any of my mobile devices.

Lol. "Most people that know what they're doing", don't pull up the desktop version, because they're pretty okay with mobile sites. But I guess I've no idea what I'm doing when browsing on my iPhone, and my analytics showing far better engagement with a mobile site vs desktop site on mobile just shows me a lot of people who don't "know what they're doing".

You're talking about badly built sites here. The change to Chrome discussed in the article doesn't make the situation you describe any better or worse.

I could say all mobile-versions are badly built, but I'd be wrong.

Not all mobile-optimised sites have endless scrolling. Presenting the same amount of data to mobile as you would desktop, but linearised, is bad design. Having to pan and zoom is also bad design.

Conditional loading is the ideal http://adactio.com/articles/5043/.

I do this in a minor way on my blog http://jakearchibald.com/ - the side bar doesn't appear on mobile, as it would linearise below the main content where few would see it. Instead, it becomes a navigation item at the top of the page.

Pan and zoom can be brilliant. Just brilliant.

That is to say that it usually isn't the best when paired with pages made for desktop browsers. But it is the best we've got.

Your blog is very simple, and that's great, but it hardly represents the difficulties that people have to address when creating a mobile site.

Also, having to press "Who" requires a new page to be loaded as compared to it being there in the first place (conditional loading is most definitely not ideal).

But, why is your mobile version better than the desktop version when on a phone? Honestly?

The desktop version gives me an overview, I can get a better glimpse of the topics (and you on your sidebar) and I quickly and literally dive in on the content I'm after without having to load a new page (which is expensive). And I bet that the desktop version would be just as readable and fast as your mobile version. But I can't test it out because your page does not respect the "request desktop site" option on the latest Chrome on android (4.4.2). That is really bad.

Your page is so simplistic that I would assume, only being served a mobile page, that if I didn't find what I was looking for I'd wonder if it were present on the "real" site. That is reason alone not to have a mobile version at all for a simple site. Yes, that's only a consequence of the pathetic state of affairs that is mobile web pages but it is the reality.

So, you agree that a mobile site with endless scrolling is bad. How have you imagined to solve that when your blog count increases? With pagination every 10 posts? That is bad enough on a workstation but traversing pages on a phone is a nightmare. Just give me the whole list in the desktop version and with a flip of a finger I can scroll through the content with breeze.

Disabling zoom is also not good for visually impaired users and other people who need things to be bigger sometimes.

I hate non-zoomable sites, even when "mobile friendly" sometimes the fonts on my phone are too small, even in mobile, or I'd like to zoom in on an image a bit.. I'd rather have the delay... (actually I'd rather nuke double-tap to zoom)

Chrome on Android has the Accessibility setting "force enable zoom" that can be ticked to achieve that

Mobile Safari allows the viewport settings to be changed at runtime, so you could make a JavaScript bookmarklet to achieve the same. EDIT: already done https://gist.github.com/jasonbarry/6047338 as per user andrethegiant below.

Absolutely...what do you do when a non-zoomable site is too small or too big? It's much better to have the flexibility. Double tap is less useful to me than retaining the ability to zoom any site I want to.