Section I
This document takes a look at what's happening in the world of Windows User Interface (UI) & User Assistance (UA) design as we move toward a Windows Longhorn future. What trends are emerging and what can we leverage today?
At Microsoft, "User Experience" now has a prominent voice in UI design. The User, not the System, is once again at the centre of UI design. As a result, we are seeing new UI design guidelines emerge, as well as better designed software. Windows Longhorn, even with its new technologies put aside for the moment, is looking very promising.
Longhorn UI and UA boundaries are blurring. The voice of User Experience is saying "Give me one task to do at a time. Make the UI more intuitive. If required, write UA directly into the UI. If I do need help, make it brief and to the point so I can get back to work quickly. And don't leave me at a UA dead-end".
Caveat: At the time of writing, Longhorn Beta 1 is not available. Information and links in this article may change without warning.
So where's the big fat Help window?
A year ago the Help MVPs and ISVs were shown an early preview of the new user assistance help for Windows Longhorn. I was disappointed. We had been expecting a new and improved Help window, more powerful and flexible than all the Help windows of the past. Instead we got this little side Help pane and the much loved expanding TOC was gone. We had been providing the Help Team with feedback from the online communities and our customers for several years and this just didn't make sense.
Well it took me awhile to "get it", but Longhorn is much more than just leveraging new technologies and redressing Windows.
Microsoft's Help Team were asked to create the best "User Assistance" for Longhorn and its applications, not a new container for reference documentation. The new Longhorn "User Assistance" model is an evolutionary step forward in application online Help. As you read this article I hope you will catch the vision a little quicker than I did.
So is there a new reference Help window?
This question was raised recently at PDC 2003. Speaker Shane McRoberts (MS Help Team): "We are looking at converging Longhorn Help with VS/MSDN Help. But I probably shouldn't comment on that too much at this stage".
So, it will probably happen eventually, but maybe not for several years. The Microsoft Help Team is clearly focused on designing Longhorn User Assistance at the moment. When it does happen, maybe it will run on the Windows Longhorn platform only. Who knows, a lot can happen in the space of a few years.
In the meantime, we continue to use MS HTML Help 1.x for our reference libraries, and MS Help 2.x if you are integrating into Visual Studio 7 documentation. Now let's get back to talking about User Assistance / application based Help.
Up to now, our model has been to write a neat, well-designed UI coupled with a massive Help file that documents every aspect of the software. But our software has a high learning curve, overly complex screens, and verbose Help that nobody reads. We need a better approach. We need to evolve UI design.
According to Microsoft, we need to let User Experience (UX) drive our designs. Hey, putting the User at the center of our User Interface design makes perfect sense to me.
Define User Interface (UI)
Here is a nice definition of UI from msdn.microsoft.com. Notice the fresh new emphasis on "user experience" appearing in all new Microsoft publications.
"User experience and interface design in the context of creating software represents an approach that puts the user, rather than the system, at the center of the process. This philosophy, called user-centered design, incorporates user concerns and advocacy from the beginning of the design process and dictates the needs of the user should be foremost in any design decisions."
Experience Computing
Microsoft is all about UX at the moment. Here's what Microsoft Group Vice President Jim Allchin said at WinHEC 2004.
Allchin also declared the coming product waves to be part of what Microsoft calls "the experience economy," where only those products that think through end-to-end experiences will be wildly successful...
Experiences, Allchin said, will focus on the "doing," or the entire flow of events that a user will need to perform in order to succeed at a task. In Microsoft's current operating systems, these experiences include the Windows XP photo acquisition and management system and the roles-based management tools in Windows Server 2003. "But we need to do much more," Allchin said. And in the upcoming waves of products Microsoft will issue through 2005, he noted, the company will do just that.
[Read the full article at SuperSite.com]
Aero & other Longhorn code-names
User-centered UI design is so big in Windows Longhorn that it even has its own code-name: Aero. This quote from the Longhorn Dev Center explains some of the new Longhorn code-names...
Aero is the new Windows user experience. Aero consists of guidelines, recommendations, and user experience values that help your applications get the most out of the Microsoft Windows Code Name "Longhorn" pillars: rich presentation (code-named "Avalon"), data (code-named "WinFS"), and communication (code-named "Indigo").
The 3 Longhorn technology pillars referred to here are:
- Rich presentation (Avalon).
Longhorn leverages the power of the latest graphics cards to bring big advances in graphics and animation. These advances will be leveraged to make computing more fun, and more importantly, to improve UI design and UX.
- Data (WinFS).
The WinFS (Windows File System) combines NTFS + SQL (code-name Yukon). The humble hard disk is now a powerful relational database. Finding data should be extremely fast and easy by today's standards, even on a disk with terabyte capacity. Combine this with the ability to attach metadata to your files and you have endless possibilities.
- Communication (Indigo).
Indigo is Microsoft's programming model and framework for building connected applications and Web services. All good for the UX.
Aero Graphics
A quick word on graphics.
There are two levels of user experience in Longhorn, currently called Aero and Aero Glass.
The Aero user experience is built on the low-level Longhorn graphics API (Avalon) and requires a graphics card with DirectX9 3D GPU, AGP4x bus, 32MB of RAM, minimum resolution of 1024x768 (XGA).
The Aero Glass high fidelity user experience uses high-end visuals and transitional animations. On top of the Aero requirements, it requires 64MB of RAM (128MB to 256MB recommend).
In addition to these two levels are the classic Windows 2000 type visuals. Classic visuals may initially be the choice of corporations.
WinFX & the Aero User Experience
WinFX is not just another loosely related collection of Operating system APIs. The WinFX library is very well-structured and designed, and will help programmers create better UI that conforms to the Aero user experience. From msdn.microsoft.com...
"For programmers the WinFX� managed classes make it easy to build your applications with the Aero user experience. In addition, applications that apply the Aero user experience guidelines have opportunities to integrate more deeply with the Windows shell and thereby get more exposure to more potential customers. Aero's advances in usability and aesthetics will help excite and empower your customers."
|
Avalon WinHEC PowerPoint presentations:
More information on Avalon, WinFS & Indigo:
Paul Thurrott articles:
|
Section II
Remember when product releases were once every three years? Today the pressure is on companies to deliver software releases and updates once or even twice a year.
What can we do to fast track development?
Following Microsoft's lead will save you time and money.
- Use the Microsoft design guidelines.
They will reduced your design time, and your customers will feel more comfortable with your software. (Part of Windows success is "Learn one application and you learn them all.")
- Keep up to date.
We are in a time of rapid change. Keep up-to-date by attending Microsoft free conferences and reading web articles and books.
- Programmers need to be familiar with the Microsoft Windows APIs.
Reinventing software libraries is a waste of time. The Microsoft APIs are used by millions of programmers, and are well documented and tested. Also the Internet has volumes of material written on them.
- Programmers move to managed code.
.Net framework applications are more robust and the future of coding. Longhorn WinFX is all managed code. Even if your company is not ready to program in .NET, you can still start learning a .NET language now to be ready for the future.
Microsoft Design Guidelines
- Microsoft Online Book |
Microsoft IUI guidelines, although still evolving, are an essential read for all designers.
Microsoft is simplifying software by arranging screens so that only one "task" is displayed at a time. Using descriptive headings and hyperlinks and embedded user assistance directly into the UI helps the user to quickly grasp what they need to do.
Here is one highlight I've pulled out of the Microsoft IUI guidelines.
"IUI is an extension of the common Web-style interface. In the Web environment, pages have to be simple and task-based because each piece of information has to be sent to a server over a relatively slow connection. The server then responds with the next step, and so on. Good Web design means focusing on a single task per page and providing navigation forward and backward through pages. Similarly, inductive navigation starts with focusing the activity on each page to a single, primary task."
IUI Example: The Windows XP User Accounts dialog (non-domain login):
After reading the IUI Guidelines, you will notice several things about the above screen.
- The screen is focused is on a single task.
- The title and text clearly state the task.
- The screen's content suits the task.
- The Back/Forward/Home and hyperlinks provide web-like navigation to other tasks.
What else can we say about this screen?
|
1. The Web Page Look
Windows dialogs are looking more like web pages. Buttons, being more prominent, are still being used for the main OK/Cancel type actions, and descriptive hypertext is being used for all other links that launch dialogs and UA.
Small images have been used to clarify the purpose of some links, in this case Help, file browsing, and navigation.
There is not much of the familiar battleship grey dialog colors.
|
| 2. Embedded UA
Did you notice the embedded user assistance? And the lack of a "What's this [?] button"?
Help text is integrated directly into the dialog. The user has all the information needed to quickly grasp the concepts of the screen.
Extra help is available in the form of tool tips. Notice the "Welcome screen" hyperlink just opens the tool tip and has a dotted underline to indicating that.
"Related Tasks" - IUI is focused on tasks, not topics; on doing things, not features.
There is no general Help button that throws the user into the middle of paragraphs of dense Help text, which leads to a bad user experience. Instead, there is one Help link "[?] Using your own picture" which opens a simple task focused Help pane.
Notice in particular that Microsoft has not written Help for every control on the dialog (which is what we typically do today). The embedded Help is enough. There is no need to document every control, and the more difficult task of "Using your own picture" is the only additional Help written.
|
| 3. No Overlapping windows
Another feature of this dialog is that there are no overlapping windows. Related tasks appear in the same window and links move you between tasks.
Microsoft usability tests show that novice users get confused with multiple windows. So as much as possible, Microsoft is trying to keep multiple windows to a minimum.
|
| 4. Avoid Technical Language
Longhorn will try and avoid technical language as much as possible. Not everyone is on the same technical level. If we can explain while avoiding technical jargon, all the better.
The examples above simply talk about "Pictures". The discussion never heads off into JPEG and GIF files.
|
In this Longhorn Help example, the user assistance changes as you mouse over the radio buttons or change focus.
Newer applications implement a "Tasks Pane" containing a list of commonly used tasks. The tasks are grouped by category and ordered if possible by work flow.
Typically, in complex software, a user climbs a steep learning curve, get productive, then after a break from the application needs to climb the learning curve again. The Tasks Pane is a great idea as it puts the common tasks in plain view, where normally they are hidden and scattered throughout the main menu.
The tasks can be shown/hidden by selecting the "View > Tasks" menu option or by clicking the "Tasks" toolbar button.
Here are screen shots of Microsoft Movie Maker 2 and Microsoft Digital Image Suite 9.
Section III
In this next section, we'll explore what information is available so far on Windows Longhorn Help.
The Help Pane
In a Longhorn application, Help is displayed in the "Help Pane" which is normally docked on the right side of the Windows desktop.
- It is displayed when Help is selected.
- It can be closed. It can be undocked.
- All applications share a single Help pane.
- Use back & forward buttons to revisit Help pages.
- You can add your own icon to brand your Help (the screen shot right uses the Windows XP icon).
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.
UA the Longhorn Way
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
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 MAML-based authoring tools.
I wont say any more about MAML as you can read more yourself on the Microsoft web site.
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).
- Identify user goals and tasks
- Consider adding assistance directly into the UI
- Document/implement tasks
- Call API to invoke task (show help pane)
- Surface search in your user interface (see Note below)
- Distribute Help with your application
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.
Hey, where's the TOC navigation?
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.
Index navigation
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.
Search navigation
Longhorn search will be a quantum leap forward. At the moment, it's "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:
- Shortcuts
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.
- Expanding sections
Expanding/contracting sections will be available, just like we have HTML Help currently.
- Active Content Wizard (ACW)
Imagine we need to write assistance for setting the screen resolution. In Longhorn Help, there are three ways to do this:
- Tell me - Traditional type Help where you display the steps on screen.
- Show Me - Longhorn shows you how to get to a dialog and execute the command. At each step, you are prompted to interact with the system. e.g., Click a button. Select a resolution. And so on...
- Do It - The system simply performs the action for you. You really don't care how its done. Just do it and let me get back to work.
- Content adapts to User/Machine state
Conditional markup combined with the ability to detect the current user or machine state means we can display only that assistance that is appropriate to the user's current environment.
EG. If the user is on a domain, does s/he really need to see the non-domain Help? Probably not, the author can hide that bit completely from view.
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.
- "Active Content" (see above) uses behaviors to detect the current user/machine states and display conditional markup.
- "Active Content" also uses behaviors to achieve the expanding / contracting sections of the Help.
- There will most likely be a behavior that allows Flash to be embedded in Longhorn Help.
Like with ActiveX, you will need a programmer's assistance if you want to write your own behavior.
Section IV
Here are some brief design tips.
Spec It
List what the product needs to do, and how it's going to do that. Develop a spec. Get people from different departments involved.
Proto Type
Experiment with screen design up front. Build prototypes. Do it before coding begins. You don't need to be a VB or Delphi programmer. Do it in Flash. Do it in PowerPoint. Do it in pencil sketches. Reorganize screen shots by using cut and paste in your favorite Paint program.
Usability Tests
Get users of various experience to look at your prototypes and record their reactions. Take it small steps. Focus on just a few tasks and a few users each day. Try not to lead the tester but offer help if needed. Have someone else from the team record video or take notes.
You will be surprised at the results you get. Often we are too close to a design and oblivious to the design flaws.
Ask for feedback
Ask your users for feedback. Again, we can be completely blind to design flaws until some user says "it took me hours to find out how to do xyz". Talk to your users.
Scenarios
Microsoft designers now talk in scenarios. For example: I may say I want some feature. The MS guys will say to me "give me some scenarios demonstrating of how you would use this feature".
Its another useful way we can be User Centric in our design.
Refine your design. If the UI is not easily discoverable, consider adding descriptive headings and embedding UA directly into the screen. Break complex screens down into simpler tasks (all the stuff we talked about over the previous pages). It's an iterative process. Run the usability tests again.
Recently, Microsoft decided to make their processes and people more visible to the world. Over the last few months, interviews with Microsoft people have been popping up everywhere on the web. Some of them are very revealing and give us a great insight into how Microsoft carries out design and usability testing.
Paul Thurrott's (WinSuperSite.com) interviews with Hillel Cooperman and Tjeerd Hoek from the Longhorn User Experience team (formally known as the Shell team). This two-page interview is a great read.
WinSuperSite: Interview with Hillel Cooperman and Tjeerd Hoek (User Experience team)
Another favorite site is the new channel9.msdn.com. Here the people behind the various Microsoft technologies are interviewed informally using a small DV camera. You then have a chance to contribute to the resulting forum.
Channel9 Interviews
Kam Vebdbart - What influenced the visual design in Longhorn?
Scott Swanson - How do you come up with new features for Help in Visual Studio?
Last Words
Programmers and Help authors will need to work more closely. Get actively involved with design in the very early stages of your product before coding begins.
What if I want to stick with CHMs for now? That's not a problem. HTML Help 1.x is fully supported under Longhorn, but you won't have the deeper integration with Longhorn Aero UX. WinHelp files are missing from the Longhorn landscape, but Longhorn still supports WinHelp files at least for the time being.
Well, that's a small glimpse of what's happening in design as we move toward Longhorn. Keep an eye on Microsoft & Longhorn developments. And keep reading those web articles.
Many thanks to Char James-Tanny fellow Help MVP for assistance with editing this article
