PART II
THE TECHNOLOGY:
DEMYSTIFYING COMPUTERS AND NETWORKS


Chapter 4: GUI -- Can Computers Be Usable?

Chapter 5: The Server -- Client/Server the First Time Around

Chapter 6: The Local-Area Network -- A New Type of Computer

Chapter 7: Wide-Area Networks -- Connecting the World

Chapter 8: The Mainframe -- The Technical Shift to Distributed Systems

Chapter 9: Database -- The Concept

Chapter 10: Database -- The Technical Landscape


69

95

117

135

181

223

259

Seven big chapters: this is by far the most ambitious part of the book. Should you read it? For both technical and nontechnical readers the answer is an absolute yes. For the same reasons and for different reasons. The common reason is that gaining an understanding of the technology and the reasons for that technology will provide the means for truly participating in the coming revolution.

FOR THE NONTECHNICAL READER

One reason you might decide to not read Part II is because you're afraid it's too hard to understand. Technology, however, can be explained at many different levels. Some of these levels are too abstract to be useful; some are too detailed to be understandable. The trick is striking the right balance.

That's what Part II is about for non-technical readers: taking important computer concepts, picking the ones that matter, and explaining each of them in a few minutes based on common sense. Why does it take seven chapters? Because the computer industry has developed some amazing and amazingly useful concepts in 40 years. Simply put, there are seven chapters of explanation because there are seven chapters of material worth explaining.

FOR THE TECHNICAL READER

Never trust anyone over thirty. That was the motto of the generation growing up in the '60s. And that is the motto of many personal computer-based developers who just don't know what to think about mainframes, databases, and all the professionals who work with them.

Never trust anyone under thirty. That's what many of those mainframe-based professionals think about the undisciplined, inexperienced youngsters producing all those flashy (but shallow) applications running little toy PCs.

One reason for technical people to read Part II is because it builds some bridges between these two camps. You can't afford to choose between the large application-centered, database-oriented world of the mainframe, and the personally focused, graphical world of the PC. You need them both, and bridges are required to make that fusion happen.

The American Heritage Dictionary defines philosophy as "the critique and analysis of fundamental beliefs as they come to be conceptualized and formulated." Many of the fundamental beliefs driving the computer industry need that kind of critique and analysis much more frequently than is normally the case today. Can PCs replace mainframes? That question can't be answered rationally until some other questions are asked. What makes a mainframe different? Is it just a bigger PC, or is a PC just a smaller mainframe? What about LANs -- where do they fit into this picture?

The same dictionary also talks about philosophy in terms of investigating the causes and laws underlying reality. That's what the next seven chapters are about.

69

Chapter 4

GUI, UI -- CAN COMPUTERS BE USABLE?

Computers are hard to use. Learning to use them in the first place is hard, but even after months of experience, many users still have trouble with common tasks that should be easy to accomplish. VCRs are hard to use, too. Cars are not. Yet a car -- particularly its entertainment system, power windows, and seven-way seats -- is at least as complex as a VCR, and most computer applications should be approachable by any adult who can drive. Consider the following three challenges:

Flying to a foreign country with a different language, renting a car, and getting to a new destination at night.
Buying a new VCR and immediately programming it to record a show running the following night.
Buying a computer application (a project-management package, for example) and using it to plan a short vacation trip.

In theory, the first task ought to be the most difficult, and the third task should be the easiest. After all, the computer application involves no new hardware, talks to you in English, and is designed to actively help its users. Yet, without a doubt, most adults would be guaranteed to succeed at the first task, would have concerns about the second, and would be highly skeptical about their probability of successfully using the new software product.

70

THE INTIMIDATING INTERFACE

Why would noncomputer tasks be so much less threatening? Why does the little challenge in the last paragraph strike a resonant chord with so many people? Because cars, electronic appliances, and most other technical products that people use every day have much more mature packaging than computers. To be more precise, although you don't normally think of a car as having a user interface, it does. And the user interface of a car, after 90 years of development, is far more mature than the user interface of most computer applications. The car's user interface, and the user interface of the highways -- street signs, traffic lights, and so on -- have become so refined that even driving in a foreign country has become possible with no advance training. The challenge is to make computers as nonthreatening and easy to use as any other appliance, and the way to get there is to focus on the user interface, or the UI.

