Has Hypercard a natural son with wiki?

In article ,
Mark Schonewille <nospam.RemoveThis@nospam.com> wrote:

 > All HyperText systems resemble HyperCard.

If you are implying that all hypertext systems are inspired by
Hypercard, then that is not so. Hypercard is just one of many hypertext
platforms, and was not even the first. (I believe 'Memex' from 1945 can
claim that title. There is even an open source project afoot to simulate
it on modern hardware).

 > However, HyperCard has many built-in multimedia features which
 > are not available in a wiki, because wiki's are usually
 > text-based with limited graphical options.

Some wikis permit standard html pages and media objects to be uploaded
and linked to. These can contain scripts or plugin content if desired.
This expands the possibilities far beyond what is possible with
hypercard, which AFAICT is limited to QuickDraw and QuickTime out of the
box. QuickTime works very nicely in a web browser too.

Example: A video art group to which I belong uses wiki for its webpage.
Every user has a page which they can edit freely. They are also allowed
to upload their videos and link to them.

 > Besides, a wiki isn't as scriptable as a HyperCard stack. Ever
 > tried to do on-the-fly filtering of a list and playing a sound
 > when ready, in a wiki?

I don't see either of these as a big problem. Wikis are built around
given subjects, purposes and interest groups. If a given Wiki needs
these features, they may be implemented by the site designer. Does
Wikipedia need its contributors to be able to 'play sound when ready'?

Example: The open source 'Colloquy' chat client has a wiki for
documentation, support, bug reporting, and so on. Because Colloquy has a
particularly strong AppleScript bias, I requested that they enable the
applescript:// url protocol, so that script text could be embedded in
wiki pages, and opened in Script Editor with a single click. It took a
few minutes for this to be implemented, site wide, and end users were
not required to download anything to gain this functionality, apart from
refreshing the page they may have been looking at.

The idea of a wiki corresponds more or less to the Hypercard's 'typing'
level, with the option for privileged users to operate at 'scripting'
level. If you haven't been able to do what you want with a Wiki, you
simply didn't have the required privileges.

That doesn't mean that Wiki makes those things impossible, it merely
restricts them, in a similar way that hypercard restricts access through
the various user levels.

 > Or what about writing a file to disk and
 > opening it in a different application?

Of course the public nature of wiki (as opposed to the single-user
nature of hypercard) brings security to the fore, so scripting things
like this becomes a risk as much as a benefit. Fortunately client-side
scripting languages are required to be secure. When security holes are
found they are usually patched rapidly.

Besides, with the correct configuration, you *can* write a file to disk,
in the most standard way: File->Save, or with cookies, or even with a
plugin or applet with the right privileges, as is common with intranets.

Similarly opening downloaded stuff in other applications is a completely
standard browsing activity. For obvious reasons, the user is usually
required to "OK" that operation. When I download a pdf file, it opens in
Acrobat automatically. (Acrobat also supports javascript, incidentally).

So, these 'shortcomings' that you mention are not an arbitrary technical
restriction, but a different security paradigm that follows naturally
along with multi-user/networked systems. As I have demonstrated, a wiki
can be modified to support these features if necessary.

If there is a good community around a wiki, then there will be
sufficient folk on the back end to implement whatever the users want
rapidly and easily. Most users don't need or want to script Wikis (or
Hypercard stacks) in the first place.

If you want a single-user/standalone system, Hypercard might still be a
good choice, but is that what your customers want these days? Good luck
if you can run a business on that premise.

 > A wiki does one of the many things that HyperCard can do.

....and Hypercard does some, but not all, of the things wiki can do, for
example being publicly available for editing by multiple users on the
fly. You could probably create a HC stack which had this feature, but it
does not come ready to do it out of the box. It would also be a security
nightmare.

I think it's important for die-hard hypercard enthusiasts to recognise
that, not only does HC have certain special features, it also does LESS
than the some other tools, in a way that made it uniquely useful in some
contexts, and highly unsuitable in others.

It's really not useful to keep on saying "yeah, but it doesn't have
feature X that hypercard has" every time someone suggests an
alternative. That complaint is meaningless if enough users simply don't
need that feature X, or perhaps that feature is offered by still another
tool. Who needs QuickDraw if they've got PDF?

