Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!leah!rpi!batcomputer!cornell!rochester!pt.cs.cmu.edu!cat.cmu.edu!ns
From: ns@cat.cmu.edu (Nicholas Spies)
Newsgroups: comp.sys.mac.hypercard
Subject: Re: ComputerWorld article on HyperCard...
Message-ID: <4508@pt.cs.cmu.edu>
Date: 16 Mar 89 21:18:24 GMT
References: <5966@bsu-cs.UUCP> <990@taurus.BITNET> <46208@linus.UUCP>
Organization: Carnegie-Mellon University, CS/RI
Lines: 23

In article <46208@linus.UUCP> jkm@faron.UUCP (Jonathan K. Millen) writes:
>
>Here's one thing I think is conceptually wrong in Hypercard.
>The highlighted state of a background button is common to all
>cards in the background.  What I really want a background button
>for is to have it show up on all cards, but highlight it on
>some cards but not others.  Background fields do this right:
>the field contents belong to the card.  Why not buttons?
>
It can also be argued that the contents of background fields should belong
to the fields rather than each card: this would make building an index much
less of a chore than now. I agree that the metaphor of background fields and
buttons is not symmetrical, and this has been noted by several people here
a while ago and should be corrected by adding:
(1) background fields whose text and scroll does not change from card to card
(2) background buttons whose state does change from card to card
...while keeping the present types.


-- 
Nicholas Spies			ns@cat.cmu.edu.arpa
Center for Design of Educational Computing
Carnegie Mellon University
--