controls that don't really "control"

mzimmers

Hi all -

I could use some advice regarding an app I'm working on. My Qt program is the GUI for a larger application that controls a given installation. One of the primary uses of my program is to control various elements of that equipment (eg, turn on a pump).

Except...my controls don't really do any controlling in the literal sense; they just generate a request that's passed to the core process (not a Qt process) of the application and wait for a response. A subtle but IMO important distinction. The core process then attempts to effect the requested change, and sends me a response based on the result of its attempt.

In such a scenario, what's the best way to handle the visual change of a control? I don't like the idea of just changing the switch state because the user clicked on it - to me, the UI should only reflect "real" data, not just user wishes. Agree/disagree?

Most of these message exchanges will be quite fast (on the order of 1ms), but it still seems that I shouldn't change the switch state until I do get the response. Agree/disagree?

Some user requests will take longer - much longer, like on the order of 1 minute. These will need a busy indicator, and some way to represent a third state of the switch for "waiting for request to take effect." Agree/disagree?

I don't need a blow-by-blow response to all of this; any opinions are welcome. Thanks...

Chris Kawa

If the action is not immediate, nor guaranteed to succeed, then I'd agree that your controls need to have 3 states - on, off and waiting.

Depending on what type of control it is it might be a busy indicator, a flashing light, a progress bar or anything else. That's up to visual design, but the gist is that the intermediate state should be reflected in the UI for it to feel responsive. Basically it should be a state machine: On<->Waiting<->Off, with each state reflected in the visuals. It would look bad if you didn't represent it properly i.e. did On -> Off ------> On.

As an even better experience you could provide an additional intermediate state that shows up when the operation failed e.g. On -> Waiting -> Failed -> On. This could be represented e.g. with colors: green -> blinking yellow -> blinking green -> green, or whatever else is appropriate visually, like a highlight, an exclamation mark icon, progress bar changing color etc.

mzimmers

@Chris-Kawa good input. This has me wondering whether I really want to use a Switch, at least in the way that I am. My customization features two states (checked and unchecked) which change automatically when the Switch is clicked. Perhaps I need a third state (along the lines of what you suggested), but that still leaves the issue of how to display the switch while it's in that transitory state.

TomZ

@mzimmers We faced this issue when I worked with a medical company building a ventilator.
The front end was a different board/cpu than the actual one doing the controlling and the controller was the only one controlling actual operational hardware.

As a result all actions were just like in your case, requests.

The first thing to change was that the user pressing a button never caused the button-state to directly change. No, instead if caused a message to be sent to the controller-board and that board had the "contract" to reply with a response in a short amount of time.
Rule of thumb; any result that takes less than 200ms is seen as instant by humans.

So the design we went for was this. A button wants to change from state A to state B, due to a press. You wait for the response which will tell you it actually changed or why it didn't change.
And based on that message you update your GUI button.

In your gui-backing data-model you then have a bit more state. From "state A" to "requesting state B", to "state B reached" and maybe some extra rejection reason states.

Which has a neat side-effect that pressing the button multiple times will not do anything as the internal model is already in "requesting state B".

My personal advice on the usecase where getting a new state may take more than 200ms is to have your datamodel update the state after 250ms to "waiting-for-state-B" or something (use a timer) and then the front-end can show the 3rd state, indicating that its busy doing what you requested.

mzimmers

@TomZ said in controls that don't really "control":

My personal advice on the usecase where getting a new state may take more than 200ms is to have your datamodel update the state after 250ms to "waiting-for-state-B" or something (use a timer) and then the front-end can show the 3rd state, indicating that its busy doing what you requested.

I agree completely -- it's just a little hard to figure out how to do this with a Switch.

EDIT:

I got my issue with the Switch figured out - it wasn't so much a state problem as it was my lousy model implementation (explained in painful detail elsewhere in the forum). Thanks to all for the help.