Much has been made of the upcoming release of Windows, still called Longhorn. (Can we possibly get someone in Microsoft Marketing to stop that stupid Office campaign [warning: Flash site] and come up with a name for the next version of Windows?)
While I’m not convinced that Longhorn is simply a bunch of “fixes and cosmetic enhancements”, I’m also not convinced that Microsoft is going to deliver a compelling reason for lots of people to upgrade. They’ve already dropped WinFS and scaled back Avalon, both major incentives to use Longhorn.
That said, I do know of one thing that is coming that is actually kind of exciting. Terrifying in its own way, but potentially very cool. Longhorn Help. That’s right, I said Help. First, a little background.
Back in the WinHelp days, technical writers and developers rarely met, and when they did they exchanged barbs and went back to their own sides of the building. Then along came people who can write AND develop. They got a hold of the WinHelp engine and started writing DLLs that made up for the shortcomings of the Help implementation in Windows and made some usable, if not impressive, Help.
The Help got generally better, more robust and, well, helpful. One fundamental limitation still held many writers and developers back, however; Help was not a part of the application. It was a separate engine buried inside Windows, doomed to non-interaction and certainly not able to actually DO things for users (except within a very specific set of instructions).
And now, on the horizon, is Longhorn. Longhorn could change the face of Help development. Could. If Microsoft would have done one thing. Microsoft has pledged to maintain the Help engine not just for CHM files (one level of backward compatibility), but also for WinHelp (five levels of backward compatibility). Which means that all those people who cut their teeth on WinHelp, and know it inside and out, will not switch until they’re forced. They have provided no incentive (or demand) that anyone in the Help world change. Which is bad. Why?
Because of this. Longhorn Help is built on MAML, the Microsoft Assistance Markup Language. It’s a proprietary XML language specifically written for the User Assistance in Longhorn, and it’s also the first engine able to make actual end-to-end User Assistance. Why?
Help topics can use system data from Windows to determine the most appropriate content to display for the user.
For the first time in a Windows environment, writers have to work with developers because now writers have the ability to provide accurate, on-demand, personalized content. Oh sure, tool vendors will make much of this functionality available through their tools but, as with the previous incarnations of Help engines, the really useful stuff will come from that top 10% who can hack the system to make it do what they want, not what a tool dictates they can do.
Microsoft has demonstrated the ability for UA developers to have multi-tiered assistance. If the user doesn’t accomplish something by being told how to do it, you can do it for them (with some limitations). A user shouldn’t see some part of the UA because of rights restrictions? No problem; Longhorn Help is aware of the current users permission level and limits topics based on those rights. No solution was found anywhere in the UA? Within the same panel, the user can connect to a support forum or live support.
Is this pie-in-the-sky kind of assistance? Sure, because there’s nothing forcing people to learn how to develop User Assistance at this level. The adoption rate of writers/developers/companies will be driven by not just the adoption rate of the OS (which could potentially be glacial compared to XP), but also by the perceived “unnecessary” cost of training writers to be quasi-developers or the outright unwillingness of writers to learn the new technology.
This also requires a fundamental shift in the way User Assistance is written. First, it has to be developed as User Assistance, not Help. Help is informative, demonstrative, and expository. It is not well-suited to assisting users, because it can’t. Longhorn Help can, but only if you program it to do that.
Which brings up the second major shift. UA is programmed, not written. Yes, the instructional parts are written, as is much of actual assistance. But, like an interface, the words are minor parts of a larger solution. UA should be a solution, not a manual.
I’m looking forward to seeing what writers can do with Longhorn help (which I see has been dubbed TrésHelp). But, what I’ll be really interested in seeing is what the other 90% of writers can do. I said in another post directed to MadCap Software: “let writers write, designers design, and everyone publish”. That still holds true, but I think many people who self-identify as “writers” will soon be redefining that role. Should be a fun ride.