As we've mentioned before, early browsers were text-only. To make life easier on the Web, applications were developed to...well, let's start at the beginning...

Ahhh, the good old days...
In the good old days (the '80's), if you were fluent in UNIX, working on the Web was easy. You would type various cryptic command line instructions at the prompt, hit enter, and wait for the UNIX server to respond. If you were lucky and had all of your backslashes and asterisks in exactly the right place, something would actually happen. Otherwise you were rewarded with a blinking cursor and little else. Let's say you had created something like a cool 15 second .wav file and you wanted other people to be able to hear it. Here's all you had to do...

1) Fire up your UNIX shell connection, or if you were lucky, a SLIP connection.

2) FTP your cool .wav file to the bin/public/alt/sound/blah/blah/blah directory on the server.

3) Add a description of your cool .wav file to the index.txt file that every directory had. (By the way.... the only way to know what was what was to read the index.txt file in every directory you came across.) Or, you could call your friends on the telephone to tell them what and where your cool .wav file was. If you were feeling really lucky, you could use Gopher, but that's a story all by itself, since Gopherspace was notoriously unstable.

4) Once your friends finally found your file, they could FTP it down to their computer.

5) They would open up their cool .wav file player, find your file on their hard drive and.......... PRESTO!

6) They could finally hear your 15-second cool.wav file.

Transferring that one file probably only took an hour or so, and left plenty of time to do all of those other things you'd been wanting to do, like lose fifty pounds, grow six inches, and get a tan. It was all great fun when it worked, at least for the first couple hundred lines of code. After that, well, let's just say that it was a little like pulling out your nose hairs with a pair of rusty pliers.

It's Alive!...
Just about the time when everyone was beginning to think that all of this was just a little bit more trouble than it was worth, a flash of visionary genius from a group of serious scientists fused with a flash of inexhaustible enthusiasm from a group of student maniacs in the basement of the National Center for Supercomputing Applications at the University of Illinois, and Mosaic was born.

     Mosaic was the first Web browser which made use of a Graphical User Interface (also known as a "gooey"), that friendly-looking set of buttons and scroll bars and menus that hides all the command line stuff from the user. The cryptic commands are still there, mind you, it's just that the browser now does the command line stuff while you point and click. Most browsers even supply the 'http://' for you in the URL. All you have to do is type in the 'anothersite.com' , hit return, and off you go. The browser looks up the address, negotiates the connection to the server, retrieves the data ,and 'POOF,' it appears on your monitor.

     Without getting too far into the which-electron-goes-where history of it all, let's just say that Google, Netscape, Microsoft, Yahoo, AltaVista, and all the gazillion other users and companies that make their living on the Web owe a great deal to the people who created Mosaic. (As a matter of fact, the first versions of Netscape and Internet Explorer were actually created by some of the very same people.)

     Once users had a browser that made connecting and interacting with Web servers look easy, they started to realize that the browser 's abilities were somewhat limited . In effect, you used your browser to poke the Web with a stick, and it sent you a text file. You could see a lot of text, but you really couldn't interact with it very well. Pretty soon surfers began to get ideas about receiving images, then sound, then video, then Virtual Reality, then..........Remember Plug-ins and Helpers? You know, about 5 paragraphs ago? Well, here's where Plug ins and Helpers come in.

OK, So What Do They Do?
Simply, Plug-Ins and Helpers allow you to receive and manipulate files which are not supported directly by your browser. Most browsers support HTML files and two kinds of image files, GIF and JFIF/JPEG. Virtually everything else, from sound to Virtual Reality, is handled by a Plug-In or helper application.

     Plug-Ins (I love this high tech language stuff) actually 'plug in' to the browser. This means that as long as the plug-in meets a certain set of minimum requirements, software routines which live in the browser will allow a two way conversation between the browser and the plug-in. The browser temporarily relinquishes control over the incoming file in exchange for control over activation of the plug-in. This browser architecture opens up a whole new world of possibilities when it comes to working on the Web. You're no longer stuck with the choices given to you by the browser giants. Here's an example.........When a browser comes across a Flash file, it sends a message to the Flash Plug-In, activates the program, and hands the file over for execution. Flash opens up a window within Firefox and plays the file. If all goes well, the whole thing happens seamlessly, without derailing your train of thought. Once the Plug-In is configured, it's all automatic. Nothing to open. Nothing to close. And nothing to think about. Pretty neat stuff.

     Helpers often work in a slightly different way. If a Plug-In is not available to your browser, it will look for a helper to deal with the file. When your browser sees a .BMP file, for instance, it looks through its list of helper applications and MIME types in hopes of finding some instruction that will tell it what to do with the file. It may see that you have told it to use say, Paintbrush as the application to view .BMP files. The browser then calls Paintbrush, which opens a separate window outside the browser as a stand-alone application, and loads the .BMP file. You see the .BMP displayed in Paintbrush. In order to return to what you were doing, you'd have to dismiss the Paintbrush window and re-select the browser. If you wanted to refer to the .BMP later, you would have to interrupt your Web session.

