best interest to have a strategy. This helps organize your thoughts
and code and also speeds the development and debugging process. There
are scores of worthy publications that get down to the nitty-gritty
of step-by-step application design, and you’ll probably want to
adopt a strategy that works best for you. So I won’t spend too
much time here. Keeping the following things in mind, however,
before, during, and after you code your way between the
<SCRIPT></SCRIPT> tags will surely
save you some headaches. It’s pretty simple: just answer what?,
who?, and how?
How many fields will the form include?
Will users enter the email address themselves or choose it from a select list?
Do you want to validate the form input before sending it? If so, what are you going to validate? The message? The email address? Both?
What happens after the email is sent? Do you want to redirect the user to another page or have nothing happen at all?
What browsers will people be using? Netscape Navigator? What versions: 2.x, 3.x, 4.x, or higher?
Is the application going to be used on the Internet, intranet, or locally on individual computers?
Can you determine the monitor resolution that most users will have?
What type of connectivity will most users have? 56K modem? ISDN? Fractional T-1? T-3?
Since most people have upgraded to at least the 4.x version of these browsers, image rollovers are acceptable. But now you have to reckon with dueling object models. That means you have to make your applications cross-browser compatible or write separate applications for each version (which can be a lesson in futility).
Where will the application reside? The Internet, an intranet, or maybe on someone’s PC converted into a kiosk? The answer to this question will in turn provide many more clues to what you can get away with. For example, if the application will run on the Internet, you can rest assured that just about any type of browser imaginable will hit your site and use (or at least try to use) the app. If the application is restricted to an intranet or a local machine, chances are some kind of browser standard is in place. At the time of this writing, I’m doing consulting work for a firm that is one big Microsoft shop. If my intranet code chokes in Navigator, I don’t care; users must have MSIE.
Monitor resolution is another major issue. If you’ve included a table 900 pixels wide on your page, and users only have an 800 × 600 resolution, they’re going to miss out on some of your hard work. Can you count on a fixed resolution for all visitors? If this is for the Internet, your answer is no. If the audience is on an intranet, you might be in luck. Some corporations standardize PC hardware, software, browsers, monitors, and even resolutions.
Connectivity issues also have an effect. Suppose you’ve whipped up a mind-blowing image rollover sequence that would give Steven Spielberg’s movie animations a run for their money (if so, maybe you and I should . . . umm . . . collaborate). Pretty cool, but users with 56K modems could probably go out and see a movie before your code loads all those images. Most users understand that the Net can get bogged down with heavy traffic, but after a minute or so, most will move on to other sites. Take the bandwidth issue into consideration.
Juggling all of these issues may sound pretty cut and dried, but it’s actually not that simple. You might have no way to accommodate all browser versions, monitor resolutions, or connectivity specs. Now what? How do you keep everybody happy and still wow them with your 500K image rollover extravaganza?
Consider one or more of the approaches I’ve proposed below. Read them all so you can make a better-informed decision.
This egalitarian method of “the greatest good for the greatest number” cross-browser coding is probably the most common and arguably the best approach. By the greatest good for the greatest number, I mean that most users probably have MSIE 4.x and NN 4.x. You can scoop up a large web-surfing population if you implement significant browser detection and code your application so that it capitalizes on the common features of the 4.x generation while it accommodates their differences.
If your users don’t have MSIE 5.0, assume they’re technological nitwits and not worthy of seeing your application, let alone using it. Now you can code away, accessing the MSIE document object model, event model, data binding, and so on. Of course, that sharply drops the size of your viewing audience and can have long-term effects on your ego.
If you’re a glutton for punishment, you can write multiple versions of the application , say for example, one for NN, the other for MSIE. This method is definitely for those into monotony, but there is at least one twist that can pay off. Let’s go back to the connectivity issue. Since it’s often impossible to determine what type of bandwidth users have, allow them to choose. A couple of links from the homepage will enable users with T-1 connections to load your image rollover spectacular, or users with modems to view the benign version.
 Some MSIE 3.x browsers for the Mac do support image rollovers.