Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!ssbell!mcmi!unocss!dent
From: dent@unocss..unl.edu (Local Submission)
Newsgroups: comp.sys.mac
Subject: Re: System 7 question
Message-ID: <1365@unocss..unl.edu>
Date: 6 Jan 90 20:09:35 GMT
References: <10734@claris.com> <578@sunfs3.camex.uucp> <1353@unocss..unl.edu>
Organization: U. of Nebraska at Omaha
Lines: 92

cca@pur-phy (Charles C. Allen) writes:
> (DEC-windows wraps menubars...)
>I have no difficulty using wrapped menubars.

This is indeed one workaround but it's major disadvantage is that it takes
even /more/ screen space.  I'm not sure Plus and SE users (of which I am one
:-) would appreciate that... Unless the Control Panel allowed us to specify
our own system font, and we happened to pick one that is considerably
smaller than Chicago?  ("system font" in the menubar sense, that is)

>Screen real estate is a problem.  On the other hand, having the menus
>that apply to the window I'm in *right there* makes it much easier to
>understand what operations make sense & doesn't force me to move my
>head up to the upper left corner of a big screen all the time.  A
>reasonable arrangement would be to have the screen menubar be reserved
>for operations affecting the entire application (open a new window,
>global preferences), while the window menubar has operations affecting
>the window contents.

On the extremely few occaisions that I get to use a large monitor, I have
to agree that if your application's window is near the bottom of the screen,
having to stop everything, go find the menus, use them, and come back, is
counterproductive.  The menubar works great for a smaller screen like the
Plus and SE have, but it's not all that well suited for larger screens.

We have two things competing here: Improved Usibility (through an improved
interface), vs. Screen Real Estate. :-)  One suggestion that I can think
of for Plus/SE-type screens is to change the default WDEFs to make title bars
smaller, like the "Shrinker WDEF" (Which I *love* on my SE, if only for this
reason, since I hardly ever use the "shrinker" box), from WindChooser
(available at better Mac FTP sites near you).  If the menubar was shrunk to
that size (user-selectable of course, via Chooser), then adding a menubar,
even if 12-point Chicago was used (which might not be a necessity), would not
increase the amount of "wasted" screen space drastically.

One thing to consider (actually a lot of them), when considering splitting
an application's menubar between it's windows and "global" menu items, as
mentioned above, is: 1.  How is the Mac going to /trasnparently/ figure out
which menu items are "global" and which are "window-specific"?  It really
can't; and more importantly: it would /really/ confuse the users.  Sure, you
could force all of the Mac programmers in the world to suddenly rewrite their
code to support "ImprovedFinder", but this would only serve to further
alienate them, and would hurt the Mac's standing in the marketplace ("oh god,
Apple came out with another version of the OS, now no one can get software 
until it is all re-written...").

This isn't to say that splitting up the menubar isn't a good idea, though!
The Finder, for example, isn't really "just an application".  Even before
MultiFinder, the Finder was always presented as a sort of "Director", or
"organizer".  It's job is to help you use "real" applications (by launching
them), and to manipulate files.  When MultiFinder came along, "Finder"
became "just another application", and given equal billing and status as
any other application.  My point is that Finder /isn't/ "just another
application; it's purpose (now at least) seems to be to "manage" all of the
stuff going on on the Mac.  And if this is the case, it seems sensible that
the Finder should inherit the menubar at the top of the screen, since menu
items there are likely to affect any or all portions of the scren -- even
the whole Mac --, and not just one window.  So if the Menubar is to be
split, it's my opinion that this is where the split should be. :-)

Well now we've really opened a can of worms.  Now the user is going to have
a "File" and "Edit" (and possibly even others) menu in several windows,
as well as at the top of the screen.  If this transition is really to take
place, then the "file" and "edit" menus in Finder really should be renamed,
or again we risk user confusion.  This comes at a pretty good time, though;
are "file" and "edit" really the best names for those menus?  Ex: I click
once on my hard drive icon, and then pull down "Open" from the "File" menu.
Does that mean that my hard drive is a file?  Well "kinda..." if additional
functionality to handle the windows that applications and such are going to
live in in this HypotheticalFinder, then something more generic, like
perhaps "Item" would be more appropriate.  (and of course, the "Open" item
in this menu could change names depending on what the user clicked on.  For
example, "Open Volume" if they clicked on a disk, "Open Document", "Open
Application", "Open Folder", etc.)

There are plenty of other issues related to a change this drastic, but I
think that I've rambled enough for the moment.. :-).  Comments, criticisms,
suggestions, etc. are all quite welcome; I think this is a fascinating
discussion (and a lot more interesting than "IBM sucks! Mac Sucks! IBM sucks!
... ad nauseum." :-)

>I would hope that the Apple HIG people have already been looking into
>these questions.

So would I!  In fact, is anyone in the HIG reading this stuff?  And how
does one go about getting a job with that group anyway? :-) :-)

>Charles Allen		cca@newton.physics.purdue.edu

-/ Dave Caplinger /---------------------------------------------------------
 Microcomputer Specialist,   Campus Computing,   Univ. of Nebraska at Omaha
 mspecial@zeus.unl.edu       ...!uunet!unocss!dent          MSPECIAL@UNOMA1