Jonathan's Apple, my 1984 online service
When Apple launched the Macintosh at the start of 1984, I was in my junior year of high school. That spring, I somehow found the time to code and launch an online service called Jonathan’s Apple. It was accessible from anywhere in the world… as long as you were willing to dial a landline in Chicago, from a terminal of your choosing.
This rang a phone in my bedroom, where I’d programmed my Apple computer to answer and log every call. Once connected, you could read and post messages for other users, features typical of such systems at the time. The server software was 100% hand crafted by me, down to the device drivers.
Three years earlier, I had already achieved some notoriety for co-founding a startup, Aristotle Software, creating and selling software for the Apple II. But it was actually eight years earlier, in 1976, remarkably, that I first got online, and the story of Jonathan’s Apple begins there.
Getting online… in 1976!
Am I among the first cohort of digital natives? I didn’t get my hands on a computer until age 8, but it was clear to me from the start that the future was online, networked, globally connected. It was a future my father was working to build every day as a software engineer at Bell Labs working on large-scale electronic switching systems for telephone networks, and it was a future we talked about all the time. Every time anyone made a phone call in that era, it probably involved running his code. The second film my parents ever took me to see was 2001 - A Space Odyssey which made an indelible impression on me as a tot (The first was Yellow Submarine!)
Bell Labs gave my dad a printer-terminal so he could also work from home, and a shelf full of printed UNIX documentation, which I dove into head first. Among the loose leaf binders was a draft of The C Programming Language by K&R.
As early as 1976, we were regularly logging in to UNIX machines through an acoustic modem on a TI Silent 700 at the very non-broadband speed of 300 baud, which the built-in thermal paper-roll printer could keep up with. This was actually a major upgrade from the punched cards that were still in use in the mid 1970s; I remember walking through noisy rooms full of punch card operators, and using them as playthings when I was very young. With the printer terminal, my dad taught me the command line UNIX utilities and C programming. I played every game on the system, of course, and started writing my own.
1978: Ward and Randy’s CBBS, first of its kind
Just before I turned 10, my hometown of Chicago was hit by a great blizzard, with snowdrifts over my then-much-shorter head. During that blizzard, a pair of Chicago hobbyists created what became the world’s first computerized bulletin board system, Ward and Randy’s CBBS.
Mr. Teich, the math teacher at my public grade school, somehow got wind of it, and procured a single giant-sized, very loud, floor-standing ALL-CAPS continuous-form printer terminal solely to try out this exciting new thing. A few of us gravitated to it, and we soon became fixtures in the corner of the math room every chance we got. CBBS was a single computer you had to dial up via landline, and as word spread, it started to become harder to access as the line was often busy during school hours.
CBBS predated even USENET as an online forum. I was also among the early participants on USENET when that came online. After experiencing CBBS, USENET seemed sort of familiar, except it was global and drew from a much larger pool of users, and forum topics were much better organized. A number of my childhood posts on various tech topics are preserved in the historical archives. On UNIX forums, I noticed a ton of contributions from UC Berkeley in particular, which would eventually influence my choice of college.
1980: Online with an actual screen
By 1980, Bell Labs provided my dad with a video terminal and a 1200 baud modem for working at home. These video terminals had rudimentary character-based graphics and you could programmatically place the cursor on the screen. Now it was a lot easier to edit code, using vi. Now it was also possible to remotely serve an interactive experience with moving text and low-res animation. It was a mammoth upgrade.
In this era, my computing world was sort of split between this online, terminal-based, character-based UNIX world my father and I explored together, and the exciting new world of personal computing, which was offline, but could support (with enough work) high-resolution, real-time graphics animations with sound.
In 1980, when I was 12, the middle of 8th grade, my parents pooled resources to buy me a personal computer of my own, a 48K Apple II Plus that I connected to my 9 inch black and white TV. More than anything else, that’s what jump started my software career. That computer would become the Apple of Jonathan’s Apple.
Online + GUI in 1982: The Blit terminal
Meanwhile, back on the UNIX side, the most amazing gizmo I got my hands on while roaming the halls with my dad at Bell Labs was Rob Pike’s prototype GUI terminal, internally known as the Blit. A coworker of his demoed it for us somewhere deep in the Indian Hill facility in 1982, well before it became a commercial product, and let me play with it. The Blit was a portrait-mode GUI terminal that let you open multiple shell windows on remote UNIX machines and run programs with interactive graphics. It was years ahead of its time, a glimpse of the future. The coffee-cup wait cursor was a cute touch.
I remember this was before we laid eyes upon the groundbreaking Apple Lisa, the immediate predecessor of the Macintosh released in 1983. The Blit terminal prototypes seemed to disappear around then, and then reappeared as a commercial product in 1984 that wasn’t aimed at consumers and didn’t make a big splash. I’d seen screenshots of the Xerox PARC GUI work and read about that years before (1977). But the hands-on GUI demo in 1982 made a big impression on me. I thought, what a brilliant concept, slightly before its time, invented by a company that wasn’t really the right one to sell it.
The “Apple Cat” modem
By this time, Aristotle Software was producing income, and I was looking for a way to get my Apple computer online. I bought the most powerful and fully-featured modem I could find, the Novation Apple Cat II, an internal direct-connect model that was highly customizable and programmable. It could answer the phone, make calls and even synthesize tones, which made it popular with “phreakers”.
Using this modem, I logged into every BBS I could find. I remember calling long-distance to a faraway place called “Puget Sound”, ostensibly the location of some pirates. These systems were simple and shared a lot of the same features, though there were no standards for how they operated. Typically only one user could connect at a time, so the cadence of interaction was more like email than chat. You could log in later and see if your message got a response.
How hard could it be?
These bulletin board systems seemed to be proliferating, fast. I didn’t know what software any of these other BBSes were running, but how hard could it be to build such a thing?
I got to work, wrote a rudimentary online editor, a little disk-based database to store messages, and tested it out locally. I figured out how to control the telephony hardware programmatically, and added code to listen and log the calls, welcome users, and guide them through an interactive experience. I saved the interaction logs so I could review them later if I wasn’t present at the time. Privacy was not a thing!
I added a feature that allowed me to engage in a two-way real-time chat with my users, but I couldn’t do it from user to user in real time because I only had one phone line of my own, and even that was a luxury in those days.
Immediate success!
When you launch a packaged software company, it takes a while before the first sale. That’s awesome, but there’s nothing like the immediate feedback of launching an online service that gets used in, like, the first hour it goes up.
As soon as I had the system working, I started promoting the service by posting my landline number online (yes, I actually did this!) There were, at the time, many informally crowd-sourced, hand-assembled lists of dozens of these BBSes floating around, each one slightly different. So I started adding “Jonathan’s Apple” to these lists.
Lo and behold, the phone started ringing.
Three problems quickly arise
The system tied up my machine, and I only had one machine. This was a single-tasking Apple II computer. If I wanted to enhance the BBS system, I had to take it offline. If I wanted to work on my video game or write that term paper on Sinclair Lewis, I had to take the BBS offline. So obviously this was not a long-term sustainable configuration.
The system tied up my phone line, which is really difficult when you are in high school and mobile phones didn’t exist. We had another line at home, but I couldn’t hog that. These were solvable problems, but there was no revenue stream to pay for extra hardware.
There were plenty of “legitimate” users, but some users (a disturbingly high fraction!) started posting inappropriate content right away. These were not files or images, yet. They were numbers — credit card numbers, bank information, some kind of airline reservation codes, I couldn’t even ID all the stuff, but clearly there was a pool of people who had learned that these BBSes were a great place to share information that wasn’t permitted anywhere else.
The credit card numbers were clearly a problem. I didn’t totally understand how this scam worked - if you had a stolen credit card you wanted to use, why would you post it for others to see? Was there external coordination? Who knew, I wasn’t the FBI, I was just an individual attempting to provide a public service. I wasn’t actually sure what my legal liability was as the host of the server on which this data was being posted - it was an interesting question - but as these posts were clearly in support of fraudulent activity, I couldn’t ignore them.
Everything in moderation
At first, I just deleted the offending posts, and sent a message back to the poster explaining why. But bad posts were multiplying, like magic brooms in the Sorcerer’s Apprentice. My policies were ignored. Only honest people would respond to a friendly request that comes with no enforcement, and those weren’t the people posting credit card numbers.
I started using my admin-user chat feature to chastise these psuedo-anonymous sociopaths in real-time if I caught them in violation, but surprise-surprise, they were unapologetic. So I learned how to identify them as they logged in. As soon as I could ID an offender, I would boot them off the system. I was supposed to be writing papers and preparing to teach summer school computer programming, and this never-ending defense was not a great use of my time.
Where to go next? How about everywhere!
Disappointed, bemused and slightly enlightened, I took the system down, and started thinking about what experiment to build next. The two ideas I came up with did not make it past the conceptual stage due to everything else going on in my life at the same exact time, but they were good ones.
The first one was basically FidoNet, in concept. It occurred to me that having a zillion isolated bulletin boards was surely not the end state, that the logical progression was to connect these systems into some kind of network. I thought, why not put all these BBS phone numbers into an array and work out some kind of automated routing algorithms so all these computers call each other like a phone tree in the middle of the night when the long distance rates are cheap, and forward stored messages to each other, like UUCP on UNIX. This would need standards, and instinctively it sounded like a lot of work, just to pass some messages around. Latency would still be an issue with this approach but you could target eventual consistency. Privacy, hmm…
I was unaware that the FidoNet project was trying to do basically this, concurrently, and they succeeded. I did not pursue it because I thought, this is a cool idea, but it’s just a pale shadow of the Internet, and that’s what we really need.
How I didn’t invent Mosaic, or the WWW, in 1984
The next idea that didn’t make it past the conceptual stage was a much better one.
I’d proved to myself I could write an online service from scratch. I was familiar with USENET and the Internet. I’d seen that Blit terminal with bitmapped graphics and a network connection.
I’d created and sold a graphics editor. I kept writing mini word processors for fun, which may have led to some career opportunities later on.
I’d also proved to myself I could write a video game from scratch with instantly responsive, real-time, high resolution color graphics and text. I had complete control over the layout, presentation, and all I/O on the machine. I could produce any sound, and I wrote my own mini device driver to record sound from a corded microphone into a file via the cassette port, and play it back on the speaker, like Voice Memos. My video game didn’t even call the OS text routines (it actually didn’t call a single line of code in the OS!) since the standard text output couldn’t overlay graphics. Instead, I designed my own graphical font, and hand-built all the rendering code in assembly language.
I had total mastery over the Apple II down to the bare metal, and I even knew how to wield a soldering gun to it. I actually had the entire circuit schematic hanging on my wall, alongside all the maps.
Apple’s Mac was bringing the graphical interface mainstream and something like that was obviously the future of the client. Apple was starting to sell an affordable add-on mouse for the Apple II.
I thought, why don’t we put these ideas together (a common theme in my career)? What would it take to deliver an interactive graphical experience to a remote client in a way that the experience itself was somehow pre-scripted and downloaded dynamically? Because it seemed like that was something the future would include. Aside from temporary performance constraints, that class of solution would encompass a great deal of the real-world digital use cases that were envisioned at the time.
I figured all you really need is a custom graphical client and a custom server that spoke the same language. Digital connections existed. GUIs were starting to exist. Basically, combine them. Why wouldn’t you?
This seemed just natural to me. I’d spent a lot of time exploring the PLATO system at the University of Illinois in 1980-81, which was sort of the crucible for a lot of these concepts both in the computer world at large as well as in my head. PLATO does not get the recognition it really deserves.
Delving deeper: Custom graphical client and matched server software
This is how I envsioned my thing working, if you had an Apple II:
To get started, you could log in to my BBS in text mode, where you’d find instructions to download my special client program. That client program would be a generic graphical shell that would communicate with matched server software over, probably, a dialup connection.
The server would send custom command tokens formed of primitives like lines, boxes, circles with various fill patterns, blocks of text in different colors and sizes, all of which I’d already figured out how to do for our graphics editor in 1982 (and later, again, for Microsoft Works for the Mac in the early 90s!)
The client would receive these scripts, and render a customizable, interactive experience for the user. The user would stay online for some period of time, and could submit forms and stuff back to the server in an interactive loop.
My basic concept for state (like, form fields you fill out, things you pick from a menu, navigation state) was that the server and client would both be stateful, and shared state would be kept in sync over the modem. The server (common to many clients) would be the system of record for persistent data like user posts. Server instances could talk to each other on the back end using some kind of network.
It seemed feasible…
AppleSoft BASIC and assembly language were not the most productive languages for building this sort of thing, but I didn’t see anything that was infeasible about this vision even with the technology of that time. The client would be lighweight. The server was like a state machine sending text and possibly some kind of script in response to user actions, nothing computationally intensive. The server didn’t have to do anything while the user was locally interacting with content, as long as there wasn’t any fresh content to push.
Most of the graphics would be vectorized, not bitmapped, and the text was just text, so it would work fine over low bandwidth connections. Latency of the connection wouldn’t be a big deal because the interactive part of the graphical experience was to be hosted on the capable client. Round trip latency was pretty decent already - it was just the baud rate that was low back then. Screen resolution was also quite low, as were the general expectations of the time. The bandwidth couldn’t support streaming video, but digital video didn’t exist and there were no cameras to capture it.
As for layout…
I had long been familiar with document formatting utilities like nroff/troff on UNIX systems that used a human-writable input format vaguely like modern Markdown. For calculating screen layout, it seemed to me that some combination of absolute and relative offsets and sizes would work well, measured in pixels. This could be combined with common primitives such as horizontal or vertical centering, justification, zooming, cropping, etc. I implemented all that stuff for my video games, rendering text as pixels, placing objects in a grid, cropping to rectangular regions, preserving Z-order. I had all that in the bag.
I did not intuit abstractions on the level of CSS or flexbox. I figured I could just hard code and hand-tweak as many pixel locations as I needed, or I could do fancier layout algorithmically, to the extent it was faster for me just to code the math than to do it by hand. I wasn’t too worried about responsive layouts per se. There weren’t any windows on the platform and the resolution was fixed.
What was really needed to get traction was to formalize some language for the primitives in some way such that more primitives could be added over time, and to start building the matching client and server.
It was easy to brainstorm some things to start with. In addition to formatted text, you want all the stuff I coded for the Graphics Editor: lines, circles, pattern-filled rectangles and other polygons, text boxes with rich formatting, plus stuff like interactive text input boxes…
Pre-Web 2.0
My thinking was, in the simplest case, the user would experience prescripted (but still potentially interactive!) content that benefits from 2-D programmatic layout inside a graphical shell. That could produce a sort of interactive brochure that could be dynamically downloaded.
But I conceived of it as a two-way street from the get-go — basically, like a BBS, but graphical. In a way, this was sort of Web 2.0, but it was pre-web. I had already launched user-submitted content with my BBS, Jonathan’s Apple, but the original CBBS pioneered the same things years earlier. With Jonathan’s Apple, which I created and launched solo from my high school bedroom - as it turns out, the same month Mark Zuckerberg was born - I faced a barrage of content policy violations and a host of identity and security issues, which led to me shutting my online efforts down prematurely.
Keyboard input, paddles if no mouse…
I imagined ways users could interact with a graphical service using only a keyboard, with arrow keys and shortcuts. A keyboard was all I could safely assume anyone had, even though I managed to procure a mouse for myself, corded, of course. The mouse was sort of a bonus.
Apple computers often had game paddles, also corded, which could serve as an alternate way to make selections in the UI. I figured they could work for anything that needs control over a continuous range. They were easy to experiment with.
Server-side…
Server-side, I figured I could just manually create some kind of scripts describing the online experience formed of underlying primitives using any text editor. Something that was easy to type, simple and easy to read, as BASIC was. These scripts would render text and graphics and enable various kinds of user interactions like multiple-choice selections and text input boxes that would be sent to the server to yield different responses.
Server-side, I stored scripts in systematically named files that the server program would read from the disk and send out on demand. That one piece of the puzzle was already working for my Jonathan’s Apple BBS that would have become the test bed for this idea had I not aborted that experiment in a sort of panic.
UI Construction Set?
It also occcurred to me that any interactive content could itself be authored with the help of some kind of GUI. I had this unfinished (also overambitious) project I dubbed Arcade Construction Set, inspired by Bill Budge’s Pinball Construction Set, to build game UI, and I figured that concept could eventually be adapted to assist in creating the script for this interactive experience. Generalizing beyond games, this would be, like, a user interface construction set. You could move, say, an input text box around, as you crafted an experience for someone else. But for starters, you could hand-edit text files in the editor of your choice that described the UI declaratively.
Over time, as everything improved - computing power, communication speeds, display and multimedia technology, these dynamically scripted online experiences would just keep improving. The approach I had in mind at the time was that the server was a microcomputer like mine, running standard server software I would provide that could just be hand-customized for any instance of the server software, to the extent the basic call-and-response approach with locally-sourced script files wasn’t enough. The server could do generative text, which I was doing in our adventure games and other side projects at the same time. A file-oriented database could store messages and user posts, as with Jonathan’s Apple.
With that much flexibility, you could do a ton a fun stuff that didn’t need a high bandwidth internet connection, just a connection to another computer that others could use. You could hook up two lines at once and have real time interactions. With an Apple II you could hypothetically attach several modems to the same computer for multi-user scenarios. You could do collaborative adventure games. I could make my video game, Quasar, into a multi-player game over the modem.
An achievable vision — but not by me at that time
None of my fantasy required a fast CPU. All of it was an achievable vision in 1984, just not by me when I was also working on several other ambitious coding projects, wrapping up a demanding junior year, taking a bunch of dumb tests, applying to nine colleges, while also doing fun stuff like preparing to teach a programming class for the first time, and biking with a friend to Milwaukee and back over a weekend. There weren’t enough hours in the day.
Metropolis, my vision of a vector-based endless scrolling map
I spent a lot of time looking at maps. I had maps mounted to the front of my bike for real-time navigation, maps on my wall, maps in my mind. One persistent vision came to me in a lucid dream, with a name: Metropolis, a 2-D top-down vector-based city map showing labeled streets (in a vector-based font), and showing various labeled destinations, in an endlessly scrollable, zoomable view.
In my dream, it was dark mode, monochrome, high contrast, and it had dynamic locations of individual people or vehicles on it, blinking on the map. There was no conceivable way to implement that part of the vision because GPS was not even publicly available back then, but wow, would that be cool.
The furthest I got towards any of this was drawing vector maps of my own neighborhood to scale on graph paper, working through the math for scaling and rotating vectors after 10th grade trigonometry, and drawing a bunch of lines on the screen. Sourcing real data to populate a big map was an insurmountable obstacle.
Some, but not all, of the ingredients of modernity
Since I was very young I’ve always been fascinated by paleoanthropology. How many times in prehistory were the same things invented in parallel, or forgotten and reinvented? Probably lots. And what were the Neanderthals thinking? Now we think they were pretty smart.
Well, having been a Neanderthal myself of sorts in the online world as I was online for a dozen years before the Web was invented, let me invite you into my pre-web head.
My vision in 1984 was online + offline, client + server, graphical + interactive. It was web-like in some ways, but crucially lacked HTML, HTTP, and the concept of a URL. I had access to UNIX and the Internet but I didn’t have any vehicle to deploy UNIX for others, so anything I built for public consumption had to be based on the Apple II.
My vision hadn’t evolved to include links with canonical URLs, just local links on the site. I was vaguely familiar with the hypertext concept in principle from computer magazines (which referred to Ted Nelson’s foundational text), though in my head at the time, a hyperlink was just actionable text that could navigate. I hadn’t conceived an abstraction of a sharable, canonical URL.
Even if the concept were hosted on individual computers rather than the Internet, you could still do a ton of fun stuff with your client/browser while communicating with one server at a time. Futhermore, there was no reason the servers themselves couldn’t talk to each other behind the scenes, somehow, maybe overnight to sync stuff up in batch when rates were cheap. Modems were slow, but serviceable. Screens were low-res, but legible.
The only internet access I had was through my dad’s work equipment, basically on the down low. Even in the tiny population of early 80’s computer owners, almost nobody had internet access. And I’d discovered that running an online service was actually expensive, fraught and time-consuming. Between my demanding school schedule, my family and social life, other software projects and a paid teaching job, there was no time to implement the wildly ambitious successor to Jonathan’s Apple.
A tale untold, until now
Why did I completely omit the Jonathan’s Apple I actually did launch from my resume all these years? Well, it wasn’t a real job, didn’t last long, didn’t make any money, it was a long time ago, and nobody’s heard of it. The truly innovative follow-on was never actualized. Plus I had a surplus of other great material from that fertile period, and my resume was already too long.
But I don’t know why I kept so mum about all my prior online experience when MSN was spinning up, because sharing that would surely have spawned some conversations, and quite possibly a better job. I’m sure I could have made that service into something more interesting if I could have convinced them to listen to me.
It was a difficult time and I had a lot on my mind. The Jonathan’s Apple vignette was a formative experience I just never shared until now.
Primordial soup
Looking beyond my personal experience, I view this entire period of computing as a sort of primordial soup of ideas, like an ocean quietly filling up with the organic molecules necessary to create life. The ocean may look basically the same from year to year, while zillions of tiny reactions quietly happen beneath the surface, each setting a stage for the next. New forms of life may suddenly appear to come out of nowhere, but nothing really does.
