Path: utzoo!utgpu!mnetor!frank
From: frank@mnetor.UUCP (Frank Kolnick)
Newsgroups: comp.sys.mac
Subject: Re: System 7 question
Message-ID: <5199@mnetor.UUCP>
Date: 5 Jan 90 02:00:42 GMT
References: <10734@claris.com> <578@sunfs3.camex.uucp> <1353@unocss..unl.edu> <1989Dec21.105013.7047@jarvis.csri.toronto.edu> <1618@rodan.acs.syr.edu> <6007@internal.Apple.COM>
Reply-To: frank@mnetor.UUCP (Frank Kolnick)
Organization: Computer X (CANADA) Ltd., Toronto, Ontario, Canada
Lines: 81

In article <6007@internal.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes:
>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?)

Much as I like the Mac (I use it heavily every day), and much as I think
the current hoopla over X/Motif/Open Look/etc. is focusing on flash
rather than substance (i.e., I think the fancy, multi-coloured, 3D windows
distract the user from the application), I do think Open Look has done 
a couple of things right in this area:

In the context of this discussion, any part of the window frame is
potentially available for interaction. Naturally, this can be abused,
but a well-designed application may place command buttons (which
directly activate actions, like 'save'), menu buttons (to pop up a menu),
exclusive lists (to set options), scrolling lists, etc. in any of the
four bars. For example, the top bar generally contains a window button,
a title and perhaps a message. Below this (separated by a line), may
be a row or two of buttons. The bottom bar may contain buttons, or a message
such as the current page number. Note that I said 'window button', not
'close' button. This button can be used to pop up a menu which lets you
expand the window to full-screen size, iconify it, close it, etc. You
can get the default action (usually 'close') in one click.

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

While Open Look supports hierarchical menus, too, it also provides
context sensitive menus. I.e., the menu you get in the frame is
different than the one you get in the pane (there can be multiple panes,
btw). A good application will pop-up object-specific dialogue (OL
has pop-up 'command windows' in addition to menus) such as a list of
fonts or type styles when the cursor is on text.

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

I don't think I'm any more likely to overshoot a menu bar than I am
a text string in the pane (generally a trickier target, in my experience).
I do find it tiring to visually search out the menu I want when the
window isn't at the top of the screen, and then move the cursor up there,
drag, then move it back where I need it. (Open Look 'jumps' the cursor to
the dialog window and then jumps it back to your pane when done.)

Overall, the demands placed on windowing systems has increased since their
introduction. The question (one question, anyway) is how to manage the
additional complexity without placing too many demands on the poor user.
IMHO, the single-application-at-a-time view of the current Mac interface
is slipping a little behind the times. Personally, I like the idea of having
the menus, etc., I need grouped close to the data I'm working on. The
window frame seems to be a logical choice. If I move the window, the
menu bar et al. moves with it. If I bring up another application's
window, the previous one (menus and all) is hidden until I need it again.

(I don't mean to sound like an Open Look salesman, and I could find lots
of nits to pick, but it is a step in the right direction. It pays to study
the competition :-)

-- 
Frank Kolnick,
consulting for, and therefore expressing opinions independent of, Computer X
UUCP: {allegra, linus}!utzoo!mnetor!frank