Webhelp v. MS HTML v. DotNetHelp

[docudramaqueen]

This may be a very, very novice question, and may have some of you shaking your heads, "poor fool." That said, I need a resource to help me understand the differences and similarities between WebHelp, MS HTML, and DotNetHelp. Googling didn't really get me very clear definitions. Does one publish for all three, or just choose among them? Can someone please 'splain, or point me to useful resources?

Thanks,
DDQ

[lacastle]

There are some useful topics in the Flare help that explain the difference:
http://webhelp.madcapsoftware.com/flare ... t_Type.htm

Normally, you would just create 1 version of online help unless one of your clients specifically can't use it. Each of the versions depends on what browsers, security levels, or servers are available.

[docudramaqueen]

Perfect! Thanks so much. We haven't actually installed (or even ordered) Flare yet. I've used it before, and have recommended it to the managers at my new position, where no help system exists, and there are no authoring tools. I guess I can assume that DotNet incorporates the WebHelp feature that allows help to be viewed online, separate from the application (since that's just what I looked at). What can you tell me about the "freely downloadable reader"? Will my users need to install that separately from our software, or can we incorporate it into our software in such a way that the installation process is invisible to our users?
I love Flare, and can't wait to get it installed.
Thanks,
DDQ

[NorthEast]

I guess I can assume that DotNet incorporates the WebHelp feature that allows help to be viewed online, separate from the application (since that's just what I looked at). What can you tell me about the "freely downloadable reader"? Will my users need to install that separately from our software, or can we incorporate it into our software in such a way that the installation process is invisible to our users?

The help you just looked at in that link was WebHelp, not DotNetHelp.

If you're delivering help online which is separate from the application, then you'd use WebHelp since you can view it in a browser.

If you're delivering help with the application, then you could use either DotNetHelp or WebHelp. We install WebHelp with our applications, but display it in its own application window rather than a browser. To view DotNetHelp, the user needs to have the DotNetHelp viewer installed on their PC, which I'm pretty sure can be installed 'silently' as part of your application installer.

DotNetHelp tends to get mixed reviews, it has one or two advantages over WebHelp, but has drawbacks too. On the plus side, if you're developing .Net applications then it has good integration features like dynamic help; if you install the Flare trial, there's a dynamic help pane that instantly displays help topics as you move the mouse over on-screen features. On the downside, using DotNetHelp means the user has to install a help viewer, and also the viewer itself has a lot of MadCap branding (which was enough for us to rule out using it).

I'd suggest downloading the free trial version of Flare and trying these out for yourself.

[i-tietz]

and also the viewer itself has a lot of MadCap branding (which was enough for us to rule out using it).

True. But if your developers feel like it: There's supposed to be an "SDK" (Software Development Kit) for the Viewer and I believe you can get rid of MC presence in the viewer via programming the viewer with it.

You might need people knowing their way with HTML/CSS/javascript for WebHelp, too. Why?
Your users use different browsers in different versions with different settings. If you want to make the result sort of predictable, you will have to react after each release of any of the browsers. Only way around that: Make the "permitted" browsers and versions part of your system requirements. But that doesn't mean you won't have problems, because users might still install the latest version anyway and they might not be willing to uninstall it but rather expect you to fix the help.

[NorthEast]

and also the viewer itself has a lot of MadCap branding (which was enough for us to rule out using it).

True. But if your developers feel like it: There's supposed to be an "SDK" (Software Development Kit) for the Viewer and I believe you can get rid of MC presence in the viewer via programming the viewer with it.

I wasn't aware that you can remove the branding from the MadCap viewer application - is there somewhere you've read/seen that?

There is an SDK, which might be another option. My understanding was that you can use the SDK to integrate your help inside your application, in the same way MadCap integrate their help inside Flare. However, it's something I know little about, and I'd be interested to know if anyone in this community has actually used DotNetHelp to do this, as I can't remember seeing posts from anyone who has done this.

You might need people knowing their way with HTML/CSS/javascript for WebHelp, too. Why?

It shouldn't really make any difference which output you are using; producing WebHelp requires no more specific knowledge than DotNetHelp, or for that matter any of the other Flare targets. You will need to know a basic amount of HTML/CSS knowledge to use Flare with any output, but I wouldn't say any one output requires more knowledge than any other.

[i-tietz]

It shouldn't really make any difference which output you are using; producing WebHelp requires no more specific knowledge than DotNetHelp, or for that matter any of the other Flare targets. You will need to know a basic amount of HTML/CSS knowledge to use Flare with any output, but I wouldn't say any one output requires more knowledge than any other.

If you stick to "normal", yes, but there are plenty of special wishes, as I already wrote in this thread: http://forums.madcapsoftware.com/viewto ... 13&t=13982

[NorthEast]

In comparison with Ms HTML, Webhelp is more vendor-independent and more flexible. Almost unlimited distribution flexibility. However, on the other side, bBecause WebHelp is uncompiled, and thus “open,” users could alter the text in a topic file. This may be a serious risk.

I think if you're worried about people editing your help (presumably locally), then you can't consider HTML Help to be more secure than WebHelp or DotNetHelp. Although HTML Help may be a compiled output, it is still quite easy to edit and manipulate. You can decompile a CHM to a HTML Help project and recompile it; Microsoft produce a free tool called HTML Help Workshop which can do this.

I think perhaps PDF is the only output format which you can consider to be relatively secure, since it supports a number of security features like locking the file from editing (in Acrobat).

[RamonS]

I think perhaps PDF is the only output format which you can consider to be relatively secure, since it supports a number of security features like locking the file from editing (in Acrobat).

And even with that alterations are possible, they may require more effort. Serving WebHelp from a secured server is as safe.

[i-tietz]

Online help means that the user has to have internet access on the computer he works with ... I suppose for your customers THEIR security is much more of an issue than YOUR security ...
One of those pills you will have to swallow.

[NorthEast]

I think perhaps PDF is the only output format which you can consider to be relatively secure, since it supports a number of security features like locking the file from editing (in Acrobat).

And even with that alterations are possible, they may require more effort. Serving WebHelp from a secured server is as safe.

Yep, no doubt; PDF is the only Flare output which supports security features, but I can't really comment how good that security is.

[LTinker68]

Online help means that the user has to have internet access on the computer he works with ...

I prefer the term "interactive help". "Online" does imply an Internet connection, but all of the help outputs can be run on the user's computer, so an Internet connection isn't required. WebHelp, HTML Help, and DotNetHelp are what I would call interactive help (IMHO).

As for security, you can modify your License Agreement to mention that they can't modify anything generated by your company, including the help. It's not a hard lock to prevent them from modifying it anymore than it's a hard lock to prevent them from backward engineering or decompiling your software, but it does give you a legal avenue if you find that they've modified your help output without your consent.

[i-tietz]

Online help means that the user has to have internet access on the computer he works with ...

I prefer the term "interactive help". "Online" does imply an Internet connection, but all of the help outputs can be run on the user's computer, so an Internet connection isn't required.

Doesn't this sound like "online" help:

Serving WebHelp from a secured server is as safe.

Or do you think he meant a server in the network of the customer? Would the customers have to do that themselves? Or is the software that complex (and expensve) that somebody comes around and installs all that?
Ramon?

[RamonS]

As you can read in Petra's book that I translated the term "online help" is used as a synonym for any kind of help that is linked to an application. Think decades back to mainframes and dumb terminals, the help (if there was any) came from the mainframe and for that you had to be online. The terminology was not adjusted for the PC era.

[i-tietz]

Serving WebHelp from a secured server is as safe.

What does it mean, then?

[LTinker68]

Serving WebHelp from a secured server is as safe.

What does it mean, then?

I think he means you can lock it down so external users only have read access, not modify access. Has nothing to do with whether the server is publicly accessible or not -- it has to do with how the server and folder structure is locked down.

[i-tietz]

I think he means you can lock it down so external users only have read access, not modify access. Has nothing to do with whether the server is publicly accessible or not -- it has to do with how the server and folder structure is locked down.

duh ... Is my English so bad that it is so hard to understand what I refer to?

My question is: If "Webhelp is served from a server" of any sort (secured, not secured, pink with green spots, ... ) it is not USUALLY "online" in its recent meaning, i.e.: a webserver accessed via the internet?

I know that there are constructions in companies when it's inside the network and not in the internet, but those situations are VERY far away from being the normal construction if the "webhelp is served from a server".
What are you trying to get at by denying that??

[RamonS]

Serving WebHelp from a secured server is as safe.

What does it mean, then?

I think he means you can lock it down so external users only have read access, not modify access. Has nothing to do with whether the server is publicly accessible or not -- it has to do with how the server and folder structure is locked down.

YES! That is exactly what I meant and I think wrote as well.

[LTinker68]

My question is: If "Webhelp is served from a server" of any sort (secured, not secured, pink with green spots, ... ) it is not USUALLY "online" in its recent meaning, i.e.: a webserver accessed via the internet?

If that's your definition, then you can't use "online" in conjunction with WebHelp running on a web server within your private LAN or WAN. So you can't use "online" to define the kind of help output you can create from Flare, because it can run on web servers that aren't on the public portion of the Internet. Heck, it can run on a web server on your local computer if you have Windows XP Pro or higher. By your definition, PDF output could be online help if it's accessible from a web server on the Internet and HTML Help (.chm) wouldn't because it can't run from a network drive or web server.

That's why I prefer to say "interactive help" -- it has nothing to do with how the help is provided to the end user but rather describes the type of help it is. "Print help" being the other type of help.

[i-tietz]

If that's your definition, then you can't use "online" in conjunction with WebHelp running on a web server within your private LAN or WAN. So you can't use "online" to define the kind of help output you can create from Flare, because it can run on web servers that aren't on the public portion of the Internet. Heck, it can run on a web server on your local computer if you have Windows XP Pro or higher. By your definition, PDF output could be online help if it's accessible from a web server on the Internet and HTML Help (.chm) wouldn't because it can't run from a network drive or web server.

Ok. Yet another try: I didn't mean that it can or cannot run on a server inside the network. I mean that thar is not what most users and customers USUALLY think of when they hear that it is "Webhelp on a secure server" ... I know that there are constructions that have software and help on an internal server and yes, sometimes that is a webserver.
I assumed that if sb writes "Webhelp being on a server" it means that the help is being offered in the internet, because that is MOSTLY what it is. And if it is the internet, users/customers have other security issues than the producer.

And yes, "online" 20 years ago is not the "online" of nowadays. Words change their meanings sometimes ... and you know that. Or are you trying to tell us that you write "Go online." when you want the user to switch on the PC? Or are you trying to tell us that you use "online" for the old AND the new meaning intermittently leaving it to the customer to find out what you mean if you talk about "online help"?

[RamonS]

Honestly, it should not matter at all if WebHelp runs on an intranet or internet server. The security ought to be the same.

[i-tietz]

Honestly, it should not matter at all if WebHelp runs on an intranet or internet server. The security ought to be the same.

Security for the producer, means: If you don't want anyone to change your content - yes.

From customer point of view: No. If the help is on a network server I wouldn't expect the https protocol as I would if it was a server somewhere in the internet ... and even a login for the help on an internal server is not necessary (in most cases), since other employees are simply not interested in that help and never visit that server anyway.