Call for Help for DotNet Online Help Authoring Application

# re: Call for Help for DotNet Online Help Authoring Application

Hi Jeremy,

If you haven't seen MadCap Flare yet, then you should definately give it a look. In full disclosure, I work at MadCap, but we have a dedicated new output format specifically designed for use with .NET Winforms. The format is called DotNet Help. It, and the Flare application, were impressive enough that Microsoft chose Flare as a showcase application for the launch of Visual Studio 2005.

DotNet Help is a hybrid, it has a much more modern look and feel than the older Microsoft HTML Help (.chm file) but like that format DotNet Help runs in a dedicated viewer that we provide and allow free re-distribution of. The DotNet Help viewer is written in managed C# code and conforms to all of the modern Microsoft Windows security requirements. It also suports context sensitive help and even various forms of embedded help for .NET applications.

For more information you can go to our web site at http://www.madcapsoftware.com and in our downloads area you can download the DotNet Help API which includes all of the documentation and even code samples.

I hope that this helps,

Mike Hamilton
MadCap Software 7/21/2008 9:24 PM | Mike Hamilton

# re: Call for Help for DotNet Online Help Authoring Application

Hi Mike,

Thanks so much for the response. We've been taking a look at MadCap's site and product suite and it is indeed very impressive. We will definitely be considering it moving forward.

Thanks again for the help!
Jeremy 7/23/2008 7:30 AM | Jeremy

# re: Call for Help for DotNet Online Help Authoring Application

Apologies for not responding sooner.

As per Mike, I will state up front that I work for Quadralay and WebWorks.com.

Microsoft has blessed HTML Help 1.x as their current help standard for Vista. It is true that HTML Help 1.x is not a perfect fit for .NET applications. MadCap has created a custom WinForm based runtime which may ease integration issues for your application development team. However, it may come at the cost of impacts to your own documentation work flow. Still, hats off to MadCap for tackling a problem that Microsoft has shied away from.

I am interested in your characterization of .NET support being "flaky at best". Short of a roll-your-own approach, what exactly are your expectations for .NET support?

Presently, users may choose to leverage our existing WebWorks Help offering in the .NET environment or leverage public API bindings for HTML Help 1.x.


Ben Allums
WebWorks.com
8/8/2008 1:35 PM | Ben Allums

# re: Call for Help for DotNet Online Help Authoring Application

Hi Ben,

Thanks so much for taking the time to respond.

I apologize for my characterization of flaky, that may have been an oversimplification. Specifically what I was concerned about was the fact that I had a lot of trouble finding any references online to WebWorks support for the .NET framework. I did manage to find one example of leveraging WebWorks from .NET, but the example seemed to simply connect to a specific help file using a URL and the standard HTML Help API, as you mentioned. Although this is very likely sufficient, I was concerned about having literal path references to help files throughout my product and the fact that it was effectively an HTTP connection. This would require me to have to introduce an additional layer of abstraction while unit testing so as to not to have to load the help file each time.

A few of the other products we evaluated placed a pure .NET facade over the existing HTML Help API. I realize that these products are undoubtedly using HTML Help under the hood, but the additional layer of indirection gave us a bit more freedom when working with the help subsystem and allowed us to decouple ourselves a little further from it. We strive to decouple ourselves from as much as the underlying infrastructure code (not just Help) as we can. Our product line is composed of modules which are often licensed individually or in custom combinations so each module must stay loosely coupled to not only each other but the underlying infrastructure.

I realize that it would have been trivial for us to build a similar API over WebWorks, but for the price it was easier just to buy one already made which could be supported because I'm sure we would have inevitably made mistakes somewhere.

I sincerely appreciate you taking the time to respond to me, this action reflects incredibly positively on WebWorks customer service. I hope I've helped to answer your questions, if you have any others please don't hesitate to contact me.

Take care!
Jeremy 8/9/2008 9:59 AM | Jeremy

# re: Call for Help for DotNet Online Help Authoring Application

Jeremy,

I'm glad you found a reasonable solution for your problem.

One thing to note is that although the examples use HTTP URLs, you can replace them with any valid URL protocal. "file://", "https://", etc. What this means is that an additional component (HTTP server) is not required.

Regarding literal file path references, those are not usually sprinkled through out the code base. Using either the WWHelp API or Microsoft's HTML Help 1.x API, developers determine the help set location once and then simply make context specific calls into the API. The examples provided with the WWHelp API dynamically calculate the location of the help set relative to the program's execution location and set the help set URL appropriately.

Finally, the WWHelp API and runtime were specifically designed to allow for loose coupling between help set modules. I'd be very interested in hearing which package you went with to enable the smoother .NET/HTML Help 1.x based experience you describe. I sounds like an area where we could easily improve our offering.

Ben Allums
WebWorks.com
8/11/2008 12:10 PM | Ben Allums

# re: Call for Help for DotNet Online Help Authoring Application

Hi Ben,

Thanks so much for the help and the reply. I really do appreciate you taking the time to answer my questions.

As of yet, we haven't decided on an offering but I'll likely post here when the decision is made. I must admit though, your constant attention to not only seek this matter out but to do your best to resolve it has reflected incredibly positive on WebWorks' customer service for me.

Best of luck with your product!
Jeremy 8/14/2008 7:37 AM | Jeremy