Skip to main content

Longhorn Help (or, The Way It Could Be)

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.

Then comes compiled HTML help, CHM files. Suddenly the world of HTML is open to the Help development world. Some people (not many, mind you) but some learn HTML inside and out. They learn Javascript and CSS. They learn that tool vendors can do really cool things with HTML technology. Better help is written. Disk space increases and video starts popping up. Suddenly Help and instruction collide and you have technical writers working with instructional designers and *gasp* working with developers. (Reality check: this scenario represents about the top 10% of writers/companies/developers. The usual adversarial attitudes abound in the technical writing/development world still.)

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.


Popular posts from this blog

Google Inbox: A classic Google product

My work domain (an EDU) recently had Google Inbox enabled so I had a good chance to try it out. My personal email is relatively quiet and, I believe, doesn't provide a good Inbox experience. Work is more active and requires actual management, something I've tossed many a tool at over the years. As part of my work life, I supported the Google Apps for EDU installation here and took a pretty extensive presentation to campus about how to manage large amounts of email.

Inbox is a classic Google product: the distillation of a number of excellent ideas into a set of half-complete features built for a use case most people don't meet. We've seen this in the past in products like ChromeVox, Google's Chrome extension for accessibility. ChromeVox works great on ChromeOS devices, but completely ignores the point that most users of accessibility tech (AT) don't have or want ChromeOS devices and come to services with their AT in tow. ChromeVox also ignores decades of convent…


Evernote, for better or worse, is the best note-taking service for my needs. It works across all my devices/computers/modes. It's fairly easy to get stuff into it. Hell, they even have 2-Factor authentication. The Windows app is a little clunky and my girlfriend and I have never been able to get shared notes to work properly (conflicted note! three times in the same grocery trip!), but what service is perfect? At least they have nice socks.

Everything, in fact, is pretty good as long as you don't screw up. And screw up I did. I'm not very regular about making backups, but I do make them every month or so. Once you figure out how to create a backup, that is.

There's a helpful Export Note option (which turns into Export Notes when you select multiple notes HINT). The export process is essentially opening All Notes, selecting every note, and then choosing Export Notes. Or something like that; Evernote never tells you, you're left to figure it out on your own. The file…

Happy Retirement Pat Sweeny!

In a previous life, I was an active member of the West Michigan Shores Chapter of the STC. I met a lot of really cool people there and learned a lot about what it meant to be not just a technical writer, but more about how technical writers can break out of the mold and accomplish things.

One of the people who did that was Pat Sweeny. Pat is (or was, by this point) the President and owner of The Bishop Company, a contract do-it-all house; they document, streamline and illustrate your process, and they do it damn well. Pat was one of the first people in that chapter to "get it", which is to say, he and his company understand that technical writing isn't going to be a department for very much longer, it's going to be a business.

He had the foresight to actually make it a business, but he also had something else. Pat was forever trying to better those around him. He would come to meetings (which was a big step beyond most people) and teach you things. Or he would come to …