Enhance progress state in dialogs

[jotaen]

As pointed out in https://github.com/mtlynch/tinypilot/pull/708, we could avoid some repetition in our dialog components by pulling out a generic progress state into the <overlay-panel>. The dialogs would emit events DialogProgressStarted/DialogProgressFinished that the overlay picks up and adjusts the visual state.

That would not just make the code leaner, but it also ensures that the visual pattern is always consistent. In analogy to the error dialog, the progress state could have a blue top border and a slightly blue-ish background, so that the user recognises it easily.

[jotaen]

There is also quite a common problem that the progress state appears to be flickering/flashing: the UI switches into loading state for just a split second, because the underlying operation executes very rapidly. This is inconvenient, because the user doesn’t get a chance to grasp what’s going on.

If the progress state was centrally controlled by the overlay panel, we could make it more sophisticated to account for that phenomenon. For example, the progress state could be debounced like so:

• When the DialogProgressStarted event fires, we wait for ~50–100ms. If DialogProgressFinished was fired in the meantime, we just skip and don’t do anything. If it wasn’t fired, we switch to progress state.
• Once we have switched into progress state, we do the same the other way around, so that the progress state will show up for at least ~200ms, even if DialogProgressFinished had been fired earlier. That way the user always has enough time to follow the UI.

(exact time values tbd)

[jotaen]

On a general note I think it’s not optimal that we currently tend to skip the loading states in order to avoid the flickering problem. The operations will for sure be very fast most of the time, but in case the network is delayed for example, the user doesn’t get any visual feedback that their command was received and is being processed.

[jdeanwallace]

On a general note I think it’s not optimal that we currently tend to skip the loading states in order to avoid the flickering problem.

I agree with this.

Idea: Computers are too fast. Let's slow everything down for humans. We could enforce a minimum amount of time a state can be active (i.e. loading screen must show for at least 1 sec) to give people time to "grasp what’s going on" 😆