[Note: this is an early draft in progress! Please come again soon.]

Introduction

HyperLook is a HyperCard-inspired graphical user interface development environment from the Turing Institute, but reinvented with networking, and programmed and rendered in PostScript code and graphics.

It ran on Sun Microsystem’s NeWS (Network extensible Window System) on SunOS 4, and on OpenWindow X11/NeWS on Solaris 2.2.

The Turing Institute originally released a system called “GoodNews” for free in early 1989. Later they released an even better series of free versions named “HyperNeWS”.

I later joined the team in 1992 to help develop HyperNeWS into a commercial product called “HyperLook” for Sun’s OpenWindow X11/NeWS server, supporting The NeWS Toolkit and Open Look components, with multimedia features including shared memory image views and a sound mixer server. At the same time, I also developed a version of Maxis’s game SimCity for HyperLook.

HyperLook was so far ahead of its time that there still isn’t anything quite like it today. But HyperCard itself has inspired many other systems like Scratch, Snap! and Lively Kernel, which go much further than HyperLook ever did in many ways, using SmallTalk or JavaScript instead of HyperTalk or PostScript.

This article is about how HyperLook was inspired by HyperCard but also unique, and how complex games like SimCity, high performance mathematical simulations like the Cellular Automata engine, and simple creative tools and toys like Happy Tool can artistically dovetail together, and pivot around structured PostScript graphics, data and code, to empower creative users to powerfully and pleasurably compose their own extremely personalized custom interfaces.

Structured PostScript graphics, data and code are the axis around which everything rotates.

Using SimCity, the Cellular Automata engine, Happy Tool, and the HyperLook environment itself as examples, I’ll show how HyperLook combines important and powerfully synergistic techniques like networking, message passing, delegation, prototypes, object oriented programming, direct manipulation, interface editing, property sheets and controls.

What’s So Good About NeWS?

It’s Not The X-Windows Disaster!

One wonderful thing about NeWS that it isn’t X-Windows.

Ok, cheap shot. X-Windows is an easy target (X marks the spot! Even your dog won’t like it! The World’s First Fully Modular Software Disaster! I’ve got a million of ‘em.), so that’s not a strong argument.

But anyway, NeWS had its own software disaster, thank you. But OpenWindow X11/NeWS is another story for later on…

“The X-Windows Disaster” Totally Biased Commentary on NeWS:

Sounds like science fiction? An extensible window server was precisely the strategy taken by the NeWS (Network extensible Window System) window system written by James Gosling at Sun.

With such an extensible system, the user interface toolkit becomes an extensible server library of classes that clients download directly into the server (the approach taken by Sun’s TNT Toolkit).

Toolkit objects in different applications share common objects in the server, saving both time and memory, and creating a look-and-feel that is both consistent across applications and customizable.

With NeWS, the window manager itself was implemented inside the server, eliminating network overhead for window manipulation operations — and along with it the race conditions, context switching overhead, and interaction problems that plague X toolkits and window manager.

“Ultimately, NeWS was not economically or politically viable because it the very problems that X was designed to create.” -The X-Windows Disaster

The Three Axis of AJAX, Which NeWS Also Has To Grind!!!

NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently:

…(drum roll)…

1) Used PostScript CODE instead of JavaScript
for PROGRAMMING.

2) Used PostScript GRAPHICS instead of DHTML and CSS
for RENDERING.

3) Used PostScript DATA instead of XML and JSON
for DATA REPRESENTATION.

The Axis of Eval: Code, Graphics, and Data

We will return to these three important dimensions of Code, Graphics, and Data as a recurring theme throughout this article. But which way to go from here?

Alan Kay on NeWS:

“I thought NeWS was ‘the right way to go’ (except it missed the live system underneath). It was also very early in commercial personal computing to be able to do a UI using Postscript, so it was impressive that the implementation worked at all.” -Alan Kay

