NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/humanfa/2703

Internet Message Format | 1992-11-20 | 4.0 KB

Xref: sparky comp.human-factors:2703 comp.windows.x:19424
Newsgroups: comp.human-factors,comp.windows.x
Path: sparky!uunet!haven.umd.edu!wam.umd.edu!dododge
From: [e-mail] (David O. Dodge)
Subject: Re: Click to Raise Windows vs. Point to Raise
Message-ID: <[e-mail]>
Sender: [e-mail] (USENET News system)
Nntp-Posting-Host: rac2.wam.umd.edu
Organization: University of Maryland, College Park
References: <[e-mail]> <[e-mail]>
Date: Sat, 21 Nov 1992 05:49:29 GMT
Lines: 76

In article <[e-mail]> mathew <[e-mail]> writes:
>[e-mail] (Matthew Freedman) writes:
>> We have some public X-Terminals set up in our libraries, which run a
>> very limited system with just a couple available applications.
>>
>> Before we change the system to match this defacto standard, the
>> point-to-raiseists would like to see hard evidence that click-to-raise
>> is really better. Does anybody have any?

I've tried both click-to-raise and point-to-raise under X, and found that
I didn't care much for point-to-raise. I prefer to be able to move my
mouse around without having my windows automatically obscuring each other
constantly. Ideally it should be something the user could switch on/off
while running. If your users are actually logging in to individual accounts,
then this should be a completely user-specifyable thing.

>> If not, unsubstantiated
>> personal opinion would be welcome too.
>
>Well, I can offer you some substantiated personal opinion.

And I'll add my completely opposite views :-)

>The first time I ever tried to use a Sun workstation, I fired up a shell and
>typed ls.  Nothing happened.  I checked the keyboard cable to make sure it was
>plugged in, and tried hitting a few more keys.  No response.

[ rest of scenario deleted ]

>He explained that keyboard input was being sent to whichever window happened
>to have the mouse pointer in it.

This is how most workstation windowing systems (SunView, X) work, though
they would normally provide a way to change this to the system you were
expecting.

>I settled down once more, but I found that my natural tendency was
>to move the mouse pointer out of the way so it wouldn't obscure the contents
>of the window.

This is a problem, and this is what I hated when I first used this system
as well (it still annoys me, but not as much).

>I'd used
>Macs, Windows, GEM, Amigas, Ataris... all without needing to look at the
>manuals.  But the practice of raising or activating windows under the mouse
>pointer was so damn counter-intuitive for me that I couldn't work out what
>was going on, and even when I had it explained to me I found the machine
>unusable.

This is all because you were used to systems that are based on
the principle of "click to type", aka the One True Evil (tm). My Amiga
infuriates me to no end, because I expect that if my pointer is on a screen's
surface, it's going to send input there (and naturally it instead sends it
to some screen/window I can't even see).

There are three basic systems:

  - move-to-type/move-to-focus. This is what that Sun you tried to use
    was doing.

  - click-to-type (aka the One True Evil (tm)). This is what the Amiga
    any many others do (and X can generally be set up this way). You select
    the window to receive input by clicking in it.

  - Apollo DM. This is what I first used -- this system combined the cursor
    and pointer into a single entity, so when you move the mouse your cursor
    turns into a pointer and when you start typing your pointer turns back
    into a cursor at that position in the window. I've never seen any other
    system that did it this way, and I still think it's the easist thing I've
    used. To my knowledge this is pretty much impossible with X because the
    clients would have to be written to handle it (and they aren't).

Anyway, I can live with point-to-raise, but I can't stand click-to-type for
more than a few seconds.
                                             -Dave Dodge/[e-mail]