Each of the alternatives has strengths and weaknesses above and below
Hypercard's own strengths and weaknesses. Hypercard was good, but it's
just one of many possible platforms, and for various good reasons, can
not be taken seriously any more for most authoring jobs.

Wiki, Squeak, Revolution, Director, Flash, Supercard, HTML,
PDF/Acrobat... I've used all of these tools to some degree, and they all
have one important feature that Hypercard lacks: They are supported.

If the alternatives lack features, and if the users really need those
features, then the features may be added. This is especially true of
open source tools like Squeak and Wiki.

You have to jump through hoops to use color in hypercard. You have to
jump through hoops to write files silently to the disk with a web
browser. Let's stop comparing Apple's with oranges and stay open to what
may be the better tool for any particular job.

It seems to me, Mark, that you are repeatedly saying that no other tool
than hypercard is suitable for *anything* that hypercard can do because
it can't also do *other* things that hypercard can do, which is a lousy
argument if those other things are not desired by the users or
developers.

I think it's useful and relevant to hear about HC alternatives on this
group, and I find the repetitive and dismissive response "...but it
doesn't have Hypercard's feature X" to be extremely tiresome.

Brennan
 >> Stay informed about: Has Hypercard a natural son with wiki? 

Brennan Young wrote:

.... many many interesting and positive things.

Thank you very much:-)

--
Sylvain Bouju
--
 >> Stay informed about: Has Hypercard a natural son with wiki? 

Dear Brennan,

Thank you for your extensive comments on my previous post. I am sorry I
had to wait so long before replying, because it does no justice to your
interesting ideas.

Brennan Young wrote:
 >


 >
  > > All HyperText systems resemble HyperCard.
 >
 > If you are implying that all hypertext systems are inspired by
 > Hypercard, then that is not so. Hypercard is just one of many hypertext

No, there is a resemblence and it is often stated that HC was an
inspiration to the inventor of the first hypertext system for the
internet. I am not saying that ALL hypertext systems are inspired by
HyperCard, neither am I stating myself that HyperCard was an inspiration
to the <a rel="nofollow" style='text-decoration: none;' href="http://WWW." target="_blank">WWW.</a> In fact, I believe it wasn't, but Tim Berners-Lee mentions
HyperCard several times in this document:
<http://www.w3.org/History/1989/proposal> which can be read using MS
Word. When inventing the WWW, he was aware of HyperCard, but he wrote
his own hypertext system before HyperCard existed. Although HyperCard
wasn't the first hypertext system, after reading
<http://www.w3.org/MarkUp/historical> I tend to think that HyperCard was
the first generally available hypertext system.

 > platforms, and was not even the first. (I believe 'Memex' from 1945 can
 > claim that title. There is even an open source project afoot to simulate
 > it on modern hardware).

