Loading state for imperative actions

[razor-x]

Should we disable the button while the request is still pending?

Examples of actions are lock / unlock, toggle fan mode, delete access code, etc.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[miken-seam]

Here's a way to show actions in progress as well as a pending state for actions.

device-actions-locking-unlocking-11-9-2023.mov

There are 2 scenarios in this video. In both, the user tries to unlock a device using the action menu.

Scenario 1

• User selects Unlock from menu.
• Unlock command sent to device.
• Device sends back confirmation.
• Unlocked state is shown

Scenario 2

• User selects Unlock from menu.
• Unlock command sent to device.
• Device does NOT send confirmation back before widget times out.
• Pending unlocked state is shown
• When there's a pending state, the user can resync to see if it's no longer pending

We could work this flow into other scenarios and for other actions. I don’t know how often scenario 1 would happen but ideally it happens most of the time. But I think we should not say a lock is unlocked unless we have confirmation. Same goes for fan mode and delete access code. Generally, i think with the tooltips the pending blue dot should be learned relatively quickly.

Here's the prototype in Figma: Component action menu loading widget with pending states.

[miken-seam]

Here's a summary of the general behavior dealing with loading states and pending states. These rules should apply to different actions like lock/unlock, toggle mode, etc..

Re: the question above "Should we disable the button if the action is pending", this is addressed in number 6 below. It's a little more complicated than yes/no.

1. When a device is loaded into a view, we show the devices states and modes it was in when loaded
2. The view provides the user with a way to manually refresh states and modes in the view
3. For single devices, we should auto-refresh if the view has been open for more than x minutes. (Maybe the same for list views)
4. States/modes have a pending state that basically indicates to the user that we're not totally sure of the state, like this blue dot showing that we're not sure the device is unlocked. This one shows unlock because we just sent the unlock command to the device (so it should be unlocked) but it hasn't been confirmed.

5. We always make a tooltip available for icons that represent states, so a user can hover (with short pause) to see an explanation for the state. This will help the user learn the meaning of the blue dot.

6. Re: the question above "Should we disable the button if the action is pending", we can do this for pending states:

• 1. Show a pending state (blue dot) for a device's state or mode.
• 2. Show the pending state in the state we think it should be in. For example, if we just sent an unlock command to a lock, we think it should be unlocked, so we show the unlocked icon with a blue dot. If we don't have an opinion, then show the most likely default with a blue dot.
• 3. We show buttons/actions that would be available for the state we showed in the last step. In other words, if we think the lock is unlocked, then we show actions that are available for a lock that is unlocked. An unlocked lock, would have a locked action available.
• 4. If the state is pending, we always check the state of the device and show a modal if the device is not in the state we thought it was in. So, if a lock shows a pending unlock state and the user tries to lock it, we check the true state. If the state is locked (not the state we implied it was in) we pop a modal dialog that says "This device is locked. Would you like to unlock it. [Cancel] [Unlock].
• 5. If the true state of a pending-state device is what we implied it was--blue-dot-unlocked, for example--and the user tries to lock it, we don't show any dialogs. We just send the command as if the pending state had been the true state.

So, if we want to do this, we need to have a pending state for any action that affects a state that can be stuck in a pending state. Let me know if that makes sense.