[kevindamm]

Now remove the spacebar, combine the two buttons into a single one for "tone" and adapt it to morse code. All the buttons still do only one thing and now there's only one button!

And, you don't have to worry about what to do in the case that someone hits the "rotate ball" button while it's still rotating.

[Joker_vD]

> And, you don't have to worry about what to do in the case that someone hits the "rotate ball" button while it's still rotating.

Eh, it's a pretty trivial problem, comptometers have it figured out more than a hundred years ago.

[kevindamm]

If you're suggesting that the different columns of a comptometer would relate to different rotational axes of the ball, you will likely run into gimbal lock in 3D.

You could build an interface in 4D around quaternions but that is much more complicated than my suggestion (even including the part where you learn morse code).

The quoted part of my comment is in reference to the core topic of TFA where iOS and Nothing/Android photo apps handle the "pressed again during rotation" action differently. That "rotate the typewriter ball" interface runs against the same problem, by necessity of rotating a physical ball.

[Joker_vD]

I am suggesting that the whole keyboard can lock during the time the physical ball rotates; the comptometers and pinwheel arithmometers of the yore had this functionality: while the mechanism was performing the addition of the number just entered, the user was blocked from fiddling with the input mechanism.

[kevindamm]

I get that's what you're suggesting. The locking per-axis or across all axes is fine but doesn't address the problem I'm talking about. In gimbal lock, which many graphics programmers first encounter by using only sequential rotations around the camera's axes, you can get into an orientation where you lose one of the three degrees of freedom.

https://en.wikipedia.org/wiki/Gimbal_lock