The Ghost Town Intranet

The "Ghost Town" Intranet

In many Westerns, there's a scene in which the hero enters a long-abandoned town. There are buildings there, but the paint is peeling, doors are falling off their hinges, the windows are broken, and the only motion is the tumbleweed rolling down Main Street. Most of all, there are no people there.

This is what the "ghost town" intranet is like. In this section, we'll look at ways of avoiding this fate for your own intranet, by keeping the intranet up-to-date and useful, and keeping page authors in touch with the page readers.

Do you have a "ghost town" intranet?

Some symptoms of a "ghost town" intranet are:

• None of the pages you look at have been updated in the last 6 months.

• There are broken links on numerous intranet pages that once linked to internal and external pages.

• It's not easy to contact the author to ask them to fix problems with a web page, or to obtain more information.

Maintaining the Intranet

Basic maintenance to the intranet can have a large effect on its perceived usefulness to readers, and on the willingness of authors to contribute to it. If there are broken links or outdated pages linked to or from important pages like the homepage, then it immediately devalues the intranet in the eyes of its users. In this section will look at how to reduce these problems.

Broken windows and broken links

Police officers have noticed that if one window in a building is broken and is left unrepaired, then it is likely that the other windows in the same building will be soon be broken. This is because a broken window sends out the message that nobody cares about the building, and there is no community that maintains high standards.

The same idea can be applied to the intranet. If there are no broken links on the homepage of the intranet, and one appears, then it will be immediately reported by numerous intranet users. On the other hand, if there is an expectation that the intranet is poorly maintained and much of the intranet is out-of-date and contains broken links, then any additional broken links are likely to be ignored. Likewise, intranet authors are less likely to check their work thoroughly, and to make sure that it is removed when outdated.

Automated tools, such as a link-checker, can help improve the intranet quality, but what's ultimately important is a community of users that values the intranet. If it is immediately possible for users to contact the page owners, for instance with a "Report a Broken Link" facility, and they can see their comments leading to a rapid improvement, then it is a sign to users that the intranet maintainers consider the intranet to be important and worth maintaining.

Keeping Links Valid

Links to other resources, both internal and external, are very useful on an intranet, but also tend to become broken over time as URLs change, web sites change name, and content is removed from the intranet. To keep the intranet useful, you need some way of detecting and fixing this problem.

Most CMS systems have some sort of automated link checker built in. If your CMS doesn't, or if you are not using a CMS, then there are a number of commercial and free link checkers that you can use. One good, free, cross-platform link checker is the aptly named Linkchecker, available at http://linkchecker.sourceforge.net/, which is written in Python. It shouldn't be too hard to tweak any of these link checkers to automatically contact the page owner when they detect a broken link. (One which already does is Xenu's Link Sleuth - http://home.snafu.de/tilman/xenulink.html).

The drawback of automated tests is that they cannot tell if the page being pointed to is useful, only that there is a page there. If a target page has been replaced by wholly different content, as happens all too often on the Internet, then an automated tool cannot detect this, only a human reader. While automated checks can reduce the problem of broken links, they cannot completely remove it.

Keeping Pages Updated

It's inevitable that pages will become outdated over time. In order to keep the intranet relevant, there needs to be some mechanism for updating or deleting irrelevant pages.

The standard approach is to set an expiry date for each page when it's created. This can be done by the author, or automatically based on the current date (for example, 6 months in the future). The purpose of this is to make sure that the pages are regularly reviewed, so they can be either deleted or updated every so often. The expiry date is stored as part of the page's metadata, and can be acted upon automatically by software.

Most of the time, it's best to have the expiry date set automatically by the content management software (and the CMS should also provide tools that warn of page expiry). Since it's not something that will normally need to be changed, then there's no point making the content author have to think about it - it just makes the page authoring process less usable, and wastes the page author's time as they think about it. However, some areas of the site might have different automatically set expiry dates (for example, a page in a "News releases" section automatically expires after a month, and can be moved automatically into a news archive). There are also some items, like postings of upcoming events that have a known date after which they are no longer relevant.

One possible action when the expiry date is reached is to automatically remove pages from the intranet unless they are updated. Although this is effective in ensuring that only relevant pages are found on the intranet, it has significant disadvantages. Firstly, it runs the risk of alienating the authors of the pages. Secondly, old information may still be relevant, or require only revisions to bring it up to date. If it is removed completely, then useful information will disappear from the intranet. However, in a very large, chaotic intranet, it may be worthwhile to make this trade-off because the useful pages removed will only be a small percentage of the total pages deleted (and if no-one can find the useful pages amongst all the others anyway, then they might as well not be there).

An alternative is to automatically e-mail the page owner when the page passes its expiry date, and keep on sending e-mails until the page is either deleted or edited. As long as there is a simple way for the page author to say "This page is still valid - reset the expiry date and don't bother me until it expires again" then this should help keep intranet pages up to date without imposing an undue burden on page owners.

If pages that are past their expiry date are still visible on the intranet, then there should be some visible indication of that fact - both on the page, and in any search results that list the page. Although the last time that the page was updated should be visible on the page anyway, it's easy to miss that a page is expired unless there's a large, clear indication of that fact.

It should be part of the process of removing a page from the intranet to check that there are no links elsewhere in the intranet to the page that will be broken if it is removed. A CMS will generally have this functionality built in. If the entire intranet is not in a CMS, or if the intranet is in several different CMS systems, then it may still be possible to find the linking pages.

Most web servers will store the URL of the page that was viewed before the current one. In Apache you set this up with the LogFormat configuration variable, while in IIS you can set the log format to "W3C Extended Log File Format" and configure it in the "Extended Logging Properties" dialog.

It's simple to write an automated tool that will find all the logged referrer pages for a page that's about to be removed, download and search each to see if there's a link to the page being removed, and then display each page that contains a link. It is then possible to contact each of the owners of the linking pages and ask them to remove the link (or even remove the link automatically). Of course, this requires that you store your access logs for a long period - or at least, regularly build summary files from them that list the referrers for each page.

Establishing Ownership

Authors are more likely to maintain their web pages if they feel that they "own" the pages. In order to feel a sense of ownership, authors need to be in control of the content to as large an extent as is practical. If an author is given responsibility for maintaining a section of the intranet, but they don't have easy access to the tools needed to update it, or needs to have their changes approved before they are accepted, then they will feel less of a sense of ownership than if they had immediate access to make the changes. The more intimately the author is involved with the information on the pages, the more they will tend to take operational ownership of it. The author also needs to recognize that their work is important to the company, and that the work is valued both by the organization and by the intranet users.

Connecting "Communities of Practice" Via Intranet Microsites

An alternative to having pages on the intranet owned by an individual page owner is to have a section of an intranet, such as a self-contained microsite, owned by a group.

A Community of Practice (often abbreviated CoP) is a group of people who share an interest in a topic, for example a group of HR managers who meet to discuss problems of recruitment, or a group of developers who share tips for coding. In a small company it's easy for these groups to work together and exchange information. In a larger company, particularly one spread across multiple sites or multiple countries, it is much more difficult for these groups to work together or even form, unless supported by communication technologies such as the intranet.

Using the intranet allows the CoP to have a persistent store of information in a knowledge base. It also allows the CoP to organize upcoming events, share news about their field, and other relevant information. It can store a list of CoP members and their contact details to help keep members in touch. It can also host "webinars" and other social functions to provide a social hub that helps bind the CoP together.

Small intranets have many benefits over larger in terms of ownership, trust, and community. You can bring the benefits of a small intranet to a larger intranet by using microsites on the intranet to connect communities of practice. It's much easier to motivate authors to contribute to a small intranet than to a larger one. Reciprocity is more immediate, as each intranet author is aware of who contributed what. It's also easier to build a reputation within a small group, and colleagues are more likely to become friends, and hence share information with each other from altruism.

More information on communities of practice can be found at in the following resources:

• the Yahoo "com-prac" group (http://groups.yahoo.com/group/com-prac/).

• A good book on the subject is "Cultivating Communities of Practice", Etienne Wenger et al, Harvard Business School Press, ISBN 1-578513-30-8 .

• There are links to more information in Google's directory at http://directory.google.com/Top/Reference/Knowledge_Management/Knowledge_Flow/Communities_of_Practice/.

Paradoxically, an intranet may become more useful to its users if access to some areas of it is restricted. It can be worthwhile for teams or communities of practice to have their own private areas on the intranet that cannot be read by anyone, even their managers, outside the team. This is not an approach that will be popular with all organizations, but can be effective if your company's culture allows it.

Normally, authors are reluctant to contribute information to the intranet if they are not certain that the information is correct, because any mistake can be seen by their peers and managers, and may damage their reputation. This reluctance to be publicly wrong can restrict investigation of new ideas, and can prevent others from working with the author to refine their own incomplete ideas. If each author knows that their contributions are only visible to trusted colleagues, then they have the freedom to make mistakes and to learn from them. The content in these private areas can be more experimental and express more personal opinions than on a widely-visible intranet page.

This private information can eventually be made publicly available. Firstly, members of the team can periodically convert their private intranet documents into publicly visible intranet pages. Secondly, it should be possible to identify which private teams are working on which topics through an intranet search. Even though the content is not generally available, an interested intranet user can contact a team member to find out if there is anything relevant to their own problems in the private content.

Contacting the Page Owners

If every page on the intranet has an owner then it should be possible for the reader of the page to contact the page owner. We've mentioned this several times already in this chapter, but we haven't talked about how it can be done or what the problems are.

It is important that the reader be able to contact the page owner because not all information can be recorded on the intranet. There will always be questions that the page author hadn't considered, or weren't applicable when the page was authored, that can only be answered by talking to a human being.

The traditional method of making it possible to contact the page owner is to include their e-mail address in a mailto link at the bottom of each page for which they are responsible. On clicking the link, the reader's e-mail application will open allowing them to e-mail the page owner.

A significant improvement over a simple mailto link is to use a mailto that automatically includes the details of the page at the top of the e-mail. For example, the following rather unreadable link:

 <a href="mailto:[e-mail]?Subject=Intranet query about page titled %22About the Mailto URL%22&Body=Intranet link http%3A//myintranet/info/mailto.htm">Contact page author: Inigo Surguy</a> 

will open the reader's e-mail client with a mail initialized with the subject:

Intranet query about page titled "About the Mailto URL"

and with the body content

Intranet link: http://myintranet/info/mailto.htm

There is more information on the fields that can be added to mailto URLs on Netscape's site at http://developer.netscape.com/viewsource/husted_mailto/mailto.html. Although it's described on Netscape's web site, this technique also works in Internet Explorer and with mail clients such as Outlook and Outlook Express.

As mentioned earlier another approach is to allow users to add comments to a page. As each comment is added, it can generate an e-mail to the page owner, sending the name, URL of the page, and the content of the comment. The page author can then respond by e-mail, by updating the page, or by adding a comment. This way, the usefulness of the page should increase over time, as it can provide the information to anyone reading the page at a later date. On the downside, the public visibility of questions may discourage some readers, so it should be used alongside a mailto URL rather than as a replacement for it.

An approach that can be used in conjunction with the two previous methods is to tie the intranet page into your Instant Messaging (IM) system. When a page reader clicks on a link at the bottom of the intranet page, then it can open an IM window that lets the reader talk directly to the page author.

This approach is more appropriate in a small company, where people know each other well and are happy with the relative informality of using IM. It also gives convenience and a rapid response to the reader at the cost of possibly inconveniencing the page author. Whereas e-mail can be filed to be dealt with later, IM is immediate and insistent. If authors find that they are regularly being interrupted by IM questions while trying to work, then this will not encourage them to write intranet pages in future. We'll talk again about the advantages and disadvantages of IM in Chapter 9.

Providing the author's phone number is another option. Phone calls, of course, share many of the advantages and disadvantages of IM, but are even harder to ignore.

What If the author of the page is no longer at the company, or if he has moved to a different role within the company?

Up until this point, we've been assuming that the page author is the page owner. Although this is desirable, it's not always possible. We need to draw a distinction between the "page author" who originally wrote the content of the page, and the "page owner" or "page maintainer" who is currently in charge of it.

When a page owner leaves the company, part of the leaving process should be to go through each of the pages that they own on the intranet, and either reassign it to their successor or remove it. The new owner should familiarize themselves with the contents of the pages that they are responsible for; if the intranet pages are useful, then the successor is likely to need to know the information contained on them anyway. Over time, as the intranet is maintained, the page owner is likely to replace portions of the original page content with updated material, or even remove the page entirely.

Why Should a Page Owner Agree to be Contacted?

An author will agree to be contacted about their intranet page for the same reasons that they'll write the page in the first place. As described above, these are reciprocity (the expectation of benefits to follow from doing so), repute (the increase of the author's reputation), and altruism (providing information in order to help others). For personal contacts, these reasons apply even more strongly than when the author is in contact with readers through the intermediary of an intranet page.

What Discourages Readers From Contacting the Page Author

Even though intranet readers can contact the page author, a lot of the time they will not, even when it would benefit them to do so. There are several reasons why this is the case. We'll look at what they are, and how to overcome them.

Local Knowledge is Preferred

In general, intranet users are more likely to ask the person at the next desk for help, rather than contact an expert that they don't know from an entirely different part of the company. This is true even when the person at the next desk has little chance of answering the question usefully.

This is related to the need to establish trust described earlier in this chapter. Face-to-face conversations are the best mechanisms for establishing trust, so you are likely to trust someone close more than someone further away. Incomplete information that comes from a source that you trust may be more valuable than more complete information from a source that you have no reason to trust. In addition, talking to someone nearby is quick, easy, and informal - while composing an e-mail is slower and more formal.

Trust in the content owner can be established using the methods described earlier in the "Establishing Trust in Intranet Content" section. It's also important that people consider the intranet as one of their first options for obtaining information.

I Don't Know What I Don't Know!

Users of the intranet may not know exactly what they need to know - and e-mail is more suited to asking and answering well-defined questions than it is to a broader discovery process. Until someone has at least a basic understanding of an area, then they are unlikely to be able to form useful questions relating to it.

This problem can be reduced by several mechanisms:

• By providing more information on the subject on the intranet so users can read around the subject

• The page author can provide links to background reading or Internet web pages that reference the subject

• The reader can talk to the content owner via a more immediate medium than e-mail - such as phoning the content owner, talking via IM, or meeting face-to-face

Readers Don't Want to Waste the Page Owner's Time

An intranet reader may avoid contacting the page owner to avoid wasting their time with foolish questions, particularly if the page owner is higher in the organization hierarchy. Sometimes this is justified; after all, if a subject expert is constantly interrupted by requests for answers to trivial questions, then they will be reluctant to make their knowledge available. It is often hard for a non-expert to know whether their question is trivial or difficult. Readers are not keen to embarrass themselves by asking questions that the expert might consider stupid. There needs to be a mechanism by which readers can tell whether their question is worthwhile, or embarrassingly obvious.

One solution is to use a contact mechanism that doesn't demand an immediate response from the page owner. For example, using IM is bad for this, because the author must respond immediately to an IM request if they are going to respond at all. On the other hand, adding a comment to an intranet page is less insistent, and it also allows for the possibility that another reader of the page might answer the question.

Another solution is for the page owner to establish a page of FAQs (Frequently Asked Questions) with the questions that they have previously been asked. This solution is most appropriate for a microsite owner that is responsible for a number of different pages, since most pages are unlikely to generate very many questions. Even if the reader's question isn't in the list of FAQs, then they can get an idea of the sort of question being asked from the FAQs.

On some subjects, there may already be related information elsewhere on the intranet or Internet. The page author can provide adequate and accurate links to similar articles, introductory tutorials, and existing FAQ pages. When the reader has perused these and still faces problems, then they can be sure that their problem is not too easy to bother the page owner with. In addition, the page owner can tell that the reader's problem is sufficiently important to the reader that they have spent time and effort trying to solve it, so will be more inclined to spend their time helping than they would if the problem was trivial.

These problems also apply to intranet applications like the "expert locator" or the "skills database". These typically consist of a database of people within the organization, with their skills in various fields rated. A skills database lists everyone within the organization, while an expert locator lists the top few experts within a given field. The idea is that when a member of the company has a question on that field, they can ask an expert. In addition, a project manager assembling a team for a project can search through the skills database to find people who have the talents that she needs.

Although the motivation behind these applications is good, the use of them is subject to similar problems as we've described above.

If you are assembling a team for a project, then it's often more important to know things like how well the team will work together, what sort of clients the team members have worked with before, and what similar projects the members have worked on, rather than just their skills. This is information that will not be in a skills database.

The expert locator may find an expert in the field in which you're interested, but without more background information, it gives you no reason to trust their expertise, and you will have no idea how well they will work with clients and other team members. Trust must be established using the mechanisms that we've already described in this chapter. In addition, you must overcome the reluctance to contact the expert described above, in order to make the expert locator widely used.