The Help Pane
| << Previous Page | Next Page >> |
In this next section, we'll explore what information is available so far on Windows Longhorn Help.
The Help PaneIn a Longhorn application, Help is displayed in the "Help Pane" which is normally docked on the right side of the Windows desktop.
The Help Pane, when docked, effectively reduces the desktop in size, much like the Windows taskbar does today, so no overlapping windows cover the Help Pane.
Larger Help Window
For larger content such as an overviews, multimedia, and tables, etc. that won't fit in the slim Help Pane, there is a larger free standing window that can be displayed, much like the Help and Support Center window.
The content for these Help windows is authored in a form of XML called MAML.
The initial reaction to the Longhorn Help Pane is usually "where will all the Help go?" Yep, it needs to go. We talked previously about putting UA directly in the UI and only documenting a task if necessary. A UI screen that's intuitive and discoverable may not need any Help. We have to break the habit of documenting every nook-and-cranny of the application.
We can also unload a lot of Help complexity by using other forms of UA such as Active Content and Video. Also any bulky reference type Help would still probably need to be authored in HTML Help 1.x.
What users need from UA
Let's finally acknowledge that software users only read the online Help as a last resort. Usability studies prove this. Look at your own habits. You don't have time to read Help. You just want to get from A to B in the shortest possible time.
Studies also show that when users do open the Help, they skim read. They scan the first line of each paragraph searching for that bit of text that will get them back to productive work.
Tech Writers Need to Change
This may be a difficult time of adjustment for tech writers, who typically spend months meticulously documenting every nuance of an application. Wake up, folks! Nobody reads it.
But it gets worse. Authoring in MAML XML is very different from authoring in Word or HTML (which have presentation elements). Some authors find it difficult to adjust to the transition.
But many authors do fine. This quote sums up UI/UA design for me. "The goal of the UI designer is to put the Help author out of a job". This from a Microsoft Help author and team leader who I highly respect. You don't need to document everything.
The buzz at the moment is XML, a structured markup similar to HTML. However, in XML, you define your own tags, and XML contains none of the presentation information found in HTML. Think of an XML-like a data base file. It contains hierarchical semantic information only. The interest to Help authors is that XML can neatly store large amounts of document text, different content types being wrapped in different tags. Using various in-house and 3rd party tools, the content can be extracted and transformed into say DHTML, PDF, RTF etc. Lastly add a style sheet.
It's not for everyone. It's a difficult road to travel, given the lack of mature XML authoring tools at the moment. Also your team needs to agree to what tags to use. If you do go down this path, make sure you have access to a programmer. But for those who need to solve the "multiple outputs from single source" problem, using XML can certainly pay off.
Enter MAML XML
AML (was MAML) is XML with a restricted set of content types designed for Microsoft Assistance. MAML comes at a good time given the current interest in XML. In time, Help Authoring Tool venders will produce MS AML-based authoring tools.
It may be worth mentioning that the XMetal XML editor is currently being used by some departments in Microsoft.
Shane McRoberts [MS Help Team] outlined the following steps for writing assistance for applications (taken with 2003 PDC slides).
Note: I asked Shane if he could expand on point #5. His answer demonstrates yet another way in which UI and UA can merge in Longhorn.
"This is referring
to exposing an easy assistance search entry point in application UI, as Office
does in the “Type a question for help” box in the tool/menu bar. The idea is to
make it easy and natural for users to ask a question and get their answer. They
shouldn’t have to “go to help” to ask the question, and the TOC is rarely a
useful entry point from an app. When they do ask the question, the Help UI opens
up and works in concert with the app (rather than covering/replacing the app
experience). Better integration with the OS experience and better integration
with the app experience both result" - Shane
In past operating system Help, troubleshooters would lead you just so far, then leave you at a dead end. In Longhorn, the plan is to eliminate as many dead ends as possible.
Here is the so-called Longhorn Assistance Escalation Path. It simply shows the path the user walks in finding assistance within the application. Notice if the user can't find an answer, s/he's not left at a dead end. At the very least, s/he is pointed toward the appropriate newsgroups or product support page.
A Microsoft Story
Recently the MVPs talked to one Microsoft department, which published over
40,000 web pages. Each author in the team was given several thousand web pages
to maintain. By examining the web stats, they found that only 70% of the
pages were never read. They removed all these pages and
never received a single complaint. Next, they reorganized the FAQ page
order so that popular pages were moved to the top of the list, and support calls were reduced
by 13%.
Continuous Publishing Model
With user consent, Longhorn Help will collect statistics on Help usage and at some stage, post the statistics back to Microsoft.
I believe you will be able to examine the statistics before it is upload to the server.
Microsoft will examine the stats, make any improvements required and create an update. The objective is to improve user experience by helping users find the help they need quickly so they can get back to work.
You can read about Longhorn Continuous Publishing Model here
(see also Search Navigation section below)
Won't we get confused with Help changing?
"You're not thinking 4th dimensionally Marty". This is not reference Help, but user assistance Help. The object with Longhorn user assistance is get an answer quickly and get back to productive work.
The Table of Contents is great for reference type Help, but usability tests show that it's not used in user assistance. In Longhorn, the table of contents (or taxonomy as Microsoft love to call it) is still hierarchical. However, only the current topic's parent/child relationships are exposed in the Help to the user. At the moment, this is exposed under a heading called "Related Tasks".
I like to think of it as a scoped view of Help, with the ability to quickly move the scope in or out by clicking the Related Task links in the Help Pane.
Yes, we still have an Index (I don't have a screen capture yet). It will have a new wrapper, but be something similar to the traditional index we had in HTML Help 1.x and MS Help 2.x.
Longhorn search will be a quantum leap forward. At the moment, it;s &aquot;watch this space". You can expect natural language query and results ranked by relevancy.
The continuous publishing model (described above) means Microsoft can monitor what we search for and tune the search result and ranking, so that future updates deliver better results. The hottest queries get higher ranking in the search results.
Microsoft also monitor Newsgroups and support call data when deciding how to retune a Help system.
"Active Content" provides Longhorn Help with the following additional features:
Similar to HH 1.x shortcuts, where ShellExecute() is used to run an external program.
Security & Shortcuts? At this time the toughest security in Longhorn is found when installing stuff onto the local machine. However, once content is on the machine, shortcuts can be used to run any local content.
Imagine we need to write assistance for setting the screen resolution. In Longhorn Help, there are three ways to do this:
EG. The following verbose Help will no longer be seen in Longhorn:
But maybe users want to see all the Help at once?
"You're still not thinking 4th dimensionally Marty". From your user's point of view, they just want to fix the problem and get back to work. Again think about how you use online Help. You don't.
However for the author, it may be a different story. I'm hoping that the Microsoft Help Team will provide an option that allows Help authors to easily switch between different content. Otherwise, it may get very confusing writing and testing our Longhorn user assistance.
Can MAML be extended?
In Longhorn, programmers can write behaviors to extend the Help, similar to how we use ActiveX to extend HTML today. There are a number of behaviors that will ship with Longhorn Help.
Like with ActiveX, you will need a programmer's assistance if you want to write your own behavior.
Web Links
|
| << Previous Page | Next Page >> |
