Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!bloom-beacon!gatech!udel!rochester!PT!f.gp.cs.cmu.edu!dtw
From: dtw@f.gp.cs.cmu.edu (Duane Williams)
Newsgroups: comp.sys.mac
Subject: HyperCard (again)
Message-ID: <99@f.gp.cs.cmu.edu>
Date: Sat, 29-Aug-87 19:00:55 EDT
Article-I.D.: f.99
Posted: Sat Aug 29 19:00:55 1987
Date-Received: Fri, 4-Sep-87 05:30:57 EDT
Distribution: na
Organization: Carnegie-Mellon University, CS/RI
Lines: 32
Keywords: What HyperCard should have been!


In my previous post, I complained about the fact that HyperCard applications
(at least those released by Apple as examples) don't have a standard Mac
interface.  Now I want to say how I think HyperCard should have been.

As I already mentioned, there should be a convenient way to create menus for
a stack of cards.  It should be possible to create them in response to the
startup message to a stack.  It should be possible to replace any of the
existing HyperCard menus or individual items.  It appears that one can
already handle menu selections by trapping the domenu message with a
handler.  Applications designers should be discouraged from hiding the menu
bar, except during startup screens.

Commands that are currently accessible only through menu selections should
be made available as functions, e.g. newcard.

HyperCard needs windows!  Each stack should be represented in its own
standard Mac window (i.e., resizeable, moveable, scrollable, etc.).  The
user should be able to open and work with several stacks at the same time.
This would be especially nice on a large screen display.  Designing the
contents of the window could work just the way laying out backgrounds and
cards on the full screen does now, but the design would be done inside a
window.

The effect of the above suggestions would be to make it possible, indeed
to encourage, HyperCard applications that looked like, and worked like,
standard Macintosh applications.  I don't see that much, if anything, would
be lost in the ease with which HyperCard applications could be built.  I
can't imagine why Apple didn't do it this way.

Duane Williams
dtw@me.ri.cmu.edu