Is there any good UX justification for disabling the minimize button, but not the maximize or close buttons?

I notice that Eclipse (the IDE) has several dialogs that do this, and there are questions on other StackExchanges about how to achieve this behavior.

The 'Check for Updates' dialog in Eclipse, illustrating a disabled minimize button

My question is, in what case would this be desirable? Why would a designer or developer not want the user to minimize their dialog (assuming a modal dialog, this would minimize the application itself as well).

In the Eclipse case, the "Run in Background" button gets the window out of the way, but I do not think this is a good substitute for disabling the minimize functionality.

I understand there might be good reasons for disabling the maximize button, and I believe handling the close button should be treated the same way as the "cancel" button.

But why disable the minimize button?

  • 1
    Isn't 'Run in Background' the same as minimize in this case? I think the design is a little bit inconsistent in this case, because Cancel seems to have the same function as the [ x ] button. It is interesting that they didn't disable the maximize button.
    – Michael Lai
    Commented Mar 19, 2015 at 22:39

2 Answers 2


I think in this case disabling the minimise button is a good idea.

  • "Run in background" does not minimise the window, it actually closes it, even if the operation keeps going in background. The window can be shown again by clicking somewhere bottom-right (if I remember correctly).
  • The minimise button is not supposed to close a window, but just to minimise it on some sort of taskbar. Supposing it wasn't disabled, giving it the same meaning of "Run in background" (i.e. basically closing the window) would be inappropriate.
  • On the other hand, allowing a standard minimise operation for that window is confusing, because then you have a third behaviour the meaning of which is uncertain (the window is shown: the operation runs in foreground; the window is not visible: the operation runs in background and I can make that window reappear by clicking somewhere; the window is minimised on the taskbar: huh?).

Anyway, it is a very unusual dialog, in a particular application that is designed for developers in the first place, developed around a technology (Java) that hardly looks 'native' in many cases. I wouldn't be surprised most UI choices are purely random or convenience-driven.

  • 1
    Although disabling the minimize button is perfectly possible in native Windows applications (so is not an artifact of the "non-native" Java), and Eclipse is using the native look and feel, I felt this was the best answer given the amount of detail. It still bugs me that there doesn't seem to be a standard UX practice for this (this is seriously the only application I can ever recall seeing that does this) but I guess it's just one of those quirks of Eclipse. Commented Apr 8, 2015 at 19:31

I find that you typically run into this scenario when the parent window that created the dialog window is waiting for information or workflow from the child window.

Therefore, if the user minimizes the child window, and can't find it for whatever reason, the entire app is basically stuck. This prevents them from minimizing it, and keeps it in their face.

  • Interesting idea, and definitely something to look out for on non-modal dialogs. Although I have never seen this behavior in modal dialogs (at least on Windows); in my experience, if you minimize a minimizable modal dialog, it minimizes the parent window as well (and, conversely, if you restore the parent window, the modal dialog reappears also). Commented Mar 23, 2015 at 14:09

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.