This chapter is about the process by which you will plan your Intranet. Although you will no doubt find your design will change as you actually implement your Web, and the people who use it will want further changes, you should nevertheless go through this process before you begin the nuts-and-bolts work of putting it together. Planning your Intranet now will result in building it more effectively and in less overall time. To this end, we'll assume in this chapter only that you have used a World Wide Web browser (such as Netscape or Internet Explorer) and that you therefore have a general familiarity with the Web as a whole.
You'll find these subjects are closely interrelated, and that your decisions in one of these areas inevitably affect the others. As a result, the process of designing an Intranet won't turn out to be the straight-line process these bulleted items seem to suggest.
This book uses the term Intranet to refer to organizations' internal use of Web and Internet technology to efficiently share data and documentation. The whole purpose of the Intranet is to encourage and facilitate easy communication among employees so that they may go about their essential work more rapidly. Proper use of the Intranet can simplify many work processes and improve the goods and services produced.
In the rush to get on the Web, most organizations think in terms of making information available to people outside the organization. Many companies have installed Web servers and made them accessible on the Internet with the idea of making corporate information available to others or of selling things on the Web. Interestingly, though, the initial objective of the Web pioneers at the European Particle Physics Lab (CERN) in Geneva, was to create a means by which CERN scientists could more easily share information. Thus, the first Web was, in fact, an Intranet, designed to distribute information within an organization to the organization's own people. Without detracting from the proven business value of World Wide Web services in making information available to those outside organizations and companies, this book focuses on how purely within an organization, Web and related technology may be used to further the purpose for which the organization exists.
Given this premise, the definition of those who will use your Intranet is sharply different than that of those who use a company's public Web. Traditionally, when a company sets up a Web server, the intended audience is one or more of the following: the general public, current and future customers, stockholders, and even competitors. What all these have in common, of course, is that all of them are outside the business. Figure 2.1 shows a typical business home page offering public information, news releases, and the like about a major computer company.
Figure 2.1: The Apple Computer home page.
Although many of Apple's employees might have an interest in this Web site, you can see that its primary focus is on presenting information to outsiders. General information about the company is available, as are public news releases about company earnings and activities. There's even a page about the company's people and its community service activities, and another about company environmental activities. Both contain valuable public relations information. Clearly, the potential audience of this Web site is external to that company.
By contrast, Figure 2.2 shows the home page for the University of Kansas campus-wide information center. Here the focus is on those people inside or closely associated with the organization: students, faculty, and administrators of the university. You see information about the university's campuses, calendars of events, course listings and schedules, departmental and campus organization information, and information such as the campus phone book.
Figure 2.2: KUFacts, the University of Kansas Online Information System.
Although there's no doubt some of the information available on
this Web server would be useful to people outside the university,
its primary audience is clearly campus insiders. The campus phone
book or the football schedule may be of wider interest. On the
other hand, the History Department's schedule of classes is probably
of interest only to a few history students at the university who
are trying to fulfill graduation requirements and/or fit a course
into their schedule.
| Note |
You'll note the decidedly nongraphical approach taken by the university's Web site. KU is the home of Lynx, a text-only Web browser that is freely available and widely used. Nongraphical browsers are important in situations in which users have dumb terminals or other nongraphical devices that cannot display the images and other graphical features of the Web. Many times, even users of graphical browsers will put them in text-only mode for better performance, as graphics take longer to transfer over the network. Intentionally unable to support graphics, Lynx and other plain-text browsers provide the ability for users to follow hyperlinks, download files, send e-mail, read and post Usenet news articles, and access other Internet services, pretty much just as the more fortunate of us who have access to Netscape or Explorer. More information about lynx is available at http://www.ukans.edu/about_lynx/about_lynx.html. |
The distinction between the intended audience of the two Web servers you've examined should now be clear. When you begin to consider the design of your Intranet, your first consideration must be a clear definition of your intended audience, your customers, if you will. As you've seen, KUFacts' customers are clearly different from Apple's. The university's primary business is education and research, with its primary customers being students, educators, and researchers, all of whom are members of the organization. KUFacts supports those business objectives by providing information services primarily to those customers. Apple's primary business is selling computers; its Web site customers are primarily the very same people who consume the company's products, the vast majority of whom are outside the organization.
Although your company might already have a World Wide Web server with a constituency similar to Apple's, your Intranet will take on the primary characteristics and orientation of KUFacts. Your organization's primary business might be the manufacture of ball bearings, the provision of health insurance services, or the payment of government benefits, but your Intranet's customers are not the same as the customers who buy or receive those products and services. Rather, in this case, your customers are the people inside your organization. Further, your customers are the people who make those products or provide those services.
These are critical distinctions that must be kept in view when
conceiving and designing your Intranet. How you design your Intranet
and what information it contains must be based on your target
audience-your customers on the inside. Later in this chapter,
we'll consider further focusing of the definition of this audience.
| Note |
This book uses the term customer from here on to refer to the people inside your organization or company who will use the Intranet. |
There are many business aspects to an Intranet. Your company provides services for one or more kinds for its employees (customers). These services may cover a wide range:
In fact, most large businesses have a formal or informal organization that reflects these services, with Material and Logistical, Human Resources, Information Systems, and other similar departments providing services to insiders. Whether your organization is a small shop, multinational corporation, government agency, or other institution, one of its business activities is the provision of these kinds of services. Looking at them is the first major step toward defining the content and layout of your Intranet.
Occasionally, this book takes a frank, customer-is-always-right point of view. Just as your business is all about selling goods or services to your outside customers, your Intranet is all about doing the same with your inside customers.
We've just cast the people in an organization as customers of some of the organization's goods and services. In addition, we've likened the provision of those goods and services as a business activity. Let's now bring those two ideas together by thinking about the sorts of things that might go into an Intranet. Just what specific things among those goods and services might fit? Consider this question using the major breakdown of business activities listed previously.
Whether or not your company has a formal personnel department, you know there is a great deal of paperwork involved. Much of that paperwork is information your customers (remember, employees) need. There are, just to name a few:
Here is a veritable treasure trove of information for an Intranet! Imagine how your Human Resources department might provide these kinds of information in a better, more up to date, and more easily accessible way with a World Wide Web server. You might even already have some of this information in some kind of electronic form. (Part III, "Setting Up Office Applications," discusses the conversion of existing electronic data for use on your Web server.) Employees then can use their Web browser to retrieve for themselves current copies of the documents you've previously stored in file cabinets-saving enormous amounts of time and money for both the employees who publish the information and those who need to find it and consult it.
For example, suppose an employee wants to know whether the company health insurance plan covers a particular surgical procedure. If the health plan brochure is available on your Web server, the employee can look it up herself at her own convenience and in a confidential, private way. Also, the employee nearing retirement age might want information about the pension plan, possibly even a benefit computation. Why not make it possible for him to get this information himself? Similarly, how about giving your people the opportunity to file trip reports, including requests for reimbursement of travel expenses, or apply for a job vacancy? How about the company phone book or the old-fashioned suggestion box?
Your Personnel department is a rich source of information for your Intranet.
Every organization, large or small, provides to its customers desks, telephones, computers, office supplies, trash removal and cleaning services, and a whole host of other related services. Fire extinguishers are serviced, parking lots and sidewalks are maintained and cleared of snow, mail is picked up and delivered, equipment and furniture is moved and repaired, and goods and services are purchased. Records are kept of all these things, some of which (Occupational Safety and Health Administration records, for example) are required by government agencies.
Here is another source of information and services your Intranet can provide. Here are some possible examples:
As you can see, these can range from administrative trivia (locating a used file cabinet) to essential company services. The last idea listed is especially intriguing. You've seen fill-in forms on the Web that allow you to sign electronic guest books and do searches on the Web using Web search services such as Yahoo (http://www.yahoo.com/) or Lycos (http://www.lycos.com/). Because a fill-in form is merely a means of collecting information and passing it off to a computer program for processing using the Common Gateway Interface, or CGI, you can now provide a Web interface to a plethora of services that must be requested. Bureaucracies already have hundreds of forms employees must fill out to get things or to get things done.
HTML forms can be generated in a few minutes with very few lines of simple code. (See Chapter 5, "What You Need to Know About HTML," for several examples.) When backed up with a fairly simple CGI script or database connection, HTML forms can take the information the user enters and e-mail it to data entry personnel in the Purchasing department. (See Part IV, "Advanced Intranet Publishing," for all the relevant techniques.) With a more elaborate back-end CGI script the very same simple form could be used to enter the order directly into an electronic ordering system, debit the orderer's charge code, update company inventory if the order is for capital equipment, and fire off return e-mail acknowledging the order. In fact, leaving questions of authorization aside, the information in the fill-in form could just as easily be sent via Internet e-mail or fax directly to the supplier, bypassing company purchasing altogether (though, probably, you'd want the program at least to leave a copy for them).
Your organization's Information Systems department, if you have one, is already in the business, at least in part, of providing data processing services to customers inside the company. (We use the term Information Systems Services here to mean any information your organization has stored on computers, all the way from the MIS mainframes to your desktop pcs and any services these computer systems provide.) As a result, you'll find crossover between Information Systems Services and the two other broad categories we've drawn in this chapter. Your Personnel department, for instance, surely uses some data processing services in doing its work whether those services are on the company mainframe or on desktop pcs. In fact, all the potential customers of your Intranet, because they must have computers to access it, are already users of some of these services.
Accordingly, perhaps here is your most fertile source of resources for your Intranet. These services will then form most of the meat of your Intranet. Let's look at some ideas, all of which are covered in detail in later chapters.
As you've read this section, you've no doubt thought about existing Information Systems resources in your company that might be made accessible on your Intranet. Just this brief listing of possibilities can lead you to think about legacy information (that is, existing documents and other data) that will be an immediate source of data you'll be able to tap to get your Intranet up and running quickly.
We now move from thoughts about the substantive content of your Intranet to those of organizational responsibility and design. In earlier years, when MIS departments had a monopoly on data and data processing, it would have been easy to assign responsibility for Intranet setup and design: The MIS Department would do it. Today, though, the Web is based on distributed computing, and MIS probably can't control everyone's desktop pc or workstation. This presents a terrific opportunity for the consumers of Information Systems Resources, who presumably know the most about what they need to take an active role in the design and construction of your Intranet. Neither Web server setup nor the Hypertext Markup Language are rocket science. With the freely available Web server and supporting software on the CD-ROM, it's easy for almost anyone with a pc or workstation to create a Web home page and make it available.
This ease of setup can be both a blessing and, the MIS folks will quickly remind you, a curse. If anyone can set up a Web server and/or a home page, who will control your Intranet? This question is valid not only from an authoritarian point of view (after all, people are supposed to use their computers to do their jobs) but also from other points of view as well. Here are some issues you might have to deal with:
If you've used the World Wide Web to any extent, you've recognized it as the world's largest vanity press; people can, and do, put anything they want on it. This is a sword that cuts both ways. You can find truly amazing (in all senses of the word) things on the Web, many of which may be offensive (again, in all senses of the word). How you feel about this sort of anarchy will inevitably color how you approach assigning responsibility and setting standards for your Intranet. At the same time, the fundamental nature of the Web as a distributed service provides unparalleled opportunities for individual and organizational development, and imposing a rigid, authoritarian structure on your Web might well inhibit the sort of creativity that can bring about breakthroughs in your company's work.
Based on the philosophical approach you decide to take in assigning responsibility for your Intranet, there are several models you can follow. Here are three:
In this top-down model, all Web services are centralized. Just one computer system in your company runs a Web server. You have a specific individual or group responsible for the setup, design, and administration of the server. All Web pages (documents, forms, and so on) are designed centrally at the request of customers. Thus, if the Personnel department wanted to put employee benefit information on the Web, a formal request would be required, including content and design requests. The Web staff would, in consultation with Personnel, design and refine the employee benefits page and once the process is complete, make the page available on the Web server. Figure 2.3 shows the centralized model of Web administration with all Web-related development funneled through an approval process before any information is placed on the central Web server.
Figure 2.3: The centralized model of Web administration involves a controlled Web server.
There are a number of good reasons this approach is sound. First and foremost, by focusing Web server administration, page design, and production in a single person or group, it provides the opportunity for you to develop a consistently designed Intranet. You can develop and use common Web page templates to ensure layout consistency as well as a standard set of substantive and navigational images. Users will see a coherent, well-thought-out Web server with each part consistent with your overall design, layout, and content standards.
Another strong argument in favor of the centralized model is that it simplifies the setup and administration of your Intranet. Only one computer system runs the server. All updates, both Web pages and server software, need to be applied only once. Security (see Chapter 10, "Intranet Security in Windows NT") can be focused on the single machine, which can also be physically secured. Backups are easy to do because everything that needs backing up is on the one system.
Unfortunately, there are equally strong reasons this approach is the wrong one to take. From a philosophical point of view, it runs counter to pretty much everything that's happened in data processing over the past two decades. With the rise of the personal computer and workstation, data processing has moved out of the glass-walled MIS data center and onto people's desks. Taking the centralized approach to your Intranet might satisfy the MIS diehards, but it also contradicts everything the Web stands for.
More practically speaking, bureaucratized administration of your
Intranet's development can choke it to death before it ever gets
off the ground as endless memoranda about "standards"
circulate before any real development takes place. Your primary
objective in setting up an Intranet is to get information to your
customers. Centralized administration can easily get bogged down
in organizational and turf matters, cutting off the potential
of rapid response to your customers.
| Tip |
It's useful to note in this connection that because your target audience is inside your company, not outside, the standards you'd apply to the former will probably be very different from those for the latter. The employee looking for help in setting up his pc probably doesn't care whether the help document he finds on your Intranet has the correctly proportioned corporate logo on it. Rather, he's interested in the substance of the document. Your company's outside Web server, aimed at a completely different audience, can-and probably will-be subject to a more rigorous set of standards. |
Finally, the centralized model places all your Web eggs in a single basket. If the computer system running your Intranet server goes down, everyone is cut off. This policy requires a decision between potentially expensive downtime and expensive duplicative hardware-another hot, spare computer ready to run in the event the main system goes down. This adds not only the extra cost of the hardware and software for the system but introduces a new aspect of the administration of the system, that of making sure all changes to the primary system get mirrored to the backup.
At the other end of the spectrum lies the decentralized model. Web server software is widely available both commercially and as freeware or shareware. The software runs on desktop pcs. This software is relatively easy to set up and run. HTML, the markup language used to create Web pages with all their nice formatting and image and hyperlink capabilities, can be picked up by just about anyone in a couple of hours. Using free software or shareware, some of which is included on the accompanying CD-ROM, even a moderately experienced pc user can have a Web server up and running with some HTML documents in an afternoon. Figure 2.4 shows the decentralized model of Web administration with users free to develop their own Web documents and even set up individual Web servers.
As with the centralized model, there are strong and weak points to this one. The most compelling argument for this model is that the user who sets up her own Web server (and who is also, you should be reminded, one of your Intranet's customers) might be the single best person to do so because she knows precisely the service she wants to provide with it. That is, if an engineer wants to share engineering drawings and technical reports with her colleagues, she and her colleagues are in the best position to decide what is to be shared and how it is best presented. In the centralized model, this customer with information to share has to negotiate the standards process before being able to get the information to her colleagues. Similarly, the Personnel Specialist who has new pension information to make available, or the Office Manager announcing the staff holiday party, is more concerned about getting the information posted than whether it's properly formatted according to some standard or whether the proper colors are used in the corporate logo.
In other words, the main advantage of the decentralized model
is that it allows those who have information to share to share
it quickly and with a minimum of fuss. If you're running a Web
server on your pc, for instance, you can put up a new Web page
on some subject in your expertise in just a few minutes. This
is also the main disadvantage of the model. The fact that it is
so easy to set up Web pages lends itself to what may best be termed
anarchy, with users putting up related or unrelated (who
decides which is which?) Web pages all over the company. A casual
walk around the World Wide Web shows how this anarchy can and
does lead from the sublime to the absurd to the obscene.
| Tip |
It's important also to note that the overall tone of a Web server can lead to increased or decreased support from both its customers and its sponsors. Too much anarchy often turns users off, and they just stop using the service. And, of course, there are few things that could be worse for the overall health of your Intranet than to have the president of the company stumbling across a particularly inappropriate or offensive link on some part-time employee's home page. |
The nature of your organization will help you evaluate this model. Academic and research institutions might find the intellectual freedom of their researchers outweighs the high noise level of the Web created under this model. Businesses might want a tighter focus on the work at hand, finding this sort of anarchy has too much potential for abuse and/or misdirected time and effort.
Somewhere between these two extremes is probably where most organizations will land when setting up Intranets. For example, you might want to establish a broad policy that your Web's primary purpose is to support a specific group of your customers and that anything consistent with that purpose is permitted. In this case, you'd rely on that part of the centralized model that dictates the overall direction and purpose of your Web but use those aspects of the decentralized model that leave most details to your customers. There will inevitably be gray areas or even outright violations of the overall policies, but you can deal with them on a case-by-case basis as management issues, just as you do with, say, misuse of company telephones or time-and-leave abuse.
Please don't make firm decisions on a model for administering your Intranet quite yet. You still need to focus on its primary objectives, and doing so will help you focus your decision-making on these administrative issues. In the following sections, you'll look at these questions as well as lay out some of the technical possibilities for implementing the mixed model.
Having considered the foregoing administrative matters, let's now turn to more interesting things: the substantive design and content of your Intranet.
You probably bought Building an Intranet with Windows NT 4.0 because you had some idea of what you might be able to do with an internal corporate Web server. So far in this chapter, you've established a framework that should help you bring your ideas into clearer definition. We first brought out the concept of thinking of the potential users of your Intranet as customers and provided some possibilities based on this concept. Next, we discussed some of the high-level administrative aspects of setting up and running an Intranet. By now you perhaps have a clearer focus on who your potential customers are and some definite ideas on the sorts of information you want to make available.
Putting your ideas together into an Intranet Statement of Purpose is your first concrete step toward realizing your ideas. Let's look at a few example Statements of Purpose, based on the possibilities listed under the previous heading Information and Services Your Customers Need:
As you can see, each of these is both specific and limited. Developing your Statement of Purpose allows you to define the task ahead of you in terms both you and your potential customers can easily grasp. There is, of course, no reason you can't write a larger Statements of Purpose incorporating several of these (or other) purposes, such as "Provide customers with Human Resources and information system services using World Wide Web technology". Such a far-reaching Statement of Purpose is certainly acceptable, provided of course that you're able to clearly define the objectives that fall under it, possibly using lower-level Statements of Purpose for each of the major subdivisions, Human Resources and Information Systems. Some people might want to start out with more limited Statements of Purpose like those listed and then expand on them later. The method you choose depends on your own ideas about what you want your Intranet to accomplish.
Besides giving you a pole star toward which to steer in developing your Intranet, your Statement of Purpose also implies some substantive choices about the work you're cutting out for yourself. For example, it's one thing to take a batch of Microsoft Word documents and put them up on a Web server as a boilerplate library (see Chapter 13, "Word Processing on the Web," and Chapter 25, "Intranet Boilerplate Library") for customers to browse and grab. Most computer-literate people can put such a library together and generate the HTML code to index it. It's quite another thing, though, to develop the CGI scripts to back up forms-based data entry and retrieval. (See Chapter 16, "Linking Databases to the Web.") The order form example mentioned earlier in this chapter is quite simple, but the program that it executes will not be. You'll need competent programmers to write the scripts in whatever programming language you choose on your system.
Once you have a Statement of Purpose, particularly if yours is a broad one like the one mentioned, you'll need to develop more concrete implementation goals, or specific objectives of the information and services your Intranet will provide to your customers. Following the Employee Benefits Statement of Purpose, you might, then, define a series of goals:
Your implementation goals can now be translated into clusters of specific tasks to be performed in order to implement and manage them. For example, if your job vacancy announcements are created using your word processor, they can be quickly saved in plain text form (or converted to HTML by a conversion package) then placed on your Web server. As they expire, old announcements can be removed and replaced by new ones. You'll need to designate someone to be responsible for managing the job announcements and, if necessary, train them in using HTML. Depending on the administrative model you've chosen for managing your Intranet, you might also need to train the individual in the process of actually placing the job announcements on the Web server so they become available.
As you develop your overall purpose statement and implementation goals, bear in mind that once a Web server starts getting hits (that is, customers start using it), you and they will start thinking of new ideas you could implement using Web technology. Accordingly, you shouldn't cast your plans in stone. Rather, you'll want to leave room for evolution. Good ideas often beget other good ideas, so don't lock yourself out with a purpose statement that's too restrictive to allow new goals.
The job vacancy announcement goal example used above is a good illustration of how such a seemingly specific goal might evolve over time. You might start out with simple one-line announcements and find customers wanting more information about the positions. Adding more details to the announcements helps, but sometimes people want to be able to communicate with a real person to ask questions not covered in the announcements, so you add contact information to the announcements. Later, someone asks about using the mailto Uniform Resource Locator (see Chapter 5), and you realize you can add hyperlinks to the job announcements that allow your customers to send e-mail to the contact person just by clicking a hyperlink. Still later, customers ask why they can't just go ahead and apply for the job directly using a Web fill-in form. So it goes.
With your Statement of Purpose and implementation goals ready, you can turn to the design and layout of your Intranet. It's useful to break this process down into two related pieces: logical and physical.
The logical design and layout is the process of arranging the
information on your Intranet according to some overall plan. (Later
you'll see you can reflect your logical design in your physical
design.) Just as I begin the process of writing a book by organizing
material with an outline, with major subjects placed into some
sort of logical arrangement, your Intranet design should begin
with some organizational layout. The information you're planning
on placing on your Intranet often naturally breaks down into logical
chunks, so you can reflect these natural divisions in its logical
design. In fact, you might do well to start out with a traditional
outline of the material. From the Statement of Purpose, you can
generate a brief outline. Look at the following example.
Provide Customers with Human Resources, Materiel and Logistics, and Information System Services Using World Wide Web Technology. Building and grounds plans Looking at this short summary outline (most of the details have been left out for space reasons of course), it's easy to see how you can organize the overall logical structure of your Intranet. Let's collapse this outline into major functional areas to make this clear. ABC Company Home Page Provide Customers with Human Resources, Materiel and Logistics, and Information System Services Using World Wide Web Technology. Major Subdivisions of this Web: Human Resources information |
You've laid out not only the overall design of a Web, but all but written its home page as well. Using WebEdit (on the CD), you can lay this out as a home page. You don't really have to know HTML to accomplish this because the Home Page Wizard in WebEdit makes it pretty easy. After a few minutes of tinkering, I came up with the sample home page for ABC, shown in Figure 2.5. (Chapter 5 covers installing and using WebEdit.)
Figure 2.5 : After creating a simple Intranet home page in WebEdit, you can view it in Explorer.
| Tip |
Your network capabilities and customers' hardware capabilities can provide important cues to help you in your Web's logical design. For example, if all your customers have high-speed (10 Mbps) LAN connections and graphical Web browsers such as Explorer or Netscape, you can take full advantage of graphics in your Intranet. If some of your customers have modem dial-up connections to your network through Windows NT Remote Access Service (RAS), you'll want to downplay graphics for performance reasons. |
Within this design, as you no doubt have guessed, each of the ABC Company's major subdivisions also has a home page with the information and services to be offered. This is a simple hierarchical design, and for purposes of the sort of high-level layout you're considering here, it's a good way of beginning your own Intranet design. Within your Intranet, though, you'll want to take advantage of the ability to create hyperlinks to other pages so your customers can get around easily and intuitively. Rigid adherence to some purely hierarchical design can limit you in Intranet design. Books are usually designed to be read sequentially, page by page, from front to back, and hierarchical design is apparent in such an arrangement. People who pick up a book expect this arrangement.
On the other hand, the World Wide Web, as you know, has introduced the concept of hypertext, a most assuredly non-hierarchical element. Through the use of hyperlinks, users can jump from place to place on the Web with little attention to page hierarchies or other structure. As a result, Web pages (and Web servers themselves) lend themselves to more human design. Users follow hyperlinks based on their own interests, predilections, and the needs of a given moment.
As you design your Intranet, the nice, neat hierarchical design you might lay out at the top level can handcuff you once you get down into the actual meat of your Web. You'll want to therefore be receptive to the use of nonlinear design as your Intranet develops. It's probably a good idea, for example, to include hyperlinks on pretty much every page (or every major page, at least) that allow the customer to jump back to the top-level page from anywhere without having to backtrack. Cross-references among documents are also great things to use as hyperlinks. If a document mentions another document, the user may want to see the referred-to document, and a hyperlinked cross reference allows this.
At the same time, your overall design decisions can set limits on where hyperlinks might take your customers. Many people like hypertext because it seems somehow more like how they actually think, but others are more literal in their thinking and prefer a well-organized, hierarchical structure to things. In either case, total reliance on hypertext features without any overall organization can lead to confusion and frustration and to the loss of your Intranet's customers. This is one reason that it is critical for you to involve your customers early in the process of designing your Intranet, as well as keeping them involved with a feedback loop. It's difficult, if not impossible, for you to anticipate what your customers will and will not like about their Intranet, so it's critical you get them involved in issues like design and layout. I'll go over these topics more carefully in Chapter 4, "The People Skills to Make it Work."
There are a number of ways to lay out the physical aspects of your Intranet. Your decisions on the administrative and logical aspects discussed in this chapter can give you important clues here as well. As suggested earlier, when discussing the centralized model of Web administration, a single computer running Web server software lends itself well to the administrative model selected. If you're using this model, you need not be concerned about the physical layout of a Web in which multiple servers in multiple locations operate; your server is inside a secure room, accessible only by its administrators. All your Web pages, and all the administration and configuration of your server, takes place in one location. This vastly simplifies server administration, maintenance, system backups, and, of course, server security.
Paradoxically, the decentralized model of Web administration, where anyone is free to set up and maintain their own Web server as part of an Intranet, is also simpler for you to administer. That is, you don't. Just by making the administrative decision that any user can set up a Web server and place anything on it, you've washed your hands of all these issues of physical layout, design, and server administration. Users are free to set up servers, placing documents on them according to whatever logical design they find applicable, and are responsible for doing so, as well as for maintaining their servers and documents. Any central administration can be limited to maintaining an overall home page for your Intranet with hyperlinks pointing to all the other servers. This administrative (and physical) layout can further suggest hardware and software requirements: if all your central Web server does is serve a home page with links to other servers, you don't need a powerful computer to run it.
As you can probably surmise, the mixed administrative model provides the most flexibility in both the logical and physical layout of your Intranet, while retaining your ability to manage its structure. For example, you might design an Intranet with a main server and several departmental servers. The sample Intranet used in this chapter lends itself to this setup. Each of the major subdivisions of your Intranet, corresponding to the major administrative departments of the ABC Company, can be hosted on a separate computer system running Web server software. Thus, the Personnel department would run and manage a Web server devoted to Human Resources, while Material and Logistics would run another. Having delegated the administration of those logical pieces of your Web to the departments, you can also, if you choose, delegate the physical ones. As with the decentralized model, this choice can impact your needs for hardware.
Personnel might not want the responsibility of physically maintaining a computer system, however. The decentralized model can still allow the logical layout of your Web to allow Personnel to maintain its own substantive Intranet content. The HTML language is not difficult to learn, and ABC's departments could share a single computer system running a Web server physically maintained by a dedicated individual or staff but still maintain their own documents on that server. HTML documents can be created and/or edited using almost any editing tool on desktop pcs and then uploaded to your main Web server. You can even use file-sharing mechanisms to make Web server administration completely transparent. Through appropriately secured use of the NT file system, your Web server's directories can be shared so users see them as local volumes with HTML documents directly accessible for editing. As far as the user is concerned, he's just creating or editing documents on his own pc, yet the documents are available to everyone else on your Intranet.
As with most three-choice models, your actual implementation of an Intranet is unlikely to be as clear cut as described here. It should seem clear to you that the mixed model described is what we would recommend, but there are virtually infinite variations possible. The nice, neat, logical, and/or physical division among ABC's departments probably won't fit your needs. It's more likely that Personnel will need one sort of setup, whereas Engineering might need a completely different one because the two groups have different skill sets and interests. You might find that one department wants their piece of your Intranet rigidly administered with all sorts of preset standards and procedures, whereas another department wants a completely decentralized model. Fortunately, you can accommodate both. Intranet server design and setup are anything if not flexible, and what you start out with might well change as you gain experience.
In this final section, you'll turn your attention to how you can get your customers to buy into your Intranet. Web technologies, or, more properly, the things that Web technology makes possible, are very seductive. The ongoing explosion of the Internet has been driven in very large part by the Web. People really like using Explorer or Netscape to find interesting things on the Web. As many managers are recognizing, there's a seductive, recreational aspect to the World Wide Web, as the widely used terms playing Web and surfing the Web indicate. The Web, in large respect, sells itself. This book is about using this seductive technology on an everyday basis in your company's work.
This might seem a no-brainer. After all, your Intranet is for people within your company. Although this is generally true, a closer look reveals the fact that you need to fine tune your definition. First, unless everyone in your company has a computer (or access to one) your audience is immediately defined as the group of users who will have some sort of access to your Intranet. Even this, however, isn't a true audience definition, rather a definition of your potential audience. You still need to break this audience down based on common characteristics. The kind of work a group of individuals do can help you define their needs as customers of your Intranet. Members of a clerical pool, for example, constitute an audience for the sort of boilerplate library of documents discussed in Chapter 25. Researchers will have more interest in using your Web in their own work, perhaps as an aid in collaboration. (See Chapter 27.) Both these groups, however, fall into the larger audience of company employees with an interest in the sorts of Human Resources and/or Material and Logistics information and services described in this chapter.
Your larger potential audience also breaks down in another way based on the capabilities of the computer hardware they'll use to access your Web. Do they all have graphical Web browser capabilities and high-speed network connections? This question raises further questions that go to both the substantive content of your Intranet and to its physical and logical nature (that is, hardware capabilities and the concomitant limits they may place on the logical design of it). Let's look at how hardware can affect your audience definition and also provide important Intranet design input.
Computer use is widespread, but not nearly universal, in organizations. Millions of people have computers on their desks at work or at home, but millions more don't. This obvious point acts to define your Intranet's audience. Further, though, even among the group of people who do have computer access, there can be a wide variation in both access and hardware capabilities. While some users have pcs with full graphical capabilities, others might be using dumb terminals with little or no graphics. In either case, a number of users may be sharing these seats.
These are important audience characteristics that speak not only to the relative ease by which your customers can access your Intranet but also to what they can see when they do access it. The user with a dumb terminal can't see graphics and can't use clickable imagemaps, so your Web design decisions must take this into account. Do you do so by not using graphics at all, dragging that part of your audience with graphical Web capabilities down to the lowest common denominator, or attempt to design a Web that everyone can use even with their hardware limits? Similarly, if large numbers of your customers share pcs or terminals-on a factory floor, for example-the timeliness and immediacy of your Intranet's information is affected, because not everyone will have easy, immediate access.
As with each of the other major subjects covered in this chapter-Intranet administration and design/layout-the characteristics of your intended audience can provide valuable help in the overall development of your Intranet.
You can help focus your audience definition and generate valuable information that can contribute to the design and content of your Intranet by involving potential customers in its development process using focus groups. Getting your customers involved early-and keeping them involved-generates an investment on their part in your Intranet. This investment will pay dividends by helping you create the right Intranet, the one your customers want.
Before you get your focus group(s) together, be sure you have something to show them. Getting a group of people together to shoot the bull about getting an Intranet going without your first having prepared some sort of presentation, is a poor way of starting out. You might have a few people who have Web experience, and some of them may already have ideas you can use, but as much as two-thirds of your focus group might never have seen the World Wide Web. If you don't have something to show them, they'll have a great deal of trouble understanding what it is you want from them.
To a person with no experience of the Web, even the crude home page shown in Figure 2.5 is a dramatic demonstration, particularly if there are hyperlinks to similar home pages for the major divisions shown on the page and an actual document or two linked into them. Even a simple demonstration can let you use that Web seductiveness we spoke of earlier to spark interest in your Intranet, getting your customers to invest early.
Encourage your demonstration participants to discuss possibilities based on what you've shown them. As mentioned repeatedly, even Web novices know the information they want from their organization. Showing them real information as well as the potential capabilities of an Intranet, will surely stimulate ideas on their part. Your focus group(s), also including your organization's information providers, should provide a lively and useful means by which you'll further define your audience and its interests. This, in turn, will help you pin down the actual kinds of information your customers will want, thereby generating audience investment and support in your Intranet.
You probably already have a good deal of experience with the World Wide Web and have based your own ideas about your Web on things you've seen. If you have good ideas from your own Web experiences, it's a good bet there are others in your company who have them too, or would have if you asked them to think about it. Experienced Web users who are also your potential customers are in the unique position of both knowing a lot about the capabilities and possibilities of Web technology and of knowing what they, as potential customers of your Web, want to see. Get these customers together, informally or in formal focus groups, to talk about your ideas and theirs.
Don't limit your focus groups to those with Web experience, though. The employees of a company or the members of an organization have definite ideas about the information they want. Even if they've never seen a Web browser, they can give you information that's important to your Intranet design. Similarly, don't forget to include people we might call Intranet information resellers. I've used the example of employee benefits and other personnel-related information in this chapter as potential Intranet content. The people in your Human Resources department who provide this information now, and who will be providing it on your Intranet, should also be part of your focus groups. They know the information they provide and probably have a good idea of how often their customers ask for it.
This chapter dealt with the overall process of designing an Intranet and covered a number of major, interrelated, topics, including
For more information on these topics, check out The World Wide Web 1996 Unleashed, by John December and Neil Randall, also published by Sams.net (ISBN 0-57521-040-1). For information on this and other Sams.net books, see the World Wide Web URL http://www.mcp.com.
The next chapter discusses Intranet infrastructure, and the hardware and software tools you'll need to get started building your Intranet.