Should indeterminate progress indicators distinguish between progress / lack of progress?

Question

If an application has a possibility of not progressing (hung thread, indefinite network timeout, etc.) how should an indeterminate progress indicator behave, so that a user knows when to give up?

I've seen lots of websites giving information about indeterminate progress indicators but none of them seem to address this issue.

From another question:

Wouldn't you rather see that the progress has halted, or is supposedly going to take more time, rather than a rotating wheel or indeterminate bars? I personally would prefer to know something has stopped working, or my progress has been halted due to download problems or such other factors. A indeterminate bar or wheel can keep us waiting long after it has probably given up... I mean come on, it's software we're talking about, it's bound to mess up sooner or later... Unless the wheel stops spinning because of progress problems or the bar stops rotating... You're going to be waiting a long time, if not getting frustrated that it's taking an absurd amount of time to get something easily done.

Answer 1

I think your scenario would apply to any type of progress indicator, since the 'indeterminate' part of the progress indicator is not actually related to when it will be completed (either by number of items or amount of time, which are related), but rather whether it is actually interrupted by something else unrelated to the current process (i.e. hung thread or disconnection).

So depending on what the potential scenarios are, you can deal with this in a number of ways. For instance, if this process can resume after interruption (as most of the more advanced download managers seem to be able to do) then you can simply ask if the user wants to stop the current process and resume it using anything from a notification on the screen to a pop-up window.

However, if there is a potentially destruction consequence to the action (i.e. you have to start the download again) then you may need to be more careful about what options you give to the users and what their expectations might be. One strategy might be to 'timebox' the problem, so that if there is still no signs of whether the process is going to complete then the system will just stop it (and restart again) but give the users plenty of warning.

Of course, the risk for the user is that they might stop a process that is actually about to complete soon, but you shouldn't decide for the user whether the risk is worthwhile unless you have good information to help justify this.