Computers have become dramatically simpler to use in the last decade. Mainframe systems were once so forbidding that only systems professionals and highly trained end users could be trusted to work with them. Yet today, children teach themselves to use Macintoshes and Windows-based PCs every day. Something has changed, and yet, as the three previous tasks show, more change is required before computers become as easy to use as they should be. Some of that change, both in the past and in the future, revolves around the computers themselves -- the hardware -- and much more around the programmers who build the software that runs on those computers.

Computers have become much simpler to use over the past ten years, yet many people still find them forbiddingly incomprehensible. "Intuitive" interfaces turn out to be anything but intuitive when put to the acid test of the real world. Does this mean that computers can never be made really approachable? Or are personal computers as easy to use as they're ever going to be -- which makes the problem cultural?

IT'S NOT YOUR FAULT

Don't blame yourself just yet. Computers still have a long way to go. I make this statement on the basis of simply watching trained computer professionals struggle with supposedly state-of-the-art interfaces and applications. Computer software -- personal computer software, in particular -- is much easier to use today than ever before. At the same time, however, even sophisticated software reviewers, application developers, and other experienced experts often struggle for hours the first time they use any particular package, trying to figure out how to initiate supposedly easy operations. So if normal humans have trouble using computers at times, it's not surprising; there is still a long way to go. Does this mean that computers can never be easy to use? Perhaps. At the same time, in watching children play computer games, administrative assistants produce complex multicolumn newsletters, and managers handle their diaries totally electronically, it's clear that personal computers have become usable in a way that was never the case until very recently.

71

What makes a personal computer different from a terminal? Why can't a mainframe be as easy to use as a personal computer, ever? What is it about the personal computer that virtually necessitates having a computer on every user's desk? The answer to all three questions is the graphical user interface, often called the GUI (pronounced gooey). Understanding GUIs, ironically, is a particular problem for terminal-oriented developers with years of user interface (UI) experience. First-time personal computer users, even children, often have a better understanding of what GUIs are about than the systems professionals charged with developing the next generation of graphical applications.

Any discussion of graphical user interfaces has to start by considering the reason for making the interface graphical in the first place: providing a powerful and evocative mechanism for computers and users to talk to each other. Broadly, then, the GUIs are a particularly powerful class of user interfaces (UIs). The American Heritage Dictionary defines an interface as: "1. A surface forming a common boundary between adjacent regions. 2. a. A point at which independent systems or diverse groups interact. b. The device or system by which interaction at an interface is effected." By following this definition, the user interface is the boundary between the computer and a person working with or through the computer to carry out some set of tasks. Sometimes the person is telling the computer what to do, and sometimes it's the other way around. Drawing a little further on the definition, the user interface is also a device or system. Specifically, in a personal computer environment, the user interface consists of the screen, the mouse, and the keyboard. In a more advanced system, the user interface might also include speakers, a microphone, and even specialized devices such as pens, eye-movement trackers, and touch-sensitive areas.

Literally speaking, the user interface consists of hardware. However, the hardware is generally the smallest part of the story. Making computers usable is very hard! Most of the elements people think of as built-in parts of their personal computers have actually been around for many years, long before personal computers even existed. For example, the color screens, windows, menus, and graphics users stare at so intently have been common since the early '70s. The mouse, too, as a pointing device, was invented in the '60s. Yet word processing packages, until recently, have taken only limited advantage of these hardware elements. Put this problem into perspective by considering the gap between what users can easily conceptualize and what their software tools enable them to do.

GREAT EXPECTATIONS

Every computer user reads books, magazines, newspapers, and newsletters every day. These publications routinely use multiple columns, pictures, and fonts to simplify the presentation of information. Ideally, then, that same user would expect to be able to use an expensive computer and word processor to produce printed material looking like what he or she reads every day. Either by using an example or by saying the words, describing the format of that material is easy: a three-column newsletter, with a

72

picture of the author in the center of the page, with text flowing around it. Ten years ago, such a newsletter could not have been produced with a personal computer. Five years ago, it would have required a combination of specialized software products and considerable training. Finally, in the last two years [Ed., Remember, written in 1995], word processing software reached the point where most users could build such a newsletter on a normal personal computer with no external training or advice. Yet the appearance of the hardware -- the keyboard, the screen, the mouse -- has hardly changed during that ten years. Yes, the computers have gotten faster, but that speed has been only an indirect factor. Two other changes have occurred that have revolutionized the perception of computers and what they can do:

Standard graphical user interfaces have provided an environment in which new ways of interacting with computers are now possible.

The programmers who build applications have developed an understanding of how those GUI elements can be used to develop a new breed of software that talks to users in ways different from ways of the past.

Most programmers think of GUIs in terms of a small number of immediately recognizable elements: mouse support, pull-down menus, overlapping windows, and pop-up dialog boxes to display errors. Throw in some color and a modicum of pictorial or graphic display, and that must be the whole thing! Applications with this set of features can be built around both terminal-based systems and very low-powered PCs. For example, products for first-time users, such as First Choice and the early versions of Microsoft Works, offered pull-down menus, windows, mouse support, and dialog boxes, all on 8088-based monochrome PCs with 256K of memory or less. At the same time, nobody thought of these applications as graphical. Something must be missing from the definition. Not only that, but the missing elements must somehow require a great deal of computer power because one thing everybody agrees on is that GUIs work well on only fast machines.

A graphical user interface is based on the following four features:

Common user interface
High-resolution, bitmapped, color display
What you see is what you get (WYSIWYG)
Direct manipulation

In turn, moving into a GUI world requires three things:

Hardware that makes these four features possible
System software that makes it easy for application developers to build graphical applications

73

 

The broad availability of applications written this way

Today, GUI is the accepted standard in at least three environments: the PC with Windows and with OS/2, the Mac with its own operating system, and on UNIX workstations with several operating systems. The following sections take a look at the characteristics of a GUI, one at a time.

COMMON USER INTERFACES

In the early '80s, it was common for every new application to have its own completely unique user interface defining the basic commands available while using that particular application. The Macintosh was the first mass-market computer to introduce the concept of a common user interface to a wide audience. After several years, market researchers discovered an interesting pattern: Mac users worked with an average of over four different applications each, and PC users tended to limit themselves to an average of only two different applications each. In retrospect, the reasons for this pattern are obvious.

Consider the situation confronting a pre-GUI PC user with a basketful of tools. Perhaps the user starts each day with 1-2-3; the leading non-GUI spreadsheet has a command structure based on a hierarchical menu at the top of the screen. Next, as the user moves to WordPerfect, the screen starts off blank to leave plenty of room for text. WordPerfect then calls for extensive use of function keys, coupled with a menu at the bottom of the screen. dBASE, in turn, uses dot commands and a scrolling style of interaction, and so on.

Each new application requires that the user learn how to control the computer completely from scratch. All the little habits and shortcuts, acquired so painfully over time, are useless when moving to the next application, even if it comes from the same vendor (Paradox, SideKick, and Quattro Pro, for example). Worse, even if the user has the time and patience to struggle through several complete learning curves, imagine how complex it is to keep all the separate interaction modes in context if the user now wants to use the tools in an integrated fashion. Little wonder that, until recently, PC users gave up after learning their first or second application.

The common user interface of a GUI defines a standard way of commanding the computer to do things. The use of pull-down menus, coupled with a help system, enables the user to explore the application, literally discovering commands often without having to read any documentation. Furthermore, because all applications use the same broad structure, after learning how to use that first application, the user has, in many ways, learned to use them all. All of this becomes particularly crucial when you picture several applications, each in its own window, running on the same screen at the same time. Having a common user interface in the multitasking world of the '90s is not only convenient, it's essential.

Making life easy for users through common interfaces requires more than just a standard way of building pull-down menus, displaying windows, and so on. At one level, much of the infrastructure required to have cross-application commonality comes

74

from the underlying operating system: Windows, the Mac, and so on. At this level, the emergence of a small number of standard GUI operating systems has been a huge boon for both users and developers of applications. At another level, building easy-to-understand applications with a high degree of commonality and cross-application integration, requires a high degree of sophistication on the part of both individual developers and the organizations for whom they work.

Standard UIs that are easy to understand across many applications require sophisticated standards. Some of these standards come from industry leaders such as IBM, Microsoft, and Apple. Many others, though, are specific to the needs of each organization as it builds and buys applications. Standards can be specified and enforced at two levels. The ideal is to have all standards supported and enforced by tools that also make designers and developers more productive. At the same time, many critical standards -- relating to naming, broad style, and so on -- can be expressed only on paper. Either way, to get the most out of GUIs, building on the huge head start already provided by today's windowing systems, every large organization involved in significant development should be thinking carefully about its UI standards.

