While there was a debate at the time about whether HyperCard was truly "Hypertext" or a "User Interface Design Tool" or a "Personal Database" or just how to classify it, the much more important thing was that it was not just a browser, but also an authoring tool, that enabled regular users to switch back and forth between browse mode and edit mode WHILE they were using it, and empowered users as authors.
This is in stark contrast with the other hypertext browsers, authoring tools, and user interface design tools of the time (the cutting edge of which was the NeXT Interface Builder), that made a distinction between "run time" and "design time", and did not enable ordinary users to switch into design or edit mode while the normal application was running, which was absolutely essential to HyperCard.
At the beginning of the web, browsers did not have the ability to author hypertext (and server-side authoring tools like Medium or even AJAX-y client-side authoring tools did not exist yet). So authoring tools (and user interface editing tools) were big and expensive and complex and not user friendly, and there was often a compilation step between editing and browsing in a different program, so you couldn't just pop into edit mode and tweak the actual specification then pop back into browsing like you could do with HyperCard.
Eventually Netscape and Internet Explorer got some shitty half-assed WYSIWYG editing abilities that were sub-par, and produced terrible HTML, and couldn't be applied to any web page, and required a lot of other user interface support to be usable even for the most trivial kinds of editing, but that was a far cry from the comprehensive fully integrated high fidelity WYSIWYG browsing/editing tool that HyperCard was from day one.
In fact, one of the earliest tools that enabled anyone, even children, to author and publish their own interactive dynamic web applications with graphics, text, and even forms and persistent databases, was actually based on HyperCard and the MacHTTP/WebStar web browser on the Mac:
https://news.ycombinator.com/item?id=16226209
>One of the coolest early applications of server side scripting was integrating HyperCard with MacHTTP/WebStar, such that you could publish live interactive HyperCard stacks on the web! Since it was based on good old HyperCard, it was one of the first scriptable web authoring tools that normal people and even children could actually use! [8]
>[8] MacHTTP / WebStar from StarNine by Chuck Shotton, and LiveCard HyperCard stack publisher:
CGI and AppleScript:
http://www.drdobbs.com/web-development/cgi-and-applescript/1...
>Cal discusses the Macintosh as an Internet platform, then describes how you can use the AppleScript language for writing CGI applications that run on Macintosh servers.
https://news.ycombinator.com/item?id=7865263
MacHTTP / WebStar from StarNine by Chuck Shotton! He was also VP of Engineering at Quarterdeck, another pioneering company.
https://web.archive.org/web/20110705053055/http://www.astron...
http://infomotions.com/musings/tricks/manuscript/0800-machtt...
http://tidbits.com/article/6292
It had an AppleScript / OSA API that let you write handlers for responding to web hits in other languages that supported AppleScript.
I used it to integrate ScriptX with the web:
http://www.art.net/~hopkins/Don/lang/scriptx/scriptx-www.htm...
The coolest thing somebody did with WebStar was to integrate it with HyperCard so you could actually publish live INTERACTIVE HyperCard stacks on the web, that you could see as images you could click on to follow links, and followed by html form elements corresponding to the text fields, radio buttons, checkboxes, drop down menus, scrolling lists, etc in the HyperCard stack that you could use in the browser to interactive with live HyperCard pages!
That was the earliest easiest way that non-programmers and even kids could both not just create graphical web pages, but publish live interactive apps on the web!
Using HyperCard as a CGI application
http://aaa-proteins.uni-graz.at/HyperCGI.html
https://web.archive.org/web/20021013161709/http://pfhyper.co...
http://www.drdobbs.com/web-development/cgi-and-applescript/1...
https://web.archive.org/web/19990208235151/http://www.royals...
>Livecard has exceeded all expectations and allows me to serve a stack 8 years in the making and previously confined to individual hospitals running Apples. A whole Childrens Hospital and University Department of Child Health should now swing in behind me and this product will become core curriculum for our medical course. Your product will save lives starting early 1997. Well done.
- Director, Emergency Medicine, Mater Childrens Hospital
The following is taken from the LiveCard web site
(http://www.royalsoftware.com):
"LiveCard is a HyperCard add-on that enables remote users to browse
and interact with HyperCard files, called "stacks", on your web
server. Once installed, you'll be able to serve any HyperCard stack
without extensive preparation - often with no preparation at all.
This means you have all the advantages of HyperCard as part of your
server solution, plus you can now serve those stacks to anyone on
the Web, regardless of whether they're using a text- or
graphics-based browser and regardless of their platform: Macintosh,
Windows, UNIX, whatever."
"LiveCard implements a CGI (Common Gateway Interface) between
Macintosh servers, such as WebStar, and HyperCard. It makes the
HyperCard interface available as high-resolution, compressed
image-maps and HTML form elements, and transforms user gestures in a
web browser to a format HyperCard can understand. LiveCard
translates between HTML, HTTP, and HyperCard "on the fly," requiring
little or no preparation of the HyperCard stack. LiveCard generates
HTML dynamically - as stack content and functionality changes, these
changes are reflected live in the remote users browser."
What does this mean for you? Well, if you have access to a Macintosh
web server running WebStar, MacHTTP, or similar server software that
is cgi-aware, you can serve your stacks using LiveCard. LiveCard can
generate an HTML forms page using the text fields on the card, an
image map with stack graphics and buttons that responds to user
clicks (although the buttons can't highlight), or a combination of
the two. In addition, each generated page has a header and footer
that can be set by scripting...and is HTML aware. This gives an
incredible amount of flexibility.
Note that LiveCard requires a Macintosh web server (not really a
criticism... I love Mac servers...but you do have to have access to
the server, and it *has* to be a Mac, since LiveCard is
HyperCard-based). And to fully realize the potential of LiveCard,
you need to learn some new commands...but there aren't too many, and
they make sense. Plus, the examples provided are very helpful. At
this point in time LiveCard has a limited ability to work with
QuickTime...you can kludge your way around the limitations, but if
your stack relies on a lot of QuickTime, you have to do some serious
modifications. Rumor has it that future versions will have more
QuickTime functionality. But for static graphics (color spoken
here!), there are no modifications.
Where LiveCard really shines is in the area of forms and databases.
I created a stack to be used for a course I was teaching...very
simple, with about 5 text fields for the students name, college,
major, and a topic they were interested in. I then just dragged this
stack into my server folder where LiveCard resides. That was it. I
called up my page on a browser (remember, any browser, any
platform), went to the LiveCard page, clicked on the link to my
stack (automatically created by LiveCard), and there was a
forms-based page with all of the fields...including their labels. I
filled the page out and hit submit. Voila...the data appeared on the
stack residing on my server. Now that is cool.
Pros: Can serve your stack mostly without modification. Can use
externals in the stack. Browser is *completely* platform independent
since a plug-in is not required. Data can be easily transferred
between web page and stack. Leverages existing HyperCard stacks,
especially databases and order processing.
Cons: Requires a Macintosh web server. Limited ability to work with
QuickTime. Can be a tad slow. Lose button highlights and card
transitions.
3. Convert your stack to a SuperCard project. Allegiant (makers of
SuperCard - http://www.allegiant.com) has recently released
Roadster, which is a plug-in for Netscape navigator. Roadster is in
public beta at this time (December '96), and is available for both
Mac *AND* Windows 95. Can anyone say cross-platform? Before you get
too excited, remember that you first have to convert your HyperCard
stack into a SuperCard project. This is fairly painless
however...unless you use externals. Externals present two problems
for the SuperCard/Roadster approach...they don't always convert, and
more importantly, at this time Roadster does not support *any*
XCMD's. This is due to security concerns (you could do some nasty
damage to a client computer...kinda like a java applet gone bad). A
future intranet version of Roadster may show up that supports
externals. Another potential problem is that Roadster only supports
a single window. Now this might not be a problem for HyperCarders,
since one window is the norm. But for dedicated SuperCard people
that have grown used to multiple windows in projects, some tinkering
has to be done.
Since Roadster is a plug-in, you get some more good news and bad
news. The bad news is that people have to download the plug-in and
install it into their Netscape Plug-ins folder before they can view
your project. The good news is the plug-in is free, and your project
runs in the browser exactly as it does on the desktop...buttons
highlight, transitions work, etc... And perhaps even more
importantly, Roadster is available for Windows, so you can finally
get your stack into the hands of the unfortunate Intel-laden masses.
Pros: Project looks and runs just like on the desktop.
Cross-platform. Ability to transfer information via forms commands.
Ability to cache and preload graphics. Very good with external media
such as QuickTime, audio, etc.
Cons: Have to convert your stack. Browser requires plug-in. Lose all
functionality of externals.
Yes, lots of good HyperCard memories for me. One convention that didn't make it to the web browser was having a key (option?) you could press to highlight which elements were clickable. Lots of modern webapps could use that...
Yes definitely there should be a way to highlight all possible links! And also instead of "disabling" links and buttons and other elements so they are inexplicably useless, they should be dimmed but still enabled, so hovering or clicking on them immediately tells you WHY they're disabled, and WHAT you can do to enable them.
HyperTIES was an early hypermedia browser and authoring tool developed at the University of Maryland Human Computer Interaction Lab under the direction of Ben Sheniderman. (I helped develop the NeWS version of HyperTIES in PostScript, FORTH, and Emacs MockLisp on the Sun.)
It had both text and graphical "embedded menus" as links, that highlighted text and popped up magnified arbitrarily-shaped cookie-cutter targets with drop-shadows when you pointed at pictures with embedded links, and it highlighted all of the text and graphical links at once when you clicked on the background.
We had a cool demo of the The Hubble Space Telescope with a diagram that popped up all the different parts of the telescope. And also a photo with pop-up targets on the three heads of the Sun founders!
HCIL Demo - HyperTIES Browsing:
https://www.youtube.com/watch?v=fZi4gUjaGAM
HCIL Demo - HyperTIES Authoring with UniPress Emacs on NeWS:
https://www.youtube.com/watch?v=hhmU2B79EDU
User Interface Strategies (UIS) 90 - Ben Shneiderman - Applications sections and demos. HyperTIES Space Telescope Demo.
https://www.youtube.com/watch?v=1uyO-xUTt6Y&t=12m42s
Ben also showed a fun NeWS / PostScript / PSIBER / PseudoScientific Visualizer / ARPAnet map demo later in that talk, which also shows clicking in the background of the PSV to highlight everything at once (the X-ray view of the ARPAnet map, at 28:10):
https://www.youtube.com/watch?v=1uyO-xUTt6Y&t=24m56s
Designing to Facilitate Browsing: A Look Back at the Hyperties Workstation Browser:
By Ben Shneiderman, Catherine Plaisant, Rodrigo Botafogo, Don Hopkins, William Weiland. Published in Hypermedia, vol. 3, 2 (1991)101–117.
https://medium.com/@donhopkins/designing-to-facilitate-brows...
>Implications of Graphics in Hypertext
>Hyperties incorporates graphics while preserving the embedded menu approach used for text only documents. A displayed page can mix text and graphics while allowing arbitrarily-shaped regions to be designated as targets, which provide links to other articles. The addition of graphics provides significant advantages (14). Information that is structured in the form of charts, graphs, maps, and images may be explored with the same facility as text. But the use of graphics in hypertext requires more work on the part of the author to produce comprehensible documents. There is no simple technique for emphasizing the targets that is acceptable in all cases, and the author must laboriously link targets to their references (they are not “self-naming”, as in the text case). In the Sun version of Hyperties rudimentary tools have been developed to simplify the author’s job of establishing graphical links between entries. These consist of editors for designating arbitrary regions of an image using rectangles or polygons, associating names with these regions (which are used by the system to locate references), designating their appearance when highlighted, as well as overall management facilities for keeping track of graphics that have been produced.
>Identifying Selectable Items
>Several existing hypertext systems permit the browsing of mixed graphics and text, but none has carefully addressed the problems inherent in this more complex realm. Apple Computer’s HyperCard (15) makes minimal distinction between textual and graphical elements of a database entry; anything can be selectable (linked to a reference) if the author so chooses, but it is left to the author to provide hints to the user about what is selectable. (However, it is possible to obtain a temporary display of selectable regions, highlighted by bounding rectangles, via a modifier-key combination.) Brown University, in its Intermedia system (16), has, in a sense, eliminated selection of graphical and textual elements entirely; instead, all links are indicated by special icons, which the author may place at will. This scheme has the advantages of simplicity and clarity, but risks obscuring pertinent information in a welter of special symbols, and may introduce ambiguities of reference: for example, in a map of the United States, does a particular icon refer only to New York City, or to the entire state of New York? A slightly different approach is taken by Guide (17), which provides four different types of linkages; the presence of a link and its type are indicated by changes in the appearance of the screen cursor as it is moved about the display and encounters selectable objects.
>An important problem is how to indicate to a user the selectable elements of a graphic. It is clear that some scheme is needed to do this — expecting a user to hunt after the targets in an image by trial and error is apt to cause frustration with the system and limit its use. Any scheme chosen must satisfy certain requirements: it must unambiguously identify the location and scope of the target, it must not itself interfere with comprehension of the image, and it must require little effort on the part of the user. Possible solutions include highlighting the targets by dynamic indicators, outlines, inverse video, fixed symbols, color, shading, and image manipulation (13,14).
>The approach taken in Hyperties has been to allow arbitrarily-shaped regions of an image to define these link targets. Normally, these regions are not distinguished in any way (other than visual cues that an author may choose to provide); however, when the mouse cursor passes over a target region, it becomes highlighted. The highlighting scheme developed is novel, and has met with favorable comments from users: it is referred to as pop-out, and consists of offsetting the highlighted object vertically and horizontally by a small amount, and placing a drop-shadow beneath. This gives the appearance of having the object pop out of the screen (Figure 5a); in addition, the slight movement of the object makes it readily detectable to the eye. Because of the use of arbitrary regions, there is no ambiguity of reference; because highlighting only occurs in response to user demand, the image itself is not cluttered; and because the targets highlight automatically in response to mouse movements, the interface requires minimal effort.
>One remaining problem is that it is not possible to identify the links in an image at a glance. However, certain user behaviors were noticed: when confronted with an image with hidden targets, they tend to sweep across the image until a target is highlighted (becomes designated), or try to select what they think might be a target until one is found. This suggested that the system could highlight all of the targets automatically (for a short time) whenever it appears that the user is searching for targets, as when sweeping the display, or clicking in non-target areas. This latter strategy has been implemented in the NeWS version of Hyperties. Whenever a user attempts to select in a non-selectable region (like the background), all targets are revealed (Figure 5b). This technique was found effective and generally very well received by users.
>Figure 5: (5a: left) The main view of the telescope. The cursor is now resting on the Faint Object Spectrograph which “popped out” to show the existence of a link (compare with Figure 1). Of course the dynamic effect cannot be rendered in this figure. (5b right) A click on the background shows all targets available on the picture.
https://miro.medium.com/max/1501/1*RWavUqU14c4PVeausFPKAA.pn...