Take the 2-minute tour ×

I developing a client using Flex and ActionScript that is run in the browser and communicates with our server backend. There has been concern that the application "needs" to have a graphic indicator to show whether the client has a connection to the server or not.

Part of the problem of this requirement is that is coming from a high-level perspective that because the interface looks "broken" (i.e. doesn't update properly). I have an idea where the problem is, but that doesn't mean that the error is in the interface.

I believe that a connection monitor feature is unnecessary because:

  1. Users won't be able to do squat. Our user base is largely non-technical.
  2. Flex generates HTTP error events but does not specify what happened. I can't tell what real problem is which could be:
    • The user actually has no network connection.
    • The application server code is broken in some way.
    • The server itself is messed up (i.e. "Oops, I broke the Apache config").
    • Server load is too high and becomes unresponsive.
    • There is a some other problem (e.g. network or hardware) beyond my or users' control.

How do I convince that this feature is not valuable to develop? If it is something worth keeping, what are alternatives to showing a "network status" or server connection problem in the client? I would rather spend the time to dig at the root of the problem and prevent it from happening rather than creating an additional "feature" that doesn't solve anything.

share|improve this question
add comment

3 Answers

up vote 1 down vote accepted

Having developed this feature for an AIR app (using URLMonitor) I think it is a worthwhile feature to add, though I can see where you are coming from.

What we did for our connection monitor is create a script on the server that the client app can ping for a response at some set interval (say, once every 10 seconds). Based on that response we can say our server is available or unavailable and display this via a little icon in the app's status bar. The server being unavailable is typically the result of some change on the server that breaks something or the user not being connected to the internet. This is helpful to the us and the user to a couple ways.

First, if the server is broken or under heavy load and unresponsive we can avoid hitting it with even more requests. Since the client app keeps track of whether or not the server is available before sending requests we can do something like:

if (serverIsAvailable)

Second, we provide a better user experience. Rather than the client app just breaking or hanging because it can't get a response to a request we can throw up an error message along the lines of "Sorry, this operation could not be completed because we could not contact the server." As an added benefit, we've found that when users contact support about this issue they will say, "I got this message about the server being unavailable" which helps us pinpoint problems faster.

If the goal is to avoid a bad user experience you shouldn't really be concerned so much with why the server is unavailable, only that it is unavailable.

To answer your question more directly, yes, I think this is a worthwhile feature to add. Having your application break for some unknown reason and not displaying the most helpful error message possible to your user is a poor experience. I agree with you that the goal should be to prevent errors from arising in the first place but errors will happen no matter what you do (especially when your application requires an internet connection) and you should always handle them gracefully.

As far as displaying this to the user, we try to keep it out of the way. At all times there is an icon in the application status bar indicating status. The only time we ever show any kind of dialog related to server connection status is when the user initiates some action that will require a server connection and the server is currently unavailable.

share|improve this answer
I like what you outlined. That makes a lot of sense. I'm sure a lot of improvements could be made to our user experience especially regarding error handling. –  Matt Chan Dec 9 '11 at 19:59
add comment

It's not possible to show the network status of an http connection because it's not a stateful connection. at best you can have an ajax method ping a high up time site like Google and say they have an active internet connection, which isn't very useful.

share|improve this answer
Or you can ping your own server, which is useful. –  whatsisname Dec 9 '11 at 19:33
but that adds more traffic to your server, which could be a problem if sever load is part of the reason the app is unreliable, and even then its not a guarantee that anything they submit will work, it just means you sent a previous successful request. –  Ryathal Dec 9 '11 at 19:43
add comment

Gmail has an indicator if your network connection is flaky.

What are the consequences of losing connection to the server? Can users lose work?

When I try to check something into version control, there are numerous things that can go wrong, some of which version control might have no influence of, but I absolutely expect it to tell me if there is a problem.

share|improve this answer
For the purposes of the application, the "worst" things that could happen is users having to re-upload or re-download large files (which doesn't happen often). Other requests are small updates. I have put in all the error handling to account for problems (so it seems) which is why I think the connection monitor is somewhat unfounded. –  Matt Chan Dec 9 '11 at 19:41
add comment

Your Answer


