I don't believe the problem you brought up is very important. Why do I care if there is a "constant, learnable latency", as long as each latency is reasonable? In the end I assume that the slowest response is the standard and any actions that happen faster are a pleasant surprise.
But more importantly this change doesn't preclude them from removing double-tap altogether in the future. I agree it is a half-solution now, but it's better than nothing if you are willing to grant that differing latency across pages is acceptable.
I do like the insight about stacking double-tap on top of single-tap, I'm just not sure how to apply it in the current world where single-tap means click/navigate and double-tap means zoom.
In video games specifically, where I work, it is well-known that you would rather have a game that runs slower, but with a solid frame rate, than a game that has a highly-variable frame rate that is faster on average. (This is more of a continuum situation than a discrete action like a tap, but the basic principle holds).
P.S./edit: Double-tap only means zoom because that is what they happened to implement. It is a convention easily changed. Look at how heavily Apple just revamped their entire interface, for an audience that is arguably much less savvy than the Android audience.
Using double-tap in this way was a mistake; it is an easy mistake to fix if you have enough design vision to know where you are going.
Within a given game (site), I'd prefer to have consistent frame-rate (latency). But if GTA (Gmail.com) is consistently faster than Need For Speed (NYTimes.com), that would bother me less.
With interaction response, the faster the better.
Seriously, there are tons of studies on this. I am not making it up.
Overall I'm not sure how I feel about this topic myself but I do understand jblow's point and somewhat agree with his rant.
Because people would rather have slower and more predictable than faster and less predictable. Especially when it comes to user interface actions where things get pushed down into muscle memory.
This is why we have the beta, to test this stuff.
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?
Removing the delay 100% of the time, always, would be a big win.
However, with non-zoomable pages, this isn't a new problem at all.
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.
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.
Which also makes all browsers that allow a page to disable zoom badly built.
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.
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.
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.
This is the wrong solution, in that it makes things more complicated and results in a generally poor experience even after the change. But that is what Google does all the time in UI, so I guess I have no reason to be surprised by this.
The proper solution: Do not make double-tap be a UI action. Done.
Or, if you insist on double-tap, make it only be an action that stacks transparently with single-tap. For example, in touch controls for The Witness, single-tap makes you walk toward the target. Double-tap makes you run. So as soon as we read a single tap, we can start doing the action without delay, and if we see the second tap we just kick up your target speed. It works great.
In short, hey Google, please stop doing band-aid solutions that make things worse, and hire some people who really have solid design vision, and give them the power to get things done.