What Things Are, and What They Seem to Be
As of December 2011, this topic has been archived. As a result, it is no longer actively maintained. For more information, see Archived Content. For information, recommendations, and guidance regarding the current version of Internet Explorer, see Internet Explorer Developer Center.
May 9, 2000
If you've seen the movie "The Matrix," you'll remember the scene in which the little boy caused a simple spoon to flow around as if it were a piece of silly putty. You will also remember the classic line he then uttered: "... there is no spoon." You all heard it, but did you understand what it meant? I know it's only a movie—but the meaning behind that simple phrase is in fact very important to programmers.
Keanu Reeves plays the character "Neo," who finds that he has been living his life trapped within a computer-generated simulation. Recently pulled out of the simulation, and into the real world, he has found friends who are capable of re-entering this ultimate graphical interface. It is during one of these trips back that Neo encounters the young boy who can do things to a spoon that would make Uri Geller weep. The spoon is a manifestation of this computer simulation. As a "spoon," it doesn't actually exist. It is instead defined by subroutines, components, parameters, and other such building blocks that should be quite familiar to a computer programmer. It just "looks" like a spoon when the function is finally executed.
Look Easy, Be Easy
As computer usage becomes more prevalent in our society, the ability to use and interact with these systems needs to become easier and easier—so that you don't need a computer science degree to know how to turn them on and off. This simplicity extends not only into the usage of computer programs, but to the tools and methods used to create these computer programs.
We old-time programmers remember the days of ML, or Machine Language coding, when we wrote programs by manually storing the individual numeric computer codes into the systems memory through the use of toggle switches. Above these switches, we usually had a single row of LEDs, which played the role of the computer's display. Just knowing how to look at existing ML code and understand what it was trying to do was hard work. For example,
73 70 6F 6F 6E 00
is the word "spoon" as it might be written into the data segment of an ML program. Today, programmers expect to be able to write something like:
spoon.monogram.letter = "R"
which you could show to almost anybody, and they could guess at what this would be expected to do. Which would you rather have to deal with?
Redefining the Spoon
In the world of the Matrix, Neo and his friends have some level of understanding of their artificial world—and their knowledge assists them in being able to have a minor influence over the programs that control what appears to be their "physical" surroundings. For the most part, these abilities are limited to the programmability illustrated in the spoon.monogram.letter example above; they can affect their surroundings, but essentially only by supplying different values for what we would call the "exposed interfaces." For example, they could change the monogram on a spoon, perhaps the metal it was made of, perhaps even turn it into a fork. The young boy showed how he had learned even more about the manipulations capable of a "spoon" object, to the point that he could affect its form radically. He realized that it was not a "spoon," but an object with physical characteristics that through proper programming he could alter. However, through all of the transforms that he applied, the object held onto some aspect of "spoonness"; you could always look at it and recognize in some way that it at least used to be a spoon.
By the end of the film (and I hope I'm not giving the plot away to anybody), Neo discovers that he can take this even further. He essentially realizes how he can work down at the ML level of this artificial reality, and—in the process—totally redefine everything.
Programming Meets the Web
I view this all as having a striking similarity to our own endeavors in programming and procedural manipulation—a similarity that is probably the most obvious when you look at the new "Web" programmers among us.
One of the more common HTML/scripting questions I get regards adding pop-up menus to a Web site. Somebody sees a menu on somebody's site, and asks me how to write the code for this. Or they "extract" some menu code from some site, and then ask me why it isn't working for them, or perhaps they've actually coded something up from scratch, and ask me why they can't get it to perform some specialized action.
There Is No Spoon
To me, this comes down to the programmer's ability to realize that there is no spoon. Or, in this particular case, that "there is no pop-up menu."
We are used to seeing pop-up menus in applications all the time. Perhaps some of us have even written some Windows code in which we define and use a pop-up menu. A couple lines of code, some definitions of the menu titles, and action codes, and suddenly a fully functional pop-up menu is part of the application. Try the same thing on a Web page, and you have a different story entirely. While most graphical operating systems have some built-in knowledge of what a "menu" is, and how to provide programmatic interactivity with it, there is no programmatic equivalent to that knowledge in HTML. Thus, a graphical operating system will supply us with a "spoon" that we can manipulate—but a Web page not only has no "spoon," it doesn't even have any silverware.
To implement a pop-up menu in HTML, or Dynamic HTML (DHTML) to be more accurate, the programmer needs to get beyond seeing it as a "menu," and instead dissolve it down to a finer level of granularity, then rebuild it into a menu bit by bit. It is only in this fashion that you can arrive at something that behaves like a menu, without having a menu object available. It can be done. In fact, here is a good article on pop-up menus.
This article contains a fairly detailed description of the complex issues involved with placement, functionality, and display methods; it even includes sample code illustrating how to do everything.
Just don't think that it will be easy. Menus are fairly complex objects. You need to define carefully how and where the menu will display, you need to hook into the event model to provide proper mouse and keyboard support, you need to be able to determine how and when to bring up submenus, and you need to determine when to cancel the menu object to get it out of the way. All of this doesn't even deal with actually making a menu selection, how to change highlighting, or how to notify some procedure as to which menu item was selected. Then, to add the icing to the cake (or the polish to the silverware), you need to design your menu interface to be as intuitive and comfortable as possible—remembering that your menu will most likely want to be shown on Windows, Macintosh, Linux, and various other operating systems, each of which have a slightly different way in which that particular GUI chose to define menu interactions. While we're on the topic of other operating systems, there is also the whole cross-browser-platform-compatibility issue.
All of which might make you think that eating with your fingers may not be such a bad idea after all.
Robert Hess hosts the MSDN Show.