 | ||
|
| ||
| ||
|
| ||
Nancy Winnick Cluts
Developer Technology Engineer
Microsoft Corporation
Updated March 30, 1999
The following article was originally published in the Site Builder Network Magazine.
Actually, the headline on this article should probably read "Cool New Stuff versus Stuff that Works Everywhere," but that's not nearly as catchy.
A question asked often by Site Builder Network readers is how should they make trade-offs between technology and breadth of coverage. If you create a control using features found on only one browser, visitors to your site not using that particular browser won't be able to use that control, and they may be relegated to the "text-only" world. On the other hand, if you create your site based on only those features supported by all browsers, you lose on the "coolness" scale; you may have great content, but nobody is going to hang around a boring a site.
What's a Web designer or producer to do?
We examined the trade-offs made by Webmasters on four sites. Each site had different goals and varying customer bases (developers, people interested in the cutting edge, consumers, and so forth).
It's easy to set lofty goals for a site. It's much harder to achieve those goals. Reality has a way of rearing its head and making it impossible to meet a goal. That is why I like to keep my goals as fuzzy as possible (only kidding).
Here on Site Builder Network, a site for Web professionals, the goal is to use new technologies where they add value to the site, while ensuring that the user experience on other browsers and platforms is satisfactory (i.e., nothing breaks, and users can still browse the site and find specific content).
On such consumer-oriented sites as Seidlers Jewelers 
, the goal is to reach as many people as possible. The user can be running any browser, quite possibly under Windows 3.1 or on a Macintosh. The site must make it easy for a visitor to find the jewelry desired (say, a nice 18" strand of Mikimoto pearls for an upcoming anniversary) and to purchase them. But the site must be compelling enough that the user doesn't grow bored and leave.
For an intranet, the job is easier. Internet Communication Network, Corp. --- which developed the site for R.L. Schrieber --- designs sites for the Internet and for intranets. Intranets function within a discrete system, so ICN can specify the browsers and platforms to be supported, and can take advantage of specific features. Web sites on the Internet are open to a much broader, more diverse array of hardware and software technologies. The Webmaster at ICN told me, "Although we create sites that target the largest audience possible, the ever-changing feature set of browsers and the requirement to stay 'backward-compatible' make it difficult to produce compelling sites. We try to utilize these technologies, but make it so that our sites can gracefully degrade to provide a good experience in a wide variety of browsers. Style sheets, introduced in Internet Explorer 3.0, are a great tool for adding graphic appeal with a low bandwidth cost, and degrade nicely. If all browsers supported this feature in a standard way, there would be a lot of better looking sites out there."
Microsoft's Internet Explorer 
site also must keep its goals extremely flexible. While showcasing Internet Explorer, the site has to look good on all platforms (including Windows 3.1 and the Macintosh). The Webmasters have provided a downlevel version of their site for users running older versions of Internet Explorer (allowing those users to upgrade from the site), while ensuring the site looks good in Netscape Navigator. You aren't going to get people to read about Internet Explorer if the site looks crummy on their browsers.
The Site Builder Network site is constantly being updated. We like to see how new technologies can solve problems or spice up the site. Sometimes, we find a wonderful solution. Sometimes, we implement features only to discover that, however great an idea, it's way too slow.
To strike a balance among showcasing new technology, performance, and browser support, the Site Builder team had to decide whether to use a couple of new controls: a label control that supported a drop-down menu and the Ikonic Menu Control, which supported images. These were terrific controls, but they had a drawback: They were created using Visual Basic® 5.0, and required the presence of the Visual Basic run-time dynamic-link library (DLL). Not every desktop has this DLL installed, and anyone visiting our site on a machine lacking it would have to download the DLL at run time. The run-time DLL is more than 700K (and that's compressed size!). Anyone using a modem running at less than ISDN or T1 speeds would have a very long wait during the download. The Webmasters could either provide each user with a good book and tea for the wait, or they could scrap the controls.
Our site's Webmasters decided that the new controls weren't worth the download hit. Instead, they chose to use Dynamic HTML for Internet Explorer 4.0 users in a way that wouldn't restrict the functionality for those using other browsers. They provide a neat little mouseover effect when the user hovers the mouse over the label (the color changes). The goal was to introduce a new feature without costing current users navigation problems.
Some controls don't work well on the different platforms. At Site Builder Network, we created a control that worked great under current shipping browsers but failed under at least one beta-release browser. That control was also scrapped.
If you use a cool ActiveX™ control on your site, you have to provide what we call a "downlevel" version of your site for non-ActiveX browsers. If you don't, people using a browser that doesn't support ActiveX cannot view and navigate your content. The Site Builder Network site contains an ActiveX control that we call the navbar. In addition to the navbar, the site must provide pages of navigation links for browsers that don't support ActiveX. The same concept applies to frames. If you use framesets on your pages, you will need <NOFRAMES> sections in your frameset files so everyone will be able to access the content on your site.
The key here is Web detection (known in Webdom as a browser sniff). This is done on most of the sites I researched. Baarns Office Resource Center tracks this information in logs. As Don Baarns told me, "We use the ASP components to do browser detection and send a version that is appropriate to the browser. We have set Internet Explorer 3.0 and Netscape 3.0 (or higher in both cases) as our baseline for features. We have one page on the server, but it contains conditional code (using ASP pages) that send a slightly different page for Internet Explorer users versus Netscape users.
"The browser detection component in Internet Information Server (IIS) 3.0 is an excellent tool for pushing content that is appropriate for the current browser. Rather than lowest-common-denominator code, you can have 90 percent common code with 10 percent of the cool stuff for more advanced browsers. Combining detection with Include files allows you to have browser-specific code that is easy to maintain and update as the content gets updated."
Another solution to the problem of browser support is to move most of your work over to the server. You have control over the server, so you can have one heck of a feature-rich site. The down side? The more work you do on the server, and the more bits that have to travel across that little wire, the slower your site can become. Surprise! It's another trade-off.
You need to decide what to move over and how important any given feature is. For example, the Seidlers Jewelers site is in the process of a complete redesign to use Active Server Pages (ASP) technology for electronic commerce. The Seidlers Jewelers site was created by a team of people, including Barry Wadman, who has written several books on electronic commerce (available from amazon.com ) covering Microsoft Commerce Server, Microsoft Merchant Server, and Microsoft Site Server.
ICN hosts much of the site interactivity on the server side. "We use client-side scripting and components where they can really add value or enhance the site's appeal," said Robert Estrada, lead developer at ICN. "We also let the end-user know up-front what to expect from the site and which components, or browsers, will maximize their experience."
Nancy Winnick Cluts, developer-technology writer to the stars, has recently moved to a very toney neighborhood, but to us she'll always be that winsome gal next door.
Some standard practices to help ease the pain of technology trade-offs:
--N.C.
Three of the sites surveyed in this article are also individually featured in MSDN Online's Case Studies. Each case study examines the technology, design, and business issues behind sites created by members of then-SBN (now a part of MSDN Online).
How do other Web pros make their technology trade-offs? MSDN Online's Members Helping Members database will let you connect to other Web professionals, talk technology, share solutions, or just cry on a virtual shoulder.
Did you find this material useful? Gripes? Compliments? Suggestions for other articles? Write us!
© 1999 Microsoft Corporation. All rights reserved. Terms of use.
Back to top