|
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"
