Design For Asynchronous User Interface

Question

I have been working on a integration that has posed an interesting user interface conundrum that I would like suggestions for.

The user interface is displayed within a third party product. The state of the interface is supplied by calls to a service I have written. There can be small delays between the actual state changing the the user interface changing due to the polling for state by the third party.

When a user interacts with the user interface, requests are sent back to my application. This then affects the state and the next state poll request will update the user interface.

The problem is that the delay between pressing a button and seeing the user interface update is perhaps 1 or 2 seconds and in usability testing I can see that people are clicking again before the user interface updates, thinking that they haven't properly clicked the first time.

Given the constraints (we can only update the user interface via the polling mechanism - if we updated it when they clicked, the polling might return and overwrite the change causing unpredictable / undesirable results)... what can we do to make the user experience better.

My current idea is to show a message for a couple of seconds so people know their click was accepted, the message would not be affected by the state polling, so wouldn't be prematurely removed / overwritten etc. I'm sure there are other ideas out there and I'm also confident someone has a better idea that I have!

Answer 1

Immediately show some feedback: change the visual state of the button, display an animated throbber.

If the app logic allows, disable the button once it has been pressed, enable it back when the answer arrives.

Once the answer has arrived, show the real feedback: update the controls, remove the throbber.

Answer 2

Just for the purposes of posterity, I'll share the solution.

Race Condition

The problem here is that the polling mechanism occurs every n milliseconds, and a request may be in-flight when a user clicks, causing a race condition.

Happy path (button is enabled, then disables and stays that way):

• Poll
• Response (enable button)
• Click (disable button)
• Poll
• Response (disable button)

Race condition path (button is enabled, then button disables, enables, disables - nasty flashing state):

• Poll
• Click (disable button)
• Response (enable button)
• Poll
• Response (disable button)

Solution: State Version Correlation

When the user interacts with the UI, a new state version is generated (i.e. a GUID, timestamp, etc).

This state version is sent with each request, and returned in the response.

When a response is received, the state version is compared and those that don't match are discarded.

Example

Happy path:

• Poll (v1)
• Response (enable button) (v1)
• Click (disable button) (v2)
• Poll (v2)
• Response (disable button) (v2)

Race condition path:

• Poll (v1)
• Click (disable button) (v2)
• Response (discarded) (v1)
• Poll (v2)
• Response (disable button) (v2)