Return to Answer

First, you might reconsider the framing of the problem. The way you described it, if the user draws an object but the server doesn’t receive it, then the object was never drawn. From a UX standpoint this is precisely backwards, a system-oriented way of thinking. UX is user-centered.

The system is not the authority, the user is. An object is drawn as soon as the user draws it. He performed all the right actions and saw all the right feedback, so the case is closed and the user’s job is done. If the system isn’t up to date on the facts, that’s the system’s problem.

If the system can’t self-correct in a timely fashion, the user must be notified. But he shouldn’t have to re-draw anything, or perform any further action. Instead, the system should attempt to re-send the drawing. There’s no reason to punish the user for the system’s shortcoming by making him do the same work over again.

If the nature of the product is highly timing-sensitive and users need quick feedback, you could use a combination of well-timed animations for a “sleight-of-hand” effect (animations that take up time while latency-intensive operations are happening) and the “skeleton screens” concept (LukeW: Mobile Design Details: Avoid The Spinner) to cover over latency-related issues for a few seconds. This helps prop up the illusion of a flawless system in the mind of the user, and prevents him from worrying about technical details that have nothing to do with him.

First, you might reconsider the framing of the problem. The way you described it, if the user draws an object but the server doesn’t receive it, then the object was never drawn. From a UX standpoint this is precisely backwards, a system-oriented way of thinking. UX is user-centered.

The system is not the authority, the user is. An object is drawn as soon as the user draws it. He performed all the right actions and saw all the right feedback, so the case is closed and the user’s job is done—no waiting involved. If the system isn’t up to date on the facts, that’s the system’s problem.

If the system can’t self-correct in a timely fashion, the user must be notified. But he shouldn’t have to re-draw anything, or perform any further action. Instead, the system should attempt to re-send the drawing. There’s no reason to punish the user for the system’s shortcoming by making him do the same work over again.

If the nature of the product is highly timing-sensitive and users need quick feedback, you could use a combination of well-timed animations for a “sleight-of-hand” effect (animations that take up time while latency-intensive operations are happening) and the “skeleton screens” concept (LukeW: Mobile Design Details: Avoid The Spinner) to cover over latency-related issues for a few seconds. This helps prop up the illusion of a flawless system in the mind of the user, and prevents him from worrying about technical details that have nothing to do with him.

First, you might reconsider the framing of the problem. The way you described it, the if the user draws an object but the server doesn’t receive it, then the object was never drawn. From a UX standpoint this is precisely backwards, a system-oriented way of thinking. UX is user-centered.

The system is not the authority, the user is. An object is drawn as soon as the user draws it. He performed all the right actions and saw all the right feedback, so the case is closed and his job is done. Whether the system is up to date on the facts is for the system to figure out, not the user. It’s up to the system to deal with its own shortcomings.

If the system can’t correct its error in a timely fashion, the user must be notified, but he shouldn’t have to re-draw anything, or perform any further action. The system should attempt to re-send the drawing; computers are supposed to do work for humans, and humans should never be forced to clean up after computers.

If the nature of the product is highly timing-sensitive and users need quick feedback, you could use a combination of well-timed animations for a “sleight-of-hand” effect (animations that take up time while latency-intensive operations are happening) and the “skeleton screens” concept (LukeW: Mobile Design Details: Avoid The Spinner) to cover over latency-related issues for a few seconds. This helps prop up the illusion of a flawless system in the mind of the user, and prevents him from worrying about technical details that have nothing to do with him.

First, you might reconsider the framing of the problem. The way you described it, if the user draws an object but the server doesn’t receive it, then the object was never drawn. From a UX standpoint this is precisely backwards, a system-oriented way of thinking. UX is user-centered.

The system is not the authority, the user is. An object is drawn as soon as the user draws it. He performed all the right actions and saw all the right feedback, so the case is closed and the user’s job is done. If the system isn’t up to date on the facts, that’s the system’s problem.

If the system can’t self-correct in a timely fashion, the user must be notified. But he shouldn’t have to re-draw anything, or perform any further action. Instead, the system should attempt to re-send the drawing. There’s no reason to punish the user for the system’s shortcoming by making him do the same work over again.

If the nature of the product is highly timing-sensitive and users need quick feedback, you could use a combination of well-timed animations for a “sleight-of-hand” effect (animations that take up time while latency-intensive operations are happening) and the “skeleton screens” concept (LukeW: Mobile Design Details: Avoid The Spinner) to cover over latency-related issues for a few seconds. This helps prop up the illusion of a flawless system in the mind of the user, and prevents him from worrying about technical details that have nothing to do with him.

First, you might need to re-think the framing of the problem. The way you described it, the server is the authority on whether an object has been drawn; even if the user does all the right things and sees all the right feedback, the object still wasn’t drawn if the server doesn’t receive the necessary data. This is a system-oriented way of thinking. UX is user-centered.

The system is not the authority, the user is. An object is drawn as soon as the user draws it. He moved his hand in the correct way, and he saw the visual feedback on the screen, so the object is factually drawn, and the user doesn’t need to do or see anything else. Whether the system knows that the object is drawn is another matter. An error on the system’s part is not the user’s problem. It’s up to the system to deal with its own shortcomings.

Of course, if the system cannot correct its own error, the user must be notified that something went wrong. But he shouldn’t have to re-draw anything, the system attempt to re-send. Computers are supposed to do work for humans. The user should never have clean up after a computer.

If the nature of the product is highly timing-sensitive, and users need quick feedback regarding whether something finished sending, you could use a combination of well-timed animations for a “sleight-of-hand” effect (animations that take up time while latency-intensive operations are happening) and the “skeleton screens” concept (LukeW: Mobile Design Details: Avoid The Spinner) to cover over latency-related issues for a few seconds. This helps prop up the illusion of a flawless system in the mind of the user, and prevents him from worrying about technical details that have nothing to do with him.

First, you might reconsider the framing of the problem. The way you described it, the if the user draws an object but the server doesn’t receive it, then the object was never drawn. From a UX standpoint this is precisely backwards, a system-oriented way of thinking. UX is user-centered.

The system is not the authority, the user is. An object is drawn as soon as the user draws it. He performed all the right actions and saw all the right feedback, so the case is closed and his job is done. Whether the system is up to date on the facts is for the system to figure out, not the user. It’s up to the system to deal with its own shortcomings.

If the system can’t correct its error in a timely fashion, the user must be notified, but he shouldn’t have to re-draw anything, or perform any further action. The system should attempt to re-send the drawing; computers are supposed to do work for humans, and humans should never be forced to clean up after computers.

If the nature of the product is highly timing-sensitive and users need quick feedback, you could use a combination of well-timed animations for a “sleight-of-hand” effect (animations that take up time while latency-intensive operations are happening) and the “skeleton screens” concept (LukeW: Mobile Design Details: Avoid The Spinner) to cover over latency-related issues for a few seconds. This helps prop up the illusion of a flawless system in the mind of the user, and prevents him from worrying about technical details that have nothing to do with him.