Frequently Questioned Answers About Plug-Ins and Helpers...

Since there seems to be a bit of confusion about Plug-Ins in general , we thought we'd say a few words about them ...

Plug-Ins are Platform Specific. This means that even though the files may work on many different machines, the applications that manipulate them must be written specifically for your operating system. The same Flash file, for instance, may be viewed on any PowerPC, WIN XP, Linux, WIN 2K, or WIN NT machine, but the Plug-In that you downloaded for your WIN XP machine will not run on Linux.

Plug-Ins come in three basic flavors.......

An Embedded Plug-In appears within it's own window inside of the main browser window, much like a normal image file. Unlike plain old graphics, however, embedded Plug-Ins remain active within the window, and are capable of tracking mouse movement and location, keyboard inputs, or signals from any other input device. This means that they are capable of responding to a wide range of outside inputs from various sources in real time. In other words, they're highly interactive.

Full-Screen Plug-Ins, like Adobe's Acrobat Viewer, commandeer the entire available browser window in order to display their own content. If you're viewing a document with an Acrobat Plug-In, the document looks, feels and works just as if you had quit Netscape and opened the file in the stand-alone version of Adobe Acrobat. You can scroll, print, search, and do all the things you can do in Acrobat. When you're done, you just click on the close window and you're back on the Web.

Hidden Plugs-Ins, such as decompression engines and MIDI players, usually don't have any visible elements, but work in the background to provide you with some feature that wouldn't otherwise be available.

Different Plug-Ins are capable of working with data in different ways. Some Plug-Ins require that the entire file be present before it can be manipulated. Other Plug-Ins, such as Windows Media Player and Quicktime, support streaming, which means that the program will work with any data that it happens to have at the moment. Streaming has become a very popular way of transmitting real-time events (such as music videos) over the Web. Instead of downloading data to the hard drive of your computer, the Plug-In intercepts the 'stream' coming over the wire and displays it for you in real time.

     Now's probably a good time to talk about system requirements. All this wonderful stuff is a load on your system. Plug-Ins and Helpers, like everything else on your computer, require disk space, CPU cycles, and memory; things that are in short supply on many machines. If you have a new system (less than 2 years old), you're probably OK. Older systems are going to have a harder time.

     Some Plug-Ins, like the Real Audio Player, won't run on less than a 56K connection. Windows Media Player will struggle along on an older system, but the video will be jumpy and the audio will drop out from time to time ...... not really the way to view music videos.

     So, how do you know if your system will have what it takes to run Plug-Ins and helpers on the Web? Here's our best advice... Check the specs at the download site, then try it. If your system doesn't like the program, it's possible that it'll crash . For MAC, WINXP , and Linux users, that usually means shutting down your browser and starting it up again. Owners of older Windows systems may not be so lucky. A crash from a plug-in may require rebooting the whole system. It's probably not a good thing, but it's not the end of the world, either. It certainly shouldn't stop you from experimenting. It's not that the plug-ins are unstable or badly designed. It's just that the possible combinations of CPU, memory, modems, manufacturers, displays and operating systems are staggering. It's impossible to design anything that will work flawlessly on every system. Look at this as an adventure, which may surprise you with delight at viewing a VRML file, or have you tearing your hair out (in a virtual way, of course).

