HDTenEightyP/NetNews huggingface dataset:
From: asper@time.sbc.com (Alan E. Asper)
Subject: Re: HCI, CHI, UI, UIT, etc...
Keywords: SAPs
Organization: Southwestern Bell Technology Resources, St.Louis, MO
Date: Thu, 1 Oct 92 19:52:41 GMT

In article <1992Oct1.141142.18882@saifr00.cfsat.honeywell.com> shanks@saifr00.cfsat.honeywell.com (Mark Shanks) writes:
>
>After having been flogged with hundreds of "GUIs are Harmful" posts,
>I think an additional, separate category might be appropriate:
>
>   SAPI - Sweaty Arrogant Programmer Interface
>

Listen, pal, if you're going to insult the posters to this newsgroup,
you're working MY side of the street. Back off.
:-)

XOXO
Alan


Newsgroups: comp.human-factors
From: chrisw@chopin.FtCollins.NCR.com (Chris Whitley)
Newsgroups: comp.human-factors
Subject: RE: AI & User Interfaces
Date: 29 Sep 92 14:50:25 GMT
Reply-To: chrisw@chopin.FtCollins.NCR.com (Chris Whitley)
Distribution: world
Organization: NCR Microelectronics, Ft. Collins, CO

The work Jock Mackinlay did, let's see, maybe 6 or 7 years ago
on a system to 'automatically' (intelligently) generate 'good'
displays of graphical information is to me a classic marriage 
of AI and user interface.  I don't have references on hand right
now...maybe some other reader could provide them for me?

---------------------------------------------------------------
Chris Whitley            email: Chris.Whitley@FtCollinsCO.NCR.COM
NCR Microelectronics     Phone: (303) 223-5100 ext. 432
2001 Danfield Court        Fax: (303) 226-9556
Ft. Collins, CO  80525
From: fj_maddi@csd.brispoly.ac.uk (FJ Maddix)
Newsgroups: comp.human-factors
Subject: Re: HCI, CHI, UI, UIT, etc...
Date: 29 Sep 92 11:16:00 GMT
Organization: Bristol Polytechnic, England

Well, here in the ole UK, HCI stands for 'Human Computer Interaction'.
'Machine' sounds too specific and low level; 'interface' to o restrictive
on domains of enquiry.
Human Computer Interaction. Yep.
Newsgroups: comp.human-factors
From: robasky@iguana.cis.ohio-state.edu (Kimberly Robasky)
Subject: Where is FAQ for this group?
Organization: The Ohio State University Dept. of Computer and Info. Science
Date: Sat, 26 Sep 1992 22:17:06 GMT

Subject says it all... thanks

(email: robasky@cis.ohio-state.edu)
From: sfleming@cs.hw.ac.uk (Stewart T Fleming)
Newsgroups: comp.human-factors
Subject: Re: HCI, CHI, UI, UIT, etc...
Date: 29 Sep 92 15:18:56 GMT
Reply-To: sfleming@cs.hw.ac.uk
Organization: Dept. Of Computing and Electrical Engineering, Heriot-Watt University, Edinburgh


In article <1992Sep29.035106.7738@oracle.pnl.gov>, d3g450@tnp_op.pnl.gov (MC Pottier) writes:

>HCI - Human computer Interface

Human Computer INTERACTION.  Please.  I don't want to be a cyborg yet.

-Marc

STF
--
sfleming@cs.hw.ac.uk                        ...uknet!cs.hw.ac.uk!sfleming
"I go out walking after midnight, searching for you..."
  -Patsy Cline
From: mike@isgtec.com (Mike Sellers)
Newsgroups: comp.human-factors
Subject: Re: Should dialogs pop-up other windows?
Keywords: dialog gui
Date: 26 Sep 92 15:44:06 GMT
Distribution: na
Organization: ISG Technologies Inc., Mississauga Ontario

In article <1992Sep21.145235.29976@sdc.com> psm@sdc.com (Steve Murphy) writes:
> I've always known that "as a rule" that dialogs should not pop-up other
> windows. I need to be able to defend this position so I need some help.
> What is the reasoning behind this rule?

