Do you serve your WebHelp?

[kevinmcl]

How do you folks get your WebHelp onto the screens of your customers/end-users?

A) Do you serve it from your company's site, and the customers can get Help for your product only if they have a working internet connection?

B) Do you provide a server (like apache or something else) on the distribution media for your product and its associated WebHelp, and tell the customers to run the server so they can see the Help with their browsers? Or do you provide the WebHelp and _tell_ the customers to use their own server to serve that WebHelp so they can browse it with a web browser?

C) Or do you just provide the WebHelp output as it was published from Flare, and expect the customer to browse it directly from the CD or to copy it to their local hard disk (or network drive) and browse it directly from there as local html files (with no server involved)?

D) Other? What?

Thank you,

Kevin (in Ottawa, Canada)

[LTinker68]

Depends. One company offered the WebHelp as a free download from their website. They had the entire output compressed into a ZIP file that self-extracted to a specific spot on the user's hard drive, depending on where they had installed the company's software. (That is, it installed to a sub-directory in the same program folder.)

For another company, the WebHelp was bundled with the installer, so when the user ran the installation program, it not only installed that user's program, but it also extracted and saved the help files to a sub-folder in the program files folder.

If you want to give your users the most flexible option, then I recommend having the help installed to their computer, but also give them a path to look up/download an updated version from your web server. Kind of like how Microsoft Office has the option to look in the local help or look online. That way if the user doesn't have access to the Internet then they still have access to the help, but if they do have access to the Internet, then they have access to the latest help available.

[kevinmcl]

Lisa,

I and a few other people had reported a problem where Firefox 3beta would not show our WebHelp.

Most people who were asked did not have the problem.

For those that did, it was a showstopper. You'd get a Firefox tab window populated by empty frames where your WebHelp and navigation panes were supposed to be.

After a bit of poking around... in which he could not replicate the problem, Neal at Madcap asked me to send him a sample project.
He reported back that he could now see the problem, and that it seemed to be a problem with Firefox 3 and locally-accessed WebHelp. The same WebHelp delivered by a server would display properly in Firefox 3.

