Updating the update system
Let's talk about automatic updates.
Recently there were words had over the fact that we force-update Orynt3D automatically. It's not a complaint we receive regularly, but there were enough good points brought up that we thought it was worth reevaluating that decision and if there was a better option for everyone.
Since one of my favourite activities is mulling things over (for our non English native speakers: this is thinking and reflecting on an idea), I wanted to spend proper time with Rob and Steve and give this the attention it deserved.
What makes a software update?
The first thing we looked at was actually what is a software update made of. We found there were 3 parts to it:
- How the update works - this is the pre-install experience. Are there documents about how the update works to allow people to understand if this is something they're okay with?
- Update information - this is the in-app update information. Is an update available, what will the update change about the system?
- Update action - this is the in-app update experience: How it downloads and when it installs.
Although the current model of automatic updates is good from a business perspective to keep the community on the same version and ensure that new features get maximum exposure, it's not great from a customer perspective, since:
- There's no documentation to make a decision to install. There's an implicit decision to install and accept the updates.
- When a new update is available, information on what's about to get changed isn't visible before it gets changed.
- An install happens invisibly, preventing the customer from making a decision on when that occurs.
Informed consent as a better experience
We spent time and energy thinking about data usage and collection due to GDPR, but the update system didn't fall under the same scrutiny. Informed consent was the right right model there, anad we think it's the right model here too.
For the data usage, informed consent is part of first-run and in settings, so you can always turn it on when you first install, and change your mind later.
To address the key points above, we applied the same "informed consent" mental model and are replacing the current update/version area in Settings with two things:
- A check box: "Check for updates on app start" (enabled by default, never automatically reenabled)
- A button: "Check for update now" (always available, but probably used less if you've ticked the box)
They both perform the same action which is to reach out to the update server and check for a new update. Obviously one of them is automagical, the other is manual.
If an update is found, we will show a popup with the next version's release notes with 3 choices:
- "Download now & install on next restart", so you can keep working without interruption (this is to prevent having the app close & restart mid-flow if you're autochecking but have only just opened it up)
- "Hide this window", so you don't have to make a decision now ("snooze" if you're autochecking or "okay, good to know" if you're manually checking)
- If autochecking: "Hide this window until the next release", so you leave autocheck on but not have it actually download anything or nag you until the next release ("skip release" if you're autochecking)
We're planning on disabling the existing autoupdate mechanism and replacing it to help you to actively choose a next step.
This change will also remove the post-update release notes screen.
If you've ever used Cyberduck, we drew some inspiration from there, but wanted to improve on the experience of download & install to not interrupt your flow.
The combination of these changes means we don't have to hide downloads behind terms of service agreements, we make it clear what's about to happen at the moment that it becomes important to know, and you get to make an active decision about how you wish to proceed, and when, but it still encourages user engagement.
Since we can't go back in time and retroactively add this method of updating to the prerelease version that's out in the wild now, we'll be implementing this for the next prerelease after 0.12.0-307. The first time you'll see it in action will be the prerelease after that. This may mean the next prerelease comes a little later than we'd otherwise planned while we thoroughly test the new update process. After all, can't fix the update process with an update if the update process is broken ...
Until then, happy organising everyone!