>With HyperCard ( and eventually with OpenCard ), the development
>environment and the end-user interface are closely intertwined.
Not necessarily, Alain.
More than half the stacks I have written are completely button-drive (no
menu bar) and show the user virtually nothing of HC's development
emvironment. There is nothing in the HC development environment per se
that forces the stack interface to be the same as the development interface
(thank heavens).
>It seems strange to use HyperCard as a development tool to create
something that will surmount the difficulties and constraints of HyperCard.
One of the stated goals of the OC project was 100% compatibility with HC.
If a prototype is done in HC, it need only be converted to OC format and
modified to support those features that are a superset of HC to be
operational. One does not have to have functioning color drawing tools to
design menuItems for color drawing, etc.
>we could script some handlers that could then be proposed as new
OODL-native commands
Is the problem here that I have a different definition of UI than the rest
of you? Once again, my focus is the card, menu (if any), button, and
(possibly) palette layout OC provides the scripter when he/she sits down to
create OC documents. It seems to me a fairly complete mockup could be done
without writing a single handler.
>Besides, we want to support as many well-designed and widely-accepted
standards as possible, like HTML and XML
Supporting HTML is one thing, writing a OC prototype in HTML is something
entirely different.
Rob Cozens, CCW
Serendipity Software Company
"Prolonging the hour of astonishment..."
"And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee."
from "The Triple Foole" by John Donne (1572-1631)
