TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: Client access to edit Help From:Suzette Leeming <suzette -dot- leeming -at- gmail -dot- com> To:Steve Hudson <sh1448291904 -at- gmail -dot- com> Date:Thu, 24 Mar 2016 08:24:03 -0400
Thanks to all who replied and offered suggestions.
We're leaning in the direction Steve Hudson suggested. We are going to
discuss having a topic called "Internal Information" or something like
that, which any of our clients can modify the html file to add links to
their own help information, whether it's another help file, PDF files, or
whatever they want.
We can't offer this service to our clients (nor do I think they'd want us
to) because every client has their own process, so while we can tell them
what our software does and how to use each feature, we don't tell them what
their own process should be. That's the type of information they want added
Thanks again for all the responses!
On Thu, Mar 24, 2016 at 8:15 AM, Steve Hudson <sh1448291904 -at- gmail -dot- com>
> I'd be inclined to have a 'Localised' include HTML file which isn't
> but the client can complete at will. If they don't complete it, they get
> std help, if they do, they get the std help + the include file. These
> include files would have set names, so that shipping updates wont overwrite
> the client 'addendums'. Maybe one step further, 2 such include files, one
> 'pre' and one 'post' so the client can choose whether their stuff goes
> before or after the bog std stuff.
> -----Original Message-----
> We deliver browser based help files for our enterprise software but it`s
> installed on our clients' servers for security reasons (let`s not debate
> Our clients want the ability to "modify" the help files so that it can
> include their own internal process information and links to their internal
> documents as well.
> This has been fairly straight forward in the past and all they required was
> an html editor because we deliver the help in an uncompressed format.
> We now have much more complex help files and it`s not straight forward
> anymore and some clients may have an issue with this, and it`s become a bit
> of an internal thorn in my side. Indeed, many of the RFPs we respond to
> specifically ask "can the help files be modified?"
> My question to the group is this; is anyone else in the same situation and
> if so, how do you handle it?
> Suzette Leeming
> PS - My most recent suggestion was to give clients our source files and
> suggest they buy a license to the help authoring tool we use. That
> suggestion did not go over very well.
> Visit TechWhirl for the latest on content technology, content strategy and
> content development | http://techwhirl.com
> You are currently subscribed to TECHWR-L as sh1448291904 -at- gmail -dot- com -dot-
> To unsubscribe send a blank email to
> techwr-l-leave -at- lists -dot- techwr-l -dot- com
> Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit
>http://www.techwhirl.com/email-discussion-groups/ for more resources and
> Looking for articles on Technical Communications? Head over to our online
> magazine at http://techwhirl.com
> Looking for the archived Techwr-l email discussions? Search our public
> email archives @ http://techwr-l.com/archives
> This email has been checked for viruses by Avast antivirus software.
Visit TechWhirl for the latest on content technology, content strategy and content development | http://techwhirl.com