🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.mac
Article #26106

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

#26106
From: Charles L Ditzel
Date: Wed, 09 Mar 1988 07:23
72 lines
5051 bytes
In article <5674@cit-vax.Caltech.Edu>, sho@tybalt.caltech.edu (Sho Kuwamoto) writes:
# In article <1735@ssc-vax.UUCP> benoni@ssc-vax.UUCP 
# (Charles L Ditzel) writes:
#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.
> 
> Enlighten me.  If you have two windows side by side on a Sun, what
> happens when you type something from the keyboard?  Why should you
> choose one over the other in sending characters to it for that one?
Your cursor is *IN* that window. That is you are explicitly defining
the environment you want your keyboard input and mouse input to go to.
That doesn't mean that *other* applications (within windows) are not
active. 

> 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.
Yes.  The issue is really designing a system which *out of necessity* 
defines user input :) Lots of systems exist that *unnecessarily* constrain 
user activity.  The MacOS may be viewed by some as an example of one these
systems (i.e., no command shell, serial menu-bar activity, etc) 
The context of my response was to the suggestion that a Multi-user
Mac would change the *menu-bar* when an application was at the top OR
chosen.  My comment was that the menu-bar was fine in a serial environment
however in a multi-tasking environment, the user inputs should be 
contrained *within* the applications window. Why should the desktop 
*deal* with inputs of *one* of its windows(i.e. :application environments)? 
 If anything a desktop menu-bar should deal with meta-events, that is 
events that act upon the desktop environment (for instance, open a new 
window).  However, a desktop menu-bar robs you of pixels in an already
limited screen...a more logical solution is Sun's SunTools popup/pullright
menus (which are customizable) and Window frame menus.
> In either case, it seems that certain events can only be posted to the
> active window (whether or not it is topmost) and you are always going
> to have this type of problem.  In response to someone who said the
You are correct, as far as input via the keyboard/mouse.  You are not
*always* going to have this problem.  A simple touch screens that groks
two fingers on two different windows is a simple example.
  
> Another thing that scares me.  Customizable mice seem fine for a multi
> user environment; if I get an account on a new Sun, I copy over my
> setup files or whatever and everything is hunky dory, right?  But for
> a single user machine, I couldn't imagine what would happen if *my*
> mac functioned differently from the one my friend has, which
> functioned differently from the one the school has for public use.  
Why do *so* many people think that the ability to customize or extend
is necessarily scary.  Done correctly, this would be a feature.  A
key on keyboard could reset your mouse to a default and knowable
configuration.
  
> There are definite problems with the Mac interface, such as the grow
> box being in the right hand corner and all.  However, these are all a
> side effect of the way it was designed.  Ease of use was built in
> before Apple realized that power was important too.  I think a three
> button mouse would confuse the, uh, counfuse the... stuffing out of
> beginners, especially if all three buttons were somehow necessary to
> do the most basic, necessary tasks.  
  
> 						-Sho
I would say the one button mechanical mouse is a drawback.  You are
correct the Mac was designed for a beginner (which is not necessarily
bad - it has been its strength but its lack of power is its weakness)...
There is no reason a priori to view a three button mouse as more
confusing...properly done...it could be a benefit...(for example :
the first mouse button could be the normal Mac mouse button,
the second mouse button could invoke a builtin MacOS editor,
the third mouse button could be a help button or somesuch thing
- i make no claim that this is the ideal...just an example.)
Technical Details
Message-ID: <1740@ssc-vax.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!water!watmath!clyde!att-cb!att-ih!pacbell!ames!mailrus!tut.cis.ohio-state.edu!uwmcsd1!bbn!rochester!cornell!uw-beaver!ssc-vax!benoni
References: <4129@hoptoad.uucp> <283@rhesus.primate.wisc.edu> <1710@ssc-vax.UUCP> <5674@cit-vax.Caltech.Edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!water!watmath!clyde!att-cb!att-ih!pacbell!ames!mailrus!tut.cis.ohio-state.edu!uwmcsd1!bbn!rochester!cornell!uw-beaver!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)
Keywords: window human computer interface
Message-ID: <1740@ssc-vax.UUCP>
Date: 9 Mar 88 07:23:19 GMT
References: <4129@hoptoad.uucp> <283@rhesus.primate.wisc.edu> <1710@ssc-vax.UUCP> <5674@cit-vax.Caltech.Edu>
Organization: Boeing Aerospace Corp., Seattle WA
Lines: 72