Software Updates

Designs for the software update experience.

Goals

  • Update the full range of software - firmware, operating system, applications, add-ons.
  • Require as little interaction from the user as possible.
  • Don't consume bandwidth when it is potentially limited or costly.
    • Where possible automatically detect when bandwidth is limited/costly.
  • Prioritise important updates, particularly security updates.
  • Show details about updates prior to installing them. This is most important for OS upgrades.

Constraints

  • Checking for package-based updates is bandwidth intensive.
  • It's not always possible to automatically detect when on a metered/mobile connection.
  • Updates don't always have descriptions. When they do have them they're often not very good, and they're typically not translated.
  • Various things relating to update logic:
    • Reboot is required to install package-based updates, OS upgrades and firmware updates for the computer.
    • Peripherals can't be used while their firmware is updated.
    • Flatpaks need to be restarted after an update, in order to use the new version.
    • If a Flatpak runtime is updated, running apps need to be restarted to start using the new version.

Relevant Art

GNOME 3.26

  • Package-based and firmware updates: are automatically downloaded in the background. They can then be manually installed (requires a restart).
  • OS upgrades: are automatically checked for; then manually downloaded and installed.
  • Application updates: automatically checked for; manually installed.
  • Has a hidden "download-updates" settings key. When this is false: FIXME.

Android 8.0

  • Apps are auto-updated by default. When auto-update is on apps are automatically downloaded and installed (installation happens in chunks; app updates that are yet to be installed are shown in the Play Store app and can be manually installed).
  • When auto-update is off, a banner is shown which encourages you to turn it on. Updates are automatically checked for and the user is prompted to download and install them.
  • OS updates require manual download and a separate manual install step.
  • Provides three settings for auto-update:
    1. "Do not auto-update apps"
    2. "Auto-update at apps at any time. Data charges may apply."
    3. "Auto-update apps over Wi-Fi only" (default)

There's also a separate "data-saver" feature, but that only seems to affect mobile data.

Discussion

  • How to handle a case where an update makes an application less sandboxed than it was previously?
  • When automatically updating software, it can be good to show what's been updated recently. However, in the Flatpak case we require that the app is restarted, which negates the need for this.

Technical notes on how updates currently happen:

  • Updates are checked for every 24 hours
  • If updates are found they are downloaded
  • Updates are only shown in the updates list once downloaded
  • The frequency of "updates available" notifications is limited (perhaps once every 4 days?), to avoid spamming the user
  • The user can perform a manual updates check
    • This blanks the updates view and replaces it with a spinner while updates are both checked and then, if found, downloaded
    • The view is blanked because some distributions are unable to resolve conflicts between updates (eg. 1.0 ready to be installed and 1.1 available to download)

The existing design doesn't show download progress for updates. The main reason for this is probably to try and make the behavior more automatic and less user-managed. However, there might be some reasons to show download progress:

  • When bandwidth is limited, updated shouldn't be automatically downloaded, but it should still be possible to manually download them. In this case, download progress should be displayed, and it is simpler to show it in all cases than only one.
  • It helps users to answer the question "why is software using bandwidth?"
  • If a user is going to be offline for a while, it enables them to check to see if any updates are in progress - they might choose to let updates finish.
  • It helps if a user knows about a new version of an app and wants to find out whether it is available or in the process of being downloaded.
  • It shows that Software is active and isn't broken.
  • In the future, automatic update downloads could be given lower priority than other network traffic. In this case, it might be useful to offer a way for users to accelerate/prioritise a download, in order to speed it up.

Tentative Design

Automatic update behaviour

Automatic update is used by default. It can be manually disabled from a setting and is automatically disabled for metered and mobile connections.

TODO: should there be a way to force automatic updates on mobile/metered connections?

https://raw.githubusercontent.com/gnome-design-team/gnome-mockups-software/master/updates-process-diagram.png

Mockups

Wireframes:

Updates list notes:

  • Updates are shown in a list containing five sections, each of which contains a different type of update
  • Clicking on row:
    • Apps > opens app details page

    • OS updates or firmware updates > details dialog

  • "Contains important security fixes" is shown for any update that's flagged as having security fixes.

Comments

See Also

Design/Apps/Software/Updates (last edited 2018-01-17 16:42:05 by AllanDay)