Designing Winning Websites for Engineers Forget the talking heads and dancing balloons - designers want graphics with information. Peter Shikli Senior Partner BusinessWare Inc. San Clemente, Calif.

American Zettler (www. azettler. com) has a comprehensive and effective Internet presence for an engineering company. The company, for example, directs customers to their local distributor by drilling down through a world map. It also makes it easy for customers to simply download CAD drawings in AutoCAD or DXF standard format.

Web-site design, an emerging technology, poses new application challenges to engineers. The overt challenge is the volume of competing tools, techniques, products, services, and opinions that appear daily. The covert challenge is the pressure to collect such resources into screen designs that are proclaimed "cool" yet fail to address engineering customers.

The origin of this covert challenge goes back to the multimedia folks who brought us the Web in the first place. Sound and light rule their world, and their customers are consumers. This is why Web-design journals promote the engaging and the entertaining.

For most engineers, however, customers are purchasing agents, business people, and other engineers. They do not look to Web sites for entertainment. They want effective information delivery, and they don't have time for Java- powered dancing balloons.

If we design the Web site to deliver information, we can simplify our choices by discarding the inapplicable - if we have the fortitude to walk away from yet another on-line arcade of technical curiosities.

Start With The Spec

The process begins with an old engineering tool, the system specification, that applies equally well to Web sites. Webmasters may claim that the Web site itself will be the spec, much like prima donna software developers may claim that the prototype can replace the software spec. The prescription for failure is often similar, particularly when several departments are involved.

The Web spec should begin with the command links for each page and description of any activation, including image maps, which let the customer mouse-click on different locations on a single image to link to different Web pages. For example, clicking on the components of a carburetor could link to pages describing each of the corresponding components.

The Web spec should grow more detailed in areas such as database-Web site connectivity or any server-side/client-side programming. The Web spec encourages a constant review of Web-site features, discarding the many solutions looking for a problem, or at least diverting them to R&D projects if we're not strong enough, and then looking for the wheat in the chaff. Many of you would be offended if that process did not begin with an assault on the overuse of graphics on Web sites. We seem to hear the Information Superhighway moniker less and less as its throughput begins to resemble the concrete version, and the culprits are often gratuitous clip art, animated graphics, expansive logos, and other forms of graphics pollution.

Consider that the letter "a" will take 60 times as long to transmit as pixels in a picture instead of as a single ASCII text code representing a letter in a text sentence. We can wax philosophical about how the pointless proliferation of graphics threatens to throttle the Internet itself, but there is a here-and-now threat Web designers should also consider. Engineering Webmasters need to realize that busy customers will discover how easily they can set their browser's default options to turn graphics off and load only the graphics they wish - and then they will never go back.

A 1996 poll of technical professionals by O'Reilly and Associates revealed that 40% cruise the Web with Netscape's "Autoload Images" turned of. If that professional arrives at your Web site to little more than a collection of icons, all your work may have earned you the ignominious "Back" button.

Of course, Web sites should have graphics, but not by the same rules as brochures. Every Web-site picture should have a purpose, a clear value to customers, because unlike with brochures, Web-site customers pay for each picture with their time.

Maintaining a value/cost table listing all Web-site graphics is a simple way to insure the ratio remains high.

Value / Cost Tips

With a value/cost table in hand, we can progress to the first dozen practical tips that can improve the value/cost ratio of each graphic.

• Use ALT tags with all graphics as this: "<IMG SRC="filename.gif" ALT="CAD Drawing - 45kbytes">". For the few who can't display graphics and for the many who choose not to, this identifies the graphic as a CAD drawing and informs the customer of the cost - 45 kbytes of download time. With a right-click of their mouse, customers can prefer to view your graphic. This approach is the mark of an information-delivery Web site that respects customer time. (Note that ALT specifies a text alternative to an image [IMG]. Also, SRC means source.)
• Use few colors. In your graphics software, specify two-bit black and white if it's a standard CAD drawing, and you will be surprised to fill four screens with data for around 50 kbytes. If instead you use the default of most graphics software (millions of colors), you have needlessly raised the graphics cost to several megabytes. See how far you can go with 16 colors on a colored drawing before going higher.
• Test with a modem. Your PC loads graphics from your hard drive at over a megabyte/sec, hardly the price your customers will pay with their modem. Feel their pain, and then reassess value to cost. This also uncovers the many design flaws that work on your PC but not on the Web server. These flaws, for example, may include forgetting links to files on the local hard drive, or disregarding upper/lower case for links while developing with case-insensitive Windows which then breaks with case-sensitive Unix Web servers.
• Use the correct standard. JPEG (Joint Photographic Experts Group) is for photographs and gif (graphics interchange format) is for all else.
• Compress. Start with ridiculously high compression ratios for JPEG, and if your eyes can't tell the difference (because most of us have 80-pixel monitors), then go with it.
• Specify image size. If you tell browsers how big your image is in pixels with tags such as "<IMG SRC="filename.gif" WIDTH="594" HEIGHT="568">", the browsers will leave space for your image, quickly fill in all the remaining text, and then go back to fill in the graphics. Customers downloading graphics have something to read while they wait, and the rest of us can see how large the image will be if we choose to download it.
  
• Separate large graphics pages. If large graphic files become necessary, put them on their own Web page. Some browsers start to crash when the total Web page memory requirements (text and graphics) exceed 200 kbytes. You can also use a thumbnail image to link to the grand picture in all its glory.
• Use a small file for a background. First experiment with solid colors for the background (via the BGCOLOR tag) since they have no download cost. If you have to use background graphics instead, use small tiles that the browser will replicate instead of one large picture. Go to the Web directories (Alta Vista to Yahoo), search for "background images," and you will find dozens of Web sites with collections of small, optimized background tiles you can download free. Since you can't easily control the customer's window size, you can't force a single background to span the screen anyway.
• Repeat icons. Reuse the same graphics for icons such as check marks, sunbursts proclaiming something "new," command buttons, and, of course, the company logo. After loading them once, browsers will load them from cache.
• Avoid the command image map Many Web sites have a single graphic with different commands depending on where the customer clicks. It's better to have a collection of reusable command graphics, each with ALT tags. You can even position them to appear to be one image. Customers with graphics off can thus choose based on the words of the ALT tag. Also, once the user chooses to load a command graphic it will be loaded from cache free even if the commands are reorganized on subsequent pages. Rearranged image maps pay full price with every rearrangement.
• Store animation changes. If you must use animated graphics, don't just collect a bunch of images into a slide show. The animated gif standard allows you to add just the changes to the previous image. See how we left a machine's stator stationary and just overlaid moving rotor images at www.powerengineering.com to produce a 12-kbyte animated gif.
• Don't force graphics with button. Even with your browser set to "graphics off," you will notice some pages still make you wait for pictures. This can be done with a dirty trick whereby you fool the browser into thinking your masterpiece is just a huge button.
  Customers don't appreciate being tricked or coerced, and you come off like a jilted artist. Even if we design a Web site that rivals the cover of Wired magazine, we have to accept that many customers have a life outside our Web site.

Product Drawings And Maps

Two of the most effective graphic applications for well-engineered Web sites are product drawings and geographic maps showing locations for sales reps, distributors, repair depots, and the like. For example, American Zettler (www.azettler.com), maker of electromechanical relays, directs customers to its local distributor by drilling down through a world map starting at www.azettler.com/worldmap.htm. (Ed. note - American Zettler is a client of the author's Web-site design firm.)

Product drawings and geographic maps both begin as CAD drawings for reasons engineers know well: drawing information stored as vectors is much easier to maintain than as a pixel or raster image. Unfortunately, Web graphics use pixels. Conversion pro- grams abound, but not in the area of image maps, which add significant value to product drawings and maps.

To understand the difficulty, consider that image-map information must be maintained and converted into two separate destination files. The straightforward vector-to-pixel conversion of the image ends in a gif or JPEG graphics file, but the information tracking where different mouse- clicks go is part of the separate Web page file (ASCII text). Note that this information consists of AREA tags containing the X-Y coordinate boundaries in pixels and the Web address showing where to link for a click within the boundary, for example, for the popular rectangle boundary:

"<AREA SHAPE="RECT" COORDS="365,9,581,46" HREF="filename.gif">"

Such information can be made part of the vector objects in a CAD or drawing program, but conversion requires the information to be extracted and inserted into the right location within the right Web page, which may or may not already exist. At the time of this writing, only Corel Draw 7 (www.corel.com) had an operational image map conversion program (with bugs), though AutoCAD was expected to quickly follow.

Alternate solutions involving Java and Active-X programming don't seem to be catching on. Developers may not want to put in the time to produce two solutions to cater to both Microsoft and Netscape users. Also, data-processing managers are increasingly disabling their company's browsers from executing such programs, citing the risks of allowing unpredictable software downloaded and executed on their chines without their knowledge.

Easy Downloading

An overlooked solution for CAD product drawings and their specs help customers simply downloaded them. At the bottom of a page describing an American Zettler relay (www.azettler.com/5.htm), for example, customers can download the CAD drawing in AutoCAD or DXF standard format. This can be a simple link on the Web page such as "<A HREF=az5.dwg">", and the browser gives customer options after clicking on it.

They can download and save or they can associate their AutoCAD program to *.dwg files, in which case the browser will load AutoCAD with the downloaded dwg file as its data file. A better option for large files is to compress them using standard zip convention, leaving the zip file extension on the linkman. Then customers can download them quickly and expand them into CAD drawings.

"Displaying CAD drawings on the Web was never a priority," notes Nate Benedict, vice president of engineering at American Zettler. "Our customers don't need to see the drawing during the evaluation phase. We prefer to give them an easy way to incorporate the relay drawings into their own circuit board drawings to complete the sales process. A simple download accomplishes that."

At the bottom of the same www.azettler.com/5.htm example page, customers can also download the product spec and drawing in the popular Adobe Acrobat format. Acrobat acts much like the Web browser except that because it has been around much longer, it is more stable (doesn't crash) and provides more functionality in terms of fonts, tables, graphics, and other display options.

With total program storage requirements under 2 Mbytes (compared with Netscape and MS Explorer bloating out to over 40 Mbytes in their Version 4), Acrobat is quick to load and remains popular with engineers. It is also free. For more information on Acrobat, see www.adobe/prodindex/acrobat.

Using Acrobat may not be well received by the Web-development community, which feels the Web should be the center of graphics display. Because engineers are application oriented, their acceptance of Acrobat demonstrates the theme of this article. We can get past the hype to use the best tools for the job.