Following on the work of bug 740720, we should try to disturb users as little as possible. Popping up an intrusive system dialog while they're in the middle of something is annoying. Instead, since the default behavior of the confirmation is to auto-restart after a timeout, we should try only popping up the confirmation dialog after the user has been idle for a while, let's say 10 minutes. Then, odds are the user isn't paying attention to the phone and won't notice the update process.
nsUpdateService.js is already using the idle service to decide when to show dialogs. Is there more you wanted here?
What does the current update service do?
If you look in toolkit/mozapps/update/nsUpdateService.js, line 3218, it appears to wait for a the IdleService to be idle for a period defined by a pref before showing UIs. ShowUpdateAvailable makes use of this function. I haven't tested the paths (we don't have a complete set of Update UIs in any case). This is just based on code reading.
That's a different screen than we want here. That's UI to tell the user that an update is available for download. What we want here is similar, but for a different usage: show the "Restarting to apply update in 10 mins, [ Delay ] [ Restart now ]" dialog after an idle timeout. This will happen after an update is already downloaded and ready to apply. There'll be followup work for the updatesavailable case when on a billed pipe, but not for this bug.
Jim: Status please? Thanks!
Assignee: nobody → jstraus
Status: NEW → ASSIGNED
blocking-basecamp: --- → +
blocking-kilimanjaro: --- → +
Josh, do we have designs for the UX facing parts of updates?
Renom if you think we can't ship a v1 without this.
blocking-basecamp: + → ---
Per IRC conversations with a few other folks, I think the best course of action if there is disagreement on whether this blocks or not is to do the following: - Move the blocking-basecamp flag to ? for re-evaluation - Indicate a rationale for why you disagree
blocking-basecamp: --- → ?
Where are we on updates from a UX perspective, Josh?
Whiteboard: [blocked-on-input Josh Carpenter]
I've posted a draft update process proposal to the following: https://wiki.mozilla.org/Gaia/System/Updates#Draft_process_for_atomic_Gecko.2BGaia_updates That reflects my current understanding of the technical requirements and constraints, plus some nice-to-haves thrown in for good measure. Abridged flow diagram here (minus some details, and the Manual update flows): https://wiki.mozilla.org/images/4/46/SystemUpdates_Flow1.pdf WRT to the specific question raised above, re: delays, the process proposes both Silent and Manual updates, and nuanced behavior behind each. For the Manual Install prompt (received by user once update download is complete, and the device in On and Unlocked), I imagine the simplest options would be "Now" or "Later", with the second deferring the update until the conditions for a Silent Install were in place (details here: https://wiki.mozilla.org/Gaia/System/Updates#6._Install) That's my first take on it, anyways.
Hi folks, by way of update, I'm updating the Update specs to incorporate feedback from Sao Paulo work week, and Marshall's work since then. The update will be posted to dev-gaia, as usual. FWIW, the idea in the current specs (here: https://www.dropbox.com/sh/23ri1b7tfr03qd4/tSbqoawnPT) is that pressing "Later", defers the reminder prompt until the next redularly scheduled poll. As per the dock, that scheduled check behavior is envisioned as follows: • By default, scheduled automatic update checks are restricted to WiFi or zero-rated connections only. • If there is no active WiFi or zero- rated connection at the scheduled check time, the check fails silently. • When the connection type changes to WiFi or zero-rated, the system checks to see if any scheduled checks were missed. If true, the system checks for an update immediately, instead of waiting until the next scheduled time. • User can set the frequency of scheduled update checks from the Settings within the App Update and System Update utilities. Nuances like these are designed to reduce both bandwidth, and user annoyance. I appreciate that time is running tight, though, so I can work with you guys to figure out what's feasible for v1.
This doesn't appear to be in the v1 update UX design.
blocking-basecamp: ? → -
blocking-kilimanjaro: + → -
Copying response from #744715: > This doesn't appear to be in the v1 update UX design. Au contraire. As per comment 11, automatically checking for updates (both for System and Apps) at a timed interval is essential to the proposed updates UX spec: https://www.dropbox.com/sh/23ri1b7tfr03qd4/tSbqoawnPT This should be blocking-basecamp + unless we want to switch to manual updates only for v1.
Blocking based on comment #13.
blocking-basecamp: - → +
Attachment #665740 - Flags: review?(fabrice) → review+
After talking w/ Etienne, we decided we should have a separate event for the apply prompt. This new patch also changes the behavior of the "wait" response. Instead of waiting a fixed amount of time, both the "wait" response and the initial apply prompt will now wait for the user to be idle for a fixed amount of time.
Attachment #666748 - Flags: review?(fabrice) → review+
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.