The very first time I encountered Usenet, it was via a VT-100 terminal emulation program on an Apple II. I was poking around places like The Well and Software Tool and Die on a warm summer evening in 1987, and took a detour into tin. (At 300 bits per second, poking is probably an understatement.) In the early days of the Internet, and of commercial online services like The Source and CompuServe, there was no such thing as a graphical interface.
Even Mac users had to peer onto the online world though a character-based command line interface. The first graphic user interface for Usenet that I became aware of, in 1993, was a program called VersaTerm-Link, a companion to Synergy Software’s VersaTerm terminal emulation software. VTerm link was a Usenet, FTP, SLIP dialup, email, and directory front end.
I am taking a brief trip down memory lane not because I am trying to bore you to death with old war stories (they are not really boring, though – you try to imagine surfing the net at 24 bucks an hour!). I want to show you the history of why things are the way they are today and to remember some of the useful capabilities we lost along the way. In the race from 600 Usenet groups to over 30 thousand, software designers forgot to make the user’s life easier, rather than just faster.
Nearly every graphical front end has evolved from a character-based interface. The earliest front ends acted like hyper-fast users by inserting a graphical layer between the user and the traditional character command line. A user would click on a button, and the front end would type a command, and the host could not tell if it was talking to a human on a terminal or a front end that pretended to be a terminal. When the host sent data, it worked in the reverse direction. For a time, CompuServe’s schizophrenic CIM could switch between terminal windows and pretty icons depending on whether that area of the service could be easily translated into graphic output.
If you ever spent any time on a dial-up connection in those days, you probably remember the garbage characters that would occasionally appear. On a Mac, they were usually strings of “{{{{{{.“ Those garbage characters were the ultimate death of early front ends, because all it took was a single hiccup to unsynch the front end from the host. When that happened, the user was usually presented with a frozen interface or a dropped connection.
As connections sped up to the 1200 bps range, and dumb front ends were confused by the speeds and the garbage and the sheer weight of user interaction, smarter, synchronous front ends that could talk to hosts began to appear. Once that gap was bridged, the front end could talk to the host, and if one side made a misstep, the other would help it get back on track. At this point, prices began to decline, but they were still expensive. Front ends began to work in such a way as to minimize connect time. Data was cached on a local hard drive, when a person could read information or write a response in human-time, rather than computer time.
It is this sweet spot on the client application performance curve that I miss the most, and it is where I’ll pick up this topic next time.
"Back In My day, Why, We Didn’t Have Any Fancy Computers, Pt. 1" 
