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.

Comments

Popular posts from this blog

RIP Tom Petty

Tom Petty died today, aged 66. I won't claim to be a huge Tom Petty fan, but I've bought an album or two and sang along in the car to one of those songs everyone knows. I'll  stream a lot of his catalog today to remember the songs I've heard once or hundreds of times.

I also owe Petty credit for a singular moment in my life, and one I never expected to last in my mind.

Nearly 20 years ago, I was a fresh-ish faced transplant to Ann Arbor, MI by way of my first "real job" out of college, working for a software company in Dexter. I was renting a house with some other folks who'd also been displaced as a result of a fire at my first apartment. I was the only family member East of Lansing, which made me a contact point for anyone going through Detroit Metro airport.

Which is how my uncle Dean came to spend a few hours with me one evening. At the time, my grandparents (his parents) were wintering in Texas. My grandfather had health problems most of his life and…

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

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…