Html Help 1.x grumbling
It’s pretty sad when you look at the state of our current Help implementation on Windows. The official Help engine for application continues to be HTML Help 1.x (1.4 by now). As an engine Html Help is not the worst of things, but what really is a major pain is the fact that Microsoft has completely abandoned this platform and never bother to even fix the most fundamental problems.
Here are some problems that bug me personally:
The HTML Engine looks like it’s from the last century. Hey, wait a second it IS from the last century! Html Help showed up with Internet Explorer 3.x which was what in 1995? This platform is 10 years old and hasn’t changed or been maintained since.
On the UI front the CHM viewer has no themes support. Huge buttons that waste screen real estate and a UI that generally looks cheesy and is not real user friendly. 16 color stock icons don’t exactly help here either.
Icons in general are a problem for HTML Help 1.x. To embed custom icons you have to jump through some major hoops. Actually let me re-phrase that – you can’t embed custom icons and reference them. Instead you have to reference them externally with a hard coded or pre-defined system var path. The only way I’ve been able to embed custom icons is to ship a separate icon file in the Windows directory. This is a bug in the help engine – a simple fix. It’s been broken since the beginning. How hard could this be to fix?
Icons support only 16 colors. What year are we in again??? Then there are all sorts of issues with embedding multi-media content. Inability to print images out of the help file if the images sit in relative paths and the image tags contain extra markup. Printing in general is pretty sad. Ok, more of an HTML problem, but still maybe there’s a better way to print when we know topic boundaries? Well, there’s plenty to complain about.
In the meantime we have HTML 2.0 which is not an official Help Platform and it’s been ‘officially’ abandoned by Microsoft as well. So Microsoft has announced – “Gee, we won’t publish this platform as a help platform either. But hey, since we know HTML 1.0 sucks, we here at Microsoft will use it instead of HTML Help 1.0 for our own products” (specifically VS.NET). Nice.
Ok, so no Html Help 2.0 for our applications. So, what’s next? Next stop is Longhorn. Which means limping along for another 2 years at least with a crippled help system. From what’s been announced for the Longhorn Help System it’s not very inspiring either. Longhorn will feature a more content driven approach, which is good, but at the same time it’s getting away from HTML as the formatting standard. This means it’ll be a lot harder to build tools for it of course because with a non-HTML rendering mechanism it’ll be a lot harder to ‘preview’ or edit in place the help content and see it in it’s real final format. This may mean we can go back to imprecise WYSIWYG editors that will approximate what the output will look like. I sure hope Microsoft will provide some mechanism to to display help content without a full compilation into the final help file. My guess is this will be an afterthought or left out completely.
Help is not one of the high visibility items, so any complaints generally fall on deaf ears. But let’s remember that when we deliver an application a good help system should be part of the solution. So you have this really slick application and then you pop up help and it looks like you had your sixth grade kid do the UI design. Hmmm…
I’m not expecting any revelation here, but fixing the many known bugs in the existing help engine would at least take us through the time to the next big thing that will make life hard again.