[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
    source package
  * Drop python-update-manager, as it is unused
  * debian/tests:
    - 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:
  Fix Released

Bug description:
  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
  of view.

  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 mailing list