Chapter 22

Company Practices/Procedures Manuals


CONTENTS


Every organization, large or small, has hundreds of documents and other pieces of data that can be put on an Intranet for its customers. One major category of these is your company's practices and procedure manuals. Whether you have a formalized program of written standards for doing things or operate ad hoc much of the time, you undoubtedly have some documents that give instructions about how things are done. These instructions can range from the most mundane, such as how employees work or how vacation and sick time are recorded and reported, to the practical, such as company purchasing procedures, to the sublime, as in overall organizational policy statements on such large matters as corporate goals, employee diversity, or safety in the workplace. In this chapter, you learn how to integrate the information and tools presented earlier in this book and to make many of these documents accessible on your Practices/Procedures Intranet.

You also learn in this chapter about the use of graphical data and HTML imagemaps for your Intranet. This same general process of integrating the material from the rest of this book applies in the next several chapters.

Existing Electronic Practices/Procedures Information

If your company uses computers to create documents, you already have the foundation of your company's Practices/Procedures Intranet built. Your first task is identifying and locating these documents and getting them online on your Intranet so that they are easily accessible. You can find these documents in administration, engineering, human resources, and other corporate departments. You can also find them in filing cabinets.

The fact that paper copies of employee manuals, for example, are distributed to all new employees probably means there is an electronic original somewhere in personnel. Similarly, if your shipping/receiving department has written procedures for handling dangerous or delicate shipments of various kinds, in all likelihood you can find those procedures on somebody's computer disk in a word processor file. Although locating documents in this way might be a tedious, logistical problem, it's still possible, and what you find will provide the basis of your company's Practices/Procedures Intranet.

The main principles of this activity are those outlined in Chapter 3, "The Software Tools to Build a Web," with respect to the conversion of your legacy data for your Intranet. If you have electronic copies of documents available, you need to use what you learned in that chapter to move this data quickly onto your Intranet, making it accessible to your customers via your Web server and their browsers. When you have legacy data that's not in plain text format, you might need to use the conversion tools you learned about earlier. This might include using your applications' Save As feature to convert data into easily usable formats such as plain text. You can also use some of the other conversion tools covered in Chapter 3.

In addition, you might eventually want to use the Microsoft Rich Text Format (RTF) as an in-between while converting legacy data into HTML documents for direct use on your Intranet. Also, with more and more vendors, such as Microsoft, Frame Technologies, and Novell, adding direct HTML capabilities to their word processors and other packages, you can convert your legacy documents directly to HTML with almost no effort.

As you have learned, the basic setup of Web pages containing simple, clickable lists of available documents is quite easy. Adding a little subject matter organization is simple, too, using hyperlinks to create nested menu listings. In just a few minutes, you can present a useful list of available documents to your customers. To these ends, you should review basic HTML markup in Chapter 5, "What You Need to Know About HTML," and in Appendix A, "HTML and CGI Quick Reference," focusing on basic list markup, hyperlinks to other documents, and the jump-to-spot features of the language.

Tip
Use your operating system's basic utilities to get a leg up on the creation of simple HTML listings of documents. One way to quickly build a file containing the names of all the files you want to serve is to use the DOS prompt command-output redirection (for example, DIR > doclist.html). This captures the directory listing into a file. You can then edit the file to strip out unneeded directory listing details, add the HTML framework, add a few headlines, and add some list markup and hyperlinks. Your new Web page is ready to be sent to a Web browser, providing access to all the listed documents with a simple mouse click.

As suggested in Part I, you can come back to the skeleton Web pages containing your converted legacy documents once you have your Practices/Procedures Intranet running. Then you can refine them and add value by cutting in hyperlinked cross-references, graphics, and the like.

Monthly reports, for example, can contain clickable cross-references to other documents, statistical tables, spreadsheet data files, images, or even earlier months' reports (all with the same kinds of embedded links). This done, your customers can use their Web browsers to jump from one document to another, looking for answers to questions by following promising threads.

The more cross-references and hyperlinks you add, the more capabilities you give to your customers. A little later, you learn about indexing your practices/procedures documents to give your customers even greater opportunities to locate documents and information.

MIME Type/Subtype Setup

