Update/install experience

[Paul W. Frields]

At FUDCon, Christopher Aillon and Jon McCann gave an interesting talk
on the Fedora software update/installation experience.  Bill
Nottingham and I were present, but given that other Board members have
had questions about this talk, I wanted to bubble this topic up for
some more attention.  I'm not sure how many other Board or FESCo
members were in attendance; there were many compelling talks at FUDCon
from which attendees had to choose.

https://fedoraproject.org/wiki/Desktop/Whiteboards/UpdateExperience

I invited Jon to come to this week's Board meeting to basically give a
slightly compressed version of the FUDCon talk, and for us to discuss
how the ideas in that talk might impact groups across Fedora like QA,
rel-eng, packagers, and others.  The point of this meeting is for
Board members to ask questions about, and understand, the whiteboard
and its implications.

>From reading the whiteboard, there's a decent amount of overlap with
some of the efforts to improve Rawhide.  Currently I think those are
limited to making Rawhide more regularly installable, but we shouldn't
avoid thinking about how to make Rawhide more regularly *usable* too.
Christohper Aillon had also posted some thoughts earlier about the way
the Mozilla sheriffs process results in a more usable nightly tip for
products:

https://www.redhat.com/archives/fedora-advisory-board/2009-October/msg00100.html

Paul

----- Forwarded message from William Jon McCann <william.jon.mccann at gmail.com> -----

Hi,

On Fri, Oct 16, 2009 at 1:57 PM, Tom "spot" Callaway
<tcallawa at redhat.com> wrote:
> On 10/16/2009 01:43 PM, William Jon McCann wrote:
>> Hi Spot,
>>
>>>From an experience design perspective, here is the way I think it should be:
>> https://fedoraproject.org/wiki/Desktop/Whiteboards/UpdateExperience
>>
>> This set of requirements came out of discussions with members of QE,
>> rel-eng, and Desktop.
>>
>> Comments?  If we can agree on these goals then we just have to figure
>> out how make them happen.
>
> Jon,
>
> This document... is a bit confusing to me honestly, because I'm not sure
> that the terms used are defined effectively. What is a "System
> Component"? When you refer to "the app they are using", are you talking
> about PackageKit? Yum? XChat?

A System Component at least to first approximation is anything that is
not an Application.  An Application is something like Firefox.  A
System Component is something like upstart.  A rule of thumb may be
that if we want something to have an identity then it is very likely
an App.  I realize that this is a very subtle distinction for many
engineers.  However, there is a very fundamental difference for users
(and therefore for experience designers).

> You mention integration tests, but provide no further vision there.

Yeah hopefully the people that will be interested in doing this will
have more input there.

> I also tend to disagree with specific points, such as:
>
> * System updates may only be deferred for a short time after which they
> will be installed automatically.
>
> (I don't think we ever want to force updates down our users throats, as
> well intentioned as we may be. Then again, I might be confused because
> you seem to differentiate between "System updates" and "Application
> updates").

Yes, realizing the difference between System updates and Application
updates is key to understanding this.

> It sounds very much like you are advocating a "Service Pack" model, and
> I'm not sure that is functionally sane or even desirable.

No, it is not the same as a service pack really.

> Then again, I could be reading this wrong.
>
> I think that in general, users only care about updates when they break
> something. I'd rather focus on improving the quality (and decreasing the
> quantity of) our updates than spend a lot of time worrying about
> bundling and delivery times and locations.

Hmm, I probably didn't do a very good job getting the point across in
that page.  I'm trying to describe the experience we want to provide
from a design point of view.  I don't think you have a chance of
improving anything until you can consider an update to be more than
just a new package.

Jon

----- End forwarded message -----