Like so many other UI situations, this is a question of balance, not of rules.
Ours is not yet a propositionally-definable discipline.

First, consider what the dialog is doing in the first place:  Is the dialog
interrupting the user's task, or is it a natural part of their task and 
cognitive set?

If the former, you might want to consider getting rid of it altogether --
you're already risking annoying the user by interfering with their thoughts,
and any further "depth" in it has to be well-justified (which it _might_ be;
it depends on the specific situation).  

If the latter is the case, then you may be doing the user a favor by using 
sub-dialogs.  It could be that you're keeping the number of things they have
to simultaneously attend to low, explicitly showing the process being followed,
and hiding advanced or little-used options.  

I know this probably doesn't help much, but you really can't rely on "rules"
much in UI design -- yet.  Perhaps you'll remember the quote from the late
1700s that I posted last week:  We are still in the stages where "no textbook
contains the principles of this new science ... this is why it is hardly 
ever manifested without that boldness and the errors which, in the infancy 
of science, characterize genius."  Here's the wonderful errors you're about
to make! :-)  

--
              Mike Sellers      User Interface Team Leader
           mike@isgtec.com      ISG Technologies, Toronto, Canada
              "Actum ne agas" -- Do not do what has been done.
                         Furare tantum ab Optimis
Newsgroups: comp.human-factors
From: cnquinn@spectrum.cs.unsw.oz.au (Clark Quinn)
Subject: Re: HCI, CHI, UI, UIT, etc...
Reply-To: cnquinn@spectrum.cs.unsw.oz.au (Clark Quinn)
Organization: none
Date: Thu, 1 Oct 1992 03:22:19 GMT

In article <1992Sep29.103623.24052@sol.ctr.columbia.edu> daniel@csgi63.dcs.leeds.ac.uk (D N Crow) writes:
>In article <1992Sep29.035106.7738@oracle.pnl.gov>, d3g450@tnp_op.pnl.gov (MC Pottier) writes:

>>    I'm putting together a list of jargon for the names of the user interface
>> field...so far I have the following names, can anyone think of others?
>> 
>> HCI - Human computer Interface
>> CHI - Computer Human Interface
>> UI  - User Interface
>> UIT - User Interface Technology
>> UID - User Interface Design
>> HMI - Human Machine Interaction
>
>MMI - Man Machine Interface
>HCI - Human Computer Interaction
>HCID - Humn Computer Interface Design

I've always been partial to 

USI - User-System Interaction
UCSD - User-Centered System Design

because I feel the principles apply to systems more general than
computers, and users more general than humans (an exercise I give my
students is to design a communication system for either dolphins,
chimps, or cockatoos).  It's also more Politically Correct (tm :-).  
-- Clark

---------------------------------------------------------------------------

 _--_|\    Clark N. Quinn
/      \   School of Computer Science and Engineering	    +61-2-697-4034
\_.--._*   The University of New South Wales            Fax +61-2-313-7987
      v    PO Box 1                                cnquinn@cse.unsw.edu.au
           Kensington, NSW                             C.Quinn@unsw.edu.au
           AUSTRALIA 2033                                      

           "A California Yankee in the Land of Oz"
Newsgroups: comp.human-factors
From: daniel@csgi63.dcs.leeds.ac.uk (D N Crow)
Subject: Re: HCI, CHI, UI, UIT, etc...
Organization: School of Computer Studies, University of Leeds
Date: Tue, 29 Sep 1992 10:36:23 GMT
X-Posted-From: csgi63.leeds.ac.uk
NNTP-Posting-Host: sol.ctr.columbia.edu

In article <1992Sep29.035106.7738@oracle.pnl.gov>, d3g450@tnp_op.pnl.gov (MC Pottier) writes:
> 
> Howdy...
> 
>    I'm putting together a list of jargon for the names of the user interface
> field...so far I have the following names, can anyone think of others?
> 
> HCI - Human computer Interface
> CHI - Computer Human Interface
> UI  - User Interface
> UIT - User Interface Technology
> UID - User Interface Design
> HMI - Human Machine Interaction

