Comment by jblow | Hacker News Reader

Comment by jblow | Hacker News Reader

Parent Full thread

I agree that latency is terrible, but this is bad design that actually makes the situation worse. Now instead of a constant, learnable latency, you have latency that varies wildly depending on what page you are on.

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.

I assume they discussed removing double-tap as an action but decided it would be too disruptive. I can't say I disagree with the choice they made.

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.

The impact of variable latency is well-known among people who actually study human factors. It makes it hard for your brain to internalize interactions and make them automatic, and it increases the feeling of frustration.

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.

How much of that effect persists across games?

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.

Variable frame rates is a different issue. For example, reacting within 100ms feels instant, whereas an animation running at 10fps (one frame every 100ms) looks awful.

With interaction response, the faster the better.

Not true. I am talking specifically about interaction response, not the rate of animation display. It is about your brain learning responses to its actions so that it can better plan its actions. That cannot happen when the responses are semi-randomized.

Seriously, there are tons of studies on this. I am not making it up.

Then provide some citations, instead of vague appeals to authority?

He already did, human factors and the need for consistent performance, even if that means that the lack of speed in performance is consistently bad is in it's own way an advantage. The fact that we now have wildly inconsistent performance depending on the pages we're viewing is bad in terms of human factors. If you want precise scientific references try google but these are basic known facts.

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.

I'm not sure why you say "He already did" when I suggested providing citations. I don't see any.

Isn't this rather intuitive?

Lots of things are both intuitive and wrong.

> Why do I care if there is a "constant, learnable latency", as long as each latency is reasonable?

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 has been a behaviour for many versions of Chrome and Firefox for a while (zoomable sites vs non-zoomable) and we haven't seen confusion around this.

This is why we have the beta, to test this stuff.

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'm talking about mobile-optimized sites, but yes, I guess you could say that all mobile-versions are badly built.

Which also makes all browsers that allow a page to disable zoom badly built.

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.

Reply on news.ycombinator.com