RE: GWP and 'the foot'





Begin forwarded message:

> From: Jan Gentsch <gentsch@ifm.uni-hamburg.de>
> Date: Sat, 31 Oct 1998 13:15:57 +0100
> To: gnome-gui-list@gnome.org
> Subject: RE: GWP and 'the foot'
> Resent-From: gnome-gui-list@gnome.org
> X-Mailing-List: <gnome-gui-list@gnome.org> archive/latest/43
> X-Loop: gnome-gui-list@gnome.org
> Organization: wgw
> X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.35 i686)
> X-URL: http://www.gnome.org
> Resent-Date: 31 Oct 1998 15:31:42 -0000
> X-UIDL: 68316608299e335b3bebe55d3b682594
> MBOX-Line: From gnome-gui-list-request@gnome.org  Sat Oct 31 10:31:42 
> 1998
> Resent-Cc: recipient list not shown: ;
> Resent-Sender: gnome-gui-list-request@gnome.org
>
> Jan Gentsch wrote:
>
> > Samuel Solon wrote:
> >
> > > >
> > > >i agree with the separation between file-level menu choices and 
> > > >application-level menu choices (as i should; it was my proposal 
> > > >initially!), but would like to know if there's still anybody  
hanging
> out
> > > >here who thinks that we should follow other gui's in menu  
layout (or in
> > > >_any_ design decision) and why.
> > > >
> > >
> > > It's baaaaaack! Of course maybe this time the discussion can go on 
> without
> > > the distracting flame wars.
> > >
> > > I'm not so much in favor of following a particular other GUI  
but there
> > > seems to have been a convergence in applications that the first 
> > > "application" menu is the "File" menu which contains the way  
of ending
> the
> > > application and the "filing" operations (whether actual disk  
files are
> used
> > > or not).
> > >
> > > There are so few standards on Unix that to abandon such a  
widely followed
> > > practice should only be done if there is a significant  
advantage. I've
> > > never heard any really good arguments made in favor of the  
"foot" menu
> > > other than it being "uniquely gnome" or "logical". If I remember 
> correctly
> > > from so long ago I think the "logical" argument went along  
with a proposal
> > > to have the menu bar structured in a hierarchy that was to match an 
> > > (alleged) hierarchy of application objects.
> > >
> >
> > I think there is a significant advantage. The separation between File 
> level
> > and Application level is logical and in fact already being used. Most 
> "File"
> > menus these day come with a seperator/seperators between the
> Application and
> > the File related commands. From my personal experience I can  
only say that
> > after a number of years of using netscape and nedit for example,  
I still
> > sometimes choose exit instead of close and all my windows are gone 
> (bummer).
> > My strategy to avoid this has been to "close" windows using the  
button
> > supplied by the window manager, but really that shouldn't be needed. 
> > The problem arises because there is a big difference between  
closing a
> > document and closing the application but to little of a visual  
(and indeed
> > often spacial) difference between the two.
> >

But I think this points out deficiencies in the Netscape UI of one  
of the three approaches to MDI applications.  I don't personally  
think this argument is as particularly useful as either an argument  
for or against the "foot" menu.  The Apple YellowBox tools for  
Windows follow a similar approach to this:  each MDI window gets a  
seperate window with a menu bar, but they also include a Window menu  
with options like:  Close this Window, Minimize this Window and  
Minimize All Windows in addition to the list of active windows for  
the application.  This approach is far less confusing and you would  
have a hard time making the mistake you are describing above.

> > >
> > > Another consideration is that people will continue to use non-gnome 
> > > software along with gnome (for example xemacs) and most of it  
follows the
> > > "File" menu practice. Again, gnome should be moving towards  
unifying
> > > application interfaces not breaking them by being different for the 
> sake of
> > > being different.
> > >
> >
> > The breakage is little and easily understood.
> >

I dissagree.  I think that even if people who haven't used a Mac  
have probably seen one and probably have an idea about what the Apple  
menu is all about.  The main thing I see (and, sungod, I kind of  
agree that the "foot" menu isn't important right now, but on some  
levels it is because it defines some of the concepts of a GNOME user  
interface--one way or another) is that the foot menu is used for  
application-level operations while the only thing that user has as a  
mental reference to try and figure out what it is for is the Apple  
menu.  While the Apple menu generally has the menu items like About,  
the majority of the Apple menu contains system-level operations which  
are not especially related to the current application.  I think that  
what users would be expecting to see under "the foot" would be  
perhaps what has already been listed, but also probably a good  
portion of what is on the panel's main "foot" menu.

Some applications I have used make a distinction between  
application-level functions and file operations.  Probably the  
easiest example to describe is Apple's YellowBox ProjectBuilder  
application.  The first menu is Project and contains open/close  
project options, add/remove file from project options and exit.  The  
"normal" file operations are on the File menu, but there isn't an  
Exit option.  I think the decision to include an "application-level"  
menu more depends on the complexity of the application rather than  
just to "do it" because we can.  If the extent of the application  
menu is About and Quit, I don't know that enough arguments exist for  
not putting these in the expected places.  If the application is  
complex enough as in a project management center where you will have  
file associations to a project and be opening/closing projects, etc.  
It seems like it does make some sense.

> > >
> > > I would never argue that the menubar model that applications  
have been
> > > using for so many years is optimal but it has becoming ingrained in 
> > > people's minds. Making minor changes in it is disruptive and I  
doubt it
> > > will really improve usability significantly.
> > >
> >
> > GUI of all vendors have been changing all the time, also order  
to improve
> > usabilty (and of course the look). Some changes I found disruptive at 
> first,
> > but found them to be very productive latter.
> >
> > Jan.
>
>
> --
>          To unsubscribe: mail gnome-gui-list-request@gnome.org with  
>                        "unsubscribe" as the Subject.
>
>



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]