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.
(Reposting my comment about why to use an alias / map file instead of
hard-coding URLS so that it's in this same thread. This is one of the
most valuable lessons I've learned the hard way in my years as a tech
writer.)
Hard-coded web help URLs are specific to each authoring tool. If you
ever want to switch from, say, Flare to DocBook WebHelp, you'd need to
edit every individual help call. It took me several weeks to migrate
from RoboHelp to WebWorks since I had to edit hundreds of calls in the
application source code. If we'd been using an alias file, it would
have taken only a few hours.
Similarly, using an alias file lets you reorganize the help (split a
topic in two, fold one topic into another, etc.) without having to
touch the application source code. This is particularly helpful when
the developers won't let you edit the application source and you're
dependent on them to fix things.
On Wed, Dec 4, 2013 at 5:13 PM, Robert Lauriston <robert -at- lauriston -dot- com> wrote:
> There's no architecture, really. Web help is just HTML and JavaScript.
> You dump the files in a directory. You don't need anything but Apache
> or some other standard web server. Send the IT manager some sample
> output. Here's the information on making the help calls:
>
>http://webhelp.madcapsoftware.com/flare7/Content/CSH/WebHelp_CSH_Calls/CSH_Calls_WH_WHP.htm
>
> I strongly recommend using alias files rather than letting developers
> hard-code calls to specific pages.
>
> If you want to limit the help to registered users (what's the
> marketing case for not letting prospective customers see it?) then
> just put the help files in the application, or if for some reason you
> want to use a separate server, use the same authentication method you
> use for access to the application. If the help is password-protected,
> then I don't think you can use Google Analytics.
>
> On Wed, Dec 4, 2013 at 2:10 PM, Julie Stickler <jstickler -at- gmail -dot- com> wrote:
>> The subject line says "server specs" because our IT manager replied to my
>> initial inquiry with "We may have to build a new server for it. It all
>> depends on how this thing is architected." I've usually had to maintain
>> help that was already coded into the product, so being asked "how this is
>> going to be architected" rather baffled me. The application makes a call
>> to the Help URL (Welcome.html or some such). The call might include some
>> sort of token or password if we're locking down the Help to registered
>> users only. What else am I missing here?
>>
>>
>> On Wed, Dec 4, 2013 at 3:53 PM, Robert Lauriston <robert -at- lauriston -dot- com>wrote:
>>
>>> The subject line says "server specs." Hosting web help generally
>>> requires relatively little additional horsepower from a web server
>>> that's already handling a SaaS application.
>>>
>>> You might look into replacing Flare's default web help search with
>>> something more robust, such as Google or a Google Appliance.
>>>
>>> You'll probably want to use Google Analytics or something similar for
>>> metrics.
>>>
>>> On Wed, Dec 4, 2013 at 11:43 AM, Julie Stickler <jstickler -at- gmail -dot- com>
>>> wrote:
>>> >>Web help is not very resource-intensive as web applications go.
>>> >
>>> > Not sure what you mean by this?
>>>
>>
>>
>>
>> --
>> Julie Stickler
>> http://heratech.wordpress.com/
>> Blogging about Agile and technical writing
>>
>>
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> New! Doc-to-Help 2013 features the industry's first HTML5 editor for authoring.
>>
>> Learn more: http://bit.ly/ZeOZeQ
>>
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> You are currently subscribed to TECHWR-L as robert -at- lauriston -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 info.
>>
>> 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
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
New! Doc-to-Help 2013 features the industry's first HTML5 editor for authoring.
