"What is the Fedora Project?"

William Jon McCann william.jon.mccann at gmail.com
Fri Oct 16 19:06:49 UTC 2009


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




More information about the advisory-board mailing list