unity-design team mailing list archive

[Alex Launi <alex.launi@xxxxxxxxx>]

On Wed, Jun 17, 2009 at 12:51 AM, mac_v <drkvi-a@xxxxxxxxx> wrote:

> First of all you painted a story saying:
> devs had update ready in the night and the user got the update in the
> morning! That is misleading !
>

It was supposed to be an allusion to some kind magic entity like god, Santa
Claus, or the easter bunny. I'm sorry if you're a non-native speaker and
read that literally. I didn't consider that some people wouldn't get humour,
and mistake my jokes for proposals. The story was supposed to be playful.


> BUT assuming that the update state was checked before:
> 1: Why wait? What is the advantage in deferring the update?


Because we have a problem with how updates are presented. We need to find a
way that makes updates not a chore but a fun task and makes sure the user
ACTUALLY installs them, rather than just ignoring a notification icon.

>
> 2: Why defer a security update to the next boot?


Why defer it for 2 weeks while the icon sits idle. For high priority updates
we may want a mechanism to update the user, this is ok in this case because
it's not a normal update, it's high priority and must be addressed now. This
is similar to the actionable notification debate.

>
> 3: What about users who do not shutdown the systems? no updates for them?


Theyre essentially the same as the autologin people, we say "have updates
been here for <n> days, now we need to show a window because they havent
been to a login screen

>
> 4: What if the [non-security]update to a program is deferred to the next
> boot and the program crashes, causing work loss?


What? This isn't a real case. The bug causing the crash existed before the
update was available, the user already know this app is buggy. Or, the user
hasn't ever experience the bug before and may not suffer from it at all.
It's possible the bug might strike in the day before installing the patch,
but it more likely would have already happened or isn't going to happen. So
basically this potentially /prevents/ issues. Currently if you update
firefox, a lot of stuff in XUL breaks due to its lazy loadig


> If the propsal for the above is that the system waits [x hrs/days]
> before reminding the user of the update.


Do you mean notifiying updates havent been installed or something? Or Is
this a follow up to 4. If it's a follow up to for you can skip the follow
ups with a "im not going to answer because 4 made no sense".

5: what is the use of having updates scheduled for boot?


To help ensure they actually install updates.


> 6: what is the acceptable time limit to defer an update?[the update may
> be critical to the program the user needs, which has been crashing,
> would the user want this update immediately?]
>

This is irrelevant to the discussion and is an implementation detail.

>
> >
> > You DO get on with your work, you just start the update process first,
> > and then move on.
> >
>
> What you need to remember is that work may involve net browsing, so
> speeds are hampered during the work. The user might mot have planned on
> using the net , but needs to browse for research , so his only option is
> to cancel the on going update?
>
>  also if the user is allowed to work and it prompts for reboot, isnt
> that a break in work flow? he may choose to do it later , but the main
> purpose of the proposal does not achieve its goal .
>

This is what we do now so this isn't actually a regression. If you read
story (for what, the 3rd time?) you'll see that the user is NOTIFIED that
this update will require a reboot. So the user is already aware that in a
short time theyll be aksed to reboot, they can chose to wait and go make
some tea or proceed with the knowledge that a reboot will be necessary soon.





-- 
--Alex Launi