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.
We've been in the process of trying to move all of our help to web based formats for about a year now, with it set up to work for up to 11 different help projects, eventually. Each project is a dedicated subdomain name (subdomain.domain.com, example: mobileios.domain.com, mobileandroid.domain.com) and since we have to support multiple versions at once, things on the server are first a folder for the version number, then specifically a "help" folder since some projects may also be having a separate EULA added to them (so there would be a "eula" folder at the same level), and then folders are broken down by language, and then the actual files. This means we can have multiple versions all supported at once, for instance, one of the first projects moved to the web has 4 versions on the server. Yes, this does mean engineers need to change that folder number in their files for every new version, but it is a minor change and the rest of the structure stays the same, and it's much easier for them to update the folder number at their leisure than have to keep re-compiling projects every time there is a new version of help. The purpose of the subdomains was to try and keep all the different projects a little more "hidden" from each other, less of a chance of someone accidentally stumbling into the wrong help set for the application they are using.
We're still fighting the "please let us drop context sensitive help" fight. At least engineering is starting to realize how much extra work it also makes for them to properly do context sensitive help, so they seem a little more willing to drop it as a requirement
Map out your approach, take the time to make sure it is a solution that will work for all your current projects, and document, document, document it along the way so everyone has a clear understanding of the approach. We actually treated it like an engineering project with corresponding feasibility documents, specification documents, etc.
Only con we have run in to is a reluctance to get ALL the projects out on the web as quickly as we would have liked. And we do keep having to explain to some teams that getting the help out of the software does NOT mean we will be going back and updating old projects, etc., for changes after we reach GA. We are a "only move forward" docs shop, and while this would give us the chance to make changes to older files if there was a serious business concern about it that was costing the company money or legal issues, that would be the only reason we'd "go backwards" to change.
- V
-----Original Message-----
From: David Tinsley
Sent: Wednesday, March 11, 2015 1:21 PM
To: Technical Writing
Subject: Remote help access
Greetings,
I am responsible for writing and maintaining five helpsets for our various applications. Currently I deliver in various formats (Webhelp, .chm, java help (Yes, I know, don't go there!) to the developers for integration into the application. I am considering the possibility of hosting the helpsets, probably as Webhelp on a dedicated domain. The idea being that the user will click on the help in the application and launch the help that we are hosting here. My IT people tell me that is easy enough, so long as we provide a dedicated ID in the application that points to the correct helpset.
Has anyone done this and if so, what issues did you have? Pros and cons to this approach? One possible issue that I see is with context sensitive help?
Thanks in advance,
Regards,
David
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Adobe TCS 5: Get the Best of both worlds: modern publishing and best in class XML \ DITA authoring | http://adobe.ly/scpwfT
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
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Adobe TCS 5: Get the Best of both worlds: modern publishing and best in class XML \ DITA authoring | http://adobe.ly/scpwfT
