Who has permission to read complete product documentation? It's by far the easier, softer way to make content fully public; however, as enterprise Help migrates to the web, this requirement to apply content security (
access control) is surfacing more and more.
The cheap (or interim) approach to this is "security by obscurity": have your enterprise users log in to their product in order to reach the links to your Help (and add a robots file to instruct search engine crawlers not to index your site). You get no
SEO benefits at all from your content, so there's the marketing price to be paid: prospects googling for your product think that no useful information exists. (Some HATs, such as
HelpConsole, let you make part of the help visible to the public while securing the rest behind a login.)
Should "security by obscurity" prove inadequate, be very cautious about stacking on new authentication: If your product
support is also moving to the web, it doubtless involves its own user authentication, and if your product is
SaaS, that access is surely controlled. In either case, you need to implement single-sign-on with your existing system to keep your users from hating you.
For out-of-the-box systems that bridge secure support with access-controlled documentation, you might look at a new breed of blended solutions:
Some more thoughts on adding access control:
- You can also take advantage of HATs that publish into CMS systems, such as Doc-To-Help publishing to SharePoint.
- If you're working with structured content, it may work for you to deploy into a content publishing system such as Fluid Topics.
- If you're authoring in a web CMS directly, such as in Drupal Book modules, you'll need to set up role definitions, views, and content tagging.
Are there other authoring products that support the single-sign-on access control scenario? I'd love to hear about them!
Comments