PSIBER Space: What Was Visually Programming NeWS Like?

On top of those three dimensions, we must push into FORTH dimension!!! It is know as the dimension of “Stack”, which you can consensually hallucinate and directly manipulate with the PSIBER Space Deck, and macroscopically browse and deeply grok with the PseudoScientific Visualizer.

Cyberspace: A consensual hallucination experienced daily by billions of legitimate operators, in every nation, by children being taught mathematical concepts…A graphical representation of data abstracted from the banks of every computer in the human system. Unthinkable complexity. Lines of light ranged in the non-space of the mind, clusters and constellations of data. Like city lights, receding…

-William Gibson, Neuromancer (1989), pp. 128.

The PSIBER Space Deck is an interactive visual user interface to a graphical programming environment, the NeWS window system. It lets you display, manipulate, and navigate the data structures, programs, and processes living in the virtual memory space of NeWS. It is useful as a debugging tool, and as a hands on way to learn about programming in PostScript and NeWS.

The Pseudo Scientific Visualizer is the object browser for the other half of your brain, a fish-eye lens for the macroscopic examination of data. It can display arbitrarily large, arbitrarily deep structures, in a fixed amount of space. It shows form, texture, density, depth, fan out, and complexity.

What’s the Big Deal About HyperCard?

I thought HyperCard was quite brilliant in the end-user problems it solved. (It would have been wonderfully better with a deep dynamic language underneath, but I think part of the success of the design is that they didn’t have all the degrees of freedom to worry about, and were just able to concentrate on their end-user’s direct needs.

HyperCard is an especially good example of a system that was “finished and smoothed and documented” beautifully. It deserved to be successful. And Apple blew it by not making the design framework the basis of a web browser (as old Parc hands advised in the early 90s …) -Alan Kay

[TODO: More HyperCard Stuff]

The Great Big Release of GoodNeWS

In early 1989, Arthur van Hoff from the Turing Institute became quite the celebrity in the closely knit NeWS community, by releasing the first version of GoodNeWS (as it was then called).

GoodNeWS was deeply inspired by HyperCard, but took it to another level with the PostScript interpreter, graphics, multithreading, and networking in NeWS. There was nothing else even remotely like it, and it was far better than any of Sun’s own GUI toolkits.

The scoop on GoodNeWS !!!

Arthur and and his colleagues at the Turing Institute had just created a groundbreaking HyperCard-like PostScript-based networked user interface creation tool called GoodNeWS that they wanted to share with the world, so were about to give it away for free on the nascent Internet!

Hugh Daniel’s audacious exuberance and generous efforts to help distribute GoodNeWS in the US were actually well justified, and GoodNeWS would soon be free to download and play with. Once Hugh got excited about something there was no stopping him:

Date: Fri, 21 Apr 89 02:53:05 PDT
From: [email protected] (Hugh Daniel)
To: [email protected], [email protected], [email protected], [email protected],
[email protected], [email protected]
Subject: The scoop on GoodNeWS !!!

I just talked to Doug Scoular at the Truing Institue about the public domaining of GoodNews. He is working on the makefiles for the tape as I write this!

They are going to send two tapes of GoodNeWS to the US, one to UUNET and the other to Grasshopper. I dont know the wording of any licences they have on the tape, but they are trying to put the tape into the full Public Access Domain, if not the Public Domain its self.

The tape should be FTP’able from UUNET and brillig soon after it gets here. I will put a copy on hoptoad for downloading to Sun when ours gets here.

Now, what is GoodNeWS? GoodNeWS was a Macintosh Look/Work alike, with a HyperCard, a MacDraw and other goodies that ran as a uniqe window manager under NeWS. It was the look & feal, but implamented via NeWS insted of QuickDraw.

The new version of GoodNeWS (1.2) has the Look changed to be closer to that of OpenLook. GoodNeWS now also works at the same time a LiteWin, so both window managers can run at the same time. The hypercard like program now handles multiple windows too. We will have to wait to see what all they have really done.

One interesting note about Apple. We asked for a copy of GoodNews back when it had the Macintosh Look & Feal. Turing asked Apple if they would mind, and Apple never responded. The Turing folks decided that they would just change the Look insted of waiting forever to see if Apple was going to yell at them.

In this case at least Apple has gotten what it thinks it wanted. Lets hope it’s not to our detrement.

||ugh Daniel
[email protected] Grasshopper Group, +1 415/668–5998
[email protected] 1996 Hayes St. San Francisco CA94117

(Dug, please include the postscrit source to the manuals online if
possable!!!)

The Key to SimCity

Through a fortunate turn of events and desperate pleas, I somehow managed to legally obtain the source code for the Mac version of Maxis’s hit game SimCity, and a contract to port it to the Sun workstation.

But I certainly didn’t want to use X11 (although I eventually knuckled under and did), but instead I started porting SimCity to NeWS, using the latest version of HyperNeWS available at the time. Chaim Gingold’s “Play Design” dissertation tells the story of how that happened (except the X11 conversion and open sourcing the code came later):

Open Sourcing SimCity, by Chaim Gingold

In 1991 the computer manufacturer Sun Microsystems, as part of an initiative to address the market for GIS computing (geographic information system), became interested in bringing SimCity into their platform. Sun’s business was rooted in selling Unix workstations, and to that end, would often support the development of applications for specific market verticals. In the summer of 1991, Sun circulated a message to gauge interest in SimCity:

The GIS and Desktop Applications Segments have a window of opportunity to get the #1 selling game “SimCity” ported to Sun. The opportunity also allows us to open up the software so that it can become a front end to GIS applications by including ToolTalk and/or import/export file capability to the standard GIS formats. This and networking will differentiate it from the PC version. The Sun SimCity version will allow Sun to offer a true “desktop” GIS solution as well as a leading entertainment package!

The game is currently being used by many government offices to train their city planners. We have already received high support from ESRI [a developer of commercial GIS products] and URISA [a GIS education and advocacy non-profit] to move the game over and now are seeking Sun field encouragement that will concur with our direction.

Please respond with any comments or customer interest that you think would support the project.

The potential for a serious application, such as GIS, is overblown — it is hard to imagine SimCity enabling Sun to offer a “true ‘desktop’ GIS solution.” The email, however, speaks to the appeal of SimCity as a compelling representation of a city. Not only was it serious enough for GIS, but it was fun, qualities which enabled it to become absorbed into the current of Sun’s marketing agenda.

One person who responded enthusiastically to this proposition was Don Hopkins, a programmer at Sun who first played SimCity in 1989, while studying computer science at the University of Maryland, where it made a deep impression upon him. While a student, Hopkins had worked for the influential user interface researchers Ben Shneiderman and Marc Weiser, where he contributed to the development of pie menus (see Callahan et al. 1988), an unconventional graphical user interface mechanism that would eventually figure prominently in The Sims, on which Hopkins would be a key contributor.

Hopkins began work on the SimCity to Unix conversion while working at Sun, but the project was eventually completed under the aegis of DUX Software. On July 19th 1991, DUX signed a ten year contract to convert and market SimCity on Unix, with Hopkins brought on as a contractor about six months later. Using the Macintosh version of SimCity, Hopkins performed the conversion, rewrote the remaining sections of assembly language to platform neutral C, and changed the platform from Macintosh to X11. Throughout the 1990’s, Hopkins did the programming necessary to convert SimCity to a wide variety of Unix platforms, adding pie menus and multiplayer support (Perkins 1993; Hopkins 2013; Joffe 2015).

Moving to Glasgow for HyperLook and SimCity

I packed up my SparcStation 2 and moved to Glasgow in 1992, to work at the Turing Institute with Arthur, making what was then called HyperNeWS into a product, and porting SimCity to run the Sun Workstation’s NeWS window system with HyperNeWS.

We then renamed it HyperLook, developed a runtime version suitable for publishing commercial products, wrote documentation and promotions, and released it simultaneously with SimCity, using them both to synergistically promote and demonstrate each other’s value!

Eating Our Own Dog Food, and Loving It

Since we developed HyperLook and SimCity at the same time, that forced us to eat our own dog food, and ensure that HyperLook supported everything you needed to develop real world applications. (Not to imply that SimCity is a real world! ;)

Having such a demanding game as SimCity stress tested HyperLook and forced us to provide features that SimCity required, like high speed raster views and a sound mixer, in a way that benefited the entire environment and all other applications.

Shared Memory Library

The shared memory library we developed for SimCity enabled a client written in C or other languages to read/write the pixels of an image shared in NeWS server, so both the C client and NeWS PostScript can efficiently synchronize, draw into and read back pixels from shared memory. That enables some creative ways of combining raster bitmaps and PostScript graphics, as the Cellular Automata engine demonstrates.

We also used the shared memory library with a video capture device, by implementing a C client that connected to the device and dithered the YUV image into an 8 bit NeWS compatible color palette.

Audio Mixer

The audio mixer was essential for SimCity itself, since it required playing multiple simultaneous sounds, that must be mixed in real time. But of course all other HyperLook applications could benefit from being able to play sounds without tripping over each other, too.

The Sun’s /dev/audio device was too low level to support mixing sounds, or even more than one application playing a sound at once. The solution was to develop a sound mixer server, which was simply a HyperLook client who connects to the Sound stack and listens for messages, while mixing any playing sounds in real time.

When any HyperLook applications sends a PlaySound message to the Sound stack, it doesn’t have a handler for it so it’s delegated to the sound mixer client, which handles the message and starts paying the sound. It supports a typical set of messages for controlling the volume per application, globally, or per sound, configuring channels, canceling sounds, etc.

In this way, HyperLook messaging was able to serve the same purpose as D-Bus does today on the Linux desktop.

It’s Burgher Time!

In summary, it was great for HyperLook to have an application like SimCity driving it, and when we released them together, SimCity served as proof of HyperLook’s capabilities, while HyperLook’s capabilities make SimCity even better than it would have been otherwise. Eating our own dog food was a healthy choice!

What’s So Interesting about HyperLook?

HyperLook embodies many of the important features of HyperCard, including the ability of users to create their own stacks with direct manipulation editing (but with a non-editable stripped down runtime), property sheets (but user created stacks instead of hardwired native Mac dialogs), a built-in graphics editor (but structured PostScript instead of Pixels), a dynamic scripting language for programming arbitrary behaviors (but PostScript instead of HyperTalk), and delegating messages from “Object => Card => Background => Stack” (but with an additional optional“=> Client” tier).

But it’s different in HyperCard in the way it uses PostScript throughout as the “Three Axis of AJAX”: programming, graphics and data, and it’s more metacircular in that all of its property sheets are HyperLook stacks, which makes deeply customizing the user interface, and adding and configuring new kinds of objects and interaction techniques much easier.

User Can Create and Edit Their Own Stacks of Cards

Like HyperCard, this is the most important difference from traditional apps: at any time (unless you’re using the stripped down runtime with a product like SimCity), you can flip any stack into “edit mode” by a special click or keystroke.

Then you get a bunch more items in the context menu for selecting and creating and editing objects, and you can click and drag to select any object on the card, background or stack, and edit their properties and scripts.

You can copy and paste and duplicate objects around, and they carry their properties and procedures around with them.

Property sheets have one panel to edit their generic properties shared by all objects, and another custom panel that can be tailored specific to each kind of object. Users can even edit the existing property sheets and make their own.

Warehouse stacks like “Warehouse,” “Button Ideas,” “Clocks,” and “Neat Clocks” contain collections of exemplary preconfigured objects, whose names automatically appear under the editor’s “New Object” menu. You can create pre-configured objects from the warehouse anywhere in your own stack.

And you can create your own reusable object prototypes in a warehouse simply by, duplicating or copy/pasting in an existing object, giving it a descriptive name, and customizing its properties or scripts to your heart’s content. Then you can even define a custom property sheet if you need to.

Networking and Message Passing

Unlike HyperCard, which did not natively support networking, HyperLook clients could connect to the NeWS server, and load and attach to user-editable HyperLook stacks, so they could communicate with each other by sending messages back and forth over the network.

The client, running in a different Unix process that the NeWS server, would register asynchronous handlers for named messages with parameters, and it could send named messages with parameters back to HyperLook objects.

Object => Card => Background => Stack => Client Delegation

Both HyperCard and HyperLook use delegation: When you click on a Button, it first sends a “Click” message to the Button itself. If the Button doesn’t know how to handle it, the event bubbles on to to the Card that contains the Button. If the Card doesn’t know how to handle it, the event then bubbles up to the Background that contains the Card. If the background doesn’t know how to handle it, the event bubbles up to the Stack itself. Finally, if the Stack doesn’t know how to handle it, the events and its parameters get sent over the network to the client, who has the last chance at handling it.

All objects in HyperLook have names, unique within their container, used to address them by path.

When an HyperLook object (or client) receives a message, it includes the message name, the name of the object to whom it was originally sent (like the Button, so the receiver knows where to send any reply), the name of the object who received it (which could be different due to delegation), and a list of parameters. The client can at any time send messages with parameters back to any HyperCard Stack, Background, Card or Object by a path of names.

HyperLook Client Libraries

HyperLook stacks could send messages to clients over a network connection, and the clients could call native C libraries, Prolog or Lisp programs, image and signal processing algorithms, games like SimCity, simulations like cellular automata, tools like sound mixers, and they could control real world hardware like video capture devices and robots through device drivers.

There was also a shared memory raster animation library (so clients could efficiently draw into image pixels, and NeWS could display multiple scaled views of those images on the screen with PostScript), and a sound mixer (so SimCity and other HyperLook clients could share the audio device, and make overlapping sounds which would be mixed in real time).

Structured PostScript Graphics Editor Component

HyperCard had a wonderful built-in image editor, but it was black and white pixel based (although there were extensions to handle color pixels).

HyperLook, on the other hand, is completely PostScript based, but PostScript graphics do include pixel based images, which can be scaled, rotated, clipped and transformed in various ways. HyperLook also supports embedding Encapsulated PostScript (EPS) files in drawings, and exporting drawings as EPS to be printed or embedded in other documents.

HyperLook had a nice simple built-in structured PostScript graphics editor component, which it used in its own property sheet stacks for editing the graphical properties of any objects, like the shape and background of a stack, or the images of a switch.

HyperLook made it extremely easy (and fun) to set the stack’s shape and appearance to anything you desired!

For example, I quickly was able to whip up a Lava Lamp shaped stack that rendered a live clipped animated view of a psychedelic cellular automata that melted people’s faces.

It’s the PostScript, Dammit!

There are many advantages to using the same language for graphics, scripting, and data. PostScript data consists of arrays, dictionaries, strings, numbers, booleans and null — virtually identical to JSON or Lisp S-expressions.

PostScript’s not just for drawing. PostScript data is great for representing persistent objects, structured graphics, messages, program code, data structures, and everything else that JSON is now used for. PostScript code is homoiconic, in that PostScript code is simply normal PostScript data (a powerful property that JavaScript does not share with PostScript, but Lisp does).

You get to use the same language to draw all parts of the user interface, as you use to handle events and react to button presses and menu selections and network connections, as you use to read and write objects to the disk or the network.

Customizable buttons and switches flip between different drawings when you click them. You could point at any graphical object and press the “Props” key to bring up a property sheet to edit its properties and graphics, or edit its script to understand and change its behavior.

The ability of the user to easily open up any part of the system and look inside to see how it works, then copy and change it and use it for their own purposes, is extremely important.

Ubiquitous Structured PostScript Drawings

HyperLook’s structured PostScript graphics including stroking and filling paths, rendering text and images, embedding EPS files, grouping, transformation, and clipping. They were represented by big trees of PostScript data.

One cool technique that NeWS supported was “PostScript Capture” for snapshotting the results of procedurally drawing PostScript graphics as a flat sequence of drawing commands without any computation (like a PDF file). That’s known as “distilling” PostScript, or “partial evaluation”, and is how Acrobat Distiller creates safe dumb and happy PDF files from dangerous artificially intelligent Turing-complete PostScript documents.

HyperLook stacks had a “Copy as Drawing” menu items that could use PostScript Capture for procedural drawing like Happy Tool, but it created transformed groups that you could deconstruct in the editor for capturing the contents of stacks and objects. So the graphics of a window snapshot maintained their structure as much as possible. It made for very pretty printed documentation!

Structured PostScript graphics were ubiquitous throughout HyperLook, and could be copied and pasted on the clipboard, edited by the user, read and written to files and the network, and were used to define how everything looked (while PostScript code was used to define how everything behaved).

Here is a structured PostScript snapshot of the Clipboard stack showing the clipboard containing a structured PostScript snapshot of a graphics editor stack editing a picture of a robot arm holding a structured PostScript snapshot of a demo browser stack, containing a bunch of structured PostScript snapshots of other demo stacks to play with! You can paste it into the editor and ungroup and edit it all the way down!

Object Oriented PostScript Programming

You could edit the behavior of any object with the PostScript script editor. By defining custom message handlers, methods and properties on objects, you could handle interactions locally without sending unnecessary messages to the client over the network. That maximizes interactive responsiveness while minimizing network traffic, just like modern “AJAX”.

HyperLook is completely object oriented, using a system that’s similar to SmallTalk, using the PostScript dictionary stack. Objects could have their own unique scripts attached, which could be edited at runtime and cloned into other objects. The DocBrowser let you browse the class hierarchy and read the documentation, as well as printing documentation for the class and subclasses.

Customizable Property Sheets

Since property sheets of objects were just stacks themselves, you can customize existing ones, and create your own.

You can create your own custom stacks and objects by copying and editing existing ones. When you add our own custom object to a warehouse, you might want to customize its property sheet by copying an existing one and customizing it for your new object (by adding a few controls for new properties, perhaps).

You can make any stack into a warehouse, so each of its pages (which can have descriptive titles) appeared in edit mode on the “New Object” menu, as a submenu containing all the objects in that page. m That makes it easy to create instances in the current stack you’re editing.

Creating custom property sheets wasn’t super easy — you had to know what you were doing to name the controls properly so they magically accessed the instance variables, get and set and convert back and forth between property types and widget value types (like the drawing editor edited drawings) when you hit “apply”.

By using stacks as property sheets, HyperLook was more meta-circular than HyperCard, whose property sheets were hardwired MacOS dialogs, not HyperCard stacks.

This made it possible to create different tiers of property sheets for casual and advanced users, or for users to customize any property sheet themselves! (Not that the product lasted long enough to do that — Sun canceled NeWS right after we released HyperLook and SimCity, so it was a swan song.)

Property sheets for each type also had an LRU menu of all recently edited objects of that type, so you could easily flip back and forth between them really quickly, a common thing to do.

Practical Example: Customizable Clock Editor

A great example of an object with a custom property sheet is the user configurable clock with three persistent graphical properties: face, minuteHand and hourHand, and whose custom Clock Editor property sheet had three graphics editors for the face, minute and hour hand (NeWS was too slow to animate a second hand *blush*). All this was easily created by copying and pasting and configuring objects in the editor!

There was a warehouse stack of example clocks, which would appear on the editor’s “New Object” menu, so you could easily plop down custom clocks in any other stack.

Nutty Example: Customizable Window Manager

The entire window manager (resize corners, hamburger menus, title bars, paging controls, etc) was deconstructed and available in customizable styles from the warehouse thusly!

But why, you might ask, would anyone in their right mind ever want to customize the window manager at such a fine level of granularity???!!!

Well one reason is that SimCity demanded an extremely luxurious set of elegantly beveled matching mayoral quality resize corners and edges, securely fastened to the screen with high quality zirconium encrusted screws (patented “Screw Up Windows” [TM]), defined by eight personally commissioned custom PostScript engineering drawings that would effortlessly stretch with the window size.

Disastrous Example: SimCity

Here’s what SimCity looks like in the middle of a horrible disaster, just before a full stadium of innocent people of diverse and fully saturated ethnicities are about to be brutally and senselessly killed by a big dumb orange Trump-like monster of ambiguous Asian origin, with all SimCity’s windows opened up, Open Look menus pinned up, and pie menus popped up.

HyperLook Runtime

HyperLook supported a “runtime” version that was slimmed down and compressed, source code stripped and obfuscated as binary, with the stack editor removed (it was also just a component you plug into the stack, which could be replaced with a different editor).

But with the HyperLook editor installed, you could even edit and deconstruct SimCity while it was running!

You could edit the menus, script your own buttons and pie menus that sent messages to the simulation to help you play or cheat, and copy and paste live SimCity views into your own stacks!

That sure made development fun and easy, but I sure didn’t want to support casual users doing that! That’s why we needed a runtime system.

I shipped SimCity for NeWS as a free demo that you could FTP over the internet, buy over the phone with a credit card, and unlock the full featured game. It included the HyperLook runtime, so users couldn’t actually edit its user interface unless they had the full HyperLook editor.

The stripped-down obfuscated runtime made it possible to develop full commercial products like SimCity with HyperLook. And SimCity served as a promotion and practical example of the capabilities of HyperLook, and the other way around, too.

The HyperLook runtime included some cool demos and an extremely useful general purpose PostScript graphics editor, which was unparalleled on the Sun workstation at the time.

The graphics editor was useful in its own right, but also added value to SimCity. Users could copy pictures of their cities from SimCity to the clipboard, and edit, decorate, annotate and clip them in the graphics editor, and then print them at high resolution on PostScript printers.

A lot of people downloaded SimCity and HyperLook just to use the free HyperLook graphics editor, let alone playing a few minutes of SimCity for free before the city melted.

At the time, there was no way at the time to securely send credit card numbers over the Internet, so we took orders by phone. As long as you called during business hours, you could purchase a license and unlock SimCity within minutes.

Positive Example: Happy Tool

I made a simple “Happy Tool” demo that had a slider to configure how happy you were. You easily adjust your happiness with the Happy stack slider, then click on the face to copy it to the clipboard.

To support users with advanced cases of happiness, it had a custom property sheet to edit the fill, stroke and eye color as well as the happiness, and preview the result before applying in a small happy face.

It would draw a big happy or sad face with any colors, and you could click on it to copy it to the clipboard as a drawing.

Then you could use it anywhere: paste it into another drawing, use it as a button or a clock face, make a Unhappy Emo’s Day card, or paste it into a cellular automata machine to see how it melts and disintegrates.

The custom object property sheet of the happy face has more advanced controls (both standard shared object controls like stroke and fill color, and a custom stack for custom controls).

You can point at the preview happy face and press the “Help” key to pop up a dynamic help stack on the preview happy face, and it will tell you what you can do, and describe its happiness as text, showing a magnifying glass observing the component.

Inscrutable Example: Cellular Automata Machine

I developed a cool interactive Cellular Automata Machine interface in HyperLook that let you draw directly into the live cells, copy and paste drawings into the cells, and copy the cells out onto the clipboard and into the drawing editor or other HyperLook apps.

You could melt anything you wanted, like an air freshener from a car’s rear view mirror, a sad face from Happy Tool, or Alan Turing’s head from a clock face, then use it for any purpose you can imagine, like a clock face, a button, a Happy Mother’s Day card, or as a screen background.

This shows pasting a hippie face (John Gilmore) into the Cellular Automata Machine, and a bunch of sample cell snapshots of various rules, copied into the graphics editor! The cellular automata, like SimCity, used the shared memory library to animate the cells efficiently with a client written in C, so it runs quite fast and you can draw on it in real time!

Check out the Lava Lamp shaped stack with a clipped cellular automata machine view in it!

I’ve rewritten the CAM6 engine in JavaScript, by the way! Although its user interface is quite mysterious and hard to use. But I’d like to solve that problem by integrating it with Snap! and Lively Kernel, the same way I integrated it with HyperLook, but much better (and faster)!

All Together Now: Exploratorium HyperLook Demo

[TODO: HyperLook Demo video transcript]

The End of NeWS and Beginning of the Diaspora

Over many years of development, GoodNeWS was first released for NeWS, then HyperNeWS was released, then finally we released HyperLook with SimCity, just in time for Sun to cancel NeWS.

Arthur van Hoff

[TODO: Describe PdB, the object oriented C=>PostScript compiler Arthur wrote and used to define some of the classes in HyperLook.]

Distributed Objects Everywhere

[TODO: Describe the Distributed Objects Everywhere (DOE) stock trading game that Sun demonstrated at Object World, which Arthur and his team rapidly and ironically implemented in NeWS after it was officially canceled, in order to deliver a working networked multi player game in time for the show. The Distributed Objects of the Future, using the Network extensible Window System of the past!]

Arthur later went to work with James Gosling on Java, writing the Java compiler in Java, the AWT toolkit, working on the HotJava web browser.

Marimba Castanet and Bongo

Eventually Arthur left Sun to found Marimba, where he developed the widely used Castanet push distribution technology, and the under-appreciated Bongo user interface editing tool: a HypeLook-like user interface editor written in Java, that solved the runtime scripting extension problem by actually calling the Java compiler to dynamically compile and link Java scripts.

Nobody else had ever done anything remotely like Bongo before in Java. Dynamic scripting with Java was unheard of at the time, but since he had written the compiler, he knew the API and how the plumbing worked, so had no qualms about calling the Java compiler at runtime every time you hit the “Apply” button of a script editor.

Danny Goodman, the author of the definitive HyperCard book, “The Complete HyperCard Handbook”, went on to write the “Official Marimba Guide to Bongo”, a great book about Bongo, described as the “reincarnation of HyperCard on the Internet”.

[TODO: Write about Bongo’s relationship to HyperCard, HyperLook and Java.]

Java applets are everywhere on Web pages these days, but if you’ve made the move to Java from a contemporary programming environment you’ve probably been dismayed by its relative immaturity. The Official Marimba Guide to Bongo covers Marimba’s Bongo environment, which is designed to allow rapid development of Java user interfaces. The book shows you how to use the large library of graphics “widgets” supplied with Bongo, how to wire them together with simple scripting, and how to integrate other Java applets. It also explains how Bongo can be used to build channels for Marimba’s Castanet system. -Amazon.com Review

Java users should be rejoicing at the promise of programming aid Bongo, which is is the reincarnation of HyperCard on the Internet. It is fitting that the first major book about Bongo comes from Goodman, the author of the definitive HyperCard book of days gone by (The Complete HyperCard Handbook, Random, 1994). His background is as a journalist, not a technologist, and readers will make good use of this first-rate introduction. This book will circulate. -Library Journal Review

Arthur has also founded several successful companies including Flipboard and Jaunt.

Open Sourcing SimCity

[TODO: Open Sourcing SimCity]