As you can read here:
<http://www.ps.uni-sb.de/~duchier/pub/vbush/vbush6.shtml>
the memex was only a futuristic idea. I don't know of any hypertext
system in 1945 (and I believe there wasn't any).

  > > However, HyperCard has many built-in multimedia features which
  > > are not available in a wiki, because wiki's are usually
  > > text-based with limited graphical options.
 >
 > Some wikis permit standard html pages and media objects to be uploaded
 > and linked to. These can contain scripts or plugin content if desired.
 > This expands the possibilities far beyond what is possible with
 > hypercard, which AFAICT is limited to QuickDraw and QuickTime out of the
 > box. QuickTime works very nicely in a web browser too.

Of course, I can create a wiki system that provides all multimedia
features you can think of and even let you download a standalone
version. I suspect, though, that this is not the essence of a wiki.
Every wiki satisfies a particular need, as does every HyperCard stack,
which sometimes asks for a multimedia solution and sometimes for a
text-only solution.

 > Example: A video art group to which I belong uses wiki for its webpage.
 > Every user has a page which they can edit freely. They are also allowed
 > to upload their videos and link to them.
 >
  > > Besides, a wiki isn't as scriptable as a HyperCard stack. Ever
  > > tried to do on-the-fly filtering of a list and playing a sound
  > > when ready, in a wiki?
 >
 > I don't see either of these as a big problem. Wikis are built around

I don't see it as a problem either, but I believe it reveals a general
difference between the purpose of HyperCard and it's "descendants" on
one hand and wikis on the other hand.

 > given subjects, purposes and interest groups. If a given Wiki needs
 > these features, they may be implemented by the site designer. Does
 > Wikipedia need its contributors to be able to 'play sound when ready'?

First, you are saying: Wiki's can include multimedia. Now, you are
saying: Wiki's do not always need these features. Actually, I totally
agree with this, but I also believe that one of HyperCard's strength is
that all multimedia features are readily available and very easy to
implement. Here, I see a subtle though important difference between
HyperCard and Wiki's.

 > Example: The open source 'Colloquy' chat client has a wiki for
 > documentation, support, bug reporting, and so on. Because Colloquy has a
 > particularly strong AppleScript bias, I requested that they enable the
 > applescript:// url protocol, so that script text could be embedded in
 > wiki pages, and opened in Script Editor with a single click. It took a
 > few minutes for this to be implemented, site wide, and end users were
 > not required to download anything to gain this functionality, apart from
 > refreshing the page they may have been looking at.

So, scriptability is one of the features one might add to wikis.

 > The idea of a wiki corresponds more or less to the Hypercard's 'typing'
 > level, with the option for privileged users to operate at 'scripting'
 > level. If you haven't been able to do what you want with a Wiki, you
 > simply didn't have the required privileges.

Although I understand the analogy, I don't think one may compare every
layered system of privileges with HyperCard only because HyperCard has
user levels.

 > That doesn't mean that Wiki makes those things impossible, it merely
 > restricts them, in a similar way that hypercard restricts access through
 > the various user levels.
 >
  > > Or what about writing a file to disk and
  > > opening it in a different application?
 >
 > Of course the public nature of wiki (as opposed to the single-user
 > nature of hypercard) brings security to the fore, so scripting things
 > like this becomes a risk as much as a benefit. Fortunately client-side
 > scripting languages are required to be secure. When security holes are
 > found they are usually patched rapidly.

If I understand you correctly, you are saying that one of the main
differences between HyperCard and a WIKI is that HC is more flexible
because security risks put fewer limits on it's application, whereas
WIKIs are public in nature and thus less flexible regarding
scriptability. I fully agree and I believe it illustrates the
differences between WIKI systems and HyperCard.

 >
 > Besides, with the correct configuration, you *can* write a file to disk,
 > in the most standard way: File->Save, or with cookies, or even with a
 > plugin or applet with the right privileges, as is common with intranets.

Sure, you can write any downloadable file to your hard disk, but then
again iTunes and KaZaa are not generally said to resemble HyperCard,
even though they let you download and save files.

 >
 > Similarly opening downloaded stuff in other applications is a completely
 > standard browsing activity. For obvious reasons, the user is usually
 > required to "OK" that operation. When I download a pdf file, it opens in
 > Acrobat automatically. (Acrobat also supports javascript, incidentally).
 >
 > So, these 'shortcomings' that you mention are not an arbitrary technical
 > restriction, but a different security paradigm that follows naturally
 > along with multi-user/networked systems. As I have demonstrated, a wiki
 > can be modified to support these features if necessary.

I didn't mean to list a number of "shortcomings". Much more, I tried to
say that WIKIs and HyperCard are different in nature because they serve
different purposes. Neither did I say that a WIKI would be unable to
implement the features that HyperCard provides. I mean that a WIKI
usually doesn't need a navigation palette that decides where to lead a
user depending on the current page, the name of the user, and a few
keywords, while playing Eine kleine Nachtmusik :-) It is possible to
make such a WIKI, though, but that doesn't make it a natural son yet. If
you are in search for relatives of HyperCard, I think that SuperCard
would be quite a credible candidate nowadays.

 > If there is a good community around a wiki, then there will be
 > sufficient folk on the back end to implement whatever the users want
 > rapidly and easily. Most users don't need or want to script Wikis (or
 > Hypercard stacks) in the first place.
 >
 > If you want a single-user/standalone system, Hypercard might still be a
 > good choice, but is that what your customers want these days? Good luck
 > if you can run a business on that premise.

