Building Professional Web Sites with the Right Tools

One byte.

If you were to ask a dozen long-time programmers to name a single industry event that impacted their profession in the most far-reaching manner, you would receive at least ten unique answers (or more likely 10.25, considering the audience). I've pondered this question at length and have zeroed in on my answer. There's a story, hopefully an interesting one, behind it, so I'll keep you waiting for my answer just a while.

I joined the computer industry in 1977, an amazing period of technological beginnings after what seemed a long, relatively stagnant period. I was fortunate to learn a large breadth of programming languages, some still in use, some now lost in antiquity: BASIC, FOCAL, COBOL, FORTRAN, ALGOL, APL, Assembler, PL/1, SPL and RPG; C and C++ came later. The fortune from this knowledge was an intimate understanding through comparison of what makes a compiler tick, and as a result an understanding of how better to create an application.

I was also fortunate to make use of these programming languages, and dozens of variations of development tools and middleware, on several different computer systems. At the time, dominance in the marketplace was held by the mainframe.

I programmed an IBM 370 mainframe. I used an IBM 029 alphanumeric card-punch machine to create the cards that made up both the source code and the Job Control Language the machine required to compile and execute programs. I suppose these cards now exist mainly in computer museums, so for those of you who never saw one, each card had 80 columns (see Figure P-1). Columns 1-6 were reserved for line numbers (we were too lazy to number our cards - a decision which would haunt you if you were ever to drop your deck of, on average, 200 cards and have to put them back in order). Column 7 was only used if the card were a continuation of the card that preceded it. Columns 8 through 72 were used for the actual COBOL instructions, a styling used today despite the fact that the days of punch cards are long gone. OS/JCL was something that, once mastered, stayed with you. I can still rattle it off:

Figure P-1 A standard Hollerith card. Card courtesy of the Computer Museum of America//MYPROG EXEC //SYSOUT DD SYSOUT=A//SYS005 DD UNIT=TAPE, LRECL=80, BLKSIZE=240, DISP=(,KEEP)//SYSIN DD *

Eventually we were able to do data entry with a teletype and with one of the first CRT's (Cathode Ray Tube) to hit the market. The teletype was always a mystery; you could tell where in the processing cycle the system was by the way the print ball would stop, pop up and down, and rotate. The CRT was a blessing. It still required the same 80-column format, but at least there was a backspace.

Another system at the high end was an IBM 1103. This was considered to be a minicomputer at the time. It also used cards, and the card reader was so slow that you could see it sucking the cards through one by one. When designing applications for these beasts, you only had to remember that the input was limited to 80 columns, and the output to 132 columns. There were columnar pads in both sizes that we stocked to facilitate designing reports and input files around the column parameters.

At the low end I entered the PC market before the first PC. I wrote my first applications on a Canon programmable calculator. It was precisely that, a large desktop calculator with thermal paper tape. It could handle 200 instructions or 2,000 bytes of data at a time. Connected to it was an 8" hard-sectored floppy drive, and an IBM Selectric typewriter that had a RS232 port. After executing 200 instructions, you would fetch more by issuing the commandI/O 76I/O 90I/O 90I/O 9200I/O 9100·m20RM20I/O 9I/O a

So really, there were only 200 instructions less those 20 available. Entire applications were written by using functions still on calculators: Store Memory, Recall Memory and Accumulate Memory (M+).