Since it was claimed that only a small minority of WebHelp had the problem, I took that to mean that the large majority of WebHelp authors are providing their Help via servers, and not just giving it to customers as files on a CD that they can access locally (as I do - and as I also do for myself when I publish and want to store and verify what I've created). That's why I asked the question in this thread.

Right now, _my_ WebHelp projects aren't viewable with the next release of the world's most popular browser (because I don't serve my WebHelp, apparently). I want to know if there are other approaches that make more sense.... but everything that you mentioned is basically a variant of what I do now.

So, either others will respond and we'll see some variety, or else it'll turn out that what you describe (and what I do) is pretty much the common way to distribute WebHelp, and -- given that WebHelp that can't be viewed in Firefox 3 is the minority situation -- I'll assume that there's something special about _my_ WebHelp that produces the problem. If that turns out to be the case, then it will mean that there is something that I can/should do differently and the problem will go away for me (and my customers) too.

Meanwhile, I suggest that anybody who distributes WebHelp with their company's product should try Firefox 3 with it. If you notice a problem, then at least you get to start digging at it now, before Firefox 3 becomes the default version on everybody's computer. If you don't see a problem - and you are storing and viewing the WebHelp in the same manner as your customers do, then you can feel relieved and just ignore any further noise about a problem that affects only a tiny minority of Flare-using WebHelp authors.

Kevin

[KevinDAmery]

Ok, so does the same WebHelp output work in Firefox 2? (I.e. the release version?) If it does, it could be the problem really is on Firefox's end, not Madcap's. (FF3 is beta, after all, so problems are not out of the realm of possibility...)

Since it was claimed that only a small minority of WebHelp had the problem, I took that to mean that the large majority of WebHelp authors are providing their Help via servers

I would take that to mean that very few people out there are using Firefox 3 beta. Internet Exploder still has the largest share of the browser space, and I think most FF users are still using version 2. (I am, for example....)

[LTinker68]

You should always test across as many browsers as you can, or at least the one(s) you think your users will have. For instance, some of our projects have to be compliant with IE6 because that's what the customer specified in the contract (yes, I know, RamonS, why use IE? not my decision and definitely wouldn't be my first choice).

I'm actually a bit lax in cross-browser testing because I don't have IE7, so I have to copy the output to IIS on my computer, launch remote desktop so that I can log into a server that has IE7 then enter the URL back to the IIS on my computer so that I can test in IE7. (Why oh why don't browser manufacturers allow you to run two flavors of the same browser?) I could go to another user's computer to test IE7, but then I'd be interrupting their work. And I'd have to get up and move. So, you know, don't like that.

Anyway, as Kevin said, FF3 is in beta. I test FF2 locally on my machine all the time (outside of IIS), so the problem isn't with Flare -- it's that something changed in FF3. It may require that MadCap make some modifications to Flare to make it work with FF3. It may be that you have to do something like mark of the web to get it to work in FF3, just like you have to insert MOTW to get help to run locally for IE.

If you're beta testing FF3, then I suggest you submit a bug report via their website telling them the problem you're having running help locally.

[RamonS]

What I used to do is offer it to be viewed locally and also via web server. The customers could even switch on the fly which help source they want to use. I did think at one point to install a local web server, but on XP and especially Vista that triggers a bunch of messages (Your mouse moved - Accept or Deny?).
It depends also on what application it is and who the customers are. If it is a browser based application then there is no question as to where to place the help exclusively (on the server), with fat clients it is a case by case decision to do one or the other or both. If the target audience is not guaranteed to have 24x7 broadband access then having something local is generally a plus. If the help contains information that frequently changes then having a server based help will definitely be better. I like doing both and cover all bases, even when that means a bit more work.

[RamonS]

I'm actually a bit lax in cross-browser testing because I don't have IE7, so I have to copy the output to IIS on my computer, launch remote desktop so that I can log into a server that has IE7 then enter the URL back to the IIS on my computer so that I can test in IE7. (Why oh why don't browser manufacturers allow you to run two flavors of the same browser?) I could go to another user's computer to test IE7, but then I'd be interrupting their work. And I'd have to get up and move. So, you know, don't like that.

Did you ever look at the offering from Tredosoft? See http://tredosoft.com/Multiple_IE - let's you install all versions from IE3 up to IE6 and then allow for IE7 to come natively from Windows. I run this in a VM and while the IE versions are a bit more crash happy than how they usually are it is good enough to do some testing.

[KevinDAmery]

Right now, _my_ WebHelp projects aren't viewable with the next release of the world's most popular browser

Uhhh... excuse me? I'd love to know where you got that measurement. Much as I'd like it if everyone was using FF, I haven't seen any figures anywhere suggesting that it has overtaken IE yet (or even gotten to 25% for that matter).

[LTinker68]

Did you ever look at the offering from Tredosoft? See http://tredosoft.com/Multiple_IE - let's you install all versions from IE3 up to IE6 and then allow for IE7 to come natively from Windows. I run this in a VM and while the IE versions are a bit more crash happy than how they usually are it is good enough to do some testing.

Does it require you to run it in a VM?

[kevinmcl]

Right now, _my_ WebHelp projects aren't viewable with the next release of the world's most popular browser

Uhhh... excuse me? I'd love to know where you got that measurement. Much as I'd like it if everyone was using FF, I haven't seen any figures anywhere suggesting that it has overtaken IE yet (or even gotten to 25% for that matter).

I made it up

I'm referring to the browser that people actually want to use, versus the one that they usually get stuck with, by default.

My various googling shows Firefox way ahead on PCs (aside from pre-loaded IE), but Opera with its small-but-loyal PC following is mopping up the small-devices landscape (phones, PDAs, etc.).

[kevinmcl]

Heads up, all. Here's the latest from Madcap, via Neal P.

... and I quote:

Currently, Firefox 3b5 has a more stringent file security model that does not allow local files to use XMLHttpRequest. This is most likely going to be kept in the final version of Firefox 3.


Until this is addressed, here’s the workaround:


1) Open Firefox 3b5

2) Type about:config into the address bar and hit enter

3) Click yes at the “Void Warranty” screen

4) Filter for security.fileuri.strict_origin_policy

5) Change it to False by double-clicking the option

6) WebHelp will now work in your local browser

------------------- end quote -------------------

Before tinkering, or telling your users to tinker, notice that the problem is not observed if your WebHelp is SERVED. Only if you supply your WebHelp output on CD or in tarball (or whatever) to be saved on the user's local system and browsed directly, without an intervening server. That sounds like it lets at least half of you off the hook.[

[kevinmcl]

... It may be that you have to do something like mark of the web to get it to work in FF3, just like you have to insert MOTW to get help to run locally for IE.

Refresh my memory... what major functionality do you lose in WebHelp if you turn on MoTW?

