The Singular Purpose of a Button

By Marcin Wichary | Unsung Software Craft and Quality

One lingering concern I have regarding my recent large-scale interactive essay is that by utilizing classic desktop metaphors, the content might seem $\text{obsolete}$—as if it only applies to a vanished era of computing.

The Rotation Test

To examine this, let's look at a common task: rotating an image on a smartphone. Whether you are using an iPhone or a Nothing Phone, the control is standard:

• Tap 1: Rotate counterclockwise.
• Tap 2: Rotate again.
• Etc.

The UI usually includes a smooth transition so the user doesn't lose their sense of orientation. To test the limits, I performed an exaggerated action: tapping the rotation button eight times in rapid succession.

Mathematically, eight $90^\circ$ rotations should result in a no-op (no operation), as the image completes two full circles: $\text{Rotation} = 8 \times 90^\circ = 720^\circ \equiv 0^\circ \pmod{360^\circ}$

Comparing the Experience

The Philosophy of Accessibility

I often reflect on the concept of situational disability. This framework suggests that disability isn't a niche experience reserved for a few; rather, it is something almost everyone encounters occasionally.

"Disability is not just something that happens to a few people... pretty much everyone will occasionally encounter a situation that will make them effectively disabled."

I believe a similar logic applies to the distinction between "casual" and "power" users. Some people are just power users. Instead, we should think of this as "situational power user-ness."

The Practical Scenario

Consider a user photographing landscape-oriented documents. If the camera fails to detect the orientation (which often happens when pointing straight down), the user may need to rotate dozens of photos manually.

In this context, the user needs to be able to:

• Tap the button three times rapidly.
• Do so without conscious attention.
• Avoid being blocked by a "pretty" animation that has ceased to be useful.

The Technical Implementation

If we were to write the logic for a "bad" button versus a "good" button, it might look like this:

// THE WRONG WAY (Nothing Phone approach)
function handleTap() {
  if (isAnimating) {
    playHapticFeedback(); 
    return; // Ignore the actual command!
  }
  startRotationAnimation();
}

// THE RIGHT WAY (iPhone approach)
function handleTap() {
  tapQueue.push('rotate');
  processQueue();
}

Final Verdict

Whether you choose to accelerate the animation or allow an interrupting tap to snap the image to its new position, the fundamental rule remains:

Never force the user to wait for an animation to finish before accepting their next command.