User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this community
The application I'm working on performs very heavy calculations. Right now we're using an undeterminate spinner. I go nuts from this and can imagine our users get even more annoyed with it. I thought of having a determinate indicator, but we don't know how long the calculations will take.
So, I thought of providing a cancel button. Would this be a nice solution for the users and will it give them more control?
(when the application is calculating, there is nothing the user can do on the screen)
The left field answer to this is to make your calculation process asynchronous. In other words, don't trap your users on a page where you don't know how long they will be stuck. Instead, have the "submit" instance an asynchronous backround process, which will then notify the user once completed, at the end of the async process.
Basic user flow:
No more users sitting on a "dead" page.
The other thing to do would be to refactor your calculations so they are determinate and predictable in time period, which of course would require more time and regression testing. The async idea is, however, at least a significant step away from forcing the user to just sit there. :)
I'm not a fan of the cancel button as the only solution - would only encourage people to press it and probably would probably make them more impatient (don't think of a white elephant on a stool...dammit!). I'm assuming you have a warning about the length of time the calculations may take before they actually submit it (Warning - your calculations may take upwards of an hour (3 days, whatever). Don't close the window, but you may open a new window and gently browse while we chunk away for you.)
Can you run the calculation on a different page?
In terms of the underterminate indicator - are the calculations ordered at all (or can they be ordered?) You could display part of the calculation to the users so they know something is happening. Like installing software - thousands of libraries flash by, the user doesn't necessarily know what they do, but they know something is happening. If ordered, they may be able to ballpark about how much longer it would take.
I suggest you read a Technical Report from Carnegie Mellon's Software Engineering Insitute called "Supporting the CANCEL Command Through Software Architecture" that goes into a lot of the ins and outs about what to present to the user and how to implement it in software. There are also citations in the report to the research that supports the users' needs for a cancel in the situation you describe.
the first thing I was wondering was the fact that you mention that you can imagine that your users are more annoyed by it than you are, this seems like a perfect opportunity to go and figure that out, in the field :-)
I don't get why somebody would want to press the "cancel button", as there is, according to you, not much else they can do. There is some level of control added though, but to what purpose? I expect that one does the calculation, because that's his goal for that day.
Anyway, if the user could do anything else, you could consider putting it in a visual queue or something, so that the user may continue doing something else while he can check and see the progress of that calculation (in the upper corner for instance).
Something you should do, is warn the user that executing that action will take a very long time to calculate and that they won't be able to do anything else in the meanwhile.
You could also try to give an estimation of how long the calculation will probably run, and put the estimated countdown under the spinner. But in the end, it will always be more qualitative to figure out the time it will last. One thing you should than take into account, is the fact that it should simply move, eventhough it might be slow, some movement is better than none.
Sources:
