Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!ccicpg!felix!john
From: john@felix.UUCP (John Gilbert)
Newsgroups: comp.sys.mac.hypercard,comp.sys.mac
Subject: Re: MacUser Hypercard coverage (now Hypercard user interface)
Message-ID: <14670@felix.UUCP>
Date: Mon, 30-Nov-87 18:08:17 EST
Article-I.D.: felix.14670
Posted: Mon Nov 30 18:08:17 1987
Date-Received: Fri, 4-Dec-87 07:12:26 EST
References: <34557@sun.uucp> <7469@eddie.MIT.EDU> <34647@sun.uucp> <14541@felix.UUCP> <749@auscso.UUCP>
Sender: daemon@felix.UUCP
Reply-To: john@felix.UUCP (John Gilbert)
Organization: FileNet Corp., Costa Mesa, CA
Lines: 61
Xref: mnetor comp.sys.mac.hypercard:188 comp.sys.mac:10481

In article <749@auscso.UUCP> mentat@auscso.UUCP (Robert Dorsett) writes:
>Hypercard's been likened as the new Applesoft (for those of you whose memories
>don't extend in that direction, Applesoft was the very fast BASIC inter-
>preter built into Apple ]['s): something that one can crank up relatively fast 
>and get some "useful" work done in.  Unfortunately, it is CLEARLY producing 
>the same quality of software that Applesoft did.  

One point of my previous posting is that Applesoft (read HyperCard) does not
produce applications, the user produces (designs) the programs, for which
Applesoft (read HyperCard) generates the actions in the form of executable
code.  HyperCard's tools are weak in areas, but that can still change.

>       Anyone remember those Apple
>ads in 1981-82 promoting the II because of its "massive program reserve,"
>which was listed at 30,000-45,000 programs?  The bulk of which were utterly
>unusable or pure trash.
>
>Hypercard's going to give a lot of relative novices the power to CREATE stuff.
>They are not under the pressure that both hackers and professional developers
>have been to create standardized software (it's STILL a miracle that there
>haven't been more PD programs distributed running in xyz environment's 
>"development" shell).  It is impossible to contest that Hypercard's really 
>neat, and will be useful for a lot of people.  But I think that the overall
>quality of software for the Mac will suffer as a consequence: people will
>(and have) create embarassing software, and proudly distribute it by uploading
>their creations to BBS's or distributing copies through user groups.  I don't
>think that type of propagation will speak well for the Mac, as a whole.  And
>let's not even mention the massive SIZE of Hypercard stacks.  I do NOT think 
>that Hypercard "developers" are under the same pressure to be con-
>sistent as the people who acutally own copies of Inside Mac.

You seem to feel there is a big threat from "novices" obscuring the market
with poorly designed applications.  I still contend that you can do it well,
or do it poorly in either the HyperCard or the Toolbox environments.  There
is every bit as much potential to create poor interfaces with the toolbox if
you choose not to follow the guidelines.  There IS a HyperCard UI Guidelines
document in the APDA kit, perhaps the wrong place to get it, but it exists.

I also believe there WERE alot of poorly designed applications written with
the Toolbox.  They just don't survive long.  People tend not to pass along
things they do not find useful or appealing.  I have a bunch of public domain
applications and DAs that barely got tried because they were so obviously
non-standard and confusing.

I agree that HyperCard will encourage more "non-programmers" to produce
applications, and I think that is a good thing.  But inexperienced people
can still do bad things even with great tools.  Given the complexity of
the toolbox, even more so.

I guess my point is, what justification is there that the same person
would necessarily do better with the Toolbox than with HyperCard?
If you are responsible about your design, you will (perhaps struggle to)
find a way in HyperCard to do it well.  You may have to write some XCMDs.
I agree that HyperCard has a way to go, but I think it can still get
to a level of comercial usefulness given its current starting point.

John G.

--
John Gilbert
!trwrb!felix!john