When building your intranet, keep in mind that you want your site to be dynamic and interactive. Making your site dynamic will make it more functional and lively to the users. The users should have the ability to interact with the site by adding and extracting data. This chapter focuses on creating a dynamic, rather than static, site. Static information has been predetermined by the site developers and exists only in the form determined by them. For example, HTML text files and graphics that don't integrate with the user's data input are static.
A dynamic site might be administered by a team or an individual, but its structure and its functions encourage and allow users to manipulate the data and to communicate with other users. Your goal should be to offer the opportunity for interaction, data manipulation, and communication, while still keeping the site operational and secure. It's a challenge, but your intranet won't be fully realized unless you work hard to incorporate some dynamic functions.
The functions that will make your site dynamic are all functions you've used previously or that you read about in earlier chapters. But now is the time for some creativity. This is where you should determine your intranet's functions and limits. The exciting part of building an intranet is that you can create a site that is entirely specific to the needs and the goals of your company. If you employ the right techniques and functions, your site will express your company's style, not just through graphics, but through user interaction. Your intranet should be as unique as your company.
Let's look at an example of the development of a dynamic intranet. The board of directors of a floral company with stores in 10 different locations has decided to redesign its current Web site, which is a simple home page listing the names, addresses, and phone numbers of the stores in a static HTML file. The directors have decided that the site should be expanded to allow more options, not only for the public, but for the employees as well.
The primary internal goal is to allow the employees of the 10 stores to use the site to communicate with each other. The stores employ clerks, managers, delivery persons, and floral designers. The needs of each class (or type) of employee should be incorporated into the site. First, I'll look at the needs of each type of employee, and then I'll talk about what techniques and tools are available for meeting the goals of the board of directors and the needs of the employees.
Clerks will use the site to record financial data about the stores' sales and to update the product inventory (because they are responsible for maintaining a steady stock of greeting cards and gifts). Along with all the inventory, clerks might also record the number of hours they work each week; the site would take the place of the time-clock system currently in use. Clerks also could use the site to communicate with clerks from the other locations. Because some of the stores are near one another, employees-especially the clerks-shift from store to store as necessary.
The managers will use the site to administer payroll for all the employees and to create weekly schedules (all the employees will be entering requests for days off into the site). Managers also will use the site to keep the employees up-to-date with the amount of work and the type of work that will be needed for particularly busy times of the year, such as holidays. For example, because Mother's Day is one of the more lucrative holidays for florists, managers will want to send information to the employees about the strategies for handling the influx of business during that week. More than the data used by the others, the data manipulated by the managers will need to be secured so that sensitive data such as salaries and time-off requests will not be accessible to everyone. Therefore, a password system needs to be implemented for the databases that the managers will be accessing.
The site will be especially useful to delivery personnel. Directions and maps to office buildings of frequent clients will be posted on the site, and they will be easily available to delivery personnel when they are training new drivers. The status of delivery personnel would be updated regularly throughout the day. For example, the destination of a delivery person is entered into the site when the clerk who receives the order fills out the invoice. By means of a CGI (Common Gateway Interface) script, or program communicating with a database, the current location of a particular delivery person can be tracked throughout the day. Managers could track this information by taking a "snapshot" of the delivery operations at particular times of the year (or even the day) and could use this information as a reference for developing employee schedules.
The stores' floral designers will benefit from the site as well. Diagrams and photographs of specialty bouquet arrangements will be available through either postings or downloadable files. The board of directors also wants to establish a designers' bulletin board so that "tips of the trade" can be communicated from the design team in one store to design teams in other stores. When one designer creates a specialty design for a particular holiday, the site will allow for an immediate posting of a photo, a diagram, and written instructions, all of which will allow designers in other stores to implement the new arrangement immediately.
All of this sounds wonderful, and the advantages are obvious. But what disadvantages are there to developing an intranet like the one the floral board wants to create? For one thing, the intranet administrator must learn the technicalities and techniques of establishing and maintaining such a dynamic site. Issues of quality, security, technical ability, and expertise are important. The bottom line is that the intranet has to be useful, not only in its operations, but in its psychological appeal. Otherwise, the employees won't participate, leaving the site static.
Another concern for the board and the site developers is how to draw a division between the internal site, which will be used by the employees, and the public site, which will be used by individuals who want to place orders or simply learn about the company. Because some of the information, such as a customer order or complaint, will traverse from external to internal, the public and the private must be united, and the site developer must determine a way to allow unity without jeopardizing security.
A secure dynamic intranet that unites public and private access can be established if the intranet builder is creative and knowledgeable about what operations to include on the site. In fact, a dynamic intranet should be more secure than a static one, because the contents of the pages are determined by the users and the scripts. The pages do not exist as files on the server, vulnerable to break-ins. In fact, the pages do not exist until the user requests them, and they cease to exist when the user has obtained the needed information and logged off the server. Another advantage of creating a dynamic intranet: its nature requires that the developers use databases as a means of organizing the data. Having information in a database makes it easier to manipulate later should you change platforms, redevelop the site, or expand company operations. It increases your flexibility in terms of how you capture, manage, and analyze data. The way in which you choose to store your data is important: what you do now will affect the stability, security, and potential of your intranet.
A dynamic intranet depends on the steady flow of data, the bulk of which is input by the users. Let's go back to the floral shop. If the model that the board wants to see is developed, the employees will be entering quite a bit of important data into the site every working day. Information about costs and assets, employee hours, customer orders, and inventory cannot be put to risk by a faulty computer operation. An intranet that is entrusted with such information must be able to accept and organize the data securely and efficiently.
Begin by thinking about what types of data the users will input. Most likely, your intranet will contain the three types of data input methods outlined here, including data from e-mail and message boards. The floral-shop model allows the employees to communicate with one another and with the managers, not only by e-mail but also through electronic bulletin boards, which the Internet community refers to as discussion databases or listservs. Commercially available programs will give site developers what they need in order to establish a discussion database on an intranet. Think of these as group Web pages. In the floral shops, employees from each division have a discussion database geared especially for their questions and needs. The data travels from the user to the database and then potentially out to all users. The data can be archived as text files. It's possible to develop an archive of the static messages and postings and integrate them into a dynamic page. For example, the employees on the floral-design bulletin board could access the archive for a listing of Mother's Day bouquet samples from previous years. Look for software that allows you to establish a discussion thread so that you will have a means of organizing the text.
These datasheets list available product stock or any other type of inventory or employee information; they can be organized with a spreadsheet program, like Microsoft Excel. The floral shop requires that each of the 10 stores keep an individual inventory datasheet, but the board wants to build a common inventory database for the company intranet. This way, a clerk would access the site when looking to see whether a product not available in his store is available in another. The clerk then could immediately post a message requesting the needed product. Your intranet should allow employees to input inventory data. How the data will be stored and manipulated is discussed later in this chapter.
Even the most dynamic intranet will contain a fair amount of static data, such as the employee handbook or memos that likely would be in text or HTML files. The problem with static data, however, is that discerning old data from new data can be difficult. For this reason, you should establish a way to tag or mark static data with a time stamp or date indicator that can be posted on the site. In the floral shop, the delivery personnel's directions and the bouquet diagrams for the designers, such as the one shown in Figure 21.1, are examples of static files.
Figure 21.1: An HTML static file with the floral designer's instructions on creating a bouquet.
In addition to the data input listed previously, users might input other types of data onto the company intranet. Images or audio files are an example of user-input data that could dynamically enhance your site. The creation and manipulation of image and audio files are getting easier. Many companies have computer cameras, which operate in a way that's similar to Polaroid cameras. After taking a snapshot, the battery-powered camera is connected to the computer workstation through a serial port. By means of a simple software application, the image usually can be pulled up and saved as a JPEG (Joint Photographic Experts Group) file, like the one shown in Figure 21.2, or a GIF (Graphics Interchange Format) file, like the one shown in Figure 21.3. The entire process of taking a photo and creating a file that can be input into an intranet is often less than 10 minutes. Image input is especially useful for creating easily updatable catalogs. The designers at the floral shop might post GIFs or JPEGs to their bulletin board as a way to exhibit newly designed arrangements or to show examples of particular breeds of flowers.
Figure 21.2: A JPEG image of a flower arrangement.
Figure 21.3: A GIF visual diagram of constructing a flower arrangement.
Audio and video files can also be captured and transformed into Web-compatible files. Many commercially available software programs give instructions on how to make files that can be easily input into a Web server. RealAudio (http://www.realaudio.com) has developed a plug-in player that will play audio files from a browser as fast as they are captured. Audio files are especially useful for companies that want to make conference speeches available on their intranets. Both image and audio files can be input in ways similar to the methods used for text files. A dynamic intranet will incorporate all types of user data input and will have the flexibility to incorporate new file types as they come along.
Above all, remember that your goal is to have all the users of the site interact with it by inputting data. The more user input you have, the more potential you have for developing a site that is truly dynamic. Encouraging user input means making input easy for people who do not have much computer experience. Therefore, you'll want to be selective about the applications and functions you include on your intranet. Let's go over what's available to you.
You will most certainly have an e-mail system operating on your intranet. E-mail is the heart of Internet communication. It's a function many people feel comfortable using and want to use. Its popularity stems from its capability to communicate directly without interrupting the recipient. Users are notified when e-mail arrives and are left to decide when they want to read it. Besides setting up every user with an e-mail account, you'll want to encourage e-mail communication by creating mail-oriented functions such as topic listservs, which are e-mail implementations of discussion databases. Various software programs exist on the different network platforms, and listserv functionality often is included with Internet mail servers, along with standard e-mail functionality.
In the floral shop, the clerks might have a listserv group in which they communicate with one another about events taking place in the stores. Listservs almost always revolve around a specific topic, so you might set them up in a way to encourage discussion on topics that will help to develop employee creativity and, in turn, morale. A delivery driver might note that a stretch of highway has been closed for construction. Another driver (or any member of that listserv group) could suggest an alternative route. This conversation would be seen by all members of the group, so all drivers would know that the highway was closed and would learn of possible alternative routes.
These messages received at the listservs can be archived by the site operators and easily can be used to create dynamic pages about the topic when need arises. For example, if the managers at the floral shops are having a meeting to plan the Christmas season, quick access to the listserv discussions from the year before would be helpful. If the clerk listserv has been active, the managers will be able to access the entries, read them, and consider the previous Christmas seasons' challenges and successes when developing the new company strategy. But if the discussion list has not been active, very little data will be available, and the managers might be less likely to look for similar data as a reference for future meetings. Therefore, it's important to utilize the information gained from the listservs and to reinforce their value within your organization to encourage use.
Besides e-mail and listservs, you'll want the users of your intranet to put data and files onto the server so that the server can process them, or so that other users can access or download them. For example, the datasheets containing daily customer figures for each floral shop can be saved to the server by the clerks at specified times during the workday. Later, the managers can incorporate the files into the common datasheet along with maintaining the individual store datasheet. The transfer of these files from the clerk to the manager can be performed by FTP (file transfer protocol), which is covered extensively in Chapter 27, "FTP: Sharing Files." For large documents, you'll want the users to use FTP as opposed to HTTP (hypertext transfer protocol) forms, because FTP is faster. FTP moves data in a raw data stream from point A to point B with no need for interpretation (as opposed to HTTP forms, which require interpretation). For example, the 10 floral shops all keep their inventories in an Excel spreadsheet. On the main server, the data is compiled into one big spreadsheet. Each store (point A) uses FTP to upload spreadsheets to the common location on the main server (point B). After the data has arrived at point B, it is secured in the server, accessible only to those who have the appropriate passwords. When the server has idle time, or at a preselected time, the server can process the datasheets and generate the company datasheet. The site administrators have the job of assigning users different levels of access when using FTP.
FTP is not the only means by which a user can send files across the Internet. Most mail programs and Web browsers have an attach-file feature. File attachments arrive with e-mail messages. The users of your intranet might use the attach-file feature to send files to one another as well as to the server for site maintenance. For instance, one of the designers in the floral-shop chain could send instructions on the care of a particular plant variety to a designer in another shop. Along those same lines, downloadable files should be made available to users. The administrator would want to create topic-specific FTP directories from which users can download information. It's easiest to facilitate FTP downloads through the Web browser. This makes FTP transparent to the user. Making the files accessible to anonymous users makes it easier to administer the site but also limits the data that is available to users. Anonymous FTP allows users to access areas with a password. It is important to realize, however, that without a password requirement, anyone can access the information. This is why you must evaluate your needs and apply the appropriate levels of security. In the case of the flower shop, the appropriate access might be write access with no ability to read. This level of security would allow all users to drop off files but not read or access any of the files already there. This is similar to a night deposit box. For security reasons, when you configure your server, don't put the upload directory in a place where the user can later execute a file he uploaded. If you do, a malicious user could upload an application that formats your hard drive and then execute it remotely. The directory should be separate from your hypertext documents and your CGI program. Remember that most "anonymous" accounts without specific settings are a two-way street (send and receive) allowing full access to all users.
You can best develop the dynamic potential of your intranet with the use of forms. Most likely, you have visited Web sites that provide forms for user input. Surveys, orders, and customer complaints and comments all can be input via an online form like the one shown in Figure 21.4. Creating such forms is not as difficult as you might think, and almost all browsers support them. You will find commercially available programs that make the generation and execution of forms simple. Features such as radio buttons and pull-down windows can be incorporated at your discretion. Forms can be static or dynamic. When you use a form to capture information, clicking submit on the screen sends the information to the server. The developer of the intranet must then handle the arrival of this information. Some Web servers allow you to link a form directly to a database. In most cases, you will want to perform some kind of action with the data besides just storing it. To do this, you will have to write a script or a program that communicates with the form by using a standard called the Common Gateway Interface.
Figure 21.4: A Web browser with a floral form.
Forms have an advantage over e-mail in that you have more control over the way in which the data arrives to the site administrators. This ensures that the correct information is captured in the right places. Enhancements like JavaScript even allow the developer to check the user's input before submitting it. This is generally called masking data. Creating a database with forms is easier than creating one from e-mailed information or uploaded files, because all users of the form enter the data in the same manner. You might, however, lose some ability to process the data at the server's convenience. Because forms are connection oriented, the data they transmit must be dealt with immediately, so you'll want to have a CGI-based program generating the form response.
Successful use of forms requires that you determine what needs your company has that are best suited for online forms. Surveys are an example of a user-input function that works well with forms, because they usually require only the entry of single letters or numerals, which can be easily transformed into database fields. The floral shop chain might use forms in the employee intranet not only for surveys, but as a "suggestion box" or even a means by which to enter requests for days off or special assignments. The point is to use forms creatively for your company's needs and to develop them so that users will be able to input data successfully. Forms offer many ways to collect input and are the easiest to use for end users. As with many computer-related issues, however, taking responsibility away from end users increases the demand on the developers, but the scripts and programs required to capture the data from the forms are the trade-off.
After data is uploaded or entered by users, it must be stored. Several data-storing methods are available for intranet-building. Most likely you will store your data in a database, and you probably already have more than one database established. The floral shops have an inventory database containing a stock list of the types of greeting cards and gifts. They also have an employee database of names, addresses, and phone numbers for the people who are working or who have worked in the stores. While building your intranet, you should consider how and where user input and static data should be stored, and you also should consider what types of databases will serve as the foundation for your intranet.
Any information received by the server will require instructions at the server on how to process it. Most of the functionality required to capture information is built into the Web server. These programs, however, do not know what to do with the information after they receive it. Programs that manipulate files received through e-mail or FTP run separately from the Web server and thus can receive data through common methods from a dedicated server. (In the case of e-mail, it could be a Simple Mail Transfer Protocol (SMTP) server or a Post Office Protocol (POP) server.) Programs that work with stored data from listservs also gather information via a dedicated server. The only different development challenge associated with intranets is the use of the Common Gateway Interface standard to communicate between an HTML form and the program residing on the server that manipulates the data. The data from the HTML form isn't delivered directly to the processing software (the CGI). Rather, it is parsed into a common format that every CGI-compliant Web server can read. The following is an example of CGI data encoded in a URL that a Web server would understand:
http://www.abc.com/cgi-bin/test.exe?First_Name=Stacey&Last_Name=McKellar
The CGI formatted data is then fed to the script/program, which then handles that data and returns the results to the Web server. The Web server formats the returned data as requested and returns the document to the client (browser).
The Common Gateway Interface is a series of platform-independent rules that govern how information received by a Web server from a form is handed over to a program or script for processing. In turn, it also defines the rules by which the script or program communicates with the server and, ultimately, the user at the other end. These rules are not particularly complicated, but without them, every Web server would communicate differently with programs. To ensure that scripts (and programs when possible) can be used in different computing environments, the CGI was established. This multiplatform capability means, however, that the solution might not be ideal for all operating systems. Most popular Web servers have their own specific implementation of the CGI, but all support the international CGI as well.
Taking information from a database and displaying it works in several steps. First, through a search system, you must locate the desired information in the database. You can either buy search system software or develop your own. Often SQL (simple query language) inside a CGI script or program can achieve this objective. After the information is located, it must be presented. If the data is timely, the correct information from the database should be put into HTML dynamically and sent to the user. This approach creates "virtual" HTML files, which are sent but never stored. On the other hand, if other people might be interested in the same information, the HTML file could be generated and then stored for later access. A good example of this is working through the results of the discussion databases and turning the comments and questions into HTML.
Storing information in a database can be as simple as developing a Web form that uses a CGI program to place information into a database. It also could involve a program that receives e-mail and extracts the important data and then communicates with the database through a program or script. These methods require some programming or scripting and are specific to the type of database in use.
At some point, you will likely be faced with the job of integrating old databases into a structure that is more appropriate for intranet functions. Database administration can sometimes be a difficult and complex job. Moving data has many rules and restrictions, but at a very high level, an intranet developer could get information from existing databases in several ways. The simplest way would be to access the data from the old system directly by using a CGI between the server and the database. This method is convenient provided that the data you have is easy to access and that it supports a script or programming language that can access the data. If, however, your database is older and doesn't support such features, export the data from the old system into a type supported by the new system, and then access it using a CGI program or built-in methods. This works if you can find a database type to which the old file will export and the new system will import. The newer your original system, the easier this job will be. Another slightly different option is exporting the data from the old system into a commonly used data type, then importing it into the new system and accessing it using a CGI or built-in methods.
When working with databases, keep in mind the distinction between flat file (ASCII-based) databases and relational databases. A flat file database consists of simple ASCII text. All data in these files is nonrelational. Consider them a collection of information within a file rather than in a database. Flat file databases work in much the same way as the "merge fields" function on popular word processors like WordPerfect. The delimiting factors (such as commas or tabs) are the only indicators for how the fields should be meshed together. The following is a flat file containing contact information for three separate people in comma-separated value format:
"Smith","Mike","J.","202-555-1234","134 A Street","Washington","DC" "Baron","Ed","","703-555-3164","1616 Mary St.","Fairfax","VA" "Franklin","Stacey","L.","301-555-1143","34 Palace St.","Bethesda","MD"
Flat file databases came about as a way to manipulate text files around a hard drive. From a performance point of view, adding to them sequentially is fairly quick, but you don't want to take things out of them, and you don't want to search through them. It's easy and inexpensive to program for a flat file database. But these types of databases are slow to search through. The advantage of flat file databases is that they can function as a prototype for analyzing data, but generally only in a single-user environment. Another advantage is that they are portable and can easily cross platforms, making it simple to mail flat file databases electronically.
The main drawback with flat files is you must deal with locking them. Basically, only one person can write to a flat file at a time. Imagine an airline ticket system that could sell two people the same seat but only record one name. To prevent this problem, a flat file database must have some way of locking records. Because multiple CGI programs can be running at the same time and because they generally do not communicate with each other without substantial programming, using a scripting language or a development language to implement locking is tough. But if locking isn't implemented and two people write to the file at the same time, the file becomes corrupt.
The other type of database is the relational database. Relational databases contain a minimal amount of data to which another database can relate. Try Microsoft Access for an inexpensive, user-friendly relational database, an example of which is shown in Figure 21.5.
Figure 21.5: A complicated relationship as viewed in Microsoft Access.
Some important aspects of a relational database system are the existence of a primary key and the relationships between tables. A primary key is an important constraint of uniqueness on a field. Since every value in this field is guaranteed to be unique, you can use it to relate to other tables. Choosing your primary key is important, because it should never change. A good primary key for a table containing data about a person would be a Social Security Number-it is guaranteed to be unique and unchanging.
The relationship between tables describes how records in one table link to another. Consider a flower shop vendor list in which a company table has a primary key called COMPANY_ID and the contact information is kept in a different table with a primary key called CONTACT_ID. Each of these fields ensures that every company and contact is distinct. Linking a contact to a company requires an additional field in the contact table that points to the correct company. This field, called CONTACT_COMPANY_ID, would contain the corresponding COMPANY_ID value from the Company table. This means that if IBM had COMPANY_ID = 5, and you added a new contact for IBM, the new contact would have the field CONTACT_COMPANY_ID = 5.
One ideal use of a relational database is a situation in which the same information must appear in multiple places-such as a vendor list. Suppose that every contact you enter in your database also stores the name of the company, and multiple users are entering this information. If one of the users spelled the company's name wrong when entering it, a query wouldn't find all the company's employees. However, using a relational approach, you would create one instance of a company and link all the contacts to that company. If the company's name changes, it changes for all contacts. Likewise, if the address changes, and the address is associated with the company, only one record changes, but all contacts will have the newer address. This is the principle on which relational databases are built.
Relational databases should be used if you have a database existing in multiple tables (the flat file equivalent would be multiple files). There is little you can do with a relational database that you can't do with a flat file and a lot of programming. Relational tables allow for a multiple index (you can sort by names or by any other factor you've established). Indexes make searches faster than those performed through a flat file database, and make searching specifically for something like a name or phone number possible. Indexes also decrease the speed of updates and deletes. The use of indexes is something best left to a competent database designer.
Security is always an issue with corporate data, even on an intranet. Remember to integrate security into the database. Flat files don't inherently support security. You could develop your own custom code, but why reinvent the wheel? Most relational database systems handle security superbly, even down to a per-column privilege level. One drawback of using a relational database is that it requires that the person who's designing it have a thorough understanding of what he or she is doing. A poorly designed database could cause data corruption or data loss. Because there is only one copy of each piece of data, developing correct relations between tables is essential. It's integral that the primary key be an unchanging value.
Another advantage of some relational database systems is that they allow the storage of binary data and pictures and sound clips, which are called BLOBs (binary large objects). The Oracle RDBMS is an example of a high-end relational database system that supports BLOBs. The company has developed a Web server that integrates closely with its database. The Oracle Web server provides a fast gateway between the Oracle database and a Web browser. Instead of using the CGI, Oracle moves data by using code specific to that product. This method is very quick, but Oracle-specific; the Oracle Web server, however, supports the slower (but standard) CGI. Another RDBMS product to consider is Illustra, which is an object-relational database that is good at handling object-type inputs beyond standard text and numbers. Illustra can serve audio or video files, and it is especially useful for companies that work with multimedia. Illustra's big advantage is that it can serve video clips. Different segments can be pulled from the clip as instructed by a CGI script. Illustra's architecture is based on plug-ins; for example, you can develop and "plug in" a custom Web server interface. Illustra's plug-in system makes it very easy and inexpensive to upgrade; even third parties can write the plug-ins. The plug-in structure supports additional data types and provides new services. These could be data types and services that aren't yet available.
Deciding how to store your intranet's data is an important concern. Not only will your data-storing methods affect the operation of your intranet, but they also will determine your intranet's potential to incorporate technological developments as they become available.
To make an intranet more valuable, it is ideal to include as much dynamic information as possible. Dynamic development of a Web site means that the screens are generated when they are needed, not necessarily ahead of time. This means the information is current-and currency is critical.
Dynamic sites, which are built around data, are more complicated to build but are far more valuable than static sites. To build a successful site, one must not only display data but capture it as well. Keep in mind when communicating that the type or format of information being communicated will determine how it is communicated. FTP is an ideal choice for transferring information that is in a file or in a specific format generated by an application, whereas e-mail is a better choice for transmitting informal information that does not need to be processed. If input control is required and information must be processed and stored, WWW forms are the best choice.
After this data is captured, it should be stored in a database. If information is received from e-mail or FTP, processing all received information whenever the computer isn't busy is fine. For more complicated file transfers that must be dealt with immediately, WWW forms utilizing the CGI are ideal. However you access the database, you must choose the right application for the job. For simple cases that require minimal access and poor performance, I recommend flat file manipulation. For more complicated situations, relational databases offer great power and compatibility at a reduced price. Finally, some databases also are integrated into Web servers, making them particularly useful.
Remember that each problem has its own solution. No two problems are alike. But understanding the key issues about working with dynamic information-whether displaying it, capturing it, or storing it-allows you to make the right decisions as tough questions arise.