6 ms·

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

by jblow 13y ago

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.

jaffathecake 13y ago
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.
- jblow 13y ago
  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?
  - jaffathecake 13y ago
    You're scattergunning. What exactly about the 300ms tap delay removal do you disagree with?
    - jblow 13y ago
      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.
      - jblow 13y ago
        ... 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.
        untog 13y ago
        So you're objecting to the idea of non-scalable mobile web pages? Because the behaviour all stems from that.
        jaffathecake 13y ago
        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.
        KerrickStaley 13y ago
        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.
- tracker1 13y ago
  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)
  - mattmcknight 13y ago
    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.
  - robocat 13y ago
    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 https://gist.github.com/jasonbarry/6047338 as per user andrethegiant below.
stanleydrew 13y ago
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.
- jblow 13y ago
  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.
  - jaffathecake 13y ago
    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.
    - jblow 13y ago

by jblow 13y ago

jaffathecake 13y ago

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.

jblow 13y ago
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?
- jaffathecake 13y ago
  You're scattergunning. What exactly about the 300ms tap delay removal do you disagree with?
  - jblow 13y ago
    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.
    - jblow 13y ago
      ... 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.
      - untog 13y ago
        So you're objecting to the idea of non-scalable mobile web pages? Because the behaviour all stems from that.
      - jaffathecake 13y ago
        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.
      - KerrickStaley 13y ago
        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.
tracker1 13y ago
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)
- mattmcknight 13y ago
  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.
- robocat 13y ago
  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 https://gist.github.com/jasonbarry/6047338 as per user andrethegiant below.

stanleydrew 13y ago

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.

jblow 13y ago
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.
- jaffathecake 13y ago
  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.
  - jblow 13y ago