We're developing an online application and wondered what is the average/expected/reasonable about of time to make the user wait after form submission before we say "Hey sorry, we think there's a problem with our servers you might want to try later...".
Evidence to support your answer would be appreciated.
It's hard to answer without knowing the average response time of your service. A user accustomed to an average of 4s response time may not be too fussed about a 12s delay; but a user accustomed to 0.1s response will.
Anyhow, as indirect answer, you should expect users getting really annoyed after 10 seconds. See this famous post for more.
Just an additional anecdote:
Hey sorry, we think there's a problem with our servers you might want to try later...
You should consider an alternative phrasing for this. A user I may ask: "What do you mean 'you think' there's a problem? Is there or isn't there? And if there is... what is it? What sort of people wrote this system?"
It's a bit like a printer throwing a message such as:
I think I'm out of ink - but maybe not.
Also note that anthropomorphising is most annoying for users when the system misbehaves (see more).
Please speak to your developers - in most client-server protocols, once a request is on its way the only 'right' way to stop it is by a timeout set explicitly by the developer (on the server, client, or both). You can't just show a message as such - you need to ensure the request has been 'killed'. Just a note that you may want to discuss this with the developers before finalising the design.
Assuming that you are able to configure the timeout ..
I prefer to keep the users waiting, for around 30 seconds. To compensate for the wait, I keep the user informed of what is actually going on. E.g.
0-10 sec. Message: Contacting server ...
10-20 sec. Message: Waiting for a response ...
20-30 sec. Message: Still waiting ...
The benefit of doing this is twofold:
1) There is a higher chance that you will get a response from the server and the user will be able to continue using the app.
2) There is a lower chance that the user will close the application because they are tired of waiting.
I am basing this off a small amount of research I did a few years ago on 10 dummy web users. Unfortunately I haven't got the numbers right now but this is the basic solution that we found to work best.