Fact is that I know more people who run a business based on a series of
HyperCard stacks than on a WIKI. I am not quite sure why comparing a
WIKI and HyperCard involves being able to run a business by it or not.

 >
  > > A wiki does one of the many things that HyperCard can do.
 >
 > ...and Hypercard does some, but not all, of the things wiki can do, for
 > example being publicly available for editing by multiple users on the
 > fly. You could probably create a HC stack which had this feature, but it
 > does not come ready to do it out of the box. It would also be a security
 > nightmare.

Right, but the whole point is that HyperCard serves different purposes.
The issue here is not security but the purpose of public access. I agree
that the purpose of a HyperCard stack, and also of Revolution stacks,
SuperCard stacks, and whatever stacks you may think of, is not
necessarily to be publicly available and editable, even though it is
possible. Much more often, people want a stack to run as a non-editable
application on a local machine or network.

I believe this is the point where I should make clear that in my
previous I was only stating that in my view the WIKI isn't that much of
a natural son to HyperCard. I wasn't saying that HyperCard is still the
only tool for everyting, which is how you seem to interprete my previous
post. Although I really regret Apple not taking HyperCard 3.0 from the
shelve to make it ready for MacOS X, it is obvious one shouldn't try to
use HyperCard 2.4.1 to develop and release software for nowadays
operating systems. Besides, I believe that tools such as SuperCard and
Revolution much more closely resemble HyperCard than any WIKI. After
all, they are xTalk environments, whereas a WIKI is not.

 > I think it's important for die-hard hypercard enthusiasts to recognise
 > that, not only does HC have certain special features, it also does LESS
 > than the some other tools, in a way that made it uniquely useful in some
 > contexts, and highly unsuitable in others.

The HyperCard die-hards I know are sensible people who use different
tools for different tasks.

 > It's really not useful to keep on saying "yeah, but it doesn't have
 > feature X that hypercard has" every time someone suggests an
 > alternative. That complaint is meaningless if enough users simply don't
 > need that feature X, or perhaps that feature is offered by still another
 > tool. Who needs QuickDraw if they've got PDF?
 >
 > Each of the alternatives has strengths and weaknesses above and below
 > Hypercard's own strengths and weaknesses. Hypercard was good, but it's
 > just one of many possible platforms, and for various good reasons, can
 > not be taken seriously any more for most authoring jobs.

I agree that HyperCard shouldn't be used for professional authoring in
the final stage. Most authoring jobs, however, start with prototyping
and HyperCard is often used to quickly put together a prototype --not
just by me. Sometimes, one needs a simple script to process some data
and decides to do it in HyperCard because it is so much easier than
AppleScript, for instance.

 > Wiki, Squeak, Revolution, Director, Flash, Supercard, HTML,
 > PDF/Acrobat... I've used all of these tools to some degree, and they all
 > have one important feature that Hypercard lacks: They are supported.
 >
 > If the alternatives lack features, and if the users really need those
 > features, then the features may be added. This is especially true of
 > open source tools like Squeak and Wiki.
 >
 > You have to jump through hoops to use color in hypercard. You have to
 > jump through hoops to write files silently to the disk with a web
 > browser. Let's stop comparing Apple's with oranges and stay open to what
 > may be the better tool for any particular job.
 >
 > It seems to me, Mark, that you are repeatedly saying that no other tool
 > than hypercard is suitable for *anything* that hypercard can do because
 > it can't also do *other* things that hypercard can do, which is a lousy
 > argument if those other things are not desired by the users or
 > developers.

So, you got me wrong.

 > I think it's useful and relevant to hear about HC alternatives on this
 > group, and I find the repetitive and dismissive response "...but it
 > doesn't have Hypercard's feature X" to be extremely tiresome.

You should be aware of the fact that in this newsgroup and on the
HyperCard Mail List it is always possible to discuss alternatives to
HyperCard. However, the long-time HyperCard users already know which
alternatives are available and they are not very eager to keep the
discussion on this subject going on infinitely. I believe that it is
alright not to speak for myself only, if I say that the discussion on
alternatives to HyperCard has become somewhat tiresome in the past. New
alternatives do appear, though, and we are all interested in discussing
them in this news group and on the HyperCard list.

Kindest regards,

Mark
 >> Stay informed about: Has Hypercard a natural son with wiki?