HDTenEightyP/NetNews huggingface dataset:
From: rick@hci.hw.ac.uk (Rick Innis)
Newsgroups: comp.human-factors,comp.windows.misc
Subject: Tools vs Apps (was Re: GUIs Considered Harmful)
Date: 12 Sep 92 20:44:35 GMT
	<1992Sep6.213030.10658@news.cs.indiana.edu>
	<1992Sep7.171210.21141@news.arc.nasa.gov>
Followup-To: comp.human-factors
Organization: Computer Science, Heriot-Watt University


(I set this to followup to comp.h-f on the grounds that I'm mainly talking
about artifact design; if anyone can think of a better place for it please let
me know.)

In article <1992Sep7.171210.21141@news.arc.nasa.gov> Kevin Connery writes:

   This may be a naive question, but how does one distinguish 'tools' from
   applications when all executables have to be invoked using a GUI approach?

Is there a distinction, even in a CLI environment?  I would suggest an
application does some general class of tasks (eg, edit text) while a tool
does one specific task (eg, print lines of a text file that contain some
pattern you're looking for.)  The distinction gets blurry after a point; what
about something which which lets you find lines in a text file that match a
pattern, then execute a sequence of user-defined operations on them?  Is awk
a tool or an app?  Or is it a tool(kit?) used to create applications?

Perhaps you could argue that in a GUI environment "applications" are those
things on the desktop and "tools" are what are commonly known (in Macintalk,
anyway) as Desk Accessories.

One problem with the way things work in the (non-UNIX) GUI world is that many
things are strongly-typed.  A document has a "type" which depends on the
application whch created it.  If the application (or tool) you're using
doesn't understand this "type", you have a problem (or you hack it, but I'm
talking about J. Average Luser here.)

Now, what about a solution?  Here's a first cut, thought up on the fly
(though I'm sure someone out there has tried it).  Instead of applications
defining document types, let the system define them; have documents be
objects that respond to messages, then your application/tool need only know
the protocol needed to talk to the document.  It's always bugged that I can't
"grep" things on a Macintosh.  This kind of approach would let me.

	--Rick.
--
Rick Innis, Computer Science, 	| "Has anyone seen the secret of the universe?"
Heriot-Watt University, 	| said Zebedee, arriving. "I know I left it 
Edinburgh, Scotland.		| around here somewhere."
rick@cs.hw.ac.uk		|  -> My opinions, not the University's. <-
From: fmm+@CS.CMU.EDU (Francesmary Modugno)
Newsgroups: comp.human-factors
Subject: HCI/User Interface Reading List
Date: 8 Sep 92 20:33:48 GMT
Article-I.D.: cs.BuA14J.II5.1
Organization: Carnegie Mellon University


I am looking for reading lists or syllabi
from general survey-like seminar or courses
in Human Computer Interaction or User
Interfaces.  If you have one online, please
send it to me (fmm@cs.cmu.edu).  If it was
a reading list for a course or seminar, a brief description of the goal of the course
(or preferably the cours syllabus) would
be helpful, so I know the intended purpose
of the list.

Thanks!
Newsgroups: comp.human-factors
From: Allen Renear
Subject: Re: Evaluating Layout?
Organization: Brown University  CIS
Date: Tue, 15 Sep 1992 01:17:43 GMT

Hartley (James I think) has written many articles and at least one book that
cover issues related to the effectiveness of layout.  *Designing Instructional
Text* I think is the name of the book.  May Katzen has also written related
articles.  A monograph by her has the title something like: *The Visual Impact
of Journals*.  

In article <Ieh_LLS00VQkEA71QA@andrew.cmu.edu> tg0r+@andrew.cmu.edu (Terilyn
Gillespie) writes:
>
>I have already posted this question to netnews.comp.text.desktop, which
>no response, so though I'd give a try here--besides,I thought it would
>be nice to see a different subject line for a change!
>
>Anyway, here goes:  I am interested in learning about ways to evaluate
>the effectiveness/"usability" of a particular format or layout--in this
>particular instance, I'm talking about the design of a newsletter.  I
>don't want to evaluate the usability of the *text*, but rather the
>actual layout & format design.
>
>On the one hand, I sort of think it might be best to have two proposed
>designs and compare those--that may be the optimal case, however.  I
>figure that if I can decide how to measure people's responses
>to/dislikes/likes between two proposed designs, I should just as well be
>able to assess those on one design.  My real problems, however, have to
>do with how you would measure a person's response--I'd rather gather
>more information than just aesthetic preferences, although those will be
>important too.  But how do I measure how well the format "presents"
>information, moves the reader's focus, etc.   I have done my fair share
>of usability studies, but they have all dealt either specifically on the
>particular interface or on the comprehensibility of a document--I just
>have no point of reference on how to go about evaluating layout alone.
>
>Does anyone have ideas on how to go about this?  Any references to
>relevant work?  Any and all thoughts and discussions are greatly
>encouraged!  Thanks.
>
>Terilyn Gillespie
>Computing Services
>Carnegie Mellon University
>tg0r@andrew.cmu.edu
>


Newsgroups: comp.human-factors
From: rodneyp@tplrd.tpl.oz.au (Rodney Parkin)
Subject: Re: MS Windows GUI Application Guidelines
Originator: rodneyp@sydrd20
Organization: Telectronics Pacing Systems
Date: Wed, 09 Sep 92 05:13:09 GMT

In article <laf6jeINNht7@news.bbn.com> adolce@bbn.com (Anne Dolce) writes:
>   I think the book you want is "The Windows Interface: An Application
>   Design Guide" (Version 3.1).  I may be wrong, but I think you can
>   only get this book when you order the MSW 3.1 toolkit.  The book is
>   published by Microsoft. There is no ISBN number listed in the front.
>
>   You probably need to call Microsoft to see if you can get the book
>   by itself.

I have a copy of this book.  I bought it in a bookshop. 
The ISBN *is* inside the front of my copy.
It is ISBN 1-55615-384-8.



-- 
Rodney Parkin, System Design Engineer.   ______T_e_l_e_c_t_r_o_n_i_c_s__|/\  __
   Telectronics Pacing Systems,                        Pacing  Systems     \/
   7 Sirius Rd, Lane Cove, NSW 2066, Australia.
   Tel: (02) 413 6946  Fax: (02) 413 6060
From: wiebe@unity.ncsu.edu (Eric Wiebe)
Newsgroups: comp.human-factors
Subject: Re: American Disabilities Act
Date: 10 Sep 92 16:52:42 GMT
Organization: North Carolina State University Project Unity

In article <8eeqj7i00iUxE1Zb5e@andrew.cmu.edu>, lk1j+@andrew.cmu.edu (Lawrence Kim) writes:
|> 
|> 
|> Help !
|> 
|>     I am doing research into accessbility of the 'physically challanged'
|> at Carnegie Mellon Univ. The main issue is designing a computerized
|> 'Kiosk' that would be accessible to those defined as disabled in the
|> American Disabilities Act of 1990(ADA) .
|>     My problem is that my background is strictly in Information Systems
|> with little exposure to Human Factors or Ergonomics. Thus, I am not
|> aware of the concerns of the Physcially challanged in terms of GUI, or
|> plain-interfaces with a computer. 
|>     I would appreciate it greatly if someone, could direct me to
|> information concerning ADA and Computer Systems- Such as Intrest Groups,
|> Hardware and Software Vendors, and guidlines. 
|> 
|> Thank You
|> 
|> Larry Kim 
|> 
|> 
|> Lawrence D. Kim                            Internet: lk1j@andrew.cmu.edu
|> Information Decision Sciences              ATTmail:  lkim@tweel.attmail.com
|> Carngie-Mellon University

The Center for Accessible Housing is located in Raleigh, NC and acts as a clearinghouse for a lot
of ADA related material. Also of note is Interact '93, which will be held in Raleigh this spring.
Interact '93 is sponsored by the Consumer Products Technical Group of the Human Factors Society (HFS)
, the Carolina Chapter of HFS, the NC State Univ. student chapter of HFS, and the Industrial Design
Society of America's local chapter. The Center for Accessible Housing will be involved with this
conference and there will be sessions on both ADA and HCI related topics.

Sorry I don't have more specific info at my fingertips right now, but I'll try to do a formal
posting for Interact '93 soon.

<===========================================================>
Eric N. Wiebe                     E-Mail: eric_wiebe@ncsu.edu
Graphic Communications Program    Phone: 919-515-2234
North Carolina State U.           Fax: 919-515-7634   
Box 7801 - 510 Poe Hall
Raleigh, NC 27695-7801
Newsgroups: comp.human-factors,comp.windows.misc
From: keradwc@news.arc.nasa.gov (Kevin Connery)
Subject: Re: GUIs Considered Harmful
Organization: Nasa Ames Research Center, Moffett Field, CA
Date: Mon, 7 Sep 1992 17:12:10 GMT

In article <1992Sep6.213030.10658@news.cs.indiana.edu> 
mvanheyn@whale.cs.indiana.edu writes:

>Because the Macintosh stops you from doing stupid things, it
>also stops you from doing clever things.  Talking directly to the
>printer in some sort of raw mode should not require a special
>application; at most, it should require a special tool.

This may be a naive question, but how does one distinguish 'tools' from
applications when all executables have to be invoked using a GUI approach?
With a CLI, the user is shielded from needing to know whether 'commanda' is
a part of the os, a default-specified (path) executable, or a user-specified
executable. Which is all well and good -- but it doesn't mean that that
particular approach is _the_ right one.

Nevertheless, could someone provide an example - or pair of examples -
showing a GUI 'special tool' as opposed to a 'special application'? The
distinction escapes me.

 |--------------------|--------------------------|---------------------------|
 | Kevin Connery      | Quality must be designed |   Speaking FROM, not FOR: |
 |                    | into software; it cannot |   Integrated Systems, Inc |
 | kconnery@isi.com   | be patched on afterwards |           Santa Clara, CA |
 -----------------------------------------------------------------------------
From: marc@tanda.isis.org (Marc Thibault)
Reply-To: marc@tanda.isis.org
Newsgroups: comp.human-factors
Subject: Re: GUIs Considered Harmful
Date: Fri, 04 Sep 92 17:11:08 EDT
Distribution: world
Organization: Thibault & Friends

In article <TmBHqB5w165w@mantis.co.uk> 
mathew  writes: 
    ....
> I mean, your "mv *.txt ..." on the Mac is "Choose view by type, drag select
> the text files, drag to the destination."  This doesn't seem to me to be
> harder than the command line way of doing it, especially given that
> understanding wildcards is actually quite tricky for normal people.

    Please.. give us a break. Try "point, click and drag to find the
    source folder and open it, point, click and drag to find the
    destination folder, point, click and drag so both source and
    destination are visible on the screen, _then_ choose view by type,
    drag select the text files, drag to the destination, point click
    and drag to clean up the mess you've made.

    There are many things mice are good for, but this ain't one of
    them.
> 
> I'm not saying there aren't things which a GUI can't do well, I'm just asking
> if you can give us a few examples.
> 
    A GUI can do everything well if it supports a CLI and scripts.
    These are not mutually exclusive. At least PC users have the
    benefit of a few aftermarket Windows CLI's as well as more
    task-oriented shells to replace progman.exe. I don't know whether
    it's the overwhelming nature of the One True Mac Religion, or the
    fact that Mac programming is a PITA, but I haven't seen a CLI for
    the Mac.

    Unfortunately, too many people think that GUI means mouse and
    desktop. There are other ways to use a GUI effectively. The people
    in this group calling for standards might want to consider that it
    is much too early to put this issue in stasis. There is still a
    lot of experimenting to be done re the good ways to design a GUI.
    The most successful GUI's out there are interfacing popular games.
    None of them look like desktops and few use a mouse.




---
 Marc Thibault        |                              |  Any Warming,
 marc@tanda.isis.org  |  Oxford Mills, Ontario       |  Global or otherwise,
 CIS:71441,2226       |     Canada                   |   appreciated.
From: friday@netcom.com (Carol Anne Ogdin)
Newsgroups: comp.human-factors
Subject: Re: Mandatory vs. Optional Values in Forms
Date: 13 Sep 92 20:39:18 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)


>Many GUIs allow fields in a form to be made *inactive* or `greyed-out',
>indicating that the field is not applicable.

>Of the remaining *active* fields, I think it may be useful to have a way of
>indicating whether or not a given field is *optional* or *mandatory*.

>My first question is: Would this be good thing from an H-F standpoint, or am I

I dunno.  I'm of two minds on this one.

Assume we need it:  It's just another "marker" to confuse the user;
how to you mark *requisite* from *optional* fields in a way that
makes sense.  It seems that today's approach is to have the user
fill in what they know, and then show an error message if they've
missed.  So, the marker is either there ALL the time (and people
have to learn how to make the distinction, a potential complexity),
or there only when it's needed (the error message).

Since I favor "progressive disclosure" (that is, showing only what's
needed, and dynamically adding options as the user fills in the
requisite material), I guess I fall on the "leave it alone" side
of the question.  I don't like non-intuitive codings (the greying-
out is clear and unambiguous; how would you propose to code the
*requisite* distinctly from the *optional*), so the how may become
mixed up with the "whether" it's valuable.

Just one ill-thought-out opinion.  YMMV
-- 
---   ---   ---   ---   ---   ---   ---   ---   ---   ---   ---   ---
    - Friday -                      "Practice random acts of kindness 
      friday@well.sf.ca.us                      and senseless beauty."
      (aka Carol Anne Ogdin@Santa Clara, CA)
Newsgroups: comp.human-factors
From: jon@afs.com (Jonathan Hendry)
Subject: Re: GUIs Considered Harmful
Distribution: USA
Date: Tue, 8 Sep 1992 15:11:31 GMT

In article <1992Sep1.233227.12778@sserve.cc.adfa.oz.au>  
ghm@ccadfa.cc.adfa.oz.au (Geoff Miller) writes:
>neeri@iis.ethz.ch (Matthias Neeracher) writes:
>

>But I thought that the great advantage of the Mac was supposed to be that
>it provided power to the casual user.

But you are a power users who wants the mac to accomodate your power user  
needs, not really a "casual" user. Or, put another way, you're a casual user  
(of the mac) with power-user expectations which are geared towards the CLI  
platforms you generally use.

I'm not really happy with the Mac, either. I was, until I started working on  
NeXT's. I definitely prefer the availability of a CLI when I need it. This from  
a person who never used Unix before last fall.

Oh, and there is a Mac "CLI" type thing now. It's called Frontier, and is sort  
of like writing shell scripts, except they use system 7's Apple Events.
--
Jonathan Hendry  Anderson Financial Systems
jon@afs.com  (Nextmail Welcome!) or hendryjw@duvm.ocs.drexel.edu
From: chrisw@chopin.FtCollins.NCR.com (Chris Whitley)
Newsgroups: comp.human-factors
Subject: RE: language design tradeoffs
Date: 9 Sep 92 15:13:50 GMT
Reply-To: chrisw@chopin.FtCollins.NCR.com (Chris Whitley)
Organization: NCR Microelectronics, Ft. Collins, CO

> I have thought of taking
> each command line and doctoring it (adding ; and string quotes, etc.)
> to make it a legal statement in the language, but I'd prefer it if
> users didn't have two see two different types of syntax. 

You could update their command line for them automatically on
screen, and accept input either way.

i.e.

user types--  acommand "astring

(and then hits return or shifts focus or whatever signals 'ready')

command line is auto-updated to-- acommand "astring";

It would also be fine for the user to type-- acommand "astring"
                                        or-- acommand "astring";

This way, the user doesn't really see 'two different types of
syntax'...they seem automatic command completion!

---------------------------------------------------------------
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: denelsbe@washington.cs.unc.edu (Kevbo)
Newsgroups: comp.human-factors
Subject: Re: Moderated Human-Factors Newsgroup
Date: 7 Sep 92 00:17:23 GMT
Organization: The University of North Carolina at Chapel Hill

In article <6172@taurus.cs.nps.navy.mil> estheise@cs.nps.navy.mil (eric theise) writes:
)I think this is a good idea.  I'd like to propose that we form a new, 
)moderated newsgroup: sci.ergonomics.  This newsgroup would promote 
)dialogue relating to the discipline known variously as ergonomics, 
)human factors, man-machine interaction, and/or human-system integration.
)Topics could include physical and mental ergonomics, workplace design,
)design of displays and controls, and more.  I imagine this newsgroup
)being devoted to the whole of ergonomics, not just human-computer 
)interface.

I like the idea, but dislike the proposed name, and so I counterpropose

	comp.human-factors.moderated

This would keep the new group in the same hierarchy as its progenitor, in
much the same way as (for example) rec.humor and rec.humor.funny are, though
without the pretentiousness.  I also think "human-factors" is more descriptive
(and less restrictive) than "ergonomics".
 
)I'd expect postings to be backed up by data or theory from the literature
)or lab, and not from casual empiricism.  Humor, job postings, and 
)commercial announcements would also be welcome.  I imagine a tone similar
)to Bob Jacobson's sci.virtual-worlds.

As someone else has already mentioned, comp.compilers is run quite well, with
the moderator often injecting highly useful advice.  I'm not a follower of
sci.virtual-worlds, but if it's anything like comp.compilers then much will
get accomplished.

)And, yes, I'd be willing to serve as moderator.  More discussion would be
)welcome.

You've got my vote.

)We return you now to our regularly scheduled harmful GUIs ...
)
)= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
)  Eric S. Theise                             
)  Human-System Integration Lab               estheise@cs.nps.navy.mil  
)  Naval Postgraduate School                    estheise@well.sf.ca.us
)  Monterey, CA 93943-5000

Kevin

-- 
|| +------------------+  You Yankees are so silly 
||-| Kev @ UNC        |  About matters of the heart;
||-| Master Poetaster |  Don't you know that women are the only works of art?
|| +------------------+        -- Don Henley, "Drivin' With Your Eyes Closed"
From: tg0r+@andrew.cmu.edu (Terilyn Gillespie)
Newsgroups: comp.human-factors
Subject: Evaluating Layout?
Date: 14 Sep 92 14:46:47 GMT
Organization: Editing, Carnegie Mellon, Pittsburgh, PA


I have already posted this question to netnews.comp.text.desktop, which
no response, so though I'd give a try here--besides,I thought it would
be nice to see a different subject line for a change!

Anyway, here goes:  I am interested in learning about ways to evaluate
the effectiveness/"usability" of a particular format or layout--in this
particular instance, I'm talking about the design of a newsletter.  I
don't want to evaluate the usability of the *text*, but rather the
actual layout & format design.

On the one hand, I sort of think it might be best to have two proposed
designs and compare those--that may be the optimal case, however.  I
figure that if I can decide how to measure people's responses
to/dislikes/likes between two proposed designs, I should just as well be
able to assess those on one design.  My real problems, however, have to
do with how you would measure a person's response--I'd rather gather
more information than just aesthetic preferences, although those will be
important too.  But how do I measure how well the format "presents"
information, moves the reader's focus, etc.   I have done my fair share
of usability studies, but they have all dealt either specifically on the
particular interface or on the comprehensibility of a document--I just
have no point of reference on how to go about evaluating layout alone.

Does anyone have ideas on how to go about this?  Any references to
relevant work?  Any and all thoughts and discussions are greatly
encouraged!  Thanks.

Terilyn Gillespie
Computing Services
Carnegie Mellon University
tg0r@andrew.cmu.edu
Newsgroups: comp.human-factors
From: bsherman@s27w007.pswfs.gov (Bradley K. Sherman)
Newsgroups: comp.human-factors
Subject: Re: Moderated Human-Factors Newsgroup
Date: 7 Sep 1992 02:00:00 GMT
Organization: Institute of Forest Genetics DataBase
NNTP-Posting-Host: s27w007.pswfs.gov

>)I think this is a good idea.  I'd like to propose that we form a new, 
>)moderated newsgroup:

There isn't nearly enough traffic in this group to warrant the
need for moderation.  There is already comp.cog-eng which overlaps
this group.

It's not like the screwy-gui cross-posting interrupted any vigorous
discussions.  Personally, I like hearing what programmers have to say
about computer interfaces --after all, they use them more than anyone
else.

    --Brad Sherman
Newsgroups: comp.human-factors
From: mark@hsi.com (Mark Sicignano)
Subject: Re: MS Windows GUI
Organization: 3M Health Information Systems, Wallingford, CT.
Date: Mon, 7 Sep 1992 03:31:55 GMT

In article <laf6jeINNht7@news.bbn.com> adolce@bbn.com (Anne Dolce) writes:
>   I think the book you want is "The Windows Interface: An Application
>   Design Guide" (Version 3.1).  I may be wrong, but I think you can
>   only get this book when you order the MSW 3.1 toolkit.  The book is
>   published by Microsoft. There is no ISBN number listed in the front.
>
>   You probably need to call Microsoft to see if you can get the book
>   by itself.
>

When I called Microsoft, they didn't seem to have a clue about the book.
I even called the number which was included in a press release that
announced the book.  

They gave me a number to call, but I don't have it in front of me.
It was for the "Microsoft Press", and I think it was an 800 number,
so call 800 information.  I bought the book directly through them.

-mark
-- 
Mark Sicignano                                  ...!uunet!hsi!mark
3M Health Information Systems                   mark@hsi.com
From: johnson@nrtc.northrop.com (Greg Johnson)
Newsgroups: comp.theory
Subject: cute problem regarding finite automata
Date: 4 Sep 92 18:04:00 GMT
Reply-To: johnson@nrtc.northrop.com
Organization: Northrop Research and Technology Center

Here is a cute problem, perhaps suitable as an exam question.
I offer it to all beleaguered professors trying to think up comp
questions!  ;-)

Define a rotation of a string A as follows:  divide A into substrings A1 and
A2 such that A1 A2 equals A; A2 A1 is a rotation of A.

For the string `abcd', the rotations are abcd, dabc, cdab, bcda.

Now let L be a regular language, and let Rotate(L) be the language consisting
of all rotations of strings from L.  Is Rotate(L) regular?  Give proof
or counter-example.

- Greg Johnson
  johnson@nrtc.northrop.com