When to commit user data (a humble request from a systems guy...)

Question

So, I am a systems programmer working on a UI (bad idea, maybe, but I think I do ok all things considered). Anyway, my program is an interface to a service running on a remote machine which controls a piece of hardware. The basic model is:

1. Send command from the UI.
2. Get ACK from remote service, enter busy state.
3. Remote service processes request and sends OK or ERROR.
4. UI receives response and leaves busy state.

When the UI enters a busy state all controls are disabled (well, all but one, I'll explain that shortly as it is part of the problem). One aspect of the system is to assign arbitrary data to an object (data is a string, object is irrelevant for the purposes of this question). In order to make this process robust and simple, the data will be committed to the remote server when the user presses Enter within the text area or focus leaves the text area.

This however causes a bit of a problem. One button in the UI is always in one of two states; "start" or "stop". When the system is in a busy state this button turns into a stop button and is the only enabled control in the UI. This is necessary in order to cancel long running operations.

However, imagine the following scenario:

1. User types into text area in order to assign data to an object but does not press enter to commit.
2. User presses the "start" button.
3. Because the text area has now lost focus the data is committed. This causes the system to go into a busy state.
4. After the data is sent and we are in a busy state the click handler for the start/stop button is invoked. However, the button is now in a stop state because we sent the data when the text area lost focus and we have not yet received an OK response.

If the user clicks start again everything is ok because the UI will not commit duplicate data, only committing when it has changed. However, this is a bug and I need to fix it.

I don't want to get rid of the commit on lost focus because it ensures that, even if the user does not press enter, the data on screen will always be committed and valid. Does anyone else have any ideas here? Is there perhaps a better way of going about this? I can think of some convoluted workarounds, but they are all ugly and really break the encapsulation between various parts of the UI.

So, if anyone else has a simpler, better solution I would love to hear it.

Answer 1

A simple approach that might be "good enough":

As soon as a change is made (ie on the first character press), disable the "Start" button.

Only enable the button when changes have been saved. You might want to have an explicit "Save" button as well, in case the user isn't aware of the convention that the enter key saves.

Answer 2

Firstly, you probably should have separate buttons for start and stop/cancel. Having the same button do opposite things is a prescription for human error whenever there is lag.

As for your particular problem, if this situation is limited to the Start button, you could leave the Start button enabled and cache the Start command, sending it after the busy state ends (until status == OK). Cache only one Start command to prevent sending multiple Start commands. Disable the Start button and clear the cache only after receiving an acknowledgement that Start specifically has been received.

I think users will find it very annoying and possibly error-inducing to have to wait between inputs for the controls to enable. I can imagine users tabbing or clicking on a control that enables and disables in a way that users don’t realize that some input was lost. Perhaps there is a more general way to handle this situation for all controls:

• If busy times tend to be short (<2 sec) and errors very infrequent, consider queuing all the commands. If an error is received, halt sending the commands until the user supplies the fix, and insert the fix to the front of the queue then resume sending. You may also want to have some active queue management (e.g., removing earlier commands that are undone by later commands).

• If busy times tend to be long and errors infrequent, consider batching all the commands to be sent in some reasonable order when the user clicks the Start button. Be sure to provide feedback on when the pre-start commands are all OK’ed (e.g., a “Checking Setup” progress message), so the user knows when she or he can turn away. You may also want to consider an audio alarm if there’s an error, in case the user turned away before the process actually started despite your feedback.

• If busy times are long and errors and frequent you have an inherently clunky device that calls for a clunky UI. Consider using a wizard where users enter/accept each command one at a time, verifying each worked before moving on to the next.