[TriLUG] different versions of 7.2 for sale]

[ilan volow]

> From: Brent Fox <bfox at linuxheadquarters.com>
> To: trilug at trilug.org, "Vestal, Roy L." <rvestal at rti.org>,
>         "'trilug at trilug.org '" <trilug at trilug.org>
> Subject: Re: [TriLUG] different versions of 7.2 for sale]
> Date: Mon, 29 Oct 2001 20:32:49 -0500
> Reply-To: trilug at trilug.org
> 
> Hi Roy,
> 
>     I work for Red Hat on the installer (and various config
> tools), and I'm 
> curious as to what people like better about the Mandrake
> installer.  At the 
> end of every release, I do a comparative analysis on the
> installers for many 
> other OSes (various Linux distros, Solaris x86, various
> Windows versions, 
> etc.) to try to determine areas in which we are lacking.  I do
> this because I 
> want our installer (and our OS as a whole) to be the best one
> available.
> 
> Specifically, how is Mandrake's installer easier to use?  How
> does it help 
> you better understand what you are installing?  
> 
> So I guess the question isn't just to Roy, but to everybody:
>   What can we do to make the Red Hat Linux installer better?
> 
> 
> Cheers,
>   Brent


Like I said in previous posts (look at the Trilug List archive),
there are some very bad designs (from a HCI perspective) in
Ananconda. Stuff that doesn't work the way real users do, things
that work inefficiently, and things that could confuse a user
into making a less than optimal choice (in 7.0, the X setup
dialog was so badly designed that it could confuse a user into
picking a setting that would not allow them to boot into X!).
It's really stuff like using the wrong widgets for a certain set
of choices, or laying out widgets in a way that is inconsistent
or creates a user expectation that is not matched with the
expected action. All in all, I counted about 20 of these
problems in 7.0, one or two of which were fixed in 7.1. Most of
these problems are fairly simple to fix with the
addition/subtraction/modification of a few lines of pygtk code
(though the partitioning part, I believe, uses C. Might require
a few more). I will give you two examples of these kinds of
problems. They are from 7.1, and I haven't yet had a chance to
install the 7.2 ISO's I burned a few days ago. Maybe (I hope)
these problems have been changed in 7.2, so forgive me if these
problems have been squashed in 7.2. 

1. In of one of the anaconda partitioning screens, "allowable
drives" uses a GtkList. A List widget is a very bad choice for
this set of options because it is not immediately apparent that
you click on one or more of these options to select stuff. 
Lists widgets can have either rules for mutual exclusivity
(selecting a single option) or allow multiple selections. A user
might see the List of allowable drives and think that he/she can
only choose one of them (assuming they even recognize it as a
list widget). Multiple selection can only be discovered by
experimenting with the mouse. Forcing the user to experiment
with the mouse to discover a widget behavior at best adds extra
time to the user's task, and at worst leads to the selection of
dangerous or unwanted options. I have no idea why Red Hat ever
chose a GtkList for "Allowable Drives". Using a checkbox for
each allowable drive would be far better, as users familiar with
previous GUI's (MacOS, windows, etc) would instantly recognize
the checkbox as implying an optional selection that can be
toggled with a mouse click. Replacing the "Allowable Drives"
GtkList with something like a GtkVBox full of checkboxes would
be a good start.


2. The Anaconda partition editing dialog design is flawed. It's
modal and non-movable. Any usability person worth his salt (in
other words, those who don't work for Microsoft) will tell you
that modal dialogs, especially those you can't move out of the
way, are a Very Bad Thing (except in a few select cases). They
are Very Bad Thing because they often prevent a user from
accessing information *outside* the dialog a user that is
required for making optimal choices *inside* the dialog. The
partition editing dialog for Anaconda obscures the information
about the other partitions that have already been
created/edited, which happens to be located *outside* the
partition editing dialog. Why is this a problem? Because a user
cannot make choices about the partition currently being edited
in the context of the existing partition information. If you're
currently debating how much disk space to assign to /home, it
kind of helps to know how much you've already assigned to /usr.
Or whether you've yet created a /usr partition. The current
Anaconda partition editing dialog forces a user to close the
modal dialog, get the information about existing partitions,
remember/write it down on a piece of paper, then click the
button to bring the editing dialog back up and *then* edit the
partition. This is highly inefficient and more than a little
frustrating. An immediate solution would be to make the dialog
non-modal, or perhaps create an area of the dialog that contains
information and statistics on the existing partitions and disk
space. A more permanent solution requires substantial redesign
of the whole partitioning interface, which really should be done
anyways. 


To an experienced linux user, the Red Hat installer is a
cakewalk because they can use their existing linux knowledge to
get around the most confusing parts of the installer. To some
one just staring out with linux, the Red Hat installer is like
walking through a Funhouse. With landmines. 

In all fairness to Red Hat, Mandrake also has its share of
problems like this. But the problems are somewhat less severe.
This is why people find Mandrake somewhat easier to install. 

--Ilan