We've really just scratched the surface of Plug-Ins and Helpers here. If you really want to get a feel for what's out there, treat yourself to regular exploration days. Take some time to experiment. Almost all of the plug-in compliant brower sites either give away software or allow you download demos. Firefox Central http://www.mozilla.org/products/firefox/central.html is a good place for the curious to start. Pick something that suits your fancy, download and install it, then explore some of the other sites which use it. I can almost guarantee that you'll find at least few ideas for your site.

A Few Last Words Concerning Plug-Ins...
While many helper applications will work with a variety of browsers, at this point in time plug-ins are only available to browsers which support the architecture, such as Netscape, Firefox, and Safari. Way back in the Nineties, the folks at Netscape developed their entire original product line around their vision of an open standard. Even though they used their early dominance of the market to set the operating protocols for Plug-Ins, over the years they have been great about sharing the wealth with anyone who is willing to meet their minimal set of operating requirements. The result of this is that the Plug-Ins market has become sort of the Internet version of Showtime at the Apollo. It's a showcase for new ideas from both established developers and up-and-coming entrepreneurs who might not otherwise get the chance to publish their work. The fact that Netscape chose to allow newcomers and old-timers alike to ride their coattails has been good for the Internet as a whole. The ideas for new software are chosen and developed by the entrepreneurs, judged by the audience, and ultimately live or die on their own merits. This process should continue to provide us with a steady stream of fresh ideas, because developers of new technologies which take advantage of the Plug-In architecture won't have to overcome the corporate inertia of the huge browser developers in order to bring a new idea to market. While many of these ideas will undoubtedly die from lack of interest on the part of the public, this approach provides fertile ground for entire industries to sprout and grow.

     Microsoft, in contrast, has chosen to go in the opposite direction. Internet Explorer does not support plug-ins from other developers at all, and makes extensive use of proprietary technologies such as Active-X, which works only with other Microsoft products. In the immortal words of His Billness...."plug-ins are a no-win situation for developers". Still, Microsoft has been active in the development of plug-ins such as the Powerpoint Animation Player and Publisher for Netscape's Navigator, among others. We'll leave it to you to figure out what all this means.

     Running in parallel with the plug-in controversy is the issue of Java and JavaScript, two versatile cross-platform languages which were for many years the subject of a loud, contentious battle between Microsoft and Java's inventor, Sun Microsystems. The outcome of this lawsuit could profoundly effect the direction of the internet and computing in general for many years to come, but if you are to fully appreciate the situation I'm afraid I'll have to take you on a short detour. Hope you don't mind. Here goes.........

In order for software developers to thrive in the personal computer market, it is necessary for them to develop applications which will run on the maximum number of computers. Early in the game, Microsoft was propelled to it's present status as the 800 pound canary by a tidal wave of cheap clones and an army of developers eager to earn themselves a leading role in the then-new computer revolution. As major and much needed changes in their operating system evolved, Microsoft was quick to strike a deal which effectively gave them a virtual stranglehold on their fellow developers. It sounded kind of like this....."play nice and we let you peek under the tent at the new operating system code before the next upgrade is released. Disobey and we leave you out in the cold to be eaten by your competitors." And so it remains to this day.

     Enter Sun Microsystems with a fairly radical idea........"Why not create a language that will allow a developer to write a single version of an application which will run on any computer?" This eliminates your dependence on any particular operating system. Bad for Microsoft. Good for the rest of the world. Java and JavaScript were developed and were an instant hit on the Web, where a huge variety of computers and operating systems abound and cross-platform compatibility is a huge deal. After a year of trying to downplay the technology, and watching the Java-enabled version of Netscape sprint ahead of Internet Explorer, Microsoft reluctantly licensed Java. Recognizing the implications of allowing Java and JavaScript to take hold on the Internet, they almost immediately began to change it in a way which I will explain shortly. Sun, interpreting their actions as a hostile breech of their licensing agreement, sued.

     Microsoft claimed that Internet Explorer was fully Java compliant and that they were not in violation of their licensing agreement. The first part of their claim is more or less true. Standard Java calls will usually produce a reasonable facsimile of the expected behavior in Internet Explorer. It is, however, also true that Microsoft has developed their own implementation of Java called JS, complete with a very slick and easy-to-use, if non-standard, development shell called Visual J++ (now Visual J#). Microsoft designed a huge pile of Java-like "enhancements" into Visual J# and threw them into the same barrel with the standard Java libraries without bothering to mention to anyone that the resultant scripts often work only with other Microsoft products. Because they strayed from the standard Java implementation, certain features created with Visual J#, which will almost always run perfectly on Internet Explorer, will almost always (surprise!) crash Internet Explorer's competitors, even if they are truly Java-compliant. Java..... Netscape....... J#. Two Birds. One Stone. You gotta give 'em their props. These guys are good.

After a long, contentious court battle, Bill Gates, without admitting to anything, quietly coughed up 1.8 billion dollars to Scott McNeely, just to get Sun to stop biting at their ankles. For a company that is literally sitting on $40 billion dollars in cash, this is an amount that could easily be found between the cushions of the corporate couch.

     While Sun is trying to develop applications that will run on any operating system, Microsoft is clearly running full speed in the opposite direction. My guess is that as more and more scriptlets and other applications are generated by the unsuspecting using the heavily- promoted Visual J# and Microsoft's suite of proprietary Web "enhancements" built into the .NET architecture, not to mention the the upcoming Longhorn OS, thousands of Web surfers who don't know any better will begin thinking that all non-Microsoft browsers are just plain squirrelly. Microsoft will of course counsel anyone who will listen that all their problems will be solved if they just switch to Internet Explorer. There you go...crisis averted. Security be damned. Though Microsoft's newest version of Internet Explorer is greatly improved, it is largely thier brilliant strategic maneuvering, in conjunction with their bundling of Internet Explorer with every operating system, that has propelled Microsoft to the top of the browser business. You can bet that the new browser built into Longhorn will be unseverable from the OS.

     For those of you who may still be wondering why the Clinton Administration's Janet Reno and twenty States Attorneys spent so much time and money barking at Bill Gates, here's a clue...for Microsoft, the browser war is not about browsers at all. If you check your copy of Windows you'll see that Microsoft has built "channels" into their software which funnel their users to other products in the Microsoft empire...internet access, software sales, news, banking, investment & financial services, travel, shopping, ect. These channels are accessed through their browser. The multi-billion dollar revenue streams to be gained from controlling these channels and developing dominant market positions in these peripheral services are the real spoils of the browser wars. Data mined from the information shared among their consumer services divisions and culled directly from the user's machine using tools such as the new MSN Desktop Search tool can be converted directly to advertising revenue. Killing Netscape and the rest of the upstarts would just be icing on the cake. Think about that the next time you see Steve Balmer on your television, perched on the edge of a desk in his shirtsleeves, smiling benignly and babbling on about "innovation" like Mister Rogers. Far from embracing innovation, Microsoft has declared war on it. "Hello, boys and girls. Can you say ... monopoly is good? " We knew you could.)

     Anyway, the point of my little digression is that this ongoing insanity once again highlights the compatibility issue. If you're developing in a controlled environment, like an Intranet site where most of the machines and the browsers are similar, you can usually get away with implementing specialized, nonstandard features because you know that everyone on the system will have access to them. If you're developing a site for the Web it's a different story. Once you start to stray from strict adherence to official W3C standards, the portion of your audience that can see or hear what you're saying starts to fall off rather dramatically. You will need to keep this in mind when you design your site.

     Another thing to remember about Plug-Ins and Helpers is that while they are usually not very large, ( a 1 to 5 Meg compressed file is typical) they must be downloaded and configured before they can be used. This takes time and can cause some confusion or even frustration if they turn out to be incompatible with your viewer's computer. And corporate users seldom have any control over what is allowed on their office machines.

     Although Plug-ins and helpers can add interesting features to your site, the fact that they work at all raises a couple of important questions, and may serve to remind us that we're still missing a piece of the puzzle. Plug-Ins and helpers are applications. They're not text files written in HTML, nor are the files that the Plug-Ins and Helpers use. When you push the button to download Shockwave, for instance, or go to Yahoo! and ask for something that may not actually exist in one place, like a list of poetry sites in Pennsylvania, how does the server know which file to send? In order to give you the rest of the story, we're going to take you to the "Other Side" of your Web connection and introduce you to the world of the Common Gateway Interface.............