Confirmed users
716
edits
Gaia/System/Updates: Difference between revisions
→Open questions
| Line 71: | Line 71: | ||
* What is the sequence of events (eg: prompt user to restart device, whereupon install process runs?) | * What is the sequence of events (eg: prompt user to restart device, whereupon install process runs?) | ||
* Do we require the user to plug in the phone if battery is below X %? | * Do we require the user to plug in the phone if battery is below X %? | ||
** (sicking) This is somewhat technically doable, but a UX decision if we actually want to. What we can't do is estimate how good the battery is. I think an old "worn out" battery will fall much quicker in battery level than a new one. It's also hard to get a good estimate of how much battery is needed, but we can certainly require battery levels much higher than what's needed (say 30%). | |||
* What prompts do we present to user? | * What prompts do we present to user? | ||
* Do we have a rollback strategy for failed installs? Previous April discussion w/ cjones indicated no... | * Do we have a rollback strategy for failed installs? Previous April discussion w/ cjones indicated no... | ||
* What is time to install? Several minutes? | * What is time to install? Several minutes? | ||
* Can we avoid user friction by downloading silently, and only during periods of user inactivity? Would not want to slow down web browsing while update processed in background, for example. | * Can we avoid user friction by downloading silently, and only during periods of user inactivity? Would not want to slow down web browsing while update processed in background, for example. | ||
** (sicking) We don't have good mechanisms for giving lower priority or throttling individual channels in Necko right now. We technically could detect other downloads starting through and abort the update in that case, and then resume once we detect user inactivity. | |||
* How many reboots are required in the process? Previous April discussion w/ cjones indicated two. | * How many reboots are required in the process? Previous April discussion w/ cjones indicated two. | ||
* Do we provide link to changelog so user can review update details before installing? | * Do we provide link to changelog so user can review update details before installing? | ||
** (sicking) I think this is up to UX to set requirements. Seems technically feasible, but I'm not convinced it's needed given that in every instance we'll likely want to apply the update for security reasons. | |||
* How large are these updates? | * How large are these updates? | ||
* Do we check for available device storage before downloading? If insufficient, how do we mitigate? | * Do we check for available device storage before downloading? If insufficient, how do we mitigate? | ||
* If the user powers down the device while an update is silently downloading in background, can we resume download later on? | * If the user powers down the device while an update is silently downloading in background, can we resume download later on? | ||
** (sicking) Necko has the ability to download ranges, but this also needs server support. We certainly could require such support though. | |||
* How much user agency do we provide over installs? Can they defer? For how long? What affordances do we make for out of date software? | * How much user agency do we provide over installs? Can they defer? For how long? What affordances do we make for out of date software? | ||
* How can the user review the currently-installed version? From Settings? | * How can the user review the currently-installed version? From Settings? | ||
= Gecko Updates = | = Gecko Updates = | ||