Originally published in Intranet Journal (16-Apr-2004)
Vendors with something to sell like to complicate relatively simple matters—usually through a dazzling display of marketing slight of hand—so that they can hoist their wares upon a pedestal as the savior of all things. Who can forget how the creation of the automatic apple peeler prevented the undoing of millions of years of evolution by saving humankind from accidentally severing their opposable thumbs?
I see a lot similarity in the the e-mail I receive from disheartened would-be intranet developers who have been turned upside down by what they perceive as an unsolvable problem. But the fact of the matter is relatively simple concepts can be clouded by countless external factors. And perhaps the biggest of these concerns is what happens to an intranet after core development has been completed and must be left in the hands of multiple content owners in a non-technical environment. Well, two things can happen: it will flourish or it will fall.
Whether you manage to achieve the former or fall prey to the latter centers around your ability to create a controlled intranet management environment—and it doesn't necessarily require the investment in bloated software packages. There are a number of things you can do in-house to create an environment that allows for the flexibility of daily intranet management while preventing content owners from turning the system into a free-for-all:
Content owners don't need to be software engineers. Their role is to provide and maintain an intranet's content so it's not necessary to expose the entire physical structure of the system. After all, there are still those who are uncomfortable navigating the Windows Explorer on their own desktops, so can you imagine the possible problems that can arise when these same people need to maintain thousands of files and folders on a live production intranet server? Files and folders can be moved or deleted by accidental mouse clicks, and novice users can quickly become overwhelmed by high-volume sites where file names don't reflect the actual contents of the file.
The important lesson to be learned here is that the level of structural access should be relative to the technical proficiency of your content owners. And needless to say, they should only have access to their own content and no one else's. So, if you trust enough in your content owners' abilities to handle portions of the physical structure (the only exception is access to scripts and database files that should never be exposed to anyone but the developers themselves), feel free to grant them the necessary access rights. But bear in mind, if you end up spending the majority of the day recovering data from back-up tapes, maybe it's time to close some of the doors.
One of the most annoying problems intranet users are forced to deal with, aside from poor site navigation, is an inconsistency in document design. And the problem is magnified by the number of content owners involved in inputting information, because everyone has their own idea as to what makes a document readable. For this reason, intranet developers and content owners should all agree upon a formal set of document design guidelines.
The importance of document consistency goes hand-in-hand with Web page and navigational consistency. You want your users to feel as though they're on the same site rather than a collection of unrelated sites. Documents that change in layout and style from one document to another—or in some cases, within the same document—is the hallmark of sloppy and unprofessional intranet management.
Since content owners tend to adopt a "that's good enough for now" attitude when they're harried by numerous other tasks and tight schedules, a good way to enforce these style guidelines is to make use of cascading style sheets (a very useful CSS tutorial is offered at W3 Schools) and predefined layout templates. By doing so, content owners are provided with a framework to work within and you'll ensure that all documents end up having the same layout and style.
The primary function of most intranets is to provide timely, up-to-date information to their user communities. To accomplish this, there are usually several content owners simultaneously inputting information into the system at any given time.
With so much input traffic occurring on a daily basis you need to have some way to ensure that an intranet's structural integrity—file naming conventions, location of documents, locations of links—remains intact over the years. But trying to manually maintain a standard among multiple content owners day-after-day and over a long period of time may prove difficult. And regardless of how far technology has taken us and how much we try to automate repetitive tasks, the process of inputting content still requires some form of human interaction. This, however, doesn't mean that we can't do all we can to minimize the content owners' involvement in this process.
Aside from using CSS and templates mentioned earlier, you can also provide content owners with a Web-based utility that allows them to enter information directly onto a content input form (see image below). This option bears the same advantages as CSS and templates, but is much more transparent because it makes use of a black box script in which the majority of the work is done for the content owners.
Once all of the information has been entered into the form and the "Store Document" button is pressed, the black box script will perform several things:
Intranets with high input traffic can quickly become cluttered, forcing users to sift through a mishmash of current and past information. Different documents have different lifespans; some may still be referenced months down the line whereas others may only be useful for a few days.
Once a document has outlived its current usefulness it should be archived or deleted altogether. But rather than leaving this manual housekeeping duty in the hands of content owners who may forget and let information pile up, documents can be date stamped and provided with a lifespan flag (see the previous image). An auto-archiving script can then be scheduled to run at specified times, moving older documents to a "list of archives" page.
It's important to stress, however, that documents should only be logically archived—moving the link of the old document to an archives page. All steps should be taken to avoid moving the physical file to a different location within the intranet structure. This will cause link rot because existing links to the physically archived documents will no longer be valid—not to mention all the "Not Founds" that will be encountered by users who may have bookmarked these documents.
Content owners—especially those who are not technically adept—tend to fear the unknown, and technology remains one of the biggest unknowns for many. And I've found that the majority of intranet maintenance problems arise from content owners who are unsure about what they're doing or doing something by accident. Even small mishaps, if done repeatedly and by enough people, may result in rippling, long-term effects on the whole intranet from that point going forward. And if these mishaps are not caught and corrected, your intranet will eventually end up in a condition that makes it difficult to recover.
All content owners should be provided with adequate training and reference material so that they won't feel as though developers dropped something foreign onto their laps without any support. The goal is to help content owners familiarize themselves with the system—how content is structured, file naming conventions, posting and updating content—so that they can manage it without feeling like they're walking on eggshells.
Intranet development and management requires the interplay among several distinct groups: developers, content owners, and users. It's a three-tiered system much like a brick-and-mortar retail store; you have designers creating the atmosphere and layout, shop owners filling the store with merchandise, and customers come to the store to buy its products. The first two groups need to provide and maintain a usable system for the third or risk going out of business (see my previous article "Law & Order: Content Owners and Developers" for more on this). And the longer an intranet is in business, the more likely it will be to stray from standards—especially if it happens to change owners frequently.
Everyone must do their part. It's in the best interest of IT to create an easily maintainable intranet for the content owners, and for content owners to provide information for the user community and ensure they don't end up corrupting the infrastructure developed by IT.
But keeping an intranet clean is not as complex as some of the elaborate suggestions I've been asked about—from running a concurrent, mirrored "working" server to strange, otherworldly rituals to control the minds of content owners.
While providing content owners with a controlled environment, automated housekeeping, and training will require more involvement on IT's part, the payoff is well worth the price because the time spent preventing an intranet from turning into a mess will be miniscule compared to the time it will take to clean it up after it does.
Copyright © 2004 Paul Chin. All rights reserved.
Reproduction of this article in whole or part in any form without prior written permission of Paul Chin is prohibited.