by Bob Breedlove
The explosion in use of the Internet has shaken up the traditional paradigm for application design. In the traditional view of client/server applications, custom-written application components were distributed and used to run the application. In the new paradigm, the user has a client tool-the Web browser-to which host applications are written.
The Web browser gives the end user a unified platform on which to run applications. This new paradigm can be useful to the development of intranet applications because the new paradigm enables application designers to write multiple host applications that work with a common client. Using a common client can reduce training costs and lower the learning curve for new applications by enabling the end user to use a single client for multiple applications.
Developing applications for an intranet requires many of the same considerations as developing applications for the public Internet (see Chapter 11, "CGI and the Internet"). An intranet can be viewed as a private Internet-a non-public router-based TCP/IP network. It can, however, have some exposure to the public Internet, generally through a computer that limits the types of packets which can pass between the intranet and the public Internet-a "firewall." This chapter begins with an examination of some of the things that make programming for an intranet unique.
The purpose, and thus the design, of applications designed to operate over an intranet vary from those designed for the Internet. A set of Web pages (referred to in this chapter as an "application") intended for the Internet is generally intended for an outside audience, for example, customers, vendors, or other companies. The look and feel of the application will generally be more "glitzy." Being "cool" and "sharp" counts, and the pages often contain attention-getting graphics and other gimmicks designed to attract an audience to the pages.
The intent of these applications is generally to promote a product or service or actually to sell a product or service over the Internet. Thus, attracting and keeping a target audience is an important aspect of Internet programming.
Intranet applications, on the other hand, are usually intended for internal audiences such as co-workers, managers, or employees. These applications are intended to provide important information or services to manage the business. As such, users want these applications to convey this information succinctly, efficiently, and in a timely manner. The same graphics and other gimmicks that are the heart of an Internet application can actually interfere with the effectiveness of an intranet application.
Much of the following discussion assumes that you are developing applications that meet these general purposes. If you need general information or if you are developing applications for external audiences, you might find it helpful to read Chapter 1 "An Overview of Internet Programming."
Before you examine the actual design of applications for an intranet, look at the factors that make intranet applications a challenge to design and implement. As you will see, many of these factors affect your development time frame and implementation effort; others affect the performance of your application after it resides on your intranet.
As shown in Chapter 1 the public Internet has no central authority or controlling body for its infrastructure. The various resources over which it operates are controlled by the organizations that own them. In contrast, an intranet is usually a centrally controlled resource. Generally in large corporations, a central authority manages at least the backbone of the intranet and handles such services as these:
Authority for some of these functions can be delegated to divisional
or regional authorities, depending on the size of the corporate
domain. Control of the intranet is generally divided, however,
between locally managed local-area networks (LANs) and centrally
managed wide-area networks (WANs) and backbones. What this means
to your project is that you will have to work with these corporate
groups to get things done. Later in this chapter, we will explore
in more detail how this affects your project time lines and implementation.
| TIP |
Intranet resources are usually controlled by a corporate or divisional group. You will have to deal with these organizations to implement your system. |
Figure 4.1 represents a typical corporate intranet. The backbone of the intranet is usually some packet switching technology or other high-speed wide-area network technology. This and corporate resources such as corporate firewalls (A) are usually centrally controlled. LANs (B) are usually locally controlled; however, resources that connect the LAN to the intranet (routers and bridges) can be centrally controlled and managed. Intranets also often have to contend with dial-up access (C) from field sales and other off-site staff. This dial-up access can be accessed through corporate resources or locally controlled. Mainframe access (D) is also a concern for many corporate applications. Mainframes traditionally are centrally controlled and can be controlled by groups other than the intranet groups.
Figure 4.1 : A typical corporate intranet has centrally managed and locally managed resources.
In this chapter, you'll see how this control of resources can affect your system design and time lines for development. You'll learn about alternatives for your design and about development time-line considerations that you will face when working with the intranet control and management functions.
Most corporate intranets are a result of evolution rather than planning and design. They evolved from earlier attempts to connect LANs, WANs, and mainframes in response to the demand for greater access to information. As such, intranets are composed of a mixed bag of workstations, hosts, networks, and other devices. Intranets give users unprecedented access to corporate data resources. Dealing with the intranet itself, however, can be a major challenge in writing applications for use on this shared resource.
This chapter presents designing client/server applications that use some portion of the intranet infrastructure depending on the distribution of the data and applications that process it. In general terms, client/server applications can be categorized into various degrees of decentralization.
Figure 4.2 shows this continuum. From left to right in the figure, the typical configurations can be described as follows:
Figure 4.2 : Client/server design strategies, showing typical applications for each alternative.
| A. | Traditional applications with data, processing, and display/output on the same platform. These applications are typified by single-user PC applications and traditional mainframe batch applications. |
| B. | Data and processing on a single platform with display on a separate platform. Mainframe online transactions with video display terminals and Web server CGI applications are typical of this type of application. |
| C. | Data separated from processing and display. This is typified by SQL servers, which provide data from central repositories to distributed applications. |
| D. | Separated (three-tier) data, processing, and display, typified by applications that require processing above that provided by desktop workstations (PCs). |
You will face different issues depending on the scope of your
application. By "scope," I mean the extent to which
your application will use the intranet resources. Generally, these
fall into the following categories:
| Application Category | Use of Intranet Resources |
| Single computer system | None |
| Local LAN-based system | None |
| Central processing/data access with remote display | Minimal |
| Central data access with remote processing/display | Moderate to heavy |
| Distributed data, processing, and display | Heavy |
In single computer systems, the central processing unit (CPU) speed, available memory, and direct storage-device capacity and storage-device throughput are the limiting factors to system performance. With intranet applications, add to this list the network throughput. Throughput is a result of several factors:
Each of these factors affects the operation of your application. You will have to work with corporate organizations to modify most of these factors.
If the load on your Web server is the problem, you have a few options. The first might be to increase the size of your Web server host machine, but before considering this expensive option, take a more detailed look at the capacity problem. The problem might be caused by a single page or CGI script, or it might exist only at particular times of day. The key is to determine what, specifically, is causing the load problem and when the load problem exists before you spend money on equipment.
One important point to remember about Web-based applications is that you can, within reason, place the resources anywhere on the intranet. If your current host can't handle your application, consider moving it to an existing host that can or consider splitting it between hosts to equalize the load.
Your own LAN can be the bottleneck for your application. Here you need to examine the bandwidth and the usage on the LAN. If you find that the LAN cannot provide the needed bandwidth, again, consider hosting your application on a LAN that can or increasing the capacity of the LAN. (It is unlikely that you will be able to convince your company that purchasing new LAN equipment is worthwhile, unless your application is the major one on the LAN.)
If your problems arise from the load on the LAN, consider moving your application server to a separate LAN segment. Depending on the LAN type, you might need to provide a separate network interface card for your router to accomplish this. It might relieve your application from overloading.
The need for adequate network capacity (bandwidth) is obvious. Your intranet needs the capacity to be able to handle the volume of data that your application will generate. Your application will operate, for the most part, at the speed of the slowest segment over which it operates. Unless your LAN segment is the slowest, there might be little you can do about it. Make sure that the bandwidth from your Web server to the backbone is as fast as it can be. If it isn't fast enough, consider increasing the bandwidth or moving your application to a host on a LAN that provides the bandwidth you need.
Any device through which your application's packets must travel will delay your application. This latency is built into intranets because they rely on gateways (routers and bridges) to provide packet routing. There is probably little you can do about the overall speed of the intranet.
You also should be aware of the gateway's capabilities to filter by packet type and IP address. If you find that users can't get to your application, have your network managers examine the filtering on each of the routers to determine where the packets or your IP address are being stopped. If you are running on a UNIX host, you can use the traceroute command to find out which devices exist between you and a specific host (see Chapter 17, "Using the Win32 Internet (WinInet) API," for an example of this command).
If you find that router filtering will be a problem, you might find that the issues are more complex than just asking router operations' personnel to remove the filter. That filter was applied for a reason. You will have to examine the business issues that caused the filter to be applied; that way you can determine whether you can remove it. If you cannot remove the filter, your alternative might be to host your application on a machine that is not filtered, duplicate your application on both intranetwork segments, or exclude that segment of the intranet from using your application.
Proper equipment such as network sniffers and cable testers can be essential in the effort to determine the actual cause of the problem. If this equipment is not supplied by some corporate resource, it might be up to your department to provide this equipment in order to determine the cause of the problem and determine the proper course to correct it.
Firewalls are placed between the intranet and the public Internet to protect corporate resources, as shown in Figure 4.1. Firewalls act as single points of entry to the corporate intranet, and often, single points where users on the intranet can gain access to the public Internet.
When we speak of a firewall, we speak of users on the corporate intranet as being "inside" the firewall and the Internet as "outside" the firewall. Generally, firewalls are configured to let all types of packets out, giving users on the intranet access to the public Internet. Firewalls are almost always configured to restrict the packets coming in, thus restricting public access to the intranet that they are installed to protect. Telnet, FTP, and HTTP packets are usually filtered from the outside, as these would enable hackers access to the resources on the intranet. Mail and news packets are often allowed to pass through the firewall freely in both directions.
At this writing, Java and other languages of its type are in their infancy. It will be interesting to see how Java transactions will be treated through a firewall. This is a potential security problem because the Java application is sent from the host outside the firewall but will execute on the client machine inside the firewall.
Although firewalls are a necessity, they can cause problems for your application, especially if users on the outside of the firewall need to access your application. Firewalls can also slow transactions and become bottlenecks for your application. For this reason, it might be best to design a distributed application with a module outside the firewall to communicate with the public Internet and an equivalent module inside the firewall for users on that side. Figure 4.3 illustrates this type of design.
By placing some of the modules outside the firewall, you avoid having unauthorized HTTP packets passing through the firewall. By using IP address filtering, you can receive packets from your "trusted" host (A). For additional security, consider replicating data with the modules on machine "A" outside the firewall so they are completely isolated during online operation. Use FTP or another transport mechanism to gather transactions in a batch operation to integrate with the main database.
This type of "store-and-forward" operation can be effective for systems that have remote components such as hand-held field units or that send transactions such as sales order transactions that you can deal with as distinct entities. Thus, a sales representative might access the Internet to upload the day's orders and download information for the next day's sales calls at the end of his or her day.
The last consideration for using an intranet is the total load on the network. If the load is too great at critical times, your application becomes unusable. There is probably little you can do about this except design your application for some other infrastructure.
Be aware that intranet usage can vary widely by time period. Remember, most corporate intranets were not planned but evolved over time. Although capacity planners can examine the backbone of the intranet, there is often little centralized control over applications that use the intranet. When designing your application, consider other applications that will also share bandwidth with your application. This is especially important if your application performs special processing during typically busy times.
For example, if you are designing a financial application that accepts transactions that are processed in a weekly or monthly cycle, you can bet that your heavy activity will be in the period just before the cycle. If this happens to fall at the end of a week or a month, other systems can compete with your system for bandwidth, making the response times unacceptable for your user community. Be sure to test your application during these heavy periods. It might even be wise to develop a prototype early in the design cycle to assure that transaction times are acceptable during heavy load periods.
Using an existing intranet for your application offers many advantages. Capacity planning is the key to a successful intranet application. In considering capacity planning, you often must work with corporate entities. The major consideration in capacity planning is the time frame in which projections must be supplied to assure that changes can be implemented to accommodate the increased load. Lead times will vary from corporation to corporation, but they will usually require you to predict initial loads, expected loads over time, and peak loads.
An existing intranet can be a good choice for internal applications
because it uses existing resources, thus saving on initial costs
and start-up time. Designing for a Web browser can cut your programming
efforts and, because your user already knows the technology, can
reduce your training costs.
| NOTE |
Designing for a Web browser can solve the problem of programming for diverse workstation types. When designing Web pages, you write to the single HTML standard and let the browsers worry about formatting. |
But running your application over an intranet that has evolved over several years can be a double-edged sword. Intranet growth is typically "organic," where workstations and network technology are purchased to answer a specific business need and then are integrated at a later date into the intranet. Because of this, the types of workstations on an intranet are likely to vary greatly. Most corporations have evolved a mix of workstations, including the following:
In addition to these common workstations, your corporation can run other platforms and specialized workstations. A Web-based application is an excellent choice for applications that must accommodate these diverse platforms. By designing Web pages, you do not need to supply specialized client software. Instead, you can construct and display Web pages on the various equipment already deployed on the intranet.
As shown in Chapter 17, there are considerations when designing applications for Web browsers. There are also considerations on the Web server side of the transaction.
Hypertext Markup Language (HTML) began as a standard, but with the explosive growth of the Internet, major players in the Web browser market are racing with each other to implement new and innovative (and non-standard) features in their Web browsers. Unless your corporation has standardized a particular Web browser, your application might have to work with more than one browser.
Your application can usually detect the type of browser it services by checking a parameter passed by the browser. This parameter is not always reliable and is not passed by all browsers. If you need to support specific features or need a graphically consistent application, consider writing to a specific browser and supplying it to the users of your application.
Security doesn't seem to be such a major issue on a corporate intranet as it is on the public Internet. After all, this network is not public. But business considerations can make security an important issue with which to deal.
If security on an intranet is centralized, it is usually controlled by a corporate organization. Many corporations currently do not have centralized security for their intranets, which is unfortunate as much of the hacking done today occurs on private rather than public networks.
If your corporation does have central control of intranet security, those in charge will have security standards that your application must meet before you can place it on the intranet. As with other corporate organizations, you will probably have to plan in advance to work with the corporate security department. Some intranets might even use centrally administered security for logon passwords and other security issues.
Most technicians find that security concerns often conflict with the technical considerations of their applications. Technical advances often outstrip the security department's ability to accommodate them. You might devote your time to security modules that seem overly burdensome and might find that you are unable to implement some technologies on the intranet because of security requirements and concerns. But by planning ahead, you can prepare time in your design and construction schedules to accommodate these security needs.
Another concern in intranet applications is protecting confidential material. It is true that your application is operating over corporate resources, but it can pass data that should not be seen by unauthorized employees, contractors, customers, and others who have access to the intranet. Many confidentiality issues discussed in Chapter 1 for the Internet also can be applied to intranet applications. Because the intranet and Internet are both TCP/IP networks, they have the same limitations and problems when plain text is transmitted across them.
One issue that requires a balancing act is the need for confidentiality versus the availability of information for the corporate community. Security and confidentiality issues are always cost-benefit tradeoffs.
Remember also that you might have to apply local, state, and even national laws to the information in your application even though it passes over your private intranet. Personnel and financial applications are often subject to these laws. Another interesting consideration that spans political jurisdictions-states, provinces, or even countries-is that various segments of the intranet might be subject to different laws when it comes to the confidentiality of the information carried on them.
Maintaining security and confidentiality is a juggling act. On one side is the need to keep information secure and confidential, and on the other side is the need to make information available. There are no hard-and-fast rules for managing this dilemma. You could write an entire book on security and confidentiality issues. In a single chapter, I can provide only some guidelines by which you can develop your application.
You will need to examine two things to determine the level of security that your application requires. First, determine how sensitive your data is. Some data is easy. For example, if you are developing an organization chart application that will display information about your employees such as social security numbers, home addresses, and phone numbers, you are dealing with sensitive information that should be protected from unauthorized access. Other information is more subtle. Let's say you're working on a marketing application that will enable your managers and sales representatives to share information about current and potential customers. You might think that this information doesn't need to be very tightly secured; after all, this is your internal network-your intranet. This brings us to the second consideration in the security versus availability dilemma.
Stop for a moment to consider the people who have access to your intranet. If you are part of a company of any size, you probably have all sorts of people in your intranet:
Would you want all of these people to look at your data? Even subtle data can have an impact on your business. Let's say you want to put your company newsletter online. Along with those announcements of company activities, the local bowling league scores, and the picture of the employee of the month is an article about your marketing strategy. If consultants, vendors, or customers had access to this information, it could give them (or their other customers) a competitive advantage in the future.
If your intranet has a mix of people on it, consider giving non-employees IDs that are easily identified, perhaps with special characters in certain positions. Secure all confidential or potentially damaging information with secured Web servers. Require access via ID and password. Your application can detect the special IDs and deny access to the information.
One interesting fact is that very few corporations have implemented internal firewalls on their intranets. You might consider implementing a firewall, especially if you are designing a sensitive divisional or departmental application that needs to be isolated from other divisions or departments.
How do you decide the security issues? Only you can do so. Look at the data, and then give some thought about the people who are using your intranet. If you have any doubt, secure the information. A few tips follow.
Given a choice, most of us would select a password that was easy
to remember, never change it, and use the same password everywhere.
Your corporate security group probably has standards much stricter
than that-for a reason. Easy passwords that never change are easy
to crack, and once passwords are cracked, hackers can use them
again and again.
| TIP |
Never send passwords via electronic mail unless the message is heavily encrypted. In fact, just to be safe, never send passwords through electronic mail, period! |
If you must use passwords in your application, change them periodically. Once a month is typical, though your application might require more or less frequent changes. If you use the HTTP password capability, you will want a separate process for updating passwords. One way is to use corporate security files to obtain passwords. Another suggestion is to alter the passwords periodically yourself and distribute them to your users via a secure mechanism. Never send passwords in an electronic mail message unless the message is encrypted!
As you have probably recognized, for a major part of the design
and implementation effort for an intranet application, you will
have to work with the corporate organizations that control the
resources. Companies vary, but in this section, you'll learn some
of the typical organizations. Your company can name these groups
differently or roll the responsibilities into other groups, but
the company will probably have some group to provide these services.
| TIP |
Working with corporate organizations can take time-plan for it in your development schedule. |
Probably the first place you will have to go is to network naming and addressing, especially if you are going to implement a new server for your application. This group will provide you with new TCP/IP addresses and domain names. Often in large corporations that have multiple subdomains, this responsibility is delegated for each subdomain.
It will undoubtedly take some time to get a new domain or even machine registered in a large intranet-plan accordingly. When you request addresses or names, be sure to include your development and test environments along with your production host, if they will be on different machines.
If your application will have exposure to the public Internet, you might have to work with your corporate naming and addressing organization to obtain the IP addresses and names for your hosts and register your hosts. Often corporations are assigned blocks of IP addresses and are responsible for naming their domains. In this case, your corporate group can probably supply the names and addresses that you need.
One frustrating aspect about intranets is router operations. Routers are the "glue" that hold the whole application together and, in a corporate intranet, are often centrally controlled. Some companies use routers as security and control mechanisms; that is, they filter specific IP addresses or groups of addresses to segregate parts of the company.
If all parts of the company must share your application, you will have to work with router operations (and possibly other corporate organizations) to resolve the issue of segregation. This can generally be a time-consuming process. The end result is usually one of three:
As you can imagine, the second and third options can raise other issues of control and access to maintain and update your application.
To test whether your application is accessible by all who require it, ask users on the various segments to attempt to retrieve pages from your server. Be sure to include all protocols-that is, FTP, SMTP, NNTP-that your application will use to ensure that packet types are not being filtered at some point in the intranet. Also, make sure that your beta testers represent all network segments that will use your application.
Unlike the public Internet, you might have to conform your application to corporate standards before you can deploy it on the corporate intranet, especially if your application will be part of a "suite" of applications, such as corporate or financial applications. You might have to conform your application to the corporate look and feel and meet performance and specific programming standards. Be sure to investigate these standards early in your design process.
You will also have to work with the LAN administrators on the network where your server resides. Often, LANs are given naming responsibility for the domain of which the LAN is a part. These resources can help you work with corporate infrastructure. They also tend to be more accessible just because they're physically close.
Much of a corporation's data probably exists in mainframe files or databases. Often, this data is accessed through legacy mainframe systems over non-TCP/IP networks. The most common network architecture is IBM's System Network Architecture (SNA). Corporate intranets are often put into place as the infrastructure to access this data. However, converting legacy mainframe systems to client/server systems is often expensive and time consuming.
Thus, your system might have to access data on mainframes maintained by legacy systems. Typically, executive information systems (EIS) are LAN based. You can find many tools on the market that access mainframe data, but these tools tend to rely on the data being in a mainframe database or are expensive to install and maintain.
It is well beyond the scope of this chapter to talk about the various tools available for mainframe access, but I'll briefly discuss two alternatives to give you a framework for your design:
If you design a decision support system (DSS), you can choose to download data to a LAN-based database out of the mainframe system, often referred to as a data warehouse because it contains historic data, often summarized, optimized for data retrieval. Data warehouse design is a complex subject and will not be covered here.
Many tools to access intranet-based databases are coming to the market. If you choose to write your own tools, you will need to design a CGI application, which interfaces with your Web daemon through the CGI standard and the database's application programming interface (API). Figure 4.4 illustrates this design.
Data synchronization is an issue for this design. That is, you will have to carefully consider updating of your database and transmitting data between the mainframe database and the intranet-based database. The issues of data duplication are complex and well beyond the scope of this chapter.
Cost and time to develop client/server-based applications to meet the demands for access to corporate data are usually high. One method you can use to speed access to data at a relatively low cost is to use programs to access data from existing mainframe application screens. Figure 4.5 illustrates this application design.
There are two components in this design: a CGI application and a mainframe interface program.
The CGI program, the interface between the user and the mainframe interface program, receives input from the user in formats specified by the CGI standard and returns information to the user by formatting HTML pages. The program establishes a TCP/IP socket connection with the mainframe interface program and passes transactions that will be processed by the mainframe application just as if a human had typed them.
The CGI application details vary, depending on your application. However, all applications perform the following basic functions:
Of course, you will have to code both the CGI application and the mainframe interface program to correctly process errors such as timeouts, unavailability of the mainframe system, and other unforeseen circumstances.
This daemon program is responsible for the connections to the mainframe. It usually operates through a vendor's SNA interface API. The program varies depending on your application and the vendor's API, but programs of this type perform several basic functions:
In addition to these basic functions, the mainframe interface program can perform other specialized functions for your application.
Because the process of signing on to the mainframe can be time consuming, the mainframe interface program signs on to the system once per day and maintains the connection until it signs off in the evening. The interface program is responsible for maintaining this connection and accommodating all security procedures to sign on to the mainframe.
The mainframe interface program receives the SNA data stream,
then picks off information at specific screen locations. In doing
so, the program "scrapes" information off existing application
screens and thus gets the name screen scraping.
Using existing mainframe online screens as the source of the data,
you can usually implement this type of program more quickly than
other types of interfaces. You can also typically use this type
of screen scraping program as an interim module while more sophisticated
interface modules are being developed.
| NOTE |
A screen scraping program can be a maintenance headache if your existing mainframe screens change frequently. Screen scrapers usually require little maintenance when interfaced to stable mainframe online screens. |
One typical situation your screen scraper will face is an inactivity time-out on online applications. To deal with this, the program implements a timer that sends a dummy transaction during periods of inactivity for each monitored line. These dummy transactions can be as simple as simulating an Enter key press or can involve coding a "do nothing" transaction that can be sent periodically to the mainframe transaction monitor.
Although processing transactions will be unique to your application,
the basic format for this interaction is as follows:
| CGI Program | Mainframe Interface Program |
| Request socket connection | Establish socket with CGI program. Allocate mainframe session. |
| Send request transaction | Format request for the mainframe. Transmit request to the mainframe. Receive response from the mainframe. |
| Format information for display | Format and return information. |
| Disconnect socket | Disconnect socket. Deallocate mainframe session. |
Although the conversation between the modules can be much more complex, this is the basic conversation. One important point to note is that the connection between the CGI program and the mainframe interface program is broken after the conversation is complete. Also, the mainframe session established for the conversation is de-allocated after the socket connection is broken. This means that any information that needs to be carried over between conversations needs to be maintained by the CGI program, the mainframe interface program, or both.
As I stated at the beginning of this chapter, the purpose of intranet applications (sets of Web pages) is to convey information as succinctly, efficiently, and timely as possible. This style guide section presents some basic design elements to help you do this in your applications.
If your corporation has a style guide for intranet Web pages, use it. If not, the corporation might have a guide for Internet Web pages. If so, you look through it and keep in mind the difference between the intent of intranet versus Internet applications.
Several excellent style guides are available on the Internet. One excellent overall guide to Web page creation is the Yale University Center for Instructional Media (CAIM) Style Guide by Patrick J. Lynch. The address for this style guide is
http://info.med.yale.edu/caim/StyleManual_Top.htmL
Because excellent style guides are available and corporations differ greatly, I do not intend to present a complete style reference. Rather, with this section, I present suggestions for Web pages that are important to intranet applications and can apply to Internet applications as well.
Your application likely includes more than one Web page. In this case, organization and navigation are important aspects of your design. A user's perception of your application and its ease of use (navigation) are important aspects of design. To quote from the CAIM style guide, "Users need predictability and structure, with clear functional and graphic continuity between the various components and subsections of your [application]. Banner graphics, signature icons, or other graphic devices can be very useful in reinforcing domain identity within subsections of your [application]."
Although you probably won't need to reinforce "domain identity," you will have to give your users the information they require with a minimum of fuss and bother. You don't want the users' concept of your application to be a tangle of connections. The users need to have a clear picture of your organization.
If you build a set of pages, think of them as you would think of a written report or book. Organize your application into a single home page with specific submenus and pages off these menus. Figure 4.6 illustrates this organization.
Figure 4.6 : A Web application should be logically organized to minimize confusion.
Of course, don't interpret this to mean that you can't jump between
content pages-quite the contrary. Logical jumps between content
pages are what hypertext (the "H" in HTML) is all about.
The point to remember is that your Web application should appear
logical and organized, not random and disorganized.
| TIP |
You might just want to jump into producing Web pages, but organizational planning is as important to a Web application as it is to any traditional application. |
If you generate screens that request, then display, information dynamically, your structure should follow in much the same way. As with any traditional application, your Web application should enhance the way users do their jobs. It should take them step by step through the required screens in a logical manner so they can achieve their goals.
It is important to enable users to navigate through your application. If you have spent the time to plan your application's organization, you have decided on that organization for a reason.
One important point to remember is that users can drop into your application at any point. If you do not provide them with connections to navigate up and down through your application, they will not get the full benefit of it.
The minimal navigation aids that you should place on every page include the following:
[Previous Page][Table of Contents][Home Page][Next Page]
In addition to these buttons, you might want to include buttons to navigate to a next section if your application is organized into sections or to specific pages of general interest, such as a glossary.
Consistency and logical layout are the keys to good page organization. When you plan your Web application, design a base page template and use it whenever possible throughout your application. Figure 4.7 shows some elements you might want to consider for your template.
Important elements illustrated by this template include the following:
| Format Element | Comment |
| Banner graphic | A graphic element that ties your application pages together. This element gives your pages continuity and your users a sense of a complete application even if they drop into your pages at midpoint. |
| Document title | The title of your application; also a strong unifying element. |
| Navigation buttons | Objects for the user to navigate through your pages. These buttons are important because an outside page can link to a page in the middle of your application. |
| Dividers | Horizontal Rule (<HR>) lines and other elements that organize your pages into logical sections. |
| Page title | Element that shows the purpose of this particular page in your application. The page title and document title give users a complete sense of this page's purpose in the application. |
| Logo | This small element can tie related applications together. For example, you might use the same logo for all applications for a particular division or for all applications of a particular time, such as personnel applications. |
| Author information | This can be important information for your user. It should include both content and technical contacts, if they differ, for an application. The use of "mailto" tags can be helpful by providing a contact for further information or clarifying the use of your application or a particular page. |
| Revision date | In a medium like an intranet, it is important for your users to know how old the content on your page is so they can judge its value to them. |
The same principles apply to HTML forms and the output they produce. If you send a series of forms, you should give them a consistent look and feel. The user should find related elements together on the form and should find similar elements on the same section of each form. If you will be integrating your forms into a larger set of Web pages, you might want to design your page template such that both informational pages and forms can appear on the same template.
Be sure always to give your users positive and complete feedback from a form action. For example, if you store information as a result of a form submission, make sure to inform your users of that fact. Also give them somewhere to go from your feedback page without having to use their return button. You should use your standard application page template to display the feedback information if possible. This way, your users will have access to the navigation buttons that you have included in your application.
Designing a Web application is much the same as designing a book or other publication. The same graphic design principles apply to what is essentially an electronic version of the printed page. Consistency and predictability are important to any well-designed information system.
Unlike typesetting, in which you have absolute control, on a Web page, you only suggest some of the elements. For example, you have no control over the aspect ratio of the end user's screen. You also have no control over the type face or size that they choose for their browser display. In many cases, the user can override backgrounds, turn off graphics, and do other things that lay waste to your carefully designed pages.
Enabling the user to carefully plan and extensively test your pages on different equipment with different tastes and different software can at least alert you to some of these problems. Also, design your pages so that they are best viewed on the most common equipment and software in use on your intranet. Then make sure that they are at least usable on other common types of equipment available to the intranet users. For example, you can choose to use for your main application frames that are available on some browsers but not supported by all browsers. If there are also users who must access your pages with browsers that are not capable of viewing frames, provide a non-frame version of your pages. This way, all users who must access your pages can at least get to the information they require, even if it isn't as well-organized as it might be in the frames version of the pages.
On an intranet, you might have some control over the equipment and software used if your company enforces standards for these things or purchases browser software at the corporate level. If appearance is vital to your application, you might want to consider writing for a specific browser and then distributing that browser to the users of your application.
Graphics can be the most interesting part of a Web application. If you design for the public Internet and need to attract visitors, "sharp" graphics can do so, but intranet Web applications are intended to impart specific information or perform specific functions. Graphics take a long time to send across the intranet, especially if the end user has dialed in.
To make sure that every graphic is worth the transmit bandwidth time, consider the following. "A picture is worth a thousand words" is the old adage, but the new Web-based adage should be "Is a picture worth the bandwidth?" At six characters per word, your thousand words will take up about 6,000 bytes. Graphics to display the same idea can be much larger-in the range of 10 to 60K bytes. In an intranet application, your users expect to get the job done in a minimal amount of time. The rule of thumb is use graphics only if they convey important information for your application.
Here's an example. Let's say your application creates a table
of information that you want to display in a graph. You could
design a program to create a graphic based on this information
to display to the user. A better solution might be to design your
application to create a spreadsheet that you can transmit to your
user and to activate their spreadsheet program once it is transmitted.
You could even include a small macro with the spreadsheet to graph
the information automatically.
| NOTE |
Evaluate each graphic for its information content. If you cannot succinctly state the purpose for this graphic in your application, consider removing it. |
Look at large graphics to see whether they can be as effective if you reduce them. Also, if you use 16- or 24-bit graphics, consider converting them to eight- or even four-bit graphics. With many business graphics, such as charts and graphs, eight-bit graphics are just as effective and will greatly reduce the transmission time of the page.
If you use graphics, keep the style and placement consistent between pages. Graphics can be great devices to help users feel comfortable with your application. A small "banner" graphic can help tie pages together. This will give your users the sense that your application is unified and will help them find information on the page.
The consistent use of icons can also boost the effectiveness of your Web application. Use consistent icons across related applications. If your intranet spans national boundaries, though, remember that not all cultures share the same history. An icon that is meaningful in one culture might be completely obscure in another. If you write for an international intranet, be sure to test your icons with all cultures involved. Figure 4.8 shows a set of public domain icons that you can use in your applications.
Figure 4.8 : An effective set of icons can enhance your application greatly.
Graphic design for a Web page is much like graphic design for a book or magazine. Many of the same design principles apply to placing graphics and using white space. The CAIM style guide has a good discussion of design principles.
When designing your Web application, always give your user a text alternative to graphics used as navigation buttons or image maps. If their time is critical, many users prefer to turn the graphics off on their Web browsers. This greatly decreases the transmission time for your application pages but can wreak havoc on your image maps or carefully crafted navigation icons.
Always code the ALT= parameter on images. This parameter should include the text version of buttons, for example:
<IMG SRC="nextpage.gif" ALT="[Next Page]">
Make sure that the text on your pages can stand alone and perhaps provide an ALT tag for graphics to give the user without graphics some sense of what they're missing.
Image maps can work as excellent graphic guides through your application if they make sense, though these large complex graphics often require a long time to download. If you provide a graphic image map for navigation, place a row of text buttons below the image to provide an alternative. For example, just below your image, you might provide
<A HREF="nextpage.html">[Next]</A> <A HREF="prevpage.html">[Previous]</A> <A HREF="homepage.html">[HomePage]</A>
Often programmers make the common mistake of using graphics that are too wide to fit within the browser's default window. Graphics that spill off the screen look bad and can hide essential information. Most personal computer monitors currently display 640´480 pixels on 13- to 15-inch screens. Macintosh and Windows versions of Netscape and Mosaic both default to a window size that limits the horizontal display area of Web pages to about 500 pixels. To prevent top title banners or other wide graphics from spilling off, the graphics' horizontal measurement should not exceed 470 pixels. This leaves sufficient visual relief on both sides of the graphic and ensures that users with the most common monitor sizes will not have to scroll horizontally to see your full graphic.
By transmitting the width and height information in the anchor reference to an in-line graphic, Netscape or other browsers can instantly create a bounding box for the graphic without examining the whole graphic to determine size information. Width and height statements are added just after the standard IMG in-line image tag. Web viewers that do not support this HTML language extension will simply ignore the width and height tags:
<IMG SRC="LARGE.gif" WIDTH = 412 HEIGHT=137>
When the browser creates the image box, you can accurately place the text before completely transmitting the graphic. With large graphics, the user can start to read the information without interruption or having to wait for the graphic to fully transmit, making your pages appear much faster than they actually are.
An internal TCP/IP network or intranet can be a valuable infrastructure to tie an organization together. Intranet-centered applications can provide information to the organization in a common convenient format such as a Web browser. However, like applications written for the public Internet, these applications require careful planning and programming to ensure their integrity and usefulness. In this chapter, you learned several intranet programming issues and have learned several strategies and suggestions for dealing with these issues. Apply these strategies and suggestions in a structured design and programming environment and treat the intranet applications as you would any other corporate information technology resource, and your intranet applications will serve your organization well.