Common interfaces are important, but they're far from enough; a good GUI is also powerful and intuitive in ways that no terminal-based interface can equal.

GRAPHICAL SUPPORT: VIRTUAL REALITY

Watching a travel agent work with an airline reservation system offers an excellent window into user interfaces of 20 years ago. Computers, at that time, were thought of as working with words and numbers. Naturally, then, the screen attached to the millions of terminals found all over the world was a place where users could display these words and numbers. All the information in such a system appears in the form of characters -- either letters or numbers; for this reason, this style of interface has come to be known as character-based.

Imagine a passenger reserving a seat on a particular airplane, asking for an aisle seat, just behind the wing, preferably an exit row, and wanting to be as far as possible from the smoking section of the plane. In the world of characters and numbers, the agent sees a seat number -- perhaps 238 -- and then has to determine in some other way whether that seat is appropriate. With luck, the agent may just know whether 8 is an aisle seat on this type of aircraft, but what about the other criteria? Perhaps the airline provides each agent with a set of diagrams showing the seat layout in every type of plane. Or the agent can ask the computer a series of questions about the seat. Either way, helping the passenger is a lot of work; but what's the alternative?

BEING THERE

In a graphical world, the screen displays more than characters; it displays pictures, too. When the passenger asks to pick a seat, the agent calls a seat-layout diagram directly onto the screen; it is immediately obvious whether the seat is on an aisle, where it is in relationship to the wing, how far it is from the smoking section, and

75

whether it is an exit row. Rather than give the agent a faster way of asking about the seat, it's now unnecessary to ask at all; the information is visible immediately.

[Ed. Note: And, by 2001, this easy-to-use interface is on-line, on the Web, so travelers can pick their seats without having to go through a travel-agent.]

Graphical displays even make it easier to deal with words and numbers. One of the problems with designing a newsletter, for example, is that it is often hard to tell how the page will really look after all the text and pictures are put together. Historically, page-layout software allowed the user to specify the layout, but the result could be seen only after sending the result to the printer. Running back and forth from the printer to the screen: quickly becomes tiring and tedious. Moreover, because printing takes a long time, the overall process was expensive in terms of time and materials.

In a graphical world, the computer displays the layout of the printed page directly on the screen. Multiple columns, pictures, and fonts all appear on the screen exactly as they will look when printed. Now, the only reason to send output to the printer is when you're really done with your work.

Being able to display pictorial information directly on the screen makes existing applications dramatically simpler, but it also opens up new classes of applications. For example, a customer service rep can display a map showing a customer's home and the closest service centers or stores to give driving directions over the phone. Such an application might work in a character world, but it would be unimaginably harder to use. Similarly, an architect can display a floor plan and allow clients to directly see the result of moving a wall, a door, or a piece of furniture. More prosaically, 35mm slides can be constructed on the screen, enabling nontechnical managers to build their own graphics, knowing that what they see on the screen is exactly what they will be projecting when their slides are produced.

THE COMPUTERIZED COCKPIT

Underlying all of these examples is a single common principle: virtual reality. Most people have heard of fighter pilots learning to fly in advanced simulators based on the same concept. Wearing a special helmet, the pilot sees two tiny screens, one in front of each eye, projecting lifelike images indistinguishable from those he or she would see sitting in a real cockpit. The pilot's chair, mounted on a special hydraulic system, simulates the acceleration, deceleration, rocking, and twisting the pilot would experience in real flight. Special headphones provide the sounds. Put it all together, and normal civilians get motion sickness in seconds without ever leaving the ground. By providing the pilot with all the sensory inputs he or she would experience in the real world, the simulation creates a virtually real world. By simulating reality, pilots can learn to fly while on the ground. Displaying an equivalent set of letters and numbers specifying the status of the airplane at all times would not even come close to being the same. The graphical environment (and, in this case, the physical hydraulic system, too) makes the application work.

The airline-reservation system, the word processor, the customer service system, the architectural program, and the aircraft simulator all have models of the real world in their memory; the computer represents the world in its head, so to speak. Virtual

76

reality involves projecting that model of the real world directly for the user. Instead of converting the model of the world into words and numbers, the computer attempts to portray that real world as it is.

In a limited sense, GUIs are a special case of virtual reality at work. By projecting the interior of the plane directly, the computer shows directly where the seats are. By displaying the page as the printer will print it, the computer eliminates all the questions and guesswork associated with getting the final appearance to be right. The map of stores and service locations instantly shows the combination of right and left turns that gets the customer to his or her destination, and so on.