MMI - Man Machine Interface
HCI - Human Computer Interaction
HCID - Humn Computer Interface Design

-- 
Dan Crow
daniel@scs.leeds.ac.uk
Newsgroups: comp.human-factors
From: Herman.Woltring@bbs.oit.unc.edu (Herman Woltring)
Subject: Re: 3-D locator device
Summary: Biomechanics measurement equipment
Organization: Extended Bulletin Board Service
Distribution: comp
Date: Tue, 29 Sep 1992 05:55:24 GMT

In article <Bv3ACv.Hvs@cen.ex.ac.uk> lindsey@dcs.exeter.ac.uk (Lindsey Ford) 
writes:
 
>Imagine you hold two knitting needles, one in each hand. The one in your
>left hand is held steady and, with your eyes closed, you try to move the
>knitting needle in your right hand so that the tip of it comes into close
>proximity to the tip of the needle in your left hand. It's not easy.
>
>Such is the problem of the surgeon using an arthroscope (left hand) and
>another instrument, say a hook probe, in the right hand. The arthroscope,
> ( ... )
>I'm attempting to provide a simulation of this situation to enable surgeons
>to practice the skill. What I need is a device which relays its proximity
>(preferably its 3-dimensional position) relative to some fixed point. Does
>anyone have suggestions?
>
>Dr Lindsey Ford
>
 
There are various systems in the Biomechanics field that may accomodate this
problem, based on video ("gait analysis equipment"), ultrasound, electro-
goniometry ("elgons"), and electromagnetic principles.  I'll Xpost your CfH
to Biomch-L@nic.surfnet.nl / Biomch-L@hearn.bitnet; also, you might look into
the sci.virtual-worlds archives at the University of Washington in Seattle.

Herman J. Woltring <woltring@nici.kun.nl>, Biomch-L moderator
(do *not* send private replies to the bbs address)
--
   The opinions expressed are not necessarily those of the University of
     North Carolina at Chapel Hill, the Campus Office for Information
        Technology, or the Experimental Bulletin Board Service.
           internet:  bbs.oit.unc.edu or 152.2.22.80
From: norman@cogsci.ucsd.EDU (Donald A Norman-UCSD Cog Sci Dept)
Newsgroups: comp.human-factors
Subject: Re: AI & User Interfaces
Date: 30 Sep 92 21:52:54 GMT
Reply-To: dnorman@ucsd.edu (Donald A Norman-UCSD Cog Sci Dept)
Organization: UC San Diego Department of Cognitive Science

Mackinlay's work on graphical presentation is:


Mackinlay, J. D. (1986). Automating the design of graphical presentations
of relational information. ACM Transactions on Graphics, 5 (2), 110-141. 


Note that there are a number of follow-ups to this very important line of
work. 

don norman

Terms for the Field: I am rather partial to UCSD, myself: User Centered
System Design (among other things)


