I'm doing a usability evaluation of an application and according to Nielsen's heuristics one of the points says:

User control and freedom Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.

I'm wondering if that applies to downloads too. I know I can pause and cancel downloads on browsers. But I'm not sure it applies in a specific case, it feels wrong. How should I evaluate whether the user should stop a download?

  • Are you asking about this in the context of the web, or for a standalone app? If a user is accessing your application in a browser, I'd say that the browser controls for canceling a download are sufficient.
    – octern
    Commented Dec 31, 2015 at 17:27

3 Answers 3


Downloads should have the capability to be cancelled at all times EXCEPT if the cancelling of said download will cause some sort of corruption such as an operating system update (although ideally there should be rollbacks or other preventative measures to prevent corruption) or if the download is mandatory such as a security patch, you don't want to give users a way out of it.

Users desire a sense of control and not giving them a way to control things such as cancelling unwanted downloads will be a bad UX. This falls under Shneiderman's "Eight Golden Rules of Interface Design" rules 6 and 7:

6. Permit easy reversal of actions. This feature relieves anxiety, since the user knows that errors can be undone; it thus encourages exploration of unfamiliar options. The units of reversibility may be a single action, a data entry, or a complete group of actions.

7. Support internal locus of control. Experienced operators strongly desire the sense that they are in charge of the system and that the system responds to their actions. Design the system to make users the initiators of actions rather than the responders.

  • 2
    +1, nothing to add, this is a nice answer
    – Devin
    Commented Dec 9, 2015 at 18:40
  • 1
    great reference
    – Fattie
    Commented Dec 31, 2015 at 14:46
  • 1
    +1 always cancel if does not cause harm to any existing software
    – m1k3y3
    Commented Dec 31, 2015 at 19:21

If the user decides that they do not want the downloading item any more, are there any potential negative / inconvenient consequences to it continuing?

For example:

  • User loses time waiting for unwanted long download to finish.
  • Large file that will waste disk space or other system resources (memory, processing power).
  • Download wastes bandwidth, or causes user to incur extra data charges / waste data allowance on a mobile device.

I don't know what your specific use case is, but as a rough guide I think that if any of the above apply then you should allow canceling of downloads.


I advise caution. For example: recall in the old old days we'd compress everything. Nowadays it is totally pointless compressing anything, since both storage and bandwidth is so fast. (Of course, very very large things may still be with compressing, but that's just an obscure detail.) For a while there, there were still "legacy looking" systems that infuriatingly compressed everything, which was just completely pointless and silly.

In a similar way...

I'd perhaps suggest that for small files, today, it is completely useless allowing the user to "cancel a download".

This is worth considering.

A critical point is that, anything like a download should absolutely be in the background these days.

Here's a critical point. Consider the act of visiting any web page - as you do 1000s of times a day. In every case, it is 'downloading' files - the images.

Note that, of course, those examples of "downloading", there is no opportunity to 'cancel' the download. (There's no little individual menu system, with cancel buttons, for every single one of the dozens of images you download every single time you go to any old web page!) That does even apply to quite large images.

Another example is downloading stuff with your email: most emails clients "just do it" for anything under a few MB. You're only asked if it's bizarrely large.

So, while it might, at first, seem surprising that I recommend "Do not give the user any option to cancel a download, and don't even make the process visible", when you think about it this is becoming the way that computers work.

Note! ... in my opinion ...

An absolutely critical aspect of doing UX is we have to "Keep up with the times". An example I always give: remember (if you're old enough) in ancient history every action on a computer would be accompanied by a (now seen as humorous) confirmation dialog. "Do you really want to save the file?" "Did you actually mean to hit the OK button?" "Are you sure you want to quit the program?" These now seem ridiculous or very quaint. Because new paradigms emerged, such as always-undo, and there-is-no-quit-concept-on-phones, and so on. (Of course obviously there are some exceptionally unusual situations where you still use OK boxes ... "Do you truly want to turn off the nuclear generator?" and conversely there are a few lingering examples where UX designers have, ridiculously, not yet got rid of them. A good example is, even on the latest (end of 2015) OSX, when you "shutdown" there's an idiotic "Are you sure?" box. These days it takes only a tiny amount of time to shutdown/restart, so even if you just shutdown accidentally - who cares? Every single time you see that OK? box it's annoying and silly! You have to explain to young people that it used to take forever to restart a computer, and that's the reason such boxes used to exist.)

But indeed there was a period of 10? years where you'd see software "so old fashioned" that it still included ancient styles "OK?!" dialogs. (Indeed, on say my Mac I sometimes play a particular ancient game, one of the versions of Rail Tycoon, and it has old-old school "Do you really want to quit?!" OK boxes - when you see that on ancient software it brings a nostalgic smile.)

So any event, regarding my "Remember OK boxes?" example, as UX we have to be extremely careful to "move ahead" and not get caught in UX paradigms that have become "humorously out of date".

So, I suggest caution when thinking about this "cancel downloads" issue.

As I say, from the "web page images" example we have indeed entered an era where non-huge downloads are just "invisible" to the user - it's surprising but that example makes one realise this.

  • I don't disagree, but I want to point out that "these days" it still takes my mid-2012 macbook with a magnetic hard drive a good 15 minutes to shut down and restart, including restoring state on all my programs and web pages. The author sounds like they may be at risk of following the maxim "keep up with the times" too far, and failing to observe the maxim "design for the devices your users use, not just the ones that you and all your friends use."
    – octern
    Commented Dec 31, 2015 at 17:25
  • btw, where is the quote from?
    – octern
    Commented Dec 31, 2015 at 17:25
  • Sorry, I inappropriately used the "quote" feature to emphasis my own paragraphs! :) BTW it's surprising it takes 15 mins to restart an old Mac! (It occurs to me for literally that interface, it would be trivial for OSX to guesstimate that, normally there's no need for an OK!? box, but for old hardware it should display an OK!? box.)
    – Fattie
    Commented Dec 31, 2015 at 17:28
  • That definitely emphasized the section and made me more likely to read it. It's a shame they don't offer the quote and highlight affordances separately.
    – octern
    Commented Dec 31, 2015 at 17:33
  • I like your solution and I wonder if Apple does have anything like that going on in the background. It would fit their model of supporting older devices without forcing them to run an old OS.
    – octern
    Commented Dec 31, 2015 at 17:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.