Re: fundamentals of the gnome user interface

["Andrew S. Townley" <atownley informix com>]

Actually, this subject is addressed in great detail in a book I have on  
developing user interfaces (it's at home and I'm at work so I can't give you  
the particulars...).  Anyway, I think the concepts involved are definately  
worth considering and trying to figure out a reasonable way to included them  
in some form for the Style Guide.

This subject is also addressed very well in the book "Programming as if  
People Mattered".  The discussion in this book centers around a simple text  
editor which was created to be easy to learn and use.  The problem was, that  
it was *too* easy to use and users were quickly hitting the limitations of  
the product after only a few times using it.  The discussion then leads the  
reader to the concept of modes--which is another matter entirely.

The biggest problem I see with a large portion of the software I use on a  
daily basis--on a variety of platforms--is that applications either generally  
fall into two different categories.  The first category is the applications  
which make every task a Wizard interface or split 60 configuration options  
across four or five property sheets (tabbed dialogs).  These applications  
help the occasional user or the user who is new to the problem domain, but  
they lock the users who have a clue into using a paradigm which is  
counter-productive.

The second category of applications errs on the other side of things.  The  
simplest operations require you to fill in 6 different values on a giant  
input form which has no extra information about what you are trying to do to.  
 Only people who either a) wrote the application or b) have spent countless  
hours performing the same task or learning the problem domain have any chance  
of performing the task the correct way the first time.

I think that UI's in general, and GNOME in particular, needs to strive for  
some sort of balance between the two.  The down-side is that applications are  
slightly more complex because there will (and should) be more than one way  
to perform the same task, but the added benifits to all levels of users  
greatly outweighs the up-front costs of adding the features.  Expert users  
can use the "monster" form or a text editor to perform the task, but users  
who perform the tasks only occasionally can also be productive.  No one group  
is forced to suffer productivity losses in favor of another.  The end result  
is applications which actually get used (definately a big plus) and a  
more-or-less contented user base.  Unfortunately, applications which fulfill  
these requirements are kinda hard to come by.

The biggest challenge in develping software for the Linux/GNOME comumnity  
will be for application developers to address these issues successfully.  We  
also need to keep in mind that what makes sense to us, the developer or the  
"power user" might not make any sense whatsoever to the person who is seeking  
a viable alternative to Windows.  They might not even know or care about  
some of the features which are built into gnome to support or configure the  
infrastructure.  For a certain class of user, this is OK.  They should't have  
to care.  I think that some of the current gnome applications are doing a  
pretty good job of this, but I think that some of the others have a ways to  
go.

Basically, it boils down to providing the right tool for the right job.  OUR  
job as people who actually care about doing things *right*, is to make sure  
that we understand the problem domain completely and make the attempt to  
realize that what we take for granted may not make sense to someone else.   
The easier and more consistent we can make GNOME, the more people will want  
to use it.  The more people use it successfully, the more people will  
evangalize it and the more people will come to the GNOME platform with new  
development ideas or, like Netscape, an existing product.  All of these  
things can either kill it or make it great.  I think that we would all prefer  
to see the latter happen.

Perhaps the correct home for what we're talking about is both in the style  
guide and in the developer's guide.  Different aspects are more relavant both  
places.  The important thing is that people are aware of the issues so they  
are thinking of these things when developing the code.

Anyway, the short version is:  "I agree too."

ast

>Begin forwarded message:
>
>Resent-Date: 30 Oct 1998 15:15:59 -0000
>Resent-Cc: recipient list not shown: ;
>MBOX-Line: From gnome-gui-list-request@gnome.org  Fri Oct 30 10:15:59 1998
>Date: Fri, 30 Oct 1998 09:00:04 -0600
>From: John R Sheets <dusk@smsi-roman.com>
>Reply-To: dusk@smsi-roman.com
>Organization: SMSI
>X-Mailer: Mozilla 4.5 [en] (WinNT; I)
>X-Accept-Language: en
>To: gnome-gui-list@gnome.org
>Subject: Re: fundamentals of the gnome user interface
>Resent-From: gnome-gui-list@gnome.org
>X-Mailing-List: <gnome-gui-list@gnome.org> archive/latest/13
>X-Loop: gnome-gui-list@gnome.org
>Resent-Sender: gnome-gui-list-request@gnome.org
>X-URL: http://www.gnome.org
>
>sungod wrote:
>
>> 1.) "browsing."
>
>[snip]
>
>> 2.) "memorizing."
>
>[snip]
>
>I think this is a very good point to raise, and I really have nothing to
>add, other than that I agree.  The style guide should address this.  I'm not
>sure if we should have discrete sections for each approach, or how we should
>encourage developers to follow such an abstract suggestion.
>
>John
>
>
>
>--
>         To unsubscribe: mail gnome-gui-list-request@gnome.org with
>                       "unsubscribe" as the Subject.
>