Don Norman                         	       INTERNET:  dnorman@ucsd.edu
Department of Cognitive Science 0515	       BITNET:    dnorman@ucsd
University of California, San Diego	       AppleLink: dnorman
La Jolla, California 92093 USA                 FAX:       +1 619 534-1128
From: gjh@hplb.hpl.hp.com (Graham Higgins)
Date: Tue, 22 Sep 1992 15:35:28 GMT
Subject: Task-oriented display organisation & `task fixation'
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Newsgroups: comp.human-factors
Distribution: comp.human-factors



Does anyone have any pointers to work that addresses the issue of the impact
that task-oriented display organisation has (direction & magnitude will do)
on `task fixation'? The domain of application may be characterised as
`control engineering'. 

I need to get some idea of whether such a display orientation would facilitate
switching between concurrent tasks or whether it would act to lock the user
into the current task at the expense of other tasks. I suspect that the effects
might well vary with workload.

Have the designers of avionics multifunction displays come across this issue?

Comments welcome.

--
Graham Higgins 
<< gjh@hplb.hpl.hp.com || gjh@hplb.hp.co.uk || gjh@hplb.uucp >>
<< My opinions above are exactly that: my own, and opinions. >>
Newsgroups: comp.theory
From: obiliset@duke.ecs.umass.edu (Sashi V Obilisetty)
Subject: BIN PACKING
Reply-To: obiliset@sulu.ecs.umass.edu
Organization: University of Massachusetts at Amherst
Date: Fri, 2 Oct 1992 18:54:55 GMT


Hi netters:

I am  looking for some heuristics for solving the bin packing 
problem.

I know about the first-fit heuristic; are there others too?
Any references would be very helpful. Thank You
Xref: sparky comp.theory:2069 rec.puzzles:6494 sci.math:12366
From: karl@ima.isc.com (Karl Heuer)
Newsgroups: comp.theory,rec.puzzles,sci.math
Subject: Re: more on .999... = 10.0
Date: 28 Sep 92 22:11:21 GMT
Organization: Formerly of Interactive Systems, Cambridge, MA

In article <2481.imc@uk.ac.ox.prg> imc@comlab.ox.ac.uk (Ian Collier) writes:
>In article <83798@bcsaic.boeing.com>, lbaum@bcsaic.boeing.com (Larry Baum) wrote:
>>The reason that .3333... = 1/3 is easier to accept is that
>>this is precisely what you get when you do the long division.
>
>So what happens if you divide 1 by 3, then multiply by 3 again?

Eventually, the person will probably attempt to claim that 1/3 is not .3333...
but is actually .3333... "and a third", i.e. there's still a remainder of 1/3
at the "infinitieth" position.

Karl Heuer   karl@ima.isc.com   uunet!ima!karl
From: vmoore@DIMACS.RUTGERS.EDU ("", Virginia Moore)
Newsgroups: comp.theory
Subject: DIMACS information on-line
Date: 27 Sep 92 17:55:53 GMT
Reply-To: "(Virginia Moore)" <vmoore@dimacs.rutgers.edu>


   CENTER FOR DISCRETE MATHEMATICS AND THEORETICAL COMPUTER SCIENCE
			       (DIMACS)

	DIMACS, a national research center funded by the National
Science Foundation as a joint project of Rutgers University, Princeton
University, AT&T Bell Labs, and BellCore, has recently developed a new
Info Service.  By telnet to dimacs.rutgers.edu, one may now access a
wide assortment of information.  In addition to information about
DIMACS in general, the current special research year, and upcoming
workshops, one may also look up the phone and email address of any
DIMACS member or visitor, scan a list of current lectures, seminars
and workshops pertinent to the interests of the discrete mathematics
and theoretical computer science community and located within
commutable distance of DIMACS, and order technical reports or DIMACS
volumes.

	To try out the DIMACS Info Service, type "telnet
dimacs.rutgers.edu" and then at the login prompt, type "info".  You
will see a menu of available commands.  Typing a unique prefix of any
command will suffice.  One of the options is "HELP!"

	Ms. Virginia Moore <vmoore@dimacs.rutgers.edu> is maintaining
the calendar of upcoming area events.  She is already on many mailing
lists.  If, however, you are running a seminar within commutable
distance of DIMACS institutions and persons outside of your
organization would be welcome, please send the pertinent information
to Ms. Moore.  For seminars held at industry research labs, please
include information on how to obtain entrance to the facility and
arrive at the location of the seminar.

	Comments or suggestions about the new DIMACS Info Service
should be directed to Dr. Fred Roberts, Acting Director of DIMACS, at
center@dimacs.rutgers.edu.
From: J68A004@HUSZEG11.BITNET (Janos Viragh)
Newsgroups: comp.theory
Subject: FCT 93 Conference in Hungary
Date: 30 Sep 92 12:32:38 GMT



                           CALL FOR PAPERS

                 FUNDAMENTALS OF COMPUTATION THEORY
                               FCT'93

                        August 23-27, 1993
                          Szeged, Hungary


   The conference is the ninth in the series of FCT conferences held every
odd year. The papers selected by the Program Committee are expected to fall
into the following categories:

 -  Semantics and logical concepts in the theory of computing
    and formal specification

 -  Automata and formal languages

 -  Computational geometry, algorithmic aspects of algebra and
    algebraic geometry, cryptography

 -  Complexity (sequential, parallel, distributed computing, structure,
    lower bounds, complexity of analytical problems, general concepts)

 -  Algorithms (efficient, probabilistic, parallel, sequential, distributed)

 -  Counting and combinatorics in connection with mathematical computer science


 Conference Chairman: Zoltan Esik


 Program Committee

    L. Babai (Budapest/Chicago), S.L. Bloom (Hoboken NJ), L. Budach (Berlin),
    R.G. Bukharajev (Kazan), L. Czaja (Warsaw), Z. Esik (Szeged),
    F. Gecseg (Szeged), J. Gruska (Bratislava/Hamburg), J. Karhumaki(Turku),
    M. Karpinski (Bonn), B. Mahr (Berlin), J. Sakarovitch (Paris),
    I. Simon (Sao Paulo), I. Wegener (Dortmund)


 FCT'93 Invited Speakers (Preliminary List)

      H.-J. Kreowski (Bremen),
      R. Milner (Edinburgh)
      D. Scott (Pittsburgh),
      E. Welzl (Berlin)

 Organizing Committee:

      T. Gaizer, J. Viragh



Authors are invited to submit five copies of a draft
paper to the Conference Chairman                           by January 5, 1993

They will be notified of acceptance or rejection            by April 10, 1993

Deadline for final text                                          May 15, 1993



The proceedings will be available at the conference.




   Organizing Committee:

      T. Gaizer, J. Viragh


   Address for correspondence:

    FCT'93
    Bolyai Institute
    A. Jozsef University
    6721 Szeged
    Aradi v. tere 1.
    Hungary

  fax:     36-62-12292

  email:  h754esi@ella.hu
          h1299gai@ella.hu
          J68A004@HUSZEG11.BITNET

-----------------------------cut off here --------------------------------

  X   I am interested in FCT'93 and would like to receive further circulars.

  X   I plan to submit a paper.


      NAME:

      ADDRESS:



      Phone:

      Fax:

      Email:
From: wanka@uni-paderborn.de (Rolf Wanka)
Subject: Combinatorial Problem
Reply-To: wanka@uni-paderborn.de, brigitte@uni-paderborn.de
Organization: Uni-GH Paderborn, Germany
Date: Fri, 2 Oct 1992 14:31:34 GMT

Dear Theory Community:

I think the following problem has been investigated (and solved)
before it came to my desk.

Given: An m-sided d-dimensional array consisting of N=m^d nodes,
       numbered from (0,..,0) through (m-1,..,m-1).

Task:  Compute the number X of nodes that have exact distance i from
       the node numbered (0,..,0).

This number X is very easy determined on the hypercube, for instance, and
it is a nice exercise to compute X, if i<m.

But it seems difficult to give a general formula (consisting of
binomials, ...) for X.

So please, can someone give me a pointer to a textbook or other
relevant literature?

Thank you very much.

	Rolf Wanka
--------------------------------------------------------------------------
 Rolf Wanka                           | e-mail: wanka@uni-paderborn.de 
 Universitaet-GH Paderborn            | or:     wanka@pbinfo.uucp
 Fachbereich 17-Mathematik/Informatik | or:   ...!uunet!unido!pbinfo!wanka
 Warburger Str. 100                   | FAX:   +49 5251 603836
 D-W-4790 Paderborn, Germany          | Phone: +49 5251 603309
--------------------------------------------------------------------------
Newsgroups: comp.theory
From: hermann@uran.informatik.uni-bonn.de (Hermann Stamm)
Subject: Re: A Generalized Graceful Number
Reply-To: hermann@uran.informatik.uni-bonn.de (Hermann Stamm)
Organization: Praktische Informatik III
Date: Mon, 28 Sep 1992 09:55:34 GMT

Hello!

In article <9209241519.AA11392@hyowon.pusan.ac.kr>,
hgcho@HYOWON.PUSAN.AC.KR ("", Hwangue Cho) writes:
> 
>         Do you know any references for this graph labeling problem ?
> 
>         Problem : For a given graph, (especially complete graph),
>         we label the vertices with distinct positive integers f(x)
>         in { 1, 2, ..... } to have distinct edge (x,y) numbers, which
>         is labeled  | f(x) - f(y) |. Find the labeling which
> 	minimizes  max { f(x) }
> 
>         Comment : This problem is a generalized graceful numbering.
> 
> 	If you let me know about this problem, I will deeply appreciate it.


A simple solution for complete graphs on n vertices is:

  define f(v_i):=2^(i-1) , 1<=i<=n

This is a generalized graceful numbering.

On the other hand this is a perhaps to pessimistic choice, since
I tried the following:

  f(v_1):=1
  for i:=2 to n do f(v_i):= "lowest allowed number"

which results in 

  1,2,4,8,13,21,31,....

The 78th number (the last I generated) was less than 7500, and this is
much less than 2^(80-1).

Thus more work needs to be done to close the gap between 2^(i-1) and the 
best value ...


Bye,

   Hermann.
Newsgroups: comp.theory
From: sbloch@silver.cs.umanitoba.ca (Stephen Bloch)
Subject: Re: Halting problem
Organization: Computer Science, University of Manitoba, Winnipeg, Canada
Date: Tue, 6 Oct 1992 19:40:24 GMT

tolman%asylum.cs.utah.edu@cs.utah.edu (Kenneth Tolman) writes:
>     Let us suppose we construct a Turing machine which will solve the halting
>   problem.  It is special in that it recognizes its own coding sequence, and
>   stops with a special output character when it sees its own sequence.  This
>   Turing machine is not susceptible to the self reference paradox which
>   normally kills it.  What is wrong with this?

and burley@geech.gnu.ai.mit.edu (Craig Burley) replies:
>Hmm, I'm no theorist, but isn't the very wording of the halting problem one
>that requires a YES or NO answer?

This one's a red herring.  In fact, there is nothing special
whatsoever about a Turing machine that recognizes its own coding
sequence: by the Recursion Theorem it's quite easy to construct such a
machine.

>Another issue is that just because the machine recognizes it's own coding
>sequence (whatever that means) doesn't mean it will recognize the coding
>sequences of all programs that attempt to determine whether a given program
>halts given particular input.

This is the real issue.  The hypothesized Turing machine M recognizes
ITS OWN coding sequence, but not necessarily the sequence of the
machine M' I construct from it, which says (on input x)

"ask machine M whether machine M', given x as input, halts.
If so, go into an infinite loop; else halt."

Now, I feed machine M' its own encoding as input.  It asks M whether
M' halts given its own encoding as input; if it does, it doesn't, and
if it doesn't, it does.

One may say "but MY machine M recognizes its own coding sequence even
WITHIN another machine."  First, I doubt that's possible under all
the different encoding schemes the other machine might use to hide the
embedded M (M' now says "Decode the gibberish string '%)(*&&^$#(*&',
treat the result as a machine, and ask it whether...")  Second, I can
also construct machine M'', which says

"ask machine M whether machine M'', given x as input, halts.  Repeat."

and machine M''', which says

"ask machine M whether machine M''', given x as input, halts.  Halt."

These sorts of things are very hard to distinguish from M' and from one
another (in fact, distinguishing them in general is equivalent to the
Halting Problem).  Whatever M does with them, it'll be wrong on at least
one of the three.

-- 
					Stephen Bloch
				sbloch@silver.cs.umanitoba.ca
Newsgroups: comp.theory