Web-Page Design Essentials
Web-page design is an art unto itself, with a broad array of graphic considerations that don't apply when you're working with printed media. Most computer magazines run design articles from time to time, and no two seem to agree on what constitutes an outstanding design. A topic as simple as frames versus no frames can trigger flame mail worthy of a barroom brawl.
That said, all would-be Web-page designers should keep a few simple tips in mind:
Obey the Web design corollary to the KISS principle—Keep It Small, Stupid. Nobody likes to wait for downloads.
Tip from 
FrontPage has a handy reminder, down on the status bar, that tells you approximately how long it will take to download the page you're constructing, using a 28.8 modem.
Avoid ransom note typography. Two different fonts on a page make your point. Three annoy anyone trying to read the page. Four convinces them to click another link and go read something else.
Make colors work together. Magenta text on a red background might be (barely) legible on some monitors. It won't be legible at all on many.
Don't break the law. Copyright protection applies in cyberspace, too. It might be easy to reproduce copyrighted work on your page, but that doesn't make it legal.s
→ To learn more about creating Web pages, effective design, and so forth, see Chapters 36, "FrontPage Essentials," and 37, "Developing and Managing a Web Site".
Browser-Compatibility Issues
When you publish a Word document, PowerPoint presentation, or a Web page that contains interactive Office Web components on a corporate intranet, you know exactly what software is running on the server. Generally, that means you can predict or even control which browsers your users will view the pages with, minimizing the possibilities for compatibility problems.
On the other hand, when you post an Office-generated page to a server that's widely accessible on the Web, you have to anticipate problems. Many of these problems can be traced back to fundamental differences in the way various Web browsers work.
Specific, known limitations include these:
When you use Access to create DAPs, they can be viewed only with Internet Explorer 5 or later. Microsoft makes no claim for compatibility with earlier versions of Internet Explorer or any version of Netscape Navigator (although the folks at Netscape might beg to differ).
If you use Excel to create interactive Web pages, they can be viewed only with Internet Explorer 4.01 or later.
Word and Excel save documents and worksheets in HTML format with XML markup tags. Thus, at least in theory, the content of Word- and Excel-generated pages should be visible in almost any browser, although some formatting might be lost, especially in older browsers.
Some Office document elements—most notably drawing layer objects, including organization charts—don't look very good in any browser, including Internet Explorer 5. Be cautious of how the various browsers render carefully crafted graphics in the drawing layer.
Adding VBScript or JScript Code
Web pages in general can contain embedded programs written in VBScript or JScript. Office provides good support for writing and deploying those programs in Web pages generated by Office.
Office allows you to attach two completely different kinds of programs—two different kinds of macros—to documents. The kind of macro you want to create depends on when you intend to use it:
If you want to run the macro while viewing the document in Office—that is, you want the program to work while you have a Word document open in Word, or an Excel workbook open in Excel—you must use Visual Basic for Applications. VBA is a robust, thorough, often complex programming language, which is covered in several chapters later in this book.
→ For an extensive introduction to these kinds of macros, see Chapter 38, "Using Macros to Automate Office Tasks".
On the other hand, if you want to run the macro while viewing the document with a Web browser—that is, you save the document in HTML, post it to the intranet or Internet, and look at it with a browser—you must use VBScript or JScript as your macro language. Both VBScript and JScript are designed to be small, quick, and limited in their capabilities.
To look at it in a slightly different way: VBA runs within Office; VBScript and JScript run within your browser. VBA has a sophisticated development environment and strong ties into Office. From a developer's point of view, VBScript and JScript are held together with a little (but not a lot) more than baling wire and chewing gum, and can nudge your browser around a bit, but they might still be the solution when used in the right situation.
For example, if you want a macro that scans and reformats a document, and you're going to use the macro when you're working in Word, you have no choice but to use VBA.
But if you want a macro that rearranges some data on a Web page and prints it, and you want to use the macro when viewing the data through a Web browser, you need either VBScript or JScript.
VBA's capabilities are discussed extensively in Chapters 38–41 of this book. Although a thorough discussion of VBScript lies beyond the scope of this book, you might find it instructive to see a sample VBScript program, and how it can be tied in to COM objects on a Word-generated Web page. Let's say you want to put a timer button on a Web page—click the button, and it responds with the current system time. You might want such a button if, for example, you're tracking response time on your company's intranet. Here's how you create one in Word:
Click the Command Button icon in the Control Toolbox. That places a command button labeled CommandButton1 in the upper-left corner of the document. Click and drag the button so you can see all the text, as in Figure 7.10.
Figure 7.10. Start by placing a Command Button control in the upper-left corner of your Web page.
Choose Tools, Macro, Microsoft Script Editor. That brings up a VBScript/JScript macro-editing environment remarkably similar to the one in FrontPage (see Figure 7.11).
Figure 7.11. The Microsoft Script Editor provides support for programming in both VBScript and JScript.
Click View, Other Windows, Document Outline to bring up the Document Outline pane (which you can dock). Then double-click CommandButton1. That brings up the properties for CommandButton1 in the Properties window, at the lower right. Click once, in the HTML pane, in the <param name=Caption … > tag. Locate the property called Caption and change it to Push for current time (see Figure 7.12).
Figure 7.12. Set the CommandButton1. Caption property by typing into the Properties window.
Set VBScript to work with HTML version 4.0 features by choosing View, Property Pages and, on the General tab, changing the Target Schema drop-down list to HTML 4.0.
Caution
Many advanced VBScript capabilities rely on HTML version 4.0, and every modern browser will work with HTML 4.0. Word 2000, by default, supports HTML 4.0. For reasons known only to Microsoft, Word 2002 ships with the Target Schema set to the earlier version, HTML 3.2. If you learned to program VBScript with Word 2000, make sure to change the Target Schema as outlined above, or you'll be faced with all sorts of problems.
In the object drop-down box at the top of the HTML pane, choose CommandButton1. In the Event box, choose Click. Word responds by creating a subroutine called CommandButton1_Click. If you've used VBScript before (or any version of Visual Basic, for that matter), you'll recognize that as the name of a program which will be run when the user clicks on the button called CommandButton1. Word even provides the Sub/End Sub pair, so all you have to do is type in the middle line of the three-line program:
Sub CommandButton1_Click CommandButton1.Caption = Time() End Sub
Open your new Web page, either by locating it in Windows Explorer and double-clicking it, or by launching your Web browser and navi gating to it. Click the command button. The current time should appear (see Figure 7.13).
Figure 7.13.
With all the controls in the Control Toolbox at your disposal, it's possible (although not easy) to build full-fledged VBScript applications inside Word or Excel.
Previewing and Testing Web Pages
As the most important—and most frequently overlooked—step in creating Web pages, testing is a necessity after you go beyond a single HTML page with no attached graphics.
If you work on a corporate network, you will probably have four or five options for testing:
If you have a good Web page design tool, such as FrontPage, the Web preview available in the tool will probably suffice for layout and general debugging. FrontPage also has a Preview in Browser feature (File, Preview in Browser), which pulls up the browser of your choice. Failing that, the Web Page Preview command on the File menu in Word or Excel will do in a pinch.
At the next level, you can double-click an *.htm or *.html file, and your browser will attempt to load it. (Equivalently, you can start the browser and type the filename, or drag and drop the file onto the browser.) This is a good quick-and-dirty approach for verifying VBScript code, and if you've carefully constructed internal file links so they're relative, you might get some feedback on mislinked graphics.
Tip from 
If you flip between, say, FrontPage and your browser to check on the status of your page, make sure you save your changes in FrontPage before opening or refreshing the page in the browser.
As a final staging area prior to release on the Web, it's hard to beat an intranet. If you have a client/server network running Window 2000 (or NT) server, you might have one already. Contact your network administrator, or look for the folder C:InetPubWwwrootIntranet.
After you're on the Web, you might find it advantageous to "hide" the main page for a few days, to shake out any final bugs. You can do that by calling the main page in the default folder Index0.htm, for example, and instructing your testers to use that page instead of the default Index.htm or Index.html.