History of SCGUI

I used to work for a company that had about 50 satellite locations around the United States, and a few international offices. The primary accounting and MIS (Management Information Systems) computer was a Digital Equipment VAX minicomputer. Most of the user interaction with the VAX was through VT-100-compliant character terminals. The VT-100 standard was commonly used throughout the industry, and many terminals and emulators were available for this standard. PC-based communications software, such as Crosstalk, also supported it.

VT-100 was a character-based standard. It provided both teletype (scrolling) interfaces and data input forms via highlighted (or "reverse-video") blocks of text to indicate data-entry fields. One of its drawbacks, however, was that each character had to be transferred back and forth between the user and the VAX. Thus, sometimes the displayed characters were a second or two behind what the hand was typing.

This is in contrast with terminals which offered "block mode". Block-mode is a lot like character versions of regular HTTP web forms. A form is painted via server commands, and no interaction happens with the host until a Submit key of some kind is pressed. (Whether the VT-100 standard had block-mode or not, I don't know. We never used it.)

Despite the character-delay weakness, VT-100-based terminals made application changes and deployment a snap. There was no installation process beyond plugging in the terminal to the wall and communications jack. (Some places needed desktop modems). Although software had to be installed for PC's to emulate VT-100's, it usually worked out-of- the-box (assuming no modem problems), and once it worked for one application, it usually worked for all the others.

Maintenance is similar in concept to a Web browser--you don't have to install a new browser for every new application (website) you use it with. This is a major reason for the popularity of the Web. One browser, many applications (sites).

There was also rarely any version problems. I believe this is mostly due to the simplicity of the VT-100 protocol. The protocol defined mostly the coordinates of characters on the screen and one "reverse video" mode which either highlighted a given character(s) or made them light-on-dark, depending on the emulator. Thus, you had just characters, coordinates (an 80 x 23 character grid IIRC), and a regular-or-highlight toggle indicator. The protocol did not try to define high-level "abstract" structures, macro languages, nor other features which may have complicated things and created versioning problems. (Perhaps there were extended versions of it out there, but our software never used such.)

It was a pretty good victory for "thin clients". If a terminal croaked, one just takes it to the back room and brings out another one. A change in our software never required a change in emulator version (that I know of). As client-server and fat clients (PC exe's) were growing in fashion for custom business applications, the "desktop babysitting" started increasing more and more. Programmers, not just general technicians, now had to frequently visit problem desktops to try to figure out what was going on between their applications and the user. Another DLL conflict? Wrong application version? Programmers started losing weight from all the walking around. (A skinny programmer is a sure sign of something being off kilter.)

Plus, distributing applications to the jet-distance satellite offices became a royal pain. I suppose one could say that it increased software quality because a new bug meant sending out stacks of upgrade diskettes. The Verbatim diskette company probably owed much of its profits to us. Not to mention the install effort on the other end of the mail. (Downloading exe's proved not to be very effective at that time. Besides the download time, it often required a client-side installation script, and even those were hard to keep updated.)

Now don't get me wrong, I am not a Luddite (at least not about this topic). The VT-100 model did not work well for all application types (partly because the VAX was overburdened). And, I am not for going back to character mode and away from GUI's. The key is that I don't think the benefits of "dumb terminals" (simple browsers) and GUI's are mutually exclusive. A standardized "GUI browser" is a workable idea.

There are two events that got me thinking heavily about this issue. The first was my early usage of data dictionaries, and the second was the online service CompuServe.

My first data dictionary-based application was done with Clipper around 1991. (Technically, it should probably be called a "field dictionary".) There were about 40 satellite offices in the target state that used a certain application. By putting much of the field rendering information (and some validation) into the data dictionary, fields could be changed without installing an updated EXE (program). Only a new data dictionary file/table would be needed.

For example, the application had a "help box" down at the bottom of the screen. The help-box had about 3-lines of detail that came up automatically describing the active field . One could change the text of these descriptions by simply supplying a new data dictionary file/table. Other field attributes included screen position (coordinates and screen identifier), field length, title, and formatting templates such as "999-999-9999 XXXXXXXX" for phone numbers. ("9" means digit, and "X" means any character, in this case for extensions.)

I have found that computerized business forms have not really changed that much since the character (pre-GUI) days. The biggest difference is the use of buttons, tabs, and the mouse instead of function keys and arrow keys for navigation and events. Contrary to common belief, character-based forms were not necessarily less "event-driven". Nor did they have to be "modal". (However, such techniques were less standardized and not always supported very well by the development tools of the time, often due to or influenced by hardware limitations. But, if you really wanted them, they could be done.)

The second inspiration event came from using CompuServe. Before the Web caught on big, CompuServe had its own "browser" (or "client") for its own service. For those of you who don't remember, CompuServe was a service similar to America Online (AOL). In fact, AOL later purchased CompuServe.

The company came out with a Windows 3.1 GUI-based service browser/client in the early 90's that was pretty good for its time. They also had a character-based interface which was their original interface, but I rarely used it. ("Browser" is probably not the best name for it, since a good portion of its interface design was hard-wired into the client program.)

I noticed that there were a few services on CompuServe that had something odd about them. When you selected these services, GUI forms would pop-up, but these forms looked kind of odd. For one, they came up a bit on the slow side. (I was using a 2400 modem baud back then.) I also noticed that the modem indicator was showing a lot of activity while the forms were drawing. It occurred to me the commands to draw these GUI's were probably coming from the CompuServe server over the modem.

That means that the form design and actions could be defined and changed on the server without CompuServe having to mail out a new version of their browser/client. That got also me wondering about what the protocol for modem-based GUI's would look like. (I didn't have enough hacker skills to really see CompuServe's protocol.) I figured that it had commands that allocated widgets (text-boxes, form panels, buttons, etc.) based on some kind of Cartesian (X, Y) coordinate scheme.

Soon after that, HTML and HTML forms became the rage. I got to thinking that maybe HTML forms could serve as the VT-100 counterpart for GUI's. However, HTML forms had problems. The biggest problem was that you had to refresh the entire page to change attributes, messages, or appearance. Each communication with an HTTP host is supposed to generate a new page on the browser. Whether the transaction is huge or tiny, a new page is still rendered. Thus, if 98 percent of the form is the same, but you want to change 2 percent, you have to re-send 100 percent of the page instead of the 2 percent that changed.

JavaScript and DOM (JS+DOM) are supposed to solve some of this, but I find JS+DOM awkward, version sensitive, and buggy. Even if one can get JavaScript and JS+DOM to act the way they want, the result is much more complex than doing the same thing in client-server tools like say Visual Basic, Delphi, or Power-builder.

I think most programmers would agree that achieving a dynamic GUI interface in the above-mentioned client-server tools is simpler than achieving something similar using JS+DOM on a Web browser. The key question is "why?". (I am assuming here that SCGUI applications could be designed and managed from such IDE's if it caught on.)

I believe part of the reason for this is that Web browsers and HTML are optimized for brochure-like interfaces, and not business forms and screens. It is hard to retrofit something originally made for "e-brochures" to make it better handle business forms. To get a good fit, one has to get a protocol that targets mostly business forms, I have concluded.

Java Applets were supposed to be one solution to this, but never quite worked out. The first problem is that any application complex enough to be a significant improvement over HTML forms often takes too long to download. The second problem is that the proper Java engine has to be on the client. If the wrong version is out there, then things can easily crash or act funny. In fact, they crash and act funny even if you do have the right version.

Java applets and JavaScript problems highlight the difficulties of executing code on the client. You almost might as well use Visual Basic (or other GUI client-server tools) if the client needs to download complex run-able content. Java is supposed to provide better security by wrapping applets in a "sandbox" to keep them from directly acting on your local file system and OS, but there are still plenty of holes if you don't upgrade the run-time engine frequently enough to keep ahead of the hackers.

The roller-coaster patterns of the dot-com era put me in a position to be a consultant/contractor for multiple companies working on B-to-B and intranets. I saw the same theme over and over again: I kept seeing companies trying to make Web-based applications act like "real" GUI's. Visual Basic and desktop applications spoiled businesses' expectations of what custom business applications can look, feel, and behave like. Yet, HTML+JS+DOM could not really satisfy these expectations.

So, a local (client-based) interpreter has pretty much flunked the quest toward server-based GUI's. Requiring a program-running interpreter on the client is too much complexity and risk to manage. The web browser has in effect become a "fat client", with most of the problems of fat clients. It encourages one to start to look back at the VT-100 model with its K.I.S.S. (simple) protocols for some inspiration.

Another attempt at a solution are technologies like PC-Anywhere, Cytrix Winframe, and VNC. However, these don't work over HTTP very well, due to latency issues and often band-width requirements. They tend to send an image of the screen and/or the parts of the screen image that change. Thus, the image of each letter you type has to be sent from the host to the "browser". HTTP is meant mostly for grouped transactions instead of a steady stream of bits.

It sounds like HTTP is the problem, so maybe it should be replaced with a more steady-stream-friendly protocol. However, HTTP is too entrenched. Other protocols are often blocked by fire-walls, for example, and network administrators are reluctant to support too many protocols and external I/O sources. Thus, unless another protocol gains significant market share, network administrators and vendors will be reluctant tinker with their fire-walls etc. There is simply too much intellectual and physical capital dedicated to HTTP.

Besides, why should HTTP's non-continuous nature stop us from having GUI's? HTML forms don't need to send the image of every character back and forth as it is being typed. Is there an inherent tradeoff going on here? Do we really need steady-stream transmissions to get the full power of GUI's for typical business applications?

The event feedback approach for communication between the server and the client seems to fall into one of three solution categories:

1. Per user-movement or pixel change

2. Per widget

3. Per form

"Per user-movement or pixel change" is what Cytrix, PC-Anywhere, VNC, and even the VT-100 protocols do, for the most part. The difference between the first three and VT-100 is that the first group usually send image chunks, while VT-100 sends characters. However, conceptually they are similar because characters were the "screen image" in the console days. One can almost think of characters as "fat" pixels, or a group of pixels.

"Per form" is pretty much what Web-browsers and block-mode terminals (see beginning) do. Nothing happens until a "submit" event sends the contents of the form "template". (However, I think block-mode terminals had the option of NOT redrawing the form, but using the same template for the next round. This is something that HTML forms generally lack, barring convoluted, crashy JS+DOM tricks.)

The second one, "per widget" is strangely sparse in actual implementations. However, I believe it holds promise to bridge some of the gap between the latency problem of screen image streams (#1) and the low interactivity level of block-mode (#3).

However, I got to thinking about whether these options had to, by call of practicality, be mutually-exclusive or "global" in a protocol definition. My conclusions was, "Heck No!". Each widget and form declaration could simply tell the client what events to send (or not send). A declaration for a "Save" button could resemble:

  declareWidget("Save", type="button", x=35, y=2, 
        onClick=Yes, onSubmit=No, onChange=Yes, etc...)

This may at first resemble the JavaScript approach. However, the event specifiers are not programming commands, but simple Boolean switches (or later "flat" codes) that tell the client which events to send back to the server, along with the widget's contents. Like strait HTML (without JavaScript), SCGUI does not send any "active" programming such as IF statements, loops, etc. This keeps the language (protocol) and the browser simple.

The options don't tell the client what to do, but simply what to report to the server. (A select few commands can directly result in client behavior.) Thus, "onClick=Yes" simply tells the client to report any clicks to the server. You can perhaps interpret it as, "TellServerAboutClicks=Yes." The server then decides what to do about it based on programming logic, event tables, etc. on the server. The server may even decide to completely ignore it. (There are also other related features, such as synchronous versus asynchronous communication, but we will not cover those here. See links below for more.)

My early drafts of SCGUI resembled syntactical aspects of Visual Basic for some unknown reason. XML started getting a lot of attention, so I decided to re-work the draft standard into XML. Besides looking less like Visual Basic, I figured that maybe it might get more attention due to the popularity of XML in the trade press.

With XML, the possibility of "flow-based" widget location management and grouping became something to consider, given XML's ability to easily nest structures. However, I rejected that partly because coordinate-based screen management tends to work better in many custom business applications, in my experience; and partly because the server can manage the flow itself if needed, sending only the resulting coordinates to the client. This is in-line with the SCGUI philosophy of keeping the client (GUI browser) simple. If it is something that the server can readily take care of, then keep it out of SCGUI. One must not forget the lessons of the VT-100.