What a debugging nightmare! If the users needed to enter alpha characters, they had to press a completely nonintuitive series of keystrokes, then press the character keys (on a calculator keyboard that didn't resemble a typewriter keyboard in the slightest), and another series of keys when they had finished.

About 1978 my Canon was replaced with an Ohio Scientific computer. Once we got the device drivers working, we had a working microcomputer with a boot choice of three internal chips: the Z80, the 8080A, and the 6502. With this micro came BASIC. This version of BASIC allowed computed GOTO and GOSUB statements, which led to debugging nightmares like:10 GOSUB VAL(LEFT$(Y$,3))

but it didn't have RENUM command, so I had to write one. This machine also made it possible to present the user with a menu because the screen supported the ASCII codes 10 through 13, which allowed the cursor to be moved in a nondestructive manner. The file

I/O was challenging and fun because it was direct, so functions had to be written to place the file cursor at the right point prior to reading or writing.

The microcomputer allowed the 132-column output format to be broken to some extent, because it did provide a means of sending output to the screen. However, despite its allowing the cursor to be moved, the cursor could not be absolutely placed. That is, if I wanted to put the cursor in the 25th column of the 15th screen row, I had to do this by starting at a given point and have the cursor move one position at a time relative to that point. This is still the way that many UI screens are drawn, but the positioning is not accomplished via a loop in a BASIC program. So full UIs were still just conceptual.

At the middle of the market was Hewlett-Packard's HP3000. I wasn't working with the original model (the Series CX), but close: a Series II, the third in the line. A large difference here was that I could touch the system, start it, shut it down, and communicate interactively with it. There was actually some comfort in the immediacy and the machine's "willingness to converse" with me.

The communications were via a terminal, the HP 2640, one of the finest terminals ever made. And this terminal brings me, finally, to my answer to the question I posed. The single industry event that impacted my profession in the most far-reaching manner.

One byte.

And that one byte is the escape character, ASCII 27.

You see, the escape character was used to get the attention of the terminal. The receipt of that character told the terminal that there was going to be a string of characters following the escape character, an "escape sequence," and that every character received after the escape character up until an uppercase character would be a request for the terminal to provide a specific service. These services could include resetting, performing a self-test, performing tape functions (for the 2645 models that supported an internal tape drive), and, germane to this discussion, formatting.

Oh the bliss. With a sequence of Esc &dA, I could make text blink. With Esc &dD, I could underline the text. And with the wonderful Esc &dJ, I could reverse the video (bright background, dark foreground) of characters. If I specified a column and row combination, then ended sequence with `Y,' I could move the cursor to any absolute address on the screen, and with a different terminating character move the cursor in a relative manner. This was my first opportunity to code a UI. I could highlight fields to draw the user's attention, even put a status line at the bottom of the screen. If the user typed something erroneous, instead of trying to stop them in mid-flow I could wait until they requested the screen to be accepted, pop an error into the status line, highlight the erroneous entry, and move the cursor to the offending field. Wow!

Most of what I've coded since then has been an exercise in improving the UI. That's what receives the majority of my consideration when coding desktop applications and creating Web sites. There is one all-important facet to providing users with a visual interface: draw the users in and make them comfortable enough to stay awhile. This requires a well-designed interface to a well-designed application. They balance each other, and if either is insufficient, the users will either not use the application, or, if they have no choice, use it under protest.

Certainly the presentation to the user is only one part of what's required for a Web site, but let's face it, there's no sense in having the rest of it if there's nothing for the user to see. And always remember, they might be coming to your site for the information, but if that information isn't presented in an appealing manner they won't be back! And for the programmer, what a joy to see that drop-down list drop down, that button respond to the mouse click, that text field change when the radio button is clicked. The feeling is even better when you see the page counter incrementing from the people visiting the Web site that you created.

Figure P-2 HP 2640B Terminal

Building Professional Web Sites with the Right Tools takes you through one of many approaches to the entire process of creating a fully functional Web site. I've taken the approach and tools I think provides the best compromise; with Web development everything is compromise.

Instead of the usual reference book type of approach where every nuance of each technology is covered, often with little or no flow, you'll be walked through only as much technology as you need to fully understand each step of the process: obtaining and installing the tools, creating the graphics, designing and developing the database, Web pages and their elements, coding the applications and publishing to the Web.

Alternative tools and technologies that accommodate the creation of a Web site will be mentioned throughout the book. It's not implied, and no inference should be made that the tools, technologies and methods chosen represent the best or only choice - the way the industry is moving at bullet-train speed a different tool might make more sense next week - but those chosen are good, industry-leading tools. Since much time will be spent taking you step-by-step through why certain things are done, and just as importantly, why some aren't, you will ultimately decide whether the approach is good.

If you want to be able to absorb the facets of Web development and view them in a component-like manner, so that you develop the knowledge to develop your own sites, then Building Professional Web Sites with the Right Tools is the book for you!Jeff Greenberg
Atlanta, 1998