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.
RE: alias files (was Re: Hosted Help - server specs?)
Subject:RE: alias files (was Re: Hosted Help - server specs?) From:"Robart, Kay" <Kay -dot- Robart -at- tea -dot- state -dot- tx -dot- us> To:Kathleen Johnson <Kathleen -dot- Johnson -at- visionsolutions -dot- com>, Robert Lauriston <robert -at- lauriston -dot- com>, Technical Writing <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Thu, 5 Dec 2013 14:14:03 +0000
We have always called a specific page.
-----Original Message-----
From: techwr-l-bounces+kay -dot- robart=tea -dot- state -dot- tx -dot- us -at- lists -dot- techwr-l -dot- com [mailto:techwr-l-bounces+kay -dot- robart=tea -dot- state -dot- tx -dot- us -at- lists -dot- techwr-l -dot- com] On Behalf Of Kathleen Johnson
Sent: Thursday, December 05, 2013 7:42 AM
To: Robert Lauriston; Technical Writing
Subject: alias files (was Re: Hosted Help - server specs?)
"I strongly recommend using alias files rather than letting developers hard-code calls to specific pages."
Why? We just had a discussion on this yesterday. Alias files seems so cryptic and high maintenance. If you have a standard naming convention between the application and the help files, it seems easier and lower maintenance to just call a specific page.
Kathleen Johnson | Advisory Technical Writer | Vision Solutions | +1 (317) 813-1116 | Kathleen -dot- Johnson -at- visionsolutions -dot- com
Double-Take | iTERA | MIMIX | www.visionsolutions.com The contents of this e-mail (and any attachments) are privileged and confidential. Unauthorized use is strictly prohibited(+).
-----Original Message-----
From: techwr-l-bounces+kathleen -dot- johnson=visionsolutions -dot- com -at- lists -dot- techwr-l -dot- com [mailto:techwr-l-bounces+kathleen -dot- johnson=visionsolutions -dot- com -at- lists -dot- techwr-l -dot- com] On Behalf Of Robert Lauriston
Sent: Wednesday, December 04, 2013 8:14 PM
To: Julie Stickler; Technical Writing
Subject: Re: Hosted Help - server specs?
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:
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.
