🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.mac
Article #26015

Re: A/UX window systems, Mac tool...( Hum Interface)

#26015
From: Charles L Ditzel
Date: Sat, 05 Mar 1988 03:37
40 lines
2866 bytes
In article <241@eos.UUCP#, lyman@eos.UUCP (Lyman Taylor) writes:
# In article <1719@ssc-vax.UUCP> benoni@ssc-vax.UUCP (Charles L Ditzel) writes:
# 
#   .... ( deleted comments Byron Han made about multifinder )
# 
# 
# >Still sounds awfully serial to me.  What happens if you have two windows
# >at the top (i do this on a sun, usually two editting sessions) maybe
# >different editors side by side...?  Your menu bar would be constantly 
# >changing as you go back and forth (cutting and pasting)... (all that
# >wasted mouse travel time and a wasted mouse click )
# >I think context-sensitive menus make more sense (try SunView applications
# >and see how well they work) :-) (Seriously, I think a menu bar starts
# >making less sense in a multitasking environment were more than one 
# >application is running at a time in a number of different windows )
# 
# 	Multitasking saves the World!      Come on, the only person I know of

Some how you picked up on the multi-tasking aspect rather than the more
important issue of the cumbersomeness (is-this-a-word?) of menu bar switching.
  
# 	2) If you actually needed two DIFFERENT editors you hopefully were
# 		looking at two DIFFERENT types of files.  In this case you are
# 		context switching between two different types of data who 
# 		hopefully have completely different menus.  ( execpt for 
# 		the APPLE, FILE, and EDIT menus, there goes that CONSISANTCY
# 		again, Mac Write and Mac Paint have for the most part different
# 		menus and operation ( those probably aren't the best examples
# 		but you get the idea :-).
Again you missed the *main* point, even if you do not have multitasking. 
The user interface you wind up with is one with constant mouse clicks and
constant menu bar switches :( .  Further, you will be constantly looking
to see which application window is the active one (a further nuisance).  
Finally (if you do have multitasking) It gets worse (as I percieve it) on 
an abstract level...when two windows are on top (side by side) why should
you choose one over the other in putting a menu bar up for that one?  Can
you really design a system which unnecessarily defines user activity in a
serial manner and *predict* the type of applications you will see in the 
future.
You wind up limiting your user interface today and for the future.
Technical Details
Message-ID: <1735@ssc-vax.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!mnetor!uunet!husc6!bloom-beacon!mit-eddie!uw-beaver!fluke!ssc-vax!benoni
References: <4129@hoptoad.uucp> <283@rhesus.primate.wisc.edu> <1710@ssc-vax.UUCP> <241@eos.UUCP>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!mnetor!uunet!husc6!bloom-beacon!mit-eddie!uw-beaver!fluke!ssc-vax!benoni
From: benoni@ssc-vax.UUCP (Charles L Ditzel)
Newsgroups: comp.sys.mac,comp.windows.misc
Subject: Re: A/UX window systems, Mac tool...( Hum Interface)
Message-ID: <1735@ssc-vax.UUCP>
Date: 5 Mar 88 03:37:02 GMT
References: <4129@hoptoad.uucp> <283@rhesus.primate.wisc.edu> <1710@ssc-vax.UUCP> <241@eos.UUCP>
Organization: Boeing Aerospace Corp., Seattle WA
Lines: 40
Keywords: window human computer interface