What do most of you do with that? Do you make two versions of your Help? One with MoTW switched on, and another (for everybody with real browsers) with MoTW switched off?

Hmm... THAT might be a reason to have both a distributed-on-the-media and a served version of the WebHelp.

Kevin (in Ottawa)

[kevinmcl]

Since it was claimed that only a small minority of WebHelp had the problem, I took that to mean that the large majority of WebHelp authors are providing their Help via servers

I would take that to mean that very few people out there are using Firefox 3 beta. Internet Exploder still has the largest share of the browser space, and I think most FF users are still using version 2. (I am, for example....)

The question was asked (in techwriter mailing list) if anybody had noticed the problem with their WebHelp, using Firefox 3beta. The people answering were either those who had tried Firefox 3beta or those who couldn't/didn't properly read the question.

Release is planned for next month, so unless a big problem surfaces, I think we're looking at the final release candidate.

However, for those of us who create WebHelp and don't provide servers, it would be _nice_ if they (Firefox developers) were to add a simple configuration choice to modify the problematic security setting without nullifying an otherwise good security improvement. Maybe one of those "Allow from this directory" choices.

-KM

[LTinker68]

Refresh my memory... what major functionality do you lose in WebHelp if you turn on MoTW?

You don't lose any functionality if it's run locally -- it just tricks IE into thinking you're viewing the help from the web when you're not. However, if you have MOTW on and you upload it to a server, then parts of the help are blank. Can't remember off the top of my head if the toolbar is blank, if the topic area is blank, or if the navigation pane is blank. It's one of those or a combination of them. So, yes, you'd have to generates two targets if you're giving users the choice between installed/locally-run help or server-run help.

Hopefully there will be a workaround like MOTW for Firefox 3. Guess it wasn't a consideration for them since the help for FF seems to be a single locally-run help app.

[KevinDAmery]

I thought MOTW also impacted what happened if you attempt to launch a file from the topic (e.g. open a pdf from a link in the help system). (Although I could be wrong--heck, my output is to CHM so this is all theoretical for me....)

[Richard Ferrell]

If MOTW is turned on, than any links you have to Non-HTML files such as PDF, DOC, XLS will not work, nor will you get any error messagdes when you try to open them.

[LTinker68]

Oops, sorry, forgot about that.

[kevinmcl]

If MOTW is turned on, than any links you have to Non-HTML files such as PDF, DOC, XLS will not work, nor will you get any error messages when you try to open them.

So, I'd like to avoid MoTW, as a matter of general policy.

By the way, when you say "links [...] to Non-HTML files" does that also include the PNG and JPG files that I have liberally scattered throughout my Help? Do they also fail to load when MoTW is on?

-KM

[RamonS]

Did you ever look at the offering from Tredosoft? See http://tredosoft.com/Multiple_IE - let's you install all versions from IE3 up to IE6 and then allow for IE7 to come natively from Windows. I run this in a VM and while the IE versions are a bit more crash happy than how they usually are it is good enough to do some testing.

Does it require you to run it in a VM?

No, it does not, but a VM helps to keep things clean.

[LTinker68]

By the way, when you say "links [...] to Non-HTML files" does that also include the PNG and JPG files that I have liberally scattered throughout my Help? Do they also fail to load when MoTW is on?

No, they're fine. I have MOTW enabled when I'm writing/building/testing and turn it off before I upload the files to the server, and I've never had problems with images.

[forfear]

I don't use MoTW at all for the following reason.


Since i expect to be testing a lot of webhelp output locally on my work station, i configure IE to allow
Active Content for local files.

This is in Tools > Internet Options > Advanced tab, and select the settings you need under the Security group

[RamonS]

Yes, for your own testing purposes changing those settings is OK, but some use WebHelp as the local help system in customer installations. I looks much better than CHM and has more features. Besides that, it can be skinned the way one wants. But leaving MOTW off would then require customers to fork around in their IE security settings, which typically doesn't go over too well especially when it in fact makes IE even less secure than it already is.

[doc_guy]

For what its worth, I installed Firefox 3 RC1 today, and I'm able to pull up webhelp off of my C drive and display it properly in Firefox without changing any configuration settings.

If you are experiencing this problem with earlier betas of Firefox 3, I recommend you upgrade to RC1 and see if you still are having issues.

[RamonS]

Firefox doesn't care about MOTW. The MOTW flag is only to compensate for the shortcomings of IE.

[Richard Ferrell]

There were some issues with an earlier build of FireFox that didn't like MOTW