Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

In case you didn't know, people are increasingly using smartphones. One problem that comes with smartphones is a shaky and unreliable internet connection. For "static" websites that primarily serving pages with content on request by the user the built-in offline detection error message in the mobile browsers enough but for interactive native or web apps I feel that it isn't enough.

What are the recommended interaction design pattern for handling network connection errors when it comes both to error messages and handling user submitted data? When should I display the error message? What should the error message contain?

share|improve this question
    
Probably best solution depends on concrete case. Still general thought is to be gentle in error handling to avoid halo effect (bad connection –> bad application). –  Alexey Kolchenko Nov 26 '13 at 12:04

1 Answer 1

I had a similar problem in one the native apps that I am designing and I ended up categorising the internet connection errors in two groups in terms of user experience.

1. Internet connection errors that appear when opening the app for the first time

My proposal is to handle these errors with error screens (most of the apps that I benchmarked are doing the same). The problem is that in this case there isn't anything cached in your app and you cannot provide content to the user. Therefore you need to ask them to quite clearly to do something about this.

However you should be careful to load some content (top bar or maybe basic navigation) just enough to communicate that there isn't something wrong with the app and put the users in the correct context.

Case 1: No cached content

2. Internet connection errors that appear while you are using the app and can affect requests to the server

My proposal is to handle these error in context with a bottom notification (gmail app is doing the same). The reasoning behind this is that you don't interrupt the user experience (users can still interact with the cached content) but in the same time you are informing them that something is wrong. Then if they end up submitting something or trying to navigate to a page where a new request is made you should go for the 1st solution.

Case 2: Cached content

share|improve this answer

Your Answer

 
discard

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.