Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

These days many apps support asynchronous updates. For example, if you're looking at a list of widgets and you delete one of them then rather than wait for the roundtrip to the server, the app can hide the one you deleted, giving immediate feedback. The actual deletion on the server will happen in the background. This can be seen in web apps, desktop apps, iOS apps, etc.

But what about when the background operation fails. How should you feed back to the user? Should you restore the UI to the pre-deletion state? What about when multiple background operations fail together?

Does this behaviour/pattern have a name? Perhaps something based on the Command pattern?

share|improve this question
Did you try asking your users/stakeholders what THEY wish to see? – PhD Jun 19 '12 at 2:07
Good point! At the moment this is just hypothetical, I haven't started building an app yet. – Andy Waite Jun 19 '12 at 6:37
Check over on Game Development. FPS games do this all the time, and there's a lot of discussion about it there and everywhere else on the web. But I think it's an awful lot of work for a normal web app. It needs rapid response times to avoid jolting the user, and if you have those why bother predicting? Your's user's just trying to submit some data, not shoot something before it shoots him. – RalphChapin Jun 19 '12 at 17:46

Since it is "just hypothetical" for now here are a few suggestions to 'help discover' this for yourself. Although it's best to put on a user's hat every now and then and see if you'd like it if you were in their place.

Let's assume every 'interaction' is a use-case or XP's user-story. Think of what it means to be 'done' or 'successful' i.e. when will you say it's fully functional and ready for delivery? That should give you the list of alternate scenarios that you probably already have.

Now for every alternate scenario trace out the steps. See if you can easily write it as step 1, step 2, ... , step N. If you can you be readily assured that you are keeping it simple. If it gets too convoluted, may be that's not the way to go and you need to look for something simpler or rethink your strategy.

Another option: Prototype the GUIs. What looks good or feels intuitive? Try capturing the steps as above and see if the 'use case' is simple/complex.

If you 'feel happy' about it you may think you've done a good job. Cross verify this with other humans who think differently than you. Reason? MS devs love their product (Windows) but most people would not like the UI :P So you need the perspective of people who'll probably use your system but are not techies.

Note: every thing should provide valuable information. Is restoring the UI to pre-deletion valid and expected? Maintain the natural/commonly found interactions so that the system is usable and intuitive.

So think of how you want to handle the failure of multiple background operations. Should you show an 'alert for each' or 'batch them up' or show it at point of submission? It depends on what are the needs and what makes life easier. Since it's all hypothetical it's hard to say and keeps things subjective. I doubt if there'll ever be an objective answer.

This pattern doesn't have any name other than 'analysis-design-feedback-iterate' IMHO :)

My suggestion: First build the app and once you actually hit the spot where this is a concern you may ask a more specific 'tactical' question.

Best of luck!

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.