[TriLUG] different versions of 7.2 for sale]

Brent Fox bfox at linuxheadquarters.com
Tue Oct 30 21:35:42 EST 2001


On Tuesday 30 October 2001 07:36 pm, ilan volow wrote:
> 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.

Yes, some of these issues have been fixed in 7.2.  For instance, the user 
entry screen was a little confusing.  We have replaced it with something a 
little more familiar to other user entry programs.  The bootloader screen is 
currently confusing...this is slated for a makeover for the next version.  I 
would like to see your entire list of problems.  If you could open a bug in 
Bugzilla with your recommendations, that would be great.  That's where we 
keep track of the RFE's (Requests For Enhancement) that we receive.

By the way, the partitioning has been redone for 7.2.  It now uses all pygtk, 
with GNU/parted as the backend instead of libfdisk that was used in the past. 
The partitioning stuff isn't perfect, and it isn't harnassing all the 
features that GNU/parted provides, but having it all in Python gives us a 
much better foundation to work from in the future.  It is so much easier to 
develop and debug in Python (at least in the installer).  

>
> 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.
>

Yes, GtkList probably isn't the best choice there.  GTK2 will give us a 
better set of widgets to choose from.  It's great for us to have issues like 
this pointed out.  We do our best to come up with a good interface, but none 
of us has formal training in interface design.

>
> 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.
>

The non movable window is due to the fact that we aren't running a window 
manager in the installer.  That was a conscious tradeoff we had to make in 
order to keep our memory footprint down.  Doing a good partitioning tool is 
hard, and we need to make ours better.  It's also challenging when you 
consider that a lot of our enterprise customers are installing on machines 
with lots and lots of drives (70 or more).  Creating a partitioning tool that 
scales to that level but that is also easy to use on single disk workstations 
is not easy, but we're working on it.

>
> 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

Thanks for your comments, IIan.  These are the kinds of things I was hoping 
to hear when I originally asked the questions...specific areas that we could 
improve upon as opposed to vague suggestions about colors, themes, and the 
like.

Cheers,
   Brent



More information about the TriLUG mailing list