Even after you have successfully converted your legacy practices/procedures documents and created skeleton Web pages for accessing them, you will no doubt end up with a wide variety of document and data formats. You will probably have plain text files, word processor files, HTML documents, spreadsheets, graphics images, data files created by other office software applications, and others. At first, this might seem to be a confusing mess. However, you can confidently deal with this situation, using what you have learned earlier in this book, to organize the data and make it available in its native formats. After all, your purpose in building an Intranet is to pull together just such a wide variety of information resources and make them accessible using a single Web browser interface. All the information about MIME data types/subtypes and helper applications you have learned earlier in this book will help you as you make your practices/procedures information available.

As you recall from earlier chapters, enabling use of your word processor, spreadsheet, and such other office software packages as Web browser helper applications is a simple, two-step process:

  1. Modify the MIME map on your Intranet's Web server(s) to add your new document types. With IIS, this information is stored in the Windows NT Registry. Other Web servers might store the MIME table in a configuration text file.
  2. Configure your customers' Web browsers to deal with the newly defined MIME types/subtypes by defining helper applications.

Chapter 12 provides a thorough grounding in the subject of MIME data types/subtypes. Chapters 13 through 15 deal with a variety of common office software packages you might need to set up as Web browser helper applications. Now that you are putting specific documents and other data in place for real work on your Practices/Procedures Intranet, you might want to review that material so that you have the ticklish syntax of the MIME map and the Web browser Helpers dialog boxes down pat. If your customers use more than one Web browser, you need to understand the slight differences between Mosaic, Explorer, and Netscape in this area. Figure 22.1, showing setup of Microsoft Word as an ncSA Mosaic helper application, will no doubt bring this all back to you.

Figure 22.1: The Mosaic Add Viewer dialog enables you to add new helpers based on MIME.

Tip
You need to make sure the necessary helper application software packages are available to everyone on your Intranet, perhaps by setting up anonymous FTP services on your Intranet (see Chapter 9, "Adding FTP and Gopher Services") or by simply creating a shared subdirectory on the NT file server that everyone can map to from their workstation. This sort of infrastructure can save you a great deal of time that would otherwise be taken up with manual distribution of software around your Intranet. This way, if customers need a copy of a new helper application (or a new release of an old one), to download it they can click a Web page you have created with links to the applications. If you're trying to build your Intranet in phases and you don't have the time to organize it that well yet, at least add a sentence to your home page or send e-mail to everyone to mention the location of the helper applications that can be installed from the file server.

Once you have taken these steps, your Intranet's customers can use their Web browsers to retrieve and view your practices/procedures documents as necessary, regardless of their actual document format. As needed, helper applications are fired off as documents are accessed. For example, clicking hyperlinks pointing to Word files opens Word to display the files on-screen; Lotus 1-2-3 spreadsheet files work the same way. Having located the necessary document with which to answer their questions, customers are just a few steps away from saving or printing a copy of the document, via your Intranet, all without a trip to the personnel or engineering department where the document might have originated. (Hey, I've been in a large company where that would have saved a 15-minute walk to the copy machine.)

Other Kinds of Data for Your Practices/Procedures Intranet

There is virtually no limit to the kinds of information you can use on a corporate Practices/Procedures Intranet. You have already surveyed the legacy information you have available and put some of it up. You have merely scratched the surface so far, so consider a few more ideas.

Personnel and Employee Benefits Information

Your personnel department can be a gold mine for your Intranet when it comes to supplying documents of the sort you're looking for. I have already mentioned the idea of an overall employee manual, but many other personnel-related documents might also be useful:

The first two of these items suggest possibilities far beyond mere static documents your customers can read. Simple fill-in Web forms can be used by employees to submit their travel expenses for reimbursement or apply for a job opening, to give a couple of simple examples. This sort of thing can turn your Practices/Procedures Intranet into something interactive, something that does something. Each of these items can be accomplished through simple CGI or ISAPI applications that take the information customers enter into fill-in forms and pass it via e-mail to the appropriate employees for processing.

Although some security issues are involved in forms information processing (see Chapter 10, "Intranet Security in Windows NT"), you can implement this sort of thing quite easily. Employees won't have to deal with paper forms or spend work time for their pickup and delivery. Instead, customers' requests for expense reimbursements or job applications are sent when they click the Submit button in their Web browser, all without any trips to the photocopy machine or interoffice mail delivery.

