unity-design team mailing list archive

[Jonathan Marsden <jmarsden@xxxxxxxxxxx>]

Scott Kitterman wrote:

> This is about how updates are presented and some orthogonal to when/if 
> users should be asked.

Well, yes, except that if many users can (probably after an initial
notice that their system will be automatically updated) get updates
automatically and regularly with no user interface at all, then that is
the simplest, most logical and most efficient presentation (user
interface) I can imagine for this task :)

In this scenario, most or even all updates are in a sense not
"presented", they just happen!  BTW, I am "eating my own dogfood" on
this -- my primary desktop machine is set up to use unattended-upgrades
for both -security and -updates, and the only 'surprise' I've had is the
Firefox weirdness when you update it underneath a running copy.

A word processor needs a UI.  A web browser needs a UI.  An IRC client
needs a UI.  Updating your system does not need one!  I submit that "no
interface" is a perfectly valid proposed user interface for this
particular (repetitive and boring) task :)  Indeed, if it can be done
well, I think full automation very clearly qualifies as "what most
people would find useful".

> Every time you update a working system there is a risk.

Agreed.  Every time you leave a system un-updated there is also a risk.
 Were it not so, leaving systems un-updated would be perfectly fine, and
there would be no reason for this whole debate about how to get more
people to keep their machines up to date :)  So this becomes an issue of
whether, for a given update or set of updates, the risk of leaving a
machine un-updated is higher than that of it receiving those (automated)
updates.  Risk assessment.

Asking an end user to assess whether updating (say) their IRC client (or
their SSL library, or their kernel!) is more of a risk than continuing
to use the version that came with their Ubuntu CD is *really* not
friendly, and is not something the average end user should be expected
to do -- yet this is in some ways *exactly* what we do every time we
present the user with a list of packages and ask if it is OK to
update/install them!  You or I may be in a good position to make such
assessments, but many (perhaps a majority of) Ubuntu users are not.

Logically, this kind of update risk assessment should be done
considerably further "upstream" than at the individual end user level.

> If we want to deliver updates automatically (I think this merits serious 
> consideration), then we will need a new scheme to mark updates as 
> appropriate for automatic delivery.  These would also probably need some 
> additional QA to reduce the risk for users installing the update with no 
> chance to consider if it would be a good update for them.

This sounds good to me; rather than a binary "automatic or not" value,
we could provide some sort of "risk level" scale (probably not named
"Risk Level" (marketing folks might be upset by this!).  Maybe invert
the scale, and do it more like "Auto-Update-Suitability: 95" on a scale
of 0 to 100, or something) for each package update.  This lets "power
users" willing to take more risks than you are set up their (desktop?)
systems to automatically include more updates that you would choose to.
 Or maybe to configure their laptop system to automatically use a higher
tolerance for update risk when at home/work on a wired network than when
travelling and using a 3G wireless card network connection, even?

Flights of fancy: Does the suitability for auto update usually increase
over time after the release of the update, since others have updated
with it and no showstopper bugs have emerged -- if so, is it useful to
model that aspect of suitability somehow in this overall approach?  Do
we want multiple suitability values per update, for different machine
roles (server/desktop/laptop)?  On a server one might even be able to
configure things to only auto update after making and verifying a full
backup, or something... but that is probably taking this too far?!

Bottom line: I think the discussion has been focused on how to regularly
notify users so that they will do something they don't *want* to deal
with (downloading and applying updates), but not so they are distracted
and annoyed by these notifications.  Focusing on how to get the task
done without needing any user notification, action, or confirmation
seems more useful, and much more of a real step forward.

Jonathan