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.

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."

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 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.

"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.

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.

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.

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.

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.

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.

Section IV

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.

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.

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

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

Comments and Discussions

All the examples of tasks with user assistance ('GUI help') that I have seen are very simple. But many tasks are the repetitive entry of data where you do NOT want the user moved from window to window of a wizard. If you want to see in-dialogue help overkill, see if you can get your hands on Microsoft Money. It might be okay for an absolute novice who needs to keep track of cheque and credit-card transactions, but it is completely frustrating for anyone with any knowledge of book-keeping to have to keep wading through endless dumbed-down filler explaining the bleeding obvious.

Users exist on a spectrum of novice <--> expert, so the user interface has to handle all levels of experience. Therefore, it makes sense to keep RELEVANT help near at hand for the novice but out of the way for the experienced user who just wants to enter data.

And rather than automatically using conditions to hide aspects of the GUI and the help according to the user profile, it nearly always HELPS to have them present but greyed out. At least the user then knows that there are alternatives. This can be of great assistance when a user has set an option or preference that causes widespread changes throughout many dialogues. By showing greyed-out alternatives, the user is able to realize that they have inadvertently switched off a functionality that they actually want, and go back and change the preference. ('Course it helps if one of the Related Tasks is that preference!)

While it is ideal to fully cater for the user, you also have to balance that against ROI of implementing a conditional user experience (GUI and help) against the higher costs of development, testing, and documentation.

As the philosopher said, "Just because you CAN do something does not mean you SHOULD do it"!

I've allways wished for a question, preferrably in the bluescreen part of windows install, asking: "Are you comfortable with computers, or do you want it easy?". Then if I press comfortable, I won't have to be offended by millions of "Idiot adapted" features and guides.The reason I bring it up here, is that I've allways thought that it would be much work implementing it, but I see now that obviously much effort is payed annyhow on usability.Don't get me wrong, I love usabillity, but not letting me view the contents of the hard drive (yes, that's disabled by default in XP. You all probably have forgotten all about that horrid experience;)) isn't what I call usable.

But it certainly does not sound something that I want to use. Dialogs split into tiny steps cluttered with help when I do not need it. Longhorn telling me what it is good for me to read. No contents page to allow one to see some sort of structure...

IMHO the key to good help is that it be written by people that actually understand what they are writing about. The reason I don't often read help is that that it generally only says the obvious and does not address my concerns.

Rather than try to improve the quality of the documentation (eg. by getting developers to write more of it) the Longhorn approach seems to be to move the other way. Making every thing superficially easy to use and explaining nothing.

You raise some good points. Sounds like me 6 months ago. I think this stuff is a real paradigm shift for most of us. Hey I was down-right angry initially when I first read about these changes.

Also remember this is just a glimpse of where things are going. LH is still a few years away. The new UI/UA Guidlines are only sketchy at this stage. Let's see how it pans out.

And obviously it will depend on the application. If you have vast amounts of reference material then the little help pane is obviously the wrong choice.

If I'm designing instrumentation display there is no way I want to start hiding critical settings and displays away - Some things need a specialist user. However for most software we need to do a better job.

>No contents page to allow one to see some sort of structure...

Thats a hard one to swallow, but that's where things are goingfor the User Assistance help at least. For the reference help and for big document sets I can't see us losing the TOC.

Anyway try and keep an open mind. In a few years time we should have this conversation again

However an embedded Web Page could be OK in that you will receive click events in your application.For 2000 and XP that could work fine. There is a small problem of tabing between application and Browser control - does no always work

All I did for mine (I use Borland tools) was to take a few panels. Make them white. Next I added text controls & made them blue and underlines. I responded to the OnClick events.

Then used MouseOver events to change text atributes like you would see on a web page.

Following the XP Visual guidlines I made the header items "Verdana Bold 8 point" and the other items "Tahoma 8 point".

Anyway you get the idea. I actually made it verypolished so that you could tab to each containerand collapse it (resize a panel).

I also Used PaintBox controls to allow me to do nice XPgraduated shading.

I have been interested in UI design since I saw articles on the Xerox Star using a mouse and a graphics screen.

Your article pulls together a lot of scattered information about the goals and design behind the Longhorn UI. It saved me a lot of researching.

I appreciated the tasks oriented approach and the user assistence and experience topics. And the thoughts on why are we documenting EVERYTHING when it is not necessary and never read.

My current product has a separate documentation section on each menu and each item in each menu. What a pain to maintain. I think I am going to delete menu documentation, as I am sure no one needs it or reads it. I do not need to document everything! What a relief!

My product uses "task panes" that relate to a category of tasks, as opposed to information on a single task. They essentially duplicated items in my toolbars and menubars. I think I will change this so that each task pane releates to a specific task and includes UA and related tasks. A general "Tasks" pane may also be needed that lists all available tasks.

I look forward to any future articles you hinted may be in the future. Keep up the good work!

I think I am beginning to "Get It!".

PS. I am surprised that there have been so few comments on this article.

This stuff has been in my face for a few years now (ISV/MVP visits to MS) and it helped me write it all down. Glad you found it helpful too.

How big is a Task? I think a task can easily be made up of smaller tasks. Remebering that an overly complex screen can be a bad UX.

I'm trying to design Task panes for a few products at the moment. My main aim I think is to create some sort of work flow (or map) for the user to follow (to get the user up to speed faster). Like I said Tasks are usually scattered thoughout the main menu which is normally hidden, its gotta help the user if we present these tasks grouped by category and if possible in a work flow order. EG. In one project I have Reporting options under the File menu, Report Editing options under the Edit menu, and some Report view options under the View menu. Its gotta help some users to group most of these tasks together in a task pane.

Sounds like your current Task pane is pretty good. I guess you don't want to make the Task panes too dense with links other wise you are being counter productive. Maybe you could create some mockups and send these to some of your users to get their reaction... "Is this a better design?"

Yes, it is a good article. I think that Microsoft, itself, is finally 'getting it'. The whole ethos of goal-centric design and user experience isn't new - it's been around for many years in the 'non-ms-world' (have a look at the UML Use Case design approach, and how the 'User Experience Model' has gained more prominence in the Unified Process. Again, cutting out swathes of non-essential documentation has, pretty much from the offset, been an underpinning of many of the Agile Develop practices (which MS seems to be 'taking notice of' these days.

I think its great that Microsoft have now reached a point where they have such a mature product that they can concentrate on design an usability (not merely keeping the blue screens of death hidden )

All in all, thanks; a great article that gives us a glimpse of where Microsoft is heading.