Tell me more ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.
up vote 4 down vote favorite
1

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.

share|improve this question

2 Answers

up vote 5 down vote accepted

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.

share|improve this answer
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 '12 at 8:32
up vote 1 down vote

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

share|improve this answer
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 '12 at 8:36
@André - indeed, it is just and example. I'll update the answer and image to show another example. – ChrisF Mar 28 '12 at 8:37

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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