Switches in UI, that correspond to serverside settings: display wish or actual system state?

Question

This is no exact dup of Should a toggle button show its current state or the state to which it will change?

Question is: I´m displaying a switch / toggle button on a mobile device, which represents the status of a system on a network server (e.g. subscribing to push notifications).

What is the best practice to display the status of the button and handle the point in time for the network connection?

1. Display the 'user wish' and manage the server connection etc. in the background. The connection does not have to be established directly, it is only guaranteed to happen sometime in the nearer future. This has the downside that there is a timeframe, where the toggle does not show the actual state of the system (e.g. when the connection fails and the client has to retry).

2. Display the actual state of the system, i.e. user toggles the button, show some progress dialog, connection is established, only set the button to the new state, when the system is also in the considered state.

3. A mix of both, e.g. setting the button instantly to the wished state, start connection, but then instantly informing the user and resetting the button, if the connection failed etc.

Looking forward to hearing some opinions!

Answer 1

The same question came up a few years ago when I had to implement a switch in a web application for desktop. I was limited to Bootstrap for the UI and found a switch plugin with a "middle state".

When the users clicks the switch slides to the middle and stays there with a loading spinner inside. This way the switch immediately reacts in the way you would expect but also shows the delay caused by the server action.

If the server action failed (or reached a time out), the switch jumps back to it's initial state. When it succeeds it continues to the other side.

Note: I don't have access to that project anymore and it looked a bit different but the idea is the same. The plugin can be found here: bootstrap-switch.org

Answer 2

I feel as though your options 1 and three conflict - you say that the connection may be established in the future and the user might have to retry, yet in 3 you mention informing the user instantly if the connection fails.

In my experience this works quite well:

The user toggles the button to the desired state ->

The system attempts to connect ->

A progress bar is shown and the button switches to the desired state ->

If the system connects the progress bar disappears ->

If the system fails to connect the user is informed of a failure and the button is switched back to its off state.

An example of when this is used is when you are streaming on Netflix for example, when the video has not buffered enough it will switch button state from pause to play, if you then try to press play and the video has still not buffered enough, it has a transition effect which flicks between pause and play and shows the play button again, this shows that the video is unable to play. Realistically this is not 100% clear unless your user understands the video is not fully loaded (as indicated by a progress bar). They then display an error message if there are connection issues during buffering. You can overcome the issue of not being obvious by showing the system trying to connect.

Answer 3

Whatsapp (for iOS at least) handles this for the "Receive notification" buttons in the following way:

• When you toggle the button, it instantly switches to the new state (the "desired" state), but at the same time it is disabled (greyed out)
• If the connection to the server succeeds, then the button is reenabled and stays at the new state (which now matches the server state)
• If the connection fails (after a timeout of a few seconds), then the button is switched back to the original state and reenabled. This tells the user that the action failed.

You can further refine this by disabling the button in the first place if you check connectivity to the server and find that it is not reachable.

Answer 4

I'm a bit confused; if you're supplying data to the server from a client, then as far as the client is concerned as long as you push out, done. Whether the server has received it or not doesn't really matter. Then as the server receives that input, it adjusts the state on the server and done.

And if there's a loss of sync, then it checks for the most recent change, which has a datetimestamp. At which point if, say, there was packet loss, the server checks back with the client every so often (say once every 24h, depending on the service) and updates accordingly.

So unless I'm missing something, I'm confused with how any of the options you list work. The user should never have to deal with the state; they deal with an option and the client handles the state, and the server is the slave to it.

Answer 5

Since your button doesn't change its state immediately and it has a dependency on the server side, then it's better to communicate this to the user to avoid possible miscommunication.

I think displaying a status message after the user has pressed the button will manage user's expectation correctly. If the server side succeeds, then the button state will be changed to "on", if not it will fall back to "off".

^{download bmml source – Wireframes created with Balsamiq Mockups}

Additional error message can be displayed below the button or if they are short then perhaps within the same button too.