Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!mips!apple!Apple.COM!lsr
From: lsr@Apple.COM (Larry Rosenstein)
Newsgroups: comp.sys.mac
Subject: Re: System 7 question
Message-ID: <6007@internal.Apple.COM>
Date: 4 Jan 90 17:49:04 GMT
Sender: usenet@Apple.COM
Organization: Objects-R-Us,  Apple Computer, Inc.
Lines: 61
References:<10734@claris.com> <578@sunfs3.camex.uucp> <1353@unocss..unl.edu> <1989Dec21.105013.7047@jarvis.csri.toronto.edu> <1618@rodan.acs.syr.edu>

In article <1618@rodan.acs.syr.edu> isr@rodan.acs.syr.edu ( ISR group 
account) writes:

> Yes! I think it's a great idea. It could be done so it woudn't take up 
any
> more room - instead of putting the menu IN the window, replace the Title 
Bar
> with a MenuBar, Perhaps in a format such as:
>  AppName  File   Edit   Menu     Menu   Menu     ZoomBox

Where would you put the title of the window?  (Or should windows not have 
titles?)

> The only problem I can think of now with it is small-width windows
> woudn't provide all the menus, but again, that can be handled by MF, just
> by providing "scrolling" of the last menu as you go off the edge of the
> menubar with the button held down.

People have enough trouble with hierarchical menus.  I'm not sure if a 
scrolling menu bar is the best approach.

The original complaint was that context switching isn't obvious in 
MultiFinder.  One proposal was to use some kind of animation, which is a 
good idea, but it takes the user's time.  The problem with Switcher is 
that you couldn't look at windows from 2 applications at the same time, 
which is very useful.

Another comment is that you can switch into an application that has no 
active windows.  I agree this is a real problem, especially for new 
MultiFinder users.  It could be solved if MultiFinder disallowed switching 
into these applications (except perhaps with the Apple menu, which would 
make it explicit).

Putting the application's menus in the window would also solve the 
immediate problem, but I think it introduces other problems.  First, is 
the problem of not having a wide enough window.  Applications are alrady 
running our of menu bar space, and this would just add to the problem, or 
force users to make windows wider than they need.

Having the menu bar in each window also takes up more screen space 
overall.  It also seems that it would be harder for the user to use the 
menus.  With the menu bar at the top of the screen, you can (normally) 
overshoot the top of the menu bar and still activate the menu.  With the 
menus in a window, you could overshoot and click the close box instead.  
One would have to do user test to see if this is a problem.

Making the inactive application windows dimmer than the active 
application's windows is a good idea.  If you do this to the structural 
parts of the window, users will still be able to read the contents.

Perhaps applications should put up a modeless splash screen if all their 
windows are closed; that way the user would always know which application 
was active.



Larry Rosenstein, Apple Computer, Inc.
Object Specialist

Internet: lsr@Apple.com   UUCP: {nsc, sun}!apple!lsr
AppleLink: Rosenstein1