[Bug 215126] Re: update-manager shouldn't use modal dialogs
Adolfo Jayme Barrientos
fitoschido at gmail.com
Fri Sep 7 08:43:06 UTC 2012
update-manager (1:0.165) quantal-proposed; urgency=low
* Implementation of "update on start" feature from spec
* Use a single main window that changes instead of having modal dialogs
* Implement several special-purpose dialogs like "No updates" or
"Dist upgrade needed" accordingn to the above spec
* Split out release upgrader code and DistUpgrade module into a separate
* Drop python-update-manager, as it is unused
- Add dep8 tests
** Changed in: update-manager (Ubuntu)
Status: Confirmed => Fix Released
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to update-manager in Ubuntu.
update-manager shouldn't use modal dialogs
Status in “update-manager” package in Ubuntu:
Binary package hint: update-manager
update-manager currently uses modal dialogs for everything except the
main list-of-updates window. This is very bad from a usability point
Conceptually, the only defensible use of modal dialogs is to demand
the user an answer without which the program cannot continue, and only
in response to an “abnormal” situation. The only example in network-
manager where this would be acceptable is when an critical error
occurs during the update. (Note that not _all_ errors must be
displayed like this.) Any other use means the work-flow of the
application is badly designed.
Practically, the modal dialogs cause many usability problems beyond the conceptual jarring:
1) No input can be given to the main window, including window-manager commands. For instance, if the main window is maximized when an update is started, it cannot be minimized or moved until the end, except with a global "show desktop" command. (Also, if the window is in full-screen mode, as I often leave it, the panel—where the show desktop button usually is—might be hidden and unaccessible.) Note that this can be doubly annoying in small-screen cases, like a PDA.
2) Some window managers sometimes place modal windows below the main window. This can make the program completely unaccessible.
3) If the dialog somehow happens to arrive somewhere different than above the main window (dual-screen is the likeliest case, but not the only possibility) it can be very non-obvious why the main window is in the “inactive” state.
I propose the update-manager be switched to a “workflow” system,
similar to how wizards work:
a) Don't show the modal dialog with the "Starting update manager"
progress bar. It doesn't ask the user for anything, so it needn't be a
dialog, nor modal. Instead, put a progress bar at the top of the main
window (or just replace its content with the progress bar).
b) Asking for the password is necessarily a global-modal for security
reasons, that can't be avoided.
c) Don't show the “downloading” progress bar in a dialog. It doesn't
expect user info (canceling is exceptional) so it needn't be a dialog.
Also, it can display lots of info (if the user wants per-file progress
info), so a small window is not very useful. Instead, switch the main
window to a “downloading” page, as a wizard would do.
c') If a non-critical download error occurs (e.g., some packages
couldn't be downloaded, but the install might continue), don't show a
dialog. Instead, ask the user if the install should continue. (Replace
the progress bar with the question; leave the download details
accessible as before.) Otherwise continue to the next step
d) Don't show the “installing software” in a dialog. The same
arguments apply as above. Use a different page to show install
progress, with the details below.
d') Don't stop for noncritical errors.
d'') Don't return to the first page when the install is done, even if successful. (1) there usually is nothing interesting there, since we probably already installed everything and (2) there is often something interesting in the install “terminal”, we should allow the user to look at it at leisure. Provide a big fat warning message if there were errors, but don't put up a dialog. Just put buttons for exiting and returning to the package list.
To manage notifications about this bug go to:
More information about the foundations-bugs