Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

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

3 Answers 3

up vote 6 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

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".

share|improve this answer

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.