In the computer world, GUI as virtual reality is often referred to as WYSIWYG, short for What You See Is What You Get. Typically, this term is used when talking about word processors: the words, fonts, columns, and other appearances you see on the screen are, ideally, exactly what you get when you print. For several years, WYSIWYG (pronounced wizzy wig) was the key selling feature for leading word processors for the simple reason that the amount of time saved by not having to run from printer to computer and back again was enough, at that time, to cause users to switch to a new word processor.

WYSIWYG and virtual reality are two sides of the same coin, both important in allowing computers to interact more naturally with humans. Essentially, the key is to eliminate translation so that the interaction can be as direct as possible. However, displaying the world is not enough to make applications natural, easy to use, and to make interaction immediate; users must be able to manipulate that displayed world directly.

DIRECT MANIPULATION: LIVING IN THE VIRTUAL WORLD

Not only did the original airline-reservation systems use words and numbers to display information, those same words and numbers formed the command vocabulary that drove the system. Travel agents used verbal commands -- abbreviated words and phrases -- to ask for information and to make reservations. The computer responded with equally abbreviated words and phrases. The system, while fast and powerful, required prolonged training -- initiation into its rites -- and was completely opaque to outsiders.

Early word processors and spreadsheets were based on the same central concept: that computers and humans would interact with each other by using commands, words, and phrases. Abbreviation was the trick to make this interaction quick and continuous. Thus WordStar, the first popular word processor, used arcane codes to represent common editing operations; beyond that, text formatting, such as bolding and centering, was accomplished by embedding equally arcane codes directly into the text of the document. 1-2-3's basic command structure, in the same way,

77

consisted of carefully chosen command words combined into phrases; users would then pick particular commands by entering the first letter of each word. Changing the width of a column, for instance, meant first choosing to work with Workspace, then specifying the Column set of commands, and finally picking Width. After abbreviating, the user would type /WCW; it was fast, but hardly intuitively meaningful.

Going back to the virtual reality model, how should the user control the application? In a virtual world, users wear bodysuits and gloves; special sensors enable the computer to know whenever the user turns his or her head or moves his or her eyes. Every movement of a finger, every step, causes the virtual body to move correspondingly. When the user looks to the left, the computer displays the precise sights (and sounds) the user would see in reality. Even if today's virtual reality simulations can't do exactly what I've just described, the concept is immediately appealing and clearly intuitive and natural; but what relationship does it have to mundane applications like word processing and airline reservations?

SOMETHING FOR EVERYONE

The core concept behind interaction in virtual reality is direct manipulation: the idea that users manipulate parts of the virtual world directly, as projected, instead of through the intermediary of word-based commands. The same concept can be applied directly to most applications with startling results in both ease of use and power of interaction:

A travel agent can reserve a seat by pointing to it with a mouse and clicking on the seat directly. If the passenger wants to move to a different seat, the mouse can be used to drag the passenger from the old seat to the new one.

A picture embedded in a newsletter page can be moved from one place to another by dragging it. The user doesn't think about, let alone enter, coordinates like twips, pixels, picas, or inches; instead, as the picture is dragged, the computer automatically adjusts the surrounding text to flow around the picture wherever it ends up.

A column in the newsletter can be made wider or narrower by dragging its right or left margin in one direction or another. Similarly, an embedded picture can be shrunken or enlarged by dragging its boundaries. The user is directly manipulating elements of the real world that the computer is already so kindly displaying.

An architect can move walls, furniture, doors, and windows by literally dragging them around. Each time the user significantly changes the structure, the drawing application adjusts the light coming into the room to show how the new arrangement will really look, complete with shading and shadows.

78

DRAG AND DROP

These examples all illustrate one particular direct manipulation technique called drag and drop, which involves selecting a displayed object, dragging it to a new location with the mouse, and then dropping it where it is supposed to be. Beyond the obvious uses of drag and drop, mostly revolving around geometrical placement in space, there are many less obvious uses that are still immediately recognizable when they are implemented. For instance, dragging a chair onto a garbage can quickly becomes a familiar way for an architect to eliminate furniture from a room. Similarly, having a palette of furniture enables the architect to drag new items (furniture, walls, doors, appliances) into rooms, essentially creating something out of nothing. Clicking on a spray can, selecting a color by clicking, and then dragging the spray can over parts of a picture to color them in, once seen, can be learned in seconds by even a four-year-old.

In general, drag and drop provides hundreds of opportunities to control the computer world in a direct, intuitive, and, best of all, efficient fashion. The best thing about drag and drop is that small adjustments are made directly by just moving the hand back and forth. Comparing this to the paradigm of only a few years ago -- setting values, looking at printouts, and going back and forth painfully for hours -- shows how much UI concepts have advanced in a relatively short period of time.

Drag and drop is particularly appealing because it is so directly analogous to what people do in the real world. However, there are also other direct manipulation approaches that, although less similar to the real world, are still very powerful in continuing to eliminate the need for commands, typing, and interpretation by users.

Although the computer may be simulating the real world, the virtual reality it projects still is based on the software running underneath it. As a result, the virtual world, although never quite as tangible as the real thing, can also be in many ways more intelligent and aware than the real world. Extending direct manipulation depends on taking advantage of the idea that technology can make virtual objects become self aware.

In Wonderland, Alice found that apparently everyday objects had magical properties: they exhibited awareness, could answer questions, and often could even talk back in unexpected ways. Objects in virtual worlds can be made to have the same properties, although in slightly less magical ways. Today, there are several standard ways of interacting with objects in the virtual world of GUIs. Drag and drop is one approach; the two other standard approaches are double-click and property inspection.

DOUBLE-CLICK AND PROPERTY INSPECTION

Both double-click and property inspection implement the same concept: drilling down into an object to look at its underlying properties. In the real world, objects have properties: color, size, weight, name, cost, and so on. (The word object is often used in many technical contexts in which it can be given complex and even mystical meanings. Here, I mean the word in the normal English -- subject, verb, object -- sense.) In

79

just the same way, objects in the virtual world have properties, too: seat number, picture size, column width, chair color, store address, and so on. Many of these properties are visible if you display the object properly in its world setting -- that's what graphical display is all about. And in the same way, many of these properties can be manipulated directly by moving the object in its world -- that's drag and drop. No matter how creative people are, there will probably always be properties that should be represented indirectly. That's where drilling comes in.

Increasingly, today's software writers are providing standard ways of inspecting the properties of an object that can't be manipulated by dragging. Two such approaches used in many applications are clicking the left mouse button twice (double-clicking) while pointing at the object and clicking the mouse's right button (left button for lefties). This action, called property inspection, enables the user to immediately inspect and set key properties of the selected object.

Ugly? Less direct than drag and drop? Yes, but property inspection is still much more direct and efficient than its alternative, command-based interaction. To understand this, consider the alternative. Every application has a command interface, even in a direct manipulation world. In most GUIs, these commands are accessed through pull-down menus, each of which provides access to a list of 10 to 20 commands. Setting the color of a line in a graph means knowing which command in which menu to use, moving the mouse to the top of the screen, pulling down the menu, and getting to the right command. Alternatively, by double-clicking on the line, you can immediately see and change the line's color with no guessing and little mouse movement.

Microsoft Excel incorporates both drag and drop and drilling down in its graphing module. A user can change the underlying values associated with the points on a graph by dragging those points up and down -- making the data value in the accompanying spreadsheet bigger and smaller. By double-clicking on the graph, the user also can change the color and thickness of its line, the shapes of the markers denoting points, and even the type of graph.

To consider a more complex example, imagine a town-planning application that displays a street map as its starting point. The user can add structures from a palette on the side of the screen or rearrange existing structures by dragging them around. Double-clicking on a building shows its floor plan and a text table describing the building's use, inhabitants, square footage, and so on. Similarly, double-clicking on a street brings up a table indicating its width, construction, and traffic capacity. This example shows that even virtual worlds can exist at many levels. Just as Alice was able to shrink and discover a whole new part of Wonderland, computer users can drill down from one virtual world to another by double-clicking.

Direct manipulation (whether it takes the form of drag and drop or double-clicking, and whether the result is as exciting as another complete reality projection or as mundane as a property table) has one important aspect: the user explores and controls the graphical world without having to find or invoke commands. The commands are still

80

there (both for more complex operations and for verbally oriented users), but the combination of rich graphical display and direct manipulation enables the user to explore and control a visual world without expressing actions in words or phrases.

ONE PERSON, ONE COMPUTER

What does it take to actually build the kind of GUIs just discussed? In short, a computer on every desktop, dedicated to the needs of a single user. To understand why this is so, consider the requirements imposed by the need to first project the virtually real, WYSIWYG world, and then look at how it's possible for the user to manipulate it directly. In doing so, the following sections discuss event-driven applications, mouse control, fonts, bitmapped displays, and windowing software. When you've finished reading this chapter, these terms will seem quite approachable -- really.

EVENT-DRIVEN APPLICATIONS

The one-person, one-computer story really starts long before the days of graphical user interfaces; the core is event-driven applications. Consider what happens when a user works the keyboard while using a spreadsheet. Each time the user enters a new number in a cell, the entire spreadsheet may be recalculated. The computer is then forced to redraw all the numbers on the screen to keep the display current. Conceptually, the entry of the new number can be thought of as an event in the life of the spreadsheet. The occurrence of the event launches the recalculation and redisplay of the spreadsheet. Fortunately, even the fastest user can't enter new numbers very quickly.

Now imagine what happens when the user holds down a cursor key causing the spreadsheet to scroll left. When the cursor key is held down, it repeats at the rate of about 15 times per second. This means that 900 times per minute, the spreadsheet program is receiving a keystroke telling it to scroll the spreadsheet to the left. And each time the spreadsheet moves, the underlying program has to redraw the entire screen. This is a new model for two things: how a computer program receives its instructions and how much work is required each time one of those instructions is received.

Classical applications, such as the airline-reservation model, operate on a conversational principle: people talk to the computer, which in turn talks back. The whole cycle is called a conversation. The travel agent enters a phrase asking the computer about the availability of certain flights, and the computer responds with the requested information. Other times, the computer asks the agent for certain information, perhaps about the passenger, and the agent is the one responsible for responding. Overall, the conversations between the computer and the user are structured in predetermined sequences called dialogues. For example, the sequence of ten questions and answers required to report a piece of lost baggage is always the same: when the agent triggers that dialogue, the computer always asks the same questions, and the interaction continues in a fixed sequence until the questions have all been answered.

81

A spreadsheet, by contrast, lives a much less ordered life. Sitting in front of the personal computer, the user has a wide range of choices at all times. He or she can enter new numbers, change existing ones, alter the width of a column, scroll the spreadsheet in any direction, split the screen into two parts, print part of the sheet, and so on. Furthermore, unlike the reservation system, where commands consist of words and phrases, many of the user's actions are triggered by single keystrokes.

Digging deeper, every user keystroke turns out to be an event that the spreadsheet must respond to! Every time the user does anything -- presses any key -- the personal computer program must respond. For example, when the user enters a number, the spreadsheet decides whether it is part of a formula, whether the formula is complete, and whether the digit is at the right margin and the entire number (five digits long) has to be wrapped to the next line. This is what is meant by event-driven programming.

INPUT FROM ALL OVER

In a character-oriented world, events are always keystrokes because the keyboard is the only input device. However, in a GUI world, the mouse (and perhaps a pen or a touch-sensitive screen) can also create events. In the character world, as well, only one program at a time is running, so interpreting the events is relatively straightforward. In the GUI world, however, consecutive events can be directed at a spreadsheet, a word processor, a drawing package, and an electronic mail program, depending on where the user moves the mouse. As a result, an event-driven program creates a world of tremendous variety -- a world in which the application program is interpreting actions and doing meaningful work frequently, often many times per second.

The first consequence of the event-driven paradigm is that just keeping up with all the user's actions requires quite a bit of computer horsepower. However, when you consider the amount of work each action translates into, the need for computer power escalates even more rapidly. Even in the character world, keeping a spreadsheet display up to date means being prepared to redraw the entire computer screen, sometimes many times per second. Spreadsheets lose a lot of their appeal when recalculation takes a second or when scrolling is less than instantaneous. This is the reason that the spreadsheet -- originally VisiCalc and then 1-2-3 -- was the first application that virtually demanded a dedicated personal computer.

As it turns out, though, however demanding event-driven interaction is in the character world, it is infinitely worse (from the perspective of computer power needed) in the GUI world. Talking about running many programs at once gave a hint, but this is only a small part of the GUI story in terms of creating a need for super-high-powered personal computers.

To see how complex the GUI concept gets, watch the computer at work as you move your mouse around. A corresponding pointer moves around on the screen, apparently moving smoothly and continuously as you move your hand. As the mouse moves

82