unity-design team mailing list archive

[Mark Shuttleworth <mark@xxxxxxxxxx>]

On 22/04/10 21:46, Jim Rorie wrote:
>
>> Jim Rorie wrote on 22/04/10 01:42:
>>     
>>> I have been silent on the update manager issue in the hopes that a sane
>>> solution would present itself.  It hasn't.  Now you are forcing our
>>> hand. So I submit.  What do you intend to do to resolve that fact that
>>> the update manager pops down on the desktop like the old X-10 web ads
>>> that we all utterly despised? :/
>>> ...
>>>       
>> Primarily, simplifying the alert.
>> <https://wiki.ubuntu.com/SoftwareUpdateHandling#alert>
>>     
> But you are still talking about interrupting work flow or confusing the
> user with a with a pop-down that they didn't initiate.

Only in the following cases:

1. There is *a critical security update* that they really should
install. There are few things that are worth interrupting someone's
daily routine for, but this is one of them.

2. There are general updates that have been waiting for a reasonably
long time to be installed.


>   Simplifying the
> dialog doesn't solve the problem.  The asynchronous nature of the dialog
> is the crux of the problem.
>   

In this rough and tumble and highly connected world of fragile hardware
and software, stuff happens, and it happens asynchronously. Your hard
drive might be about to fail. Your machine may be vulnerable to a major
attack. Under some of those circumstances, it really is appropriate to
interrupt the user, because the consequences of them not dealing with
the issue are severe.

I appreciate the desire to defend the users flow. That's a value we
share. But being dogmatic about that won't get the best result. We
should be sparing about interruptions, so that when we do them, people
pay attention. And we should be very careful about the message we
convey, so that we minimise the interruption and maximise the chances
that people will do the right thing.

That's what MPT is arguing for. Your response is "the crux of the
problem is the asynchronous window". But you're missing the point that
the underlying condition is both serious and asynchronous.

> Plus, as I pointed out several months ago, this is a HUGE security hole.
> Passwords should only be given in response to a user initiated
> operation.  Asynchronous dialogs that ask for passwords are a very bad
> precedent for a secure O/S.
>   

Best we get those finger-swipe gadgets working, then :-)

Mark

Attachment: signature.asc
Description: OpenPGP digital signature