HDTenEightyP/NetNews huggingface dataset:
From: harling@miki.pictel.com (Dan Harling)
Subject: Re: Voting Booths
Organization: PictureTel Corporation
Date: Mon, 16 Nov 1992 20:13:32 GMT

In article <palmer.721401771@news.larc.nasa.gov> palmer@icat.larc.nasa.gov (Michael T. Palmer) writes:
>...It seems every year
>I vote (at the SAME polling place) the machines are different.  One year
>the candidates will be listed in rows by office (columns = political
>party) and the next year it will be reversed.  And no matter which way
>they're listed, the flip handle is never really close enough to the
>name to give me a good feeling that I got the right one (notwithstanding
>the choice of candidates in the first place).
>
>And talk about lack of feedback... when you open the curtain, how do you
>know that your vote was really registered?  I'd like some positive way
>of knowing that I've been counted, like SEEING the punched paper ballot
>falling into the bin (or something like that).

By those standards, Massachusetts has a pretty good system.  The ballot
is printed on a piece of folded paper, and is marked with a pencil, so
the "controls" are pretty basic: mark an 'X' in the appropriate box,
which is clearly marked.

The completed ballot is re-folded and dropped into the ballot box
through a small hand-cranked machine, which pulls the ballot through
and rings a bell each time a ballot is submitted (and probably stamps
it too, but I don't know for sure).  Your name is crossed off three
lists: one when you receive your ballot, one when you hand it in, and
one when you leave.

It's pretty labor-intensive, as at least four people (usually six to
handle crowds) must be on hand to cross off names and turn cranks, but
I have more confidence in the process when a bunch of townsfolk are
keeping an eye on the place.  :-)
____________________________________________________________________________
Daniel A. Harling                        (harling@pictel.com)
PictureTel Corp.             Opinions expressed are not necessarily those of
Peabody, MA  01960                 PictureTel, but they ought to be!
Xref: sparky comp.human-factors:2667 comp.windows.x:19307
From: mattf@cac.washington.edu (Matthew Freedman)
Newsgroups: comp.human-factors,comp.windows.x
Subject: Click to Raise Windows vs. Point to Raise
Date: 18 Nov 92 22:28:50 GMT
Article-I.D.: u.1992Nov18.222850.2695
Followup-To: comp.human-factors
Organization: U.W. Information Systems

Has anyone ever really studied whether users, especially absolutely
naive, never touched a mouse in their life users, find windowing
systems more comprehensible when the windows raise and get focus when
the mouse merely points at them, vs. systems where you need to
actually click a button to raise/focus a window?

We have some public X-Terminals set up in our libraries, which run a
very limited system with just a couple available applications. When
the system was set up, many people felt that point-to-raise would be
easier for brand-new users to grasp. However, we have gotten many
complaints about this system, mainly because anyone who has used a
mouse before has done it on a Mac or MS-Windows, both of which are
click to raise. 

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? If not, unsubstantiated
personal opinion would be welcome too.

Please note that followups have been directed to comp.human-factors.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
= Matthew M. Freedman                                                 =
= U. of Washington Information Systems       mattf@cac.washington.edu =
= 4545 15th Ave. NE; 4th Floor               (206) 543-5593           =
= Seattle, WA  98105                                                  =
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Newsgroups: comp.human-factors
From: konstan@saturn.cs.umn.edu (Joe Konstan)
Subject: Solving the Unix rm problem, and others as well
Organization: Department of Computer Science, University of Minnesota
Date: Wed, 18 Nov 1992 18:25:40 GMT

Now that I finally have enough disk space to do so, I adapted Donald Norman's
rotating wastebaskets approach to cover rm as well as several other types of
files that I might need in the short term, but likely will not and certainly 
won't in the long term.

I have seven directories, .waste0 through .waste6, and rm is aliases to move
the item to .waste0.  So far, I haven't worried about name conflicts, though
I imagine I may put in code to handle that later.  Early each morning, the 
waste directories churn, cleaning out the week-old trash and creating a new
clean .waste0 for the next day.  If disk space becomes tight, I can churn
manually, or just really delete items selectively.

The side benefit is that I can create a whole bunch of temp files in .waste0.

For instance, I have all outgoing mail saved there.  Important mail is saved
elsewhere, too, but this way I never need worry about hearing that the mail
was accidentally deleted and discovering that I don't have an original.  Seven
days seems like enough to cover almost any such circumstance.  Similarly, I
put other temporary work which is likely to not be needed, but which I want to
have a chance of recovering for a while, in .waste0.  I do this with output
logs that are overwritten in place.  Once I've checked the new log, I can 
ignore the old one, but this way I have the old one available just-in-case.

Of course, this is a workaround (and a hack at that) to the real problem that
Unix doesn't have much of a way to help prevent these disasters (rm *).  
Coming from the lisp world, it seems to me that one answer would be to have
"Macro" programs that automatically are invoked with an un"globbed" command
line.  (I recognize that this would require a lot of major changes.  It is
only a design idea.)  In this way, rm and similar programs would be able to
tell that they were being called with suspicious-looking inputs and react
accordingly (for instance, being called with * and a file name 
a path is very likely to be an accidental added space).  Users could also
set up rm-defaults to specify when prompting should be done. 

I know tcsh has some inroads along this path.  File completion is programmable
by command (so rm can prefer .o to .c, but cc will prefer .c).  Maybe this
is the direction to go.

Joe Konstan
konstan@cs.umn.edu
From: atwoodj@xanth.CS.ORST.EDU (John Atwood)
Newsgroups: comp.human-factors
Subject: Re: should computers be the sole decision makers
Date: 16 Nov 92 18:32:37 GMT
Article-I.D.: flop.1e8pg5INN9nl
Organization: CS Dept, Oregon State University
NNTP-Posting-Host: xanth.cs.orst.edu


I recall a case in Florida where a construction company used Lotus 123 to estimate a job, got the bid, and found that the bid was too low.  They found that the
employee who used Lotus had incorrect formulas; it was something like she summedrows A thru M, where shee needed A thru N.

Theyt sued Lotus Dev. Corp, who, I think, was absolved.


John
From: atwoodj@xanth.CS.ORST.EDU (John Atwood)
Newsgroups: comp.human-factors
Subject: MAC eject disk into trash issue
Date: 16 Nov 92 18:48:31 GMT
Article-I.D.: flop.1e8qdvINNac0
Organization: CS Dept, Oregon State University
NNTP-Posting-Host: xanth.cs.orst.edu

A fairly well known user interface problem how, on an Apple Macintosh,to eject a disk, you must drag it to the trash can.  This feels wrong, of course, but stems from the original Mac with 1 diskette drive (You could swap disks but have both still on the desktop, such as a program disk and data disk).  

This problem has entertained me for years, but now that I'm a regular mac user, I decided to do something about it.  I created an alias for the trash can, called _Eject Disk_, clipped the diskette icon (in get info) from a diskette, and pasted it as the alias' icon.

It sits beside the trash, and now I feel much less agita when I'm under dead-
line.

So, my questions:

Is this a waste of time, or is it worthwhile?

If it's worthwhile, is this the best way to do it?

Should I keep it down near the trash, or should I keep it somewhere else, like
up top, on the top right of the screen?


John Atwood
Newsgroups: comp.human-factors
Subject: Re: The Problem With UNIX
From: alanb@sdl.mdcbbs.com (Alan Braggins)
Date: 19 Nov 92 17:37:18 GMT
Organization: Shape Data (Division of EDS), Cambridge UK
In-reply-to: mathew@mantis.co.uk's message of 15 Nov 92 13:08:36 GMT

>>>>> On 15 Nov 92 13:08:36 GMT, mathew@mantis.co.uk (mathew) said:

> qb7g6@fel.tno.nl (Maarten Landzaat) writes:
>> "rm * .c" (when you really want "rm *.c")
>> 
>> I think Unix (well, actually the shell is to blame) should always ask
>> for permission when the star is used with rm. 

> When I use UNIX I alias rm to mv files to a directory ~/wastebasket, which is
> automatically cleaned out using /bin/rm in my logout script.

I've used a sytem which did this - I just got into the habit of
emptying the wastebasket after every delete - it was quicker than
selecting the "really delete" option.
If I ask to delete stuff, I want the disk space available. If I
wanted to move it, I would have used a move command.
--
     Alan Braggins, alanb@sdl.mdcbbs.com, abraggins@cix.compulink.co.uk
Shape Data - A division of EDS-Scicon Limited.   Cambridge, UK +44-223-316673
   "Any technology distinguishable from magic is insufficiently advanced."
 "My employer does not necessarily share my views - but I'm working on it."
Newsgroups: comp.human-factors
From: ematias@explorer-dgp.dgp (Edgar Matias)
Subject: Re: Seperation of Church and Elevators
Organization: CSRI, University of Toronto
Date: 20 Nov 92 21:37:40 GMT


> > For this particular case, I think that a horizontal representation,
> with > "left" and "right" arrows, would do much better. I find it
> natural to think a > the "right" direction as the direction where
> things increase (probably > because texts grow rightwards). And, if
> you spatialise numbers, you get > > 0 1 2 3 4 . . . > > which also
> works. 
> 
> Sounds like an excellent idea.

Not too me...

                   1

                 100

                1000

               10000


Looks to me like numbers "grow" to the left; not the right.  Here's
my point: we all have weird notions of how things should be and what is
and isn't intuitive.  And by "weird", I actually mean "subjective".
The elevator in question was designed for use by the average person;
not for any one person.  I think using an up arrow to indicate "up" would
be understood by most people.  Don't you?  ?-)

> mathew@mantis.co.uk (mathew)
> >bassi@cs.unibo.it (Bruno Bassi) writes:


Edgar
-- 
Edgar Matias
Input Research Group
University of Toronto
--
I speak for no one...
From: mike@isgtec.com (Mike Sellers)
Newsgroups: comp.human-factors
Subject: Re: Dan Bricklin Demo II and Protoscreens
Date: 15 Nov 92 23:24:13 GMT
Organization: ISG Technologies Inc., Mississauga Ontario

rolandi@hssc.scarolina.edu (Walter Rolandi) writes:
> Earlier I had posted a request for information from users of Dan
> Bricklin's Demo II and/or Protoscreens.  I'd like to find out what 
> users see as each system's particular strengths and weaknesses.  I
> expected to get a dozen or so responses, summerize them, and post
> the results.

I've never heard of either of these.  Can you briefly describe them
for us?  What do they do and what environment (DOS, Unix, etc.) are 
they intended for?  

> What tools do HCI human factors folks use for interface prototyping
> these days?

I use pencil and paper, whiteboards, modelling clay (for input devices),
and the Builder Accessory from ICS for prototyping UIs in X/Motif.
BX is pretty quick and flexible, as long as you don't try anything 
out of the ordinary.  That is, you can prototype up lots of vanilla
Motif widgets, but forget trying to show snappy pictorial dynamics
or anything.  For that I go straight to Xt/Xlib.  Sigh.  

Official Usability Thought Police Disclaimer (I want to keep my
license):  Of course, no tool works real well in the absence of actual
user data.  You can make hideous UIs with even the best tools -- only
you make them faster. :-/

What other tools do people use, especially for X UIs?

--
              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: bergland@edb.uib.no (Magne Bergland)
Subject: Re: should computers be the sole decision makers
Organization: University of Bergen
Date: Mon, 16 Nov 1992 07:56:36 GMT

In article <92320.144804FR5641A@auvm.american.edu> Fadi A. Rabie <FR5641A@auvm.american.edu> writes:

>Organizations are depending on computer information to aid them in their
>  decisions.   should these computers be the one who make  the decision
>   instead of humans?

The question is wrong! Computers _can't_ be sole decision makers. If 
a program "makes a decision" then really the person who designs the program 
makes the decision. Thus letting the computer "make the decision" really 
means relegating the power of decision to system designers.

I warmly recommend the book "Understanding Computers and Cognition" by 
Terry Winograd and Fernando Flores to anybody interested in this problem
matter.

 - Magne

Magne Bergland                             Bergland@edb.uib.no
Computing Centre, University of Bergen     TEL: +47 5 54 42 15
Edb-senteret, HiB, 5020 Bergen, Norway     FAX: +47 5 54 42 99
From: pstevens@cage.gssec.bt.co.uk (Perdita Stevens)
Newsgroups: comp.human-factors
Subject: Re: Voting Booths
Date: 16 Nov 92 12:47:19 GMT
	<1992Nov10.140552.8706@saifr00.cfsat.honeywell.com>
	<96997@netnews.upenn.edu> <xhqczoy@Unify.Com>
Organization: BT Glasgow Systems and Software Engineering Centre, Scotland.

Following on from discussion of various "primitive" voting machines in
use in the US, I'd like to point out that in the UK we still put a
pencil cross next to the name of our preferred candidate on a piece of
paper; the votes are counted (and frequently recounted) by people.
Mechanisation? Work of the devil!

Perdita Stevens
definitely not speaking for my employer.
Xref: sparky comp.human-factors:2688 comp.windows.x:19381
From: brand@csgrad.cs.vt.edu (Jeff Brandenburg)
Newsgroups: comp.human-factors
Subject: Re: Click to Raise Windows vs. Point to Raise
Summary: you can't point just one
Date: 21 Nov 92 02:23:39 GMT
Organization: VPI&SU Computer Science Department, Blacksburg, VA

In article <1992Nov18.222850.2695@u.washington.edu> mattf@cac.washington.edu (Matthew Freedman) writes:
>Has anyone ever really studied whether users [prefer point-and-raise/focus
>or click-and-raise/focus?]

not me, but...

>If not, unsubstantiated personal opinion would be welcome too.

I have the same Mac/Windows bias you mentioned, but I can raise (focus?)
at least two arguments in favor of click-to-raise.

1) Cursor position is volatile.  Mouse cursors wander in response to
vibration or bumps, leading to sudden unwanted shifts in focus.  This
can be irritating or disastrous.

2) In moving the cursor to one object, one sometimes must pass over other
objects.  If these are windows, each rising in turn, the resulting flurry
may at least be distracting; at worst, one of the intermediate windows may
rise to cover your eventual destination.  In addition, mouse sampling rates
may allow you to skip over intermediate windows without raising them.

These factors yield interfaces prone to sudden, drastic, and unpredictable
changes.  This seems like the last thing you'd want for novice or occasional
users -- or, for that matter, expert ones.

	-jeffB (Jeff Brandenburg, Va. Tech CS)
Newsgroups: comp.human-factors
Subject: Re: robots in our bodies
From: fieldls@ponews.ponca.dupont.com  (Lee S. Fields)
Date: Tue, 17 Nov 1992 08:28:26
NNTP-Software: PC/TCP NNTPLines: 16

In article <1992Nov16.223231.11974@bsu-ucs> 00jhritter@leo.bsuvc.bsu.edu writes:

 >> I have been hearing a lot lately about the possibly that some day robots will
 >> become so small that they could be injected into the blood stream to fight  
 >> diseases or clean out clogged artieries.  Does any think this is possible?
 >> Does any think this could lead to mind control?  How would this effect our
 >> future?  Please reply, my grade depends on it!!

For more information on this, try reading Eric Drexler's (sp?) books on
the subject of nanotechnology.  His first one is titled "Engines of
Creation" and the title of his more recent one escapes me.  Both analyze
uses and mis-uses of this technology and are entertaining to read.

Lee
From: craig@ec.uwa.oz.au (Craig Richmond - division)
Newsgroups: comp.human-factors
Subject: Re: Click to Raise Windows vs. Point to Raise
Date: 24 Nov 1992 00:12:32 GMT
Organization: The University of Western Australia
NNTP-Posting-Host: decel.ecel.uwa.edu.au

fj_maddi@csd.uwe.ac.uk (FJ Maddix) writes:

>This is personal opinion, but:
>Click-to-raise involves a voluntary attention switch (ie to the input focus)
>whereas point-to-raise could just result in confusion as unrelated windows
>(all but one of which you do not need) pop up and down.

Ever bumped the mouse and started typing into the wrong window with
disasterous results?

Craig
--
Craig Richmond.  Computer Officer -  Dept of Economics (morning) 380 3860
  University of Western Australia    Dept of Education (afternoon)
craig@ecel.uwa.edu.au Dvorak Keyboards RULE!  "Messes are only acceptable
if users make them.  Applications aren't allowed this freedom" I.M.VI 2-4
From: pnsf01dw@UMASSD.EDU (Dennis J. Wilkinson)
Newsgroups: comp.human-factors
Subject: Re: Scientific support for GUIs?
Date: 17 Nov 92 14:25:06 GMT
Article-I.D.: umassd.Bxv6pv.2o7
Reply-To: pnsf01dw@UMASSD.EDU
Organization: UMASS DARTMOUTH, NO. DARTMOUTH, MA.

In article <1992Nov17.102543.1@cc.helsinki.fi>, mlindholm@cc.helsinki.fi writes:
>Why haven't I ever seen an article, where the graphical (destop
>metaphor) and command-line user interfaces had been compared?  
>In other words, is there any objective support to Apple's claims, 
>that the Macintosh interface is easier to learn and that people 
>are more productive when using Macintoshes?

Try-

Whiteside, J., Jones, S., Levy, P.S., and Wixon, D., _User Performance with
   Command, Menu, and Iconic Interfaces_, in the Proceedings of ACM CHI'85
   Conference on Human Factors in Computing Systems, 1985, pp. 185-191.

If I remember the article, the gist of it is that, although in the end interface
style is not related to performance level, the learning curve for iconic
interface systems is much shorter (learning is faster). 

----------------------------------------------------
Dennis J. Wilkinson, II  (pnsf01dw@umassd.edu)
University of Massachusetts Dartmouth - Design/CS Project

The opinions reflected in this post are MINE!!!! ALL MINE!!!!!
Newsgroups: comp.human-factors
From: cockrill@uokmax.ecn.uoknor.edu (Jeremy Cockrill)
Subject: Re: MIS/IS MANAGER problems with employees?
Date: Sat, 21 Nov 1992 20:48:55 GMT
Organization: Engineering Computer Network, University of Oklahoma, Norman, OK, USA

00twgivens@leo.bsuvc.bsu.edu writes:


>	With all of the new and advancing technologies in the area of MIS/IS,
>users are becoming more and more fimiliar and educated in these areas.  As a
>soon-to-graduate senior at Ball State majoring in MIS/CS, are there any 
>problems with how much knowledge these end-users have?  Do they know too much? 
>Are employees becoming too literate for the MIS/IS manager to control???

>Has anyone encountered problems with this? (i.e.  employees deleting files,
>security problems with employees, employees using their own software instead of
>company requested software, editing of bat, exec files, etc.)

I hate to nit-pick or sound like a flamer, but your sentence "Are employees
becoming to literate for the MIS/IS manager to control???" struck a chord
within me.  As a MIS/CS student, you should know that it is not the place
of a manager to "control" the users.  Instead, the manager should "manage"
the resources of the firm; one of the resources being the talents and 
knowledge of the employees. 

You are correct, however, in stating that users are becoming more familiar
and educated in the areas of the advancing technologies.  This may make
it more difficult for the manager to manage such resources if he or she
has no idea of the resources (knowledge) available.  But, as a MIS/CS
student, you should also understand that any technological field is not
static -- you will have to keep up with technology at, or above, the level
of the "typical" user in order to remain valuable as a manager.  But that's
one reason that you chose MIS/CS, no?

--Jeremy Cockrill
From: stevem@dcs.glasgow.ac.uk (Steve McGowan (RA))
Newsgroups: comp.human-factors
Subject: Re: should computers be the sole decision makers
Date: 16 Nov 92 09:35:58 GMT
Organization: Computing Sci, Glasgow Univ, Scotland

In article <bergland.14.721900596@edb.uib.no> bergland@edb.uib.no (Magne Bergland) writes:
>
>The question is wrong! Computers _can't_ be sole decision makers. If 
>a program "makes a decision" then really the person who designs the program 
>makes the decision. Thus letting the computer "make the decision" really 
>means relegating the power of decision to system designers.
>

	I think this ties in with an old legal case (which I can't remember
	the outcome of), which centered along the use of expert systems as
	information providers/decision support tools.

	The case, as vague as it is in my mind, concerned a prosecution by
	a company which took the advice generated from an expert system.
	Ultimately, it turned out this information was incorrect, and cost
	the company dearly.

	The question then arose of who was to blame - the knowledge engineer, the
	expert(s), the software engineer, the software company that sold the
	expert system, etc.

	No doubt there are numerous other similar cases, but it's an interesting
	question. One would hazard a guess that it would be the company who
	would be culpable - unless, of course, each employee signed a statement
	'disowning' the company from employee's mistakes.


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

"...scalpel.....sutures.....clamp......oopps.....pen....death certificate...."

------------------------------------------------------------------------------
From: hugh@rschp1.anu.edu.au (Hugh Fisher)
Newsgroups: comp.human-factors
Subject: Re: Mouse-warping considered harmful
Date: 22 Nov 1992 22:33:46 GMT
Organization: Research School of Chemistry, ANU
Distribution: world
NNTP-Posting-Host: 150.203.35.20

  I hate mouse warping. Every time it happens in Open Windows
  there is a delay while I find the cursor again, and another
  delay since my first reaction on seeing a dialog appear is
  to move the cursor towards it - which because of the mouse
  warping actually takes it away.

  IMHO, mouse warping used in conjunction with popup menus and
  dialog boxes is an example of either plain laziness or the
  old "control the user" mentality on the part of the programmers.
  I suspect that most of these foul systems have the coordinates
  for the dialogs hardcoded somewhere, or hardcoded in X resource
  files. Mouse warping got added on by somebody who thought it
  would be more "efficient" to cut out the mouse movement.
  
  As a example of how it ought to be done, check out the Silicon
  Graphics 4Sight Window Manager in which dialogs pop up under
  the current mouse location.

	Hugh Fisher