What would be a user-friendly error message for HTTP request timeout?

Question

We have a HTTP request timeout implemented in our mobile app, and we display an error popup when the response doesn't come on time (we will put the timeout somewhere between 30 and 60 seconds).

I want to display a friendly and informative message to the user, but without scaring them too much, and without putting too much technical jargon.

There are multitude of reasons why the timeout can occur:

• user has poor internet
• user is traveling by metro, and temporarily has poor internet
• our server is slow
• some failure in the middle of the network

so I'd like the message to cover them all.

We can start with

There was a problem with your request. Please try again later.

but it's not very actionable (no info to the user what and why went wrong), and moreover the user might not understand what "request" stands for.

I am thinking about something like "make sure you have a good network range" but I don't know how to write it in a friendly way.

The case of "no internet at all" (radio disabled / airplane mode) is a separate thing that I can handle in a separate message (for now I put Problem with internet connection. Please make sure that your device is not switched to airplane mode)

What is your advice for the informative error message?

Answer 1

You could have the app check the signal strength and accordingly give out a message.

For E.G

1. If the network is strong and there still is a timeout, you could show something like this

Looks like the server is taking to long to respond, please try again in sometime

.

2. If the network is weak, you could show something like this

Looks like you have an unstable network at the moment, please try again when network stabilizes.

If checking the signal strength is not possible for some reason, try a generic message like

Looks like the server is taking to long to respond, this can be caused by either poor connectivity or an error with our servers. Please try again in a while

Answer 2

Your use cases list out a perfect opportunity to move to an offline first implementation by using service workers. You can get started by reading more here: http://offlinefirst.org/ , but the overall sentiment is to cache some parts of your application on the user's side, and let the application handle failures more gracefully by waiting to post until connectivity is restored. There are a few apps you can look at for inspiration with this pattern, but chief among them is Facebook.

Figuring out different causes and states, to then provide contextually appropriate messaging to the user, can end up being a game of whack-a-mole. It seems like what is most important to you is providing a salient action to your users in the case they're unable to reach your site. Offline first allows you build in such a way that the user doesn't need to take any action, where they can trust that their intent will be carried out.

If you're interested in a nice solution, I'd suggest UpUp.js - https://www.talater.com/upup/

You can also Google "service workers" and learn more about how they might be helpful for your application.