4 ms·

There’s always been two button modes. “mouseup” is indeed the most common. However, “mousedown” is used in certain cases where the feedback is immediate, for ex

There’s always been two button modes. “mouseup” is indeed the most common. However, “mousedown” is used in certain cases where the feedback is immediate, for example in the phone app where the number shows up as soon as you tap. However, notice that the lock screen uses neither of these, but rather a strange combination of both: it registers on “mousedown”, just like the phone app, showing a new dot in the field, but then will “unregister” if you move away and lift your finger, removing the dot. As far as I can tell, this is the only place buttons work this way.

moritzwarhier 2y ago
Yes, but I feel this is totally Ok here? I think it would slow me down even more if it didn't have this behavior, because of typing in extra unintended numbers? I don't have any issues with typing my passcode in quickly, and tbh hadn't noticed the tweak with the immediate feedback on "tapdown" (and the possibility of the number disappearing). Would have to try, but I still feel I prefer the current behavior to what you suggested, and I'm pretty sure it's intentional. Anyway, thanks for bringing this up, hadn't noticed! I'll admit, for me this is good interaction design.
- tolmasky 2y ago
  Your comment implied that this was following the traditional pattern where moving away cancels an action before it takes place. I hope we at minimum agree that the Lock Screen uses a unique behavior that doesn’t exist anywhere else in the UI. I really think you’re just confusing this third interaction mode we’re describing with the traditional mouseup mode that has existed for 3 decades everywhere else. The simplest comparison point is the calculator app which behaves exactly as you described: if you put your finger down on the number 9, a 9 won’t show up until you lift up your finger. OTOH, if it worked like the Lock Screen, a 9 would show up, but would then be removed if you moved your finger away and lifted up. But again, nowhere else works this way. If you think this is good interaction design, do you thus think the calculator app has bad interaction design? That it should instead be adding numbers immediately and then retroactively removing them?
  - moritzwarhier 2y ago
    No, I didn't think of that Code entry character "preview" before in any way. Especially since it's only a dot appearing in practise. It's just that I usually attempt to enter that code quickly if I have to, so I never consciously noticed it. It seems great to me because when I enter my code slowly, I'm probably having input problems anyway (e.g. rain, thin gloves, tiredness). And in these situations, the behavior felt so natural to me that I only now notice it. I agree it may seem weird from a coherence standpoint, but the character appearing on keydown like it does just felt natural to me, just like a Win98 native button-down state. These buttons don't behave like physical push-button phone buttons. Regarding the calculator, the use case is the exact opposite, and I wasn't arguing against this regular "keypress" behavior anyway, just against the original suggested "keydown" behavior, which I'd consider a nightmare when used for tapping an on-screen keyboard. The "bastardized" version on the iOS lock screen just has suited me well for this use case, especially when talking about numeric lock codes
- Dylan16807 2y ago
  > I think it would slow me down even more if it didn't have this behavior, because of typing in extra unintended numbers? Can you explain how extra numbers would happen if it simply triggered on press? Do you often mis-press a number, then drag your finger out to cancel?

moritzwarhier 2y ago

Yes, but I feel this is totally Ok here? I think it would slow me down even more if it didn't have this behavior, because of typing in extra unintended numbers? I don't have any issues with typing my passcode in quickly, and tbh hadn't noticed the tweak with the immediate feedback on "tapdown" (and the possibility of the number disappearing). Would have to try, but I still feel I prefer the current behavior to what you suggested, and I'm pretty sure it's intentional. Anyway, thanks for bringing this up, hadn't noticed! I'll admit, for me this is good interaction design.

tolmasky 2y ago
Your comment implied that this was following the traditional pattern where moving away cancels an action before it takes place. I hope we at minimum agree that the Lock Screen uses a unique behavior that doesn’t exist anywhere else in the UI. I really think you’re just confusing this third interaction mode we’re describing with the traditional mouseup mode that has existed for 3 decades everywhere else. The simplest comparison point is the calculator app which behaves exactly as you described: if you put your finger down on the number 9, a 9 won’t show up until you lift up your finger. OTOH, if it worked like the Lock Screen, a 9 would show up, but would then be removed if you moved your finger away and lifted up. But again, nowhere else works this way. If you think this is good interaction design, do you thus think the calculator app has bad interaction design? That it should instead be adding numbers immediately and then retroactively removing them?
- moritzwarhier 2y ago
  No, I didn't think of that Code entry character "preview" before in any way. Especially since it's only a dot appearing in practise. It's just that I usually attempt to enter that code quickly if I have to, so I never consciously noticed it. It seems great to me because when I enter my code slowly, I'm probably having input problems anyway (e.g. rain, thin gloves, tiredness). And in these situations, the behavior felt so natural to me that I only now notice it. I agree it may seem weird from a coherence standpoint, but the character appearing on keydown like it does just felt natural to me, just like a Win98 native button-down state. These buttons don't behave like physical push-button phone buttons. Regarding the calculator, the use case is the exact opposite, and I wasn't arguing against this regular "keypress" behavior anyway, just against the original suggested "keydown" behavior, which I'd consider a nightmare when used for tapping an on-screen keyboard. The "bastardized" version on the iOS lock screen just has suited me well for this use case, especially when talking about numeric lock codes
Dylan16807 2y ago
> I think it would slow me down even more if it didn't have this behavior, because of typing in extra unintended numbers? Can you explain how extra numbers would happen if it simply triggered on press? Do you often mis-press a number, then drag your finger out to cancel?