I recently came across an interesting question, that I think is quite thought provoking. The original question was, how the person in question could make a radio button look and act enabled, but not actually check at the moment he clicked it. The reason was that the radio buttons actually controlled a hardware device setting (a PLC), and that he really wanted the state of the radio buttons to reflect the hardware state. So, if the PLC changed state, the radio buttons selected state would be updated.

That got me wondering. While I think the intention is good, I doubt this is the best solution to communicate to the user that the hardware state has not changed yet. I think I would get frustrated with a radio button that doesn't immediately change to the item I clicked. At first I would try to click it again, but depending on how long it takes, I may give up and then be quite surprised to see the change occur pershaps seconds later anyway.

My question would be: what would be a good way to provide feedback? Should the control not indicate that it at least registered the request? And how do you communicate that the state change succeeded, or worse, failed? Note that this kind of scenario can not only occur when dealing with PLCs or other hardware, but also when such a state change trigges some complicated software path that may take a while to complete, and that may fail.

3 Answers 3


There's scope for variations on the following process but it defines the basic principle

enter image description here

In the busy state, neither button is clickable until the outcome has been determined.

  • Thank you very much for this well worked-out answer. I think it is an interesting approach, though perhaps it should be state 2 that lights up red and then fades back to the unchecked state (white here). It will take quite a bit of work to make this work, as standard widgets do not provide these kinds of 'in between' states by default.
    – André
    Mar 28, 2012 at 8:32

I can think of a couple of possible solutions, though a lot is going to depend on the particular environment etc.

  1. Disable the control until the hardware reports back that it has updated.

    This would work when changing the state of the hardware via a switch, or radio button. Having the controls greyed out would indicate that the message had been sent and then the re-enabling of the controls would show that the message had been received.

  2. Have a second control that shadows the actual value.

    This might be more appropriate for continuous variables (e.g. radio frequency). The user would set the required value and then a second control (e.g. an outer ring of a dial, a "shadow" on a slider, or a second text box) would show the actual value and that would only update when the hardware reported it's new value.

enter image description here

  • Thank you for your answer. For a dial-like control, this may indeed be a good solution. However, personally, I don't like dial controls at all. While in the real world dials are easy to use, I find them to be very hard to use in computer programs, and I much prefer sliders or other linear controls. Still, I think the same principle can be applied there. Again, thanks for your input.
    – André
    Mar 28, 2012 at 8:36
  • @André - indeed, it is just and example. I'll update the answer and image to show another example.
    – ChrisF
    Mar 28, 2012 at 8:37

I would regard "what are you telling the hardware to do" and "what is the hardware actually doing" as being, from a UI standpoint, independent aspects of state. Although there will usually be a strong correlation between them, a UI design that assumes a correlation is apt to have difficulty in with many corner cases where the correlation fails. By contrast, if one has buttons for "Open valve", "Close valve", and possibly "Cancel valve action", and a readout which says "Valve opening", "Valve is open", "Valve closing", "valve is closed", and maybe "Valve stopped during open" and "Valve stopped during close", such a UI will make it possible to clearly indicate what is going on.

An additional advantage of separating commands from feedback is that such separation will make it easier to deal with hardware that makes different amounts of feedback available (e.g. if limit switches are replaced with analog position sensors or vice versa). It will also help avoid difficulties that may be rise if hardware changes state just as a user is about to click on it. If one has "open valve" and "close valve" buttons that don't care whether the valve is open or closed [and a request to open an already-open valve will be harmless], then the "command" part of the UI can be decoupled from "show current state".

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.