By Hugh Findlay

Not so long ago, the worldwide web was young and exciting, the market was booming, and webmasters were on the bleeding edge of technology. Times have changed and so has the web, along with our dreams of changing the world by building shimmering superhighways of information. Nonetheless, the web boom had an interesting side effect. The web infiltrated the enterprise and set up shop inside the walls of corporate America. A new paradigm emerged, donning the mantle of intranet.
An intranet, in contrast to the Internet, is in-house and serves the employees of an enterprise. Although intranet pages may link to the Internet, an intranet is not accessed by the public. The intranet was fertile ground for web-savvy geeks like me to till and plant. Work teams soon hung out their shingles on this in-house web, gathered up reference materials from file shares, and posted cool photos of themselves with their pets, adding blinking text and sound bytes. Everyone hopped on the bandwagon, not wanting to be left out of this trendy opportunity. As our seeds sprouted, sites expanded and were ultimately assigned to a volunteer with the hefty title of webmaster. These web sites became the bulletin boards for policies, procedures, references, templates, and anything else that formally sanctioned the group. If it was on the intranet, it was gospel.

Then we started seeing redundant, stale, and even contradictory information being posted. Worse yet, we couldn't find that critical file or piece of information that everyone else seemed to know about. Who the heck was in charge here? Where in the world was all that data we needed? How do we get there from here? Clearly, the work team web site had reached critical mass and somebody, somewhere, had to do something about it. Enter the enterprise portal.

These portals rescued the work team web site by providing central hubs for navigation that were comprehensive and up-to-date. Secondly, they served as the most official resource for all corporatewide information in the enterprise. They serve these same purposes today. But portals were no silver bullets—users still mismanaged content and organized it illogically. Good knowledge-management principles were overlooked, in deference to the old standby excuses, "I don't have time" or "It's good enough."

Time marched on. We chugged away with our portals. We started hearing a familiar mantra, a call for extended functionality and ease-of-use…and the development community responded. New tools appeared in the enterprise—ones that allowed end users to author and edit directly in the web browser itself. Eureka, now we, the employees, are empowered! The average engineer could click a few buttons and a document was posted on a website for all to view and scrutinize. Contributors did not need to go through a middleman webmaster, nor did they need to learn a web authoring tool. It was quick and easy, and anyone could do it. Surely now, we'd reached intranet nirvana?

Not exactly. With each new iteration of web tools came realizations that the web community as a whole needed parameters, guidelines, and common procedures. Intranets needed contributors to be conscious of their audiences and give them what they needed to get their jobs done. Sound familiar? This consciousness is second nature to technical communications. Intranets needed data librarians with technical communications skills. Why this shift? For the most part, it was due to the nature of the content housed on the intranet. Users went from posting mostly team-oriented content of good value to posting project-specific content of absolute critical value. The quicker and easier it was to upload this content, the stronger the need for guidelines that could be enforced by both the tools and the designated librarians.

In an environment like this, permissions became a huge issue. Who gets to see what, and how do we make that decision? Sharing in a collaborative environment is important but, in some organizations such as in R & D, potentially dangerous. Roles across teams needed to be hammered out, as did the roles of webmasters and web server administrators. Suddenly, corporate web gurus found themselves in supporting roles more often than in developmental ones. Users needed to know not only what they could do in a website, but what they should do. They needed training in best practices, while not forgetting the fundamentals and lessons of the past.

And that brings us to where we are today. We've come to depend on our intranets every day for timely, accurate information. We expect our portals to link us to every website in the enterprise, and to represent the official resource for corporate- sanctioned information. We know we don't need traditional web-editing skills to get our jobs done, but instead, we need only a browser to upload content and modify our sites. We recognize that we have the responsibility of labeling and organizing data within a logical architecture, for the benefit of both contributors and consumers. Finally, we see the need for overall training in best practices of web management.

From a high level, this all sounds obvious and easy to grasp. But how can a webmaster or administrator be sure to build a functional website to aid the enterprise community? The following list is a collection of what I call "lessons learned" in the arena of intranet webmastering. It is a list of personal rules that you can apply to any website.

Lessons Learned

1. Content is king.
   Bells, whistles, and stupid web tricks don't matter. Weed out redundancy or staleness.
2. Change is an absolute.
   Expect to re-engineer your site every 18 months. Projects don't last much longer, and pages get boring too.
3. You can't satisfy everyone, but you should try to satisfy most of ‘em.
   Find the most common denominator and build around it, including browsers and monitor resolutions.
4. Simpler is better.
   Complex sites lead to confusion. So does page clutter—multiple fonts, myriad headings, splashes of color, cutesy images. The eye should not have to wander.
5. Proof before you post.
   Or be prepared for flame mail from grammar cops.
6. Steal everything.
   Why write code when you can get it free? Get scripts, icons and images too.
7. Every end-user is correct.
   Because they are your customers, you should listen to their needs, no matter how outrageous.
8. Keep pages current/familiar/fresh.
   Put regular maintenance on your todo list and keep it there. Make small changes over time to ensure familiarity, but with freshness.
9. Omit needless words.
   Never could Strunk & White's advice be more applicable. Users don't want to read too much. Saves page real estate too.
10. Build navigation your grandmother could follow—along seek path, not file type.
    This means putting the consumer first, not the contributor. Naming a top-level folder "LINKS" is not very informative.
11. High maintenance is bad.
    Duh, but too many webmasters engage in it. JavaScripts are good examples of this—some fill a good need, but require editing for every little update.
12. It's not your web, it's your audience's.
    And they'll tell you so too! Be willing to change it for them.
13. You can bring an end-user to water, but you can't make him collaborate.
    Don't get discouraged when you roll out something cool and nobody uses it. This is usually due to the degree of publicity a given site has—more users will collaborate among close co-workers than the whole organization.
14. Use the tools at hand; don't reinvent the wheel.
    Kind of like stealing everything, but more specific. If a customer wants something special that requires a new tool, talk them into the alternative using the old tool. Chances are, this simple solution is better and familiar.
15. Customers know what they want, but not what else you can give them.
    Employees have problems—tell them every way you can provide a solution.
16. When providing information, answer who/what/where/when/why/how?
    Just like Journalism 101. Create a page, then vet it for the above. Otherwise, your audience is left wondering and they'll click away.
17. The web is like a telephone—critical, taken for granted, and sorely missed when unavailable.
    The telephone analogy is the most accurate, as they are both channels of communication.
18. Obey the three-click rule.
    If users don't find what they're looking for within three clicks, they're outa here!
19. There are always three customers: contributors, consumers, and everyone else.
    You should keep this in mind for every page you create. Fail this, and navigation is hit hard.
20. More features = more complexity.
    So spread the features around…on multiple pages instead of one. If you can't keep it simple, then make it easier to digest.
21. Buried content = lost content.
    And it's as if it never existed. Sure searching helps, but context is lost.

Hugh Findlay is NAS Web Services lead for EMC Corporation in Research Triangle Park, NC. He can be reached at findlay_hugh at emc dot com.