I was thinking about this yesterday and ended up talking to Tom about it today. We work on projects that have asked similar things of us, but in other cases, our constraints are quite different. One example is security.

Let me illustrate. One Web application may allow users to complete a process that is not in any way sensitive in and of itself. So the help content for that application also is not sensitive, so it’s not problematic for it to be on a publicly accessible server. Even if the data that the users enter in the application can be sensitive or private, you don’t know what they’re entering by reading the help, so there’s no problem.

On the other hand, another application may help users in completing a sensitive process. By association, then, because the help describes that process, it is sensitive. I have found that generally, the projects I work on require more security than Tom’s.

This creates a challenge for our team as we work on standard and best practices.

For example, Tom recently tried out SharePoint as a place for his help to live. The SharePoint site that he used has some security on it, but the number of people who could access his help for that particular project shouldn’t have access to help that I’m writing.

Had Tom decided to use SharePoint as the main platform for his help content, I would have had to work out security measures. Often, the size and roles of the audiences I write for vary widely. For an application used by 20 people, managing security in SharePoint may not be too hairy a monster, but for an application used by hundreds, it’s something on the scale of King Kong’s mother-in-law (no offense to mine!).

Right now, I check help output files into whatever Subversion repository contains the corresponding application code. The help is scooped up in the application builds, and they are included in the application’s security measures. As far as security goes, it means less worry for me.

When we’re trying to find the best way to do things across our team, differing constraints like security demand that we maintain flexibility. Standards can make projects more streamlined by reducing questions and variables, but when development teams’ approaches to security vary by project (by necessity), we have to match their decisions. Another reason that technical communicators have to maintain the flexibility of a champion gymnast.

In some cases, we’ll be able to set team standards, but in others, we may have to settle for consistency across a family of applications.

What issues in documentation security do you face?

Related entries (auto-generated):

Helping the Team Broaden Their View

The Team I’d Like to Sit With

SharePoint as a Way to Manage Document Reviews

Results of a Team Design Review: A Different Context-Sensitive Help Structure

Three out of Four User Education Team Members Choose Flare