Tip
A potentially valuable Practices/Procedures Intranet resource in the personnel area might be an interactive pension calculator. Your ordinary pension benefits information Web page would include static information about the rules of eligibility and the mathematical formula for computing pension benefit amounts. Based on an HTML fill-in form and CGI script, such a calculator would enable employees to interactively enter their salary and years-of-service information and get back a pension estimate. Such a tool, easily implemented on your Intranet, can help an employee with retirement decisions, making multiple what-if-I-worked-just-one-more-year kinds of calculations without requiring them to take time away from their desk to ask for the same calculations from a human resources specialist. Furthermore, confidentiality is preserved.

Other Corporate Department Information

You can easily extend these ideas to other departments and activities in your organization. Here's a long, but by no means complete, list of possible procedural documents:

You can probably come up with an equally long list of other documents that fit well here. Where appropriate, fill-in forms enable customers to use their Web browsers to perform job functions, such as recording time off, ordering supplies, or requesting equipment repairs.

Figure 22.2 shows the simple vacation form you saw back in Chapter 5. This form, vacation.htm on the CD-ROM, could be easily adapted into an order-entry form for supplies or equipment. Depending on how elaborate you want to get, your CGI back-end script for the order form, or one like it, can e-mail the customer's order to data entry personnel in your Purchasing Department for hand-entry into your Purchasing system. It can also actually place the order into your corporate purchasing database system for processing, untouched by human hands. Again, there are security issues here, explained in Chapter 10, that you need to consider to ensure accountability in the area of purchasing.

Figure 22.2: The vacation form, useful in its own right, could be easily adapted to an order form for supplies.

Similar forms, using HTML menus, radio buttons, and checkboxes, can be used for ordering everyday office supplies. Your CGI or ISAPI applications for all these kinds of forms can be pretty much the same script, with built-in options for sending the output of certain forms in one direction and directing others elsewhere. You can find basic e-mail scripts you can modify to meet your needs in just about every book you find on setting up Web services; you probably already have one or more of them. The Blat program on the CD-ROM with this book can be used to mail form data to a predetermined e-mail address for processing.

What You Need to Develop Web Applications
If you have heard about CGI from the UNIX world or from the early days of the Web, you might be wondering why I keep saying "CGI or ISAPI." As discussed in Chapters 19 and 20, ISAPI is a new kid on the block that uses RAM for interprocess communication between the server and the application, as opposed to the more disk-based approach of CGI. The goal of ISAPI is to run Web applications several times faster than is possible with CGI.

ISAPI was recently invented by Process Software and Microsoft and is available in both Purveyor and IIS. It is catching on, and many other Web servers are also offering ISAPI. If you're a Webmaster who is being asked to write Web applications, you also need to know that Microsoft Visual C++ version 4.1 now includes an ISAPI application wizard. All you have to do is click a few buttons and you get a DLL framework that works. You can then add extra functionality to complete the design. The Data Access Objects in Visual C++ might help you write the code that saves the form data to an ODBC database.

A CGI alternative that many claim is easier to develop (if you don't know C++, this is probably true) is Perl. Perl for Windows NT is on the CD-ROM. Perl scripts run quite a bit slower than ISAPI applications, but if your Intranet is not high traffic and your time to accomplish to the task is squeezed, you should definitely consider Perl. (Perl is also available as an ISAPI DLL.)

Chapter 19 lists other alternatives that might work without having to learn programming. If those tools don't work for you, be prepared for a learning curve if you have to write Web programs yourself.

Indexing Your Practices/Procedures Data

You're probably thinking this chapter has gotten ahead of itself. How will your customers locate answers to questions or locate specific documents? Surely they won't just have long on-screen lists of document names they have to browse through? Subject-oriented menus aren't always a big help either. As with the conversion of your legacy data, the answers to these questions take you back to material covered earlier in the book. In Chapter 21, "Indexing Your Intranet with WAIS," you learned about a variety of powerful tools for indexing data on your Intranet and, equally important, flexible tools for searching and retrieving Intranet data from the indexes created by them.

The ability to search for relatively complex text strings is an important feature of your Practices/Procedures Intranet. Similarly, keyword searches with Boolean capabilities are important also. Customers might not know exactly what they're looking for, and even being able to view document names might not be enough. Text-string and keyword searches become critical to customer searches for information. Note that the database here is one built with an indexing tool, such as WAIS or Excite. (See Chapter 21.)

Depending on the extent and nature of your library of practices/procedures documents (and other documents on your Intranet), you might also want to look at the Web-related relational database tools described in Chapter 16, "Linking Databases to the Web." This is particularly true because these packages are being extended to include many different kinds of data. The ability to create Web fill-in forms that interface with database engines via CGI scripts (or other means) enhances your Intranet and its capability of serving its customers.

Even if you have a preexisting full-text or relational database, hope isn't lost. Unless it's locked up without standard capabilities, you can just dump the data out to plain text files. As long as the data has an identifiable format, it can be run through a tool like WAIS, making it accessible via your Web browsers using fill-in forms. This enables you to continue to use the data you have accumulated in your application, and at the same time it frees you of proprietary data formats. With the outstanding capabilities of these search engines, you might find search-and-retrieval performance better than you had with your custom database-not to mention that nice, user-friendly Web interface.

Imagemaps and Your Practices/Procedures Intranet

The HTML imagemap capability can be an important part of your Practices/Procedures Intranet, adding interactive features to otherwise static documents. Imagemaps are graphical images embedded in Web pages that have hot regions marked off. Clicking such a hot region causes a predefined hyperlink to be accessed, taking the customer to another document or Web page. Clicking another hot region in the same image activates a different hyperlink, a third hot region, another hyperlink, and so on.

You can find imagemaps on many Web pages, including the Netscape home page, shown in Figure 22.3. The image in the top center of the page is a clickable imagemap, with six hot regions defined (Netscape Destinations, Company & Products, and so on). Moving your mouse cursor into one of those image areas causes the cursor to change from the standard arrow cursor to a pointing finger (not shown in this screen shot), giving you a tip-off that the image is an imagemap. The status bar at the bottom of Figure 22.3 indicates the hyperlinked HTML page pointed to by the cursor in the imagemap. Just click any of the regions to access the underlying hyperlink. Not all Web page imagemaps are as well-defined as this one, with clear delineation, but all work the same way. You should review Chapter 5 and Appendix A, or your other HTML documentation, for information on creating and using imagemaps.

Figure 22.3: The Netscape home page uses many clickable imagemaps.

For creating your own imagemaps, try Todd C. Wilson's Map This! software package, available on the CD-ROM. A sample Map This! session is shown in Figure 22.4. The package works by loading the graphics image, after which you select rectangles, circles, or polygons in the image for your hot spots. Once you have done that, you can use your mouse to drag your hot spots to size, and Map This! generates the setup file to create the imagemap. In this screen shot, you can see that the mouse currently lies within a polygon region referring to mountain.htm. Once your hot spot is selected, Map This! prompts for the URL of the underlying hyperlink. Continue to define hot spots in your image, and then save it when you're done. Map This! creates the necessary imagemap files for your Intranet.

Figure 22.4: Using the Map This! sample imagemap.

Returning from the Map This! digression, let's continue the discussion of graphics imagemaps for your Practices/Procedures Intranet. Following are some practical ideas for your Intranet.

Graphics Campus Map/Phone Book

If your organization occupies a large campus or building complex, you might want to help your customers navigate around the place via your Intranet, as well as looking for employee locations. The United States National Aeronautics and Space Administration's Johnson Space Center in Houston, Texas, maintains such a service for NASA employees and visitors, and it is accessible on the World Wide Web. They use a large graphics map of the Space Center campus. The map is useful in itself, because it shows where building, roads, parking lots, and the like are located. Both visitors to and employees of large organizations like NASA can use locator maps to find their way around, and more and more organizations are setting up such interactive, wherever-your-cursor-is-there-you-are maps on their Web servers.

In addition to the obvious value of such a map, the image has additional value because it's an imagemap. It provides direct, hyperlinked, Web browser access to a great deal of additional information about the Space Center. Clicking any building on the map, for example, takes you to a Web page specific to that building. On the building's Web pages, you see a photo of the building (good for helping the visitor identify the building), along with information about activities and NASA organizations in that building. Many of the buildings' Web pages accessible from the imagemap contain photos or other graphical images of building-related activities or facilities.

But wait, there's more! On each one of these NASA JSC building Web pages is a hyperlink labeled "Click here for building occupants." Selecting the hyperlink brings up a scrollable on-screen telephone directory for the people in that building. From there, the Web browser's Find feature (in Mosaic: File | Find in Current; in Explorer and Netscape: Edit | Find) can be used to locate an individual's name in the directory.

Blueprints, Engineering Drawings, and CAD Drawings

As the NASA imagemap example shows, there are many ways you can implement this tool on your own Practices/Procedures Intranet and many services you can provide with it. Campus maps like the NASA map can contain links to individual building imagemaps, with the individual maps further zoomable to show individual floors or even individual rooms. Your building services department might have imagemaps containing building blueprints-showing electrical, HVAC, and plumbing infrastructure-for use in building repairs or other service. Engineering drawings of industrial equipment or company products can be made available in the same way, with imagemap hot regions allowing for enlargements of individual portions of the drawings. Even your computer-aided-design (CAD) drawings can be turned into imagemaps.

Getting your paper blueprints or engineering drawings into electronic format might require a scanner, so be sure to save your scanned drawings in GIF or JPEG format, if possible. Many scanners save TIFF files, and Paint Shop Pro, available on the CD-ROM, can convert from TIFF to GIF. If you already have electronic CAD drawings available, you need to see whether your CAD software can export your drawings to one of the standard, Web-supported image formats, such as GIF, JPEG, PostScript, or Adobe Portable Document Format (PDF). You might find that your particular CAD package's image format is supported directly by Paint Shop Pro (or some other graphics utility program), and that you can turn your CAD drawings into a standard format for your Intranet. If all else fails, just search Yahoo (www.yahoo.com) for other graphics programs until you find one that runs on Windows and can handle your file format.

Along these lines (hmmm, no pun intended), you need to look at the FAQ document for the Usenet newsgroup comp.lsi.cad, where you can find descriptions of a wide variety of free and commercial CAD-related software that might be of use, especially if you're using an older CAD package. Possibilities include software to convert your existing CAD drawings to new formats, including those supported by Web browsers. You can find this at http://www.cis.ohio-state.edu/hypertext/faq/usenet/lsi-cad-faq/top.html.

Your Practices/Procedures Intranet need not be limited to blueprints and building maps. One idea is a schematic diagram for an electrical lock-out device (a device for preventing use of defective electrical equipment or equipment under repair). If you have electricians in your company, this and other procedural standards documents can be Web-accessible with little work on your part. Although your graphics images can be in any format supported by your Web browsers, diagrams can be created in the Adobe Portable Document Format (PDF) and then displayed in the Adobe Acrobat Reader as a helper application through the browser. Acrobat Reader is free software you can download from Adobe's Web site, http://www.adobe.com/. The package is available for Windows, DOS, Macintosh, and several UNIX systems. You can also find a new PDF reader for Windows 95/NT, Adobe Amber, which was in prerelease when this chapter was written.

Tip
You need to define Adobe Acrobat Reader or Amber as a Web Browser helper application before you can view PDF files found on Web pages. See Chapter 13, "Word Processing on the Web," for details on setting up helper applications.

Note
In late 1995, Adobe Systems acquired Frame Technologies, makers of the FrameMaker desktop publishing package. It seems logical to expect that Frame's products might incorporate direct support for Adobe PDF documents in the future. The no-cost FrameReader package can be set up as a read-only helper application for viewing native FrameMaker documents. In addition, Version 5 of FrameMaker includes direct HTML support for creating, saving, and viewing Web documents. Everything that rises must converge.

Yet another example of the sort of document you can place on your Practices/Procedures Intranet is a decision-making flowchart. Flowcharts can be applied to electrical devices in many endeavors, including computer programming, and you can surely find uses for them on your Intranet. As with the preceding imagemap example, you can explode portions of such flowcharts to reveal underlying details of the process.

You can see how you can make wide use of graphics images and HTML imagemaps on your Practices/Procedures Intranet. Web browsers' ease of use together with your graphics presentations can add substantial value to your overall Intranet. Having these sorts of documents and graphics available helps your customers meet their own job needs. This is particularly helpful because many of these kinds of documents are accessed only rarely. Having them immediately accessible saves the time that would otherwise be used in locating them and ensuring that the located copy is a current version.

Summary

This chapter dealt with the use of Web and Web-related technology to create a Practices/Procedures Intranet, incorporating much of what you have learned from the rest of this book. The chapter has focused on organizational documents and other information that spells out how your company does things. Large or small, every organization has standard operating procedures for many activities, just a few of which have been listed in this chapter. Documentation of those practices and procedures is a rich source of data for your Intranet, and you can easily put it at your customers' fingertips. Here's what you have done in this chapter:

The next chapter covers Intranet Help Desk applications. As with this chapter, the next one provides concrete examples of how you can integrate what you have learned in this book into useful and valuable features for your Intranet.