Engineering Windows 7 : Design

A Little Bit of Personality

e7blog — Sat, 02 May 2009 10:00:00 GMT

Greetings! Based on the data we’re seeing we know a lot of folks on MSDN/TechNet/Connect are probably busy using the RC (Release Candidate) for Windows 7. Thank you!!! And of course many folks are looking forward to downloading the RC and using it as we expand the downloads—we’re looking forward to the participation and seeing the data that will help us validate the RC. We’ve talked about making sure that you are “in control” of Windows 7 and one of the ways that people are in control of their PC is to personalize the experience. With the RC you’re going to see some of the new personalization “elements” in Windows 7. In this post, Denise Trabona and Samuel Moreau of our product design team provide a behind the scenes look at some of the work. Be sure to check out the links below the images as you can see a lot more work by these talented artists. Note, these are just thumbnails for this post so be sure to enjoy the full screen images in the RC. --Steven

PS: Just a reminder, that just as with the pre-beta and beta we’ll be testing out Windows Update and the system for doing patches and updates. So along with new drivers you might also see some other updates flowing through the system.

One of the most exciting parts of engineering Windows 7 has been the wide variety of work that gets done over the course of a full product cycle. As evidenced by the variety of topics just in this blog, one can see that we are hard at work at all levels of the product. For fun, we thought folks might enjoy hearing some of the story behind the new personalization work in Windows 7.

As some folks have noticed, we are unveiling some new personalization content (wallpapers, glass colors and sounds schemes) in the RC build which allows people greater flexibility to personalize their experience. One thing we know is that Windows users love to express themselves by changing the desktop background and like many past releases, Windows 7 includes content in the box that allows you to begin customizing your experience immediately.

A picture speaks a thousand words

In developing the personalization features, we knew that we wanted great content for people to express their personal style. Because the desktop background is such a vibrant surface, we wanted to focus on providing quality content that demonstrated how creative people could be with this feature. When folks send us screenshots using the feedback button, we are regularly inspired by the rich diversity and personality of the wallpapers that people choose.

As we thought about how we wanted to approach personalization in Windows 7, we knew one way was to honor our lineage. In the past photography has been featured heavily Windows. Some of that photography has been quite beautiful and has become a proud tradition we wanted to maintain. In addition, we also wanted to explore new territory and expand our visual palette. In the realm of photography, we kept a theme focused on landscape photography which is our tradition, but added new themes for architecture and nature. Much of the this imagery is from our stock imagery partners, but we also had the good fortune to work with a talented local photographer named Will Austin, who has photographed all over the world on many subjects with an emphasis on architecture. Will’s photos provide a little bit of the local flavor of the Seattle area that we are proud to call home.

Raising the bar of inspiration and delight

With the photography covered, we tried to broaden our coverage to include additional images that would inspire, delight and invigorate people’s imaginations. We wanted to stretch into some new content that felt unique, timely, and with a distinct point of view. Our goal was content that balanced the timelessness of great photography with graphical illustrations that are energetic, modern, and fresh. On top of it all it was also important to achieve a rich variety in the illustrations to appeal to different tastes, genders and ages, color ranges from quiet to loud, and from large compositions to small and detailed.

Inspired by our neighbors in Zune, we worked with an agency called 72 and Sunny to search for illustrators around the world to create one-of-a-kind art work for you to have in Windows 7. In the process of looking through tons of samples, we sought a group of artists whose styles seemed both incredibly varied, to cover the broad diversity we were after, and maintained a common thread that we felt was applicable to the overall tone we were striving to achieve. Then began the fun part, with little more than some simple guiding words (light, energetic, inspiring, optimistic, etc.), the artists went off with a blank canvas to create concept sketches of their original pieces.

Iterate and refine

We still remember the first chance we got to review the artist’s initial sketches and concept work, and right from that moment, we knew that these images were going to be a lot of fun. The next step was to iterate back and forth a few times to make sure certain goals were achieved and get little details just right. For example, a couple of things that were important to us were how the image flowed under the new task bar and striking the right balance between visually compelling, and not too distracting when it came to finding that important file on your desktop. It’s tricky to find the right balance and we were fortunate to have an amazingly talented set of artists and our friends at 72 and Sunny to work with on this project.

Windows is for the whole world

Finally, we wanted to recognize the global audience of Windows by seeking out illustrators with varied backgrounds and styles with the intention of representing and appealing to people all around the world.

With that, we are honored to introduce the amazingly talented artists and the work that they contributed to Windows 7 personalization.

Yuko Kondo
From Japan, now resides in London, England

Katharina Leuzinger
Born to Swiss and Japanese parents in Zurich, Switzerland, Katharina Leuzinger now resides in London, England

Osmand Nosse
Wicklow, Ireland

Klaus Haapaniemi
From Finland, now based in London, England

Chris Sickles of Red Nose Studios
Indiana, United States

Punga
Buenos Aires, Argentina

Pomme Chan
Born and educated in Bangkok, Pomme Chan now resides in London, England.

Kustaa Saksi
Amsterdam, Netherlands

Paul Hwang and Benjamin Lee of Nanosphere
Los Angeles, California

Adhemas Batista
From Sao Paulo Brazil, now resides in Los Angeles, California

Kai and Sunny
London, England

Nan Na Hvass
Born to a Danish father and Chinese mother in Swaziland, Africa, Nan Na Hvass now resides in Copenhagen, Denmark.

We hope this post has given you some insight into the Windows 7 content. We also hope that we achieved the goals we set out for ourselves with this element of Windows 7.

-Denise Trabona and Samuel Moreau

Designing Aero Snap

e7blog — Tue, 17 Mar 2009 10:00:00 GMT

Here’s a behind the scenes look at the design of the Aero Snap feature in Windows 7. We thought it would be fun to take a look at the overall design process of the feature and the tools and techniques used. This feature poses a unique design challenge in that you just use the feature without any user-interface specifically to invoke it. As with all features this is a collaboration across all of our engineering disciplines. For this post, Stephan Hoefnagels, a Senior UX designer, presents the design perspective. --Steven (P.S., keep an eye out on the Microsoft MIX conference this week!)

In Managing Windows windows and Follow-up: Managing Windows windows we talked about, and you shared, some interesting window management scenarios that we might address in Windows 7. We also touched on some data around typical configurations, as well as goals that guide our thinking in this area.

In this post we’d like to have a closer look at the Aero Snap feature that many of you have already been able to experience in our PDC builds, and of course the Beta. We’ll briefly describe the feature itself, but mostly we’d like to invite you to take a behind-the-scenes peek at our design process so far, and share our iterations, challenges and considerations.

Goals and scenarios

As we explained more in depth in our previous post, our top goal for the Aero Snap feature is to provide you with an effortless way to position your windows the way you want them. We want to reduce the number of clicks and precise movements needed to perform common activities. In a general sense, we want you to be able to manage your windows with confidence and create a feeling of power and control. This is something we touched on in our post on the Windows 7 taskbar as well, and really a theme that weaves through much of our new desktop experience.

Before we look at how we address our goals in the design, a quick note. In the scenarios below you’ll notice sequences of interactions that are fully written out. Sequences like: select the window, click the caption button, and then resize the window. Looking at interactions at this level of detail makes for somewhat awkward reading. These individual steps are so small, and so frequent, that for most of us they normally barely register. Why not simply gloss over some of those details? Well, we spell out sequences of events this way to force us to be consciously aware of the amount of “overhead” that is sometimes involved to get to the task at hand. It forces us to realize what we normally might not. Also, besides providing insight in the problems, it provides us with the right level of detail to consider our solutions.

Now, let’s look at the design!

Side-by-side windows

As many of you mentioned, doing a drag drop operation from one window to another is sometimes a pain. Windows tend to overlap and to get them positioned right can require a lot of fine mouse movement. Oftentimes the steps are as follows: select a window, resize it appropriately, and position it on the screen so that enough of it shows for it to be a meaningful drag or drop target. Then repeat the same actions with the other window. Similarly, comparing content in two windows requires a lot of mouse clicks, resize actions, careful arrangement, window switches, and a fair amount of mouse mileage.

With Aero Snap you can grab a window and move your mouse to the edge of the screen and the window will resize to fill half the screen. Repeat with the other window. Now with two easy motions you have a setup that makes both of these scenarios much easier to accomplish!

Put windows side-by-side with Aero Snap by moving the cursor to the edge of the screen (left to right, top to bottom)

Vertical maximized windows

We know our users love the maximized window state. Many love it so much that they maximize all of their windows and never even run in any other state! However, with screens increasing in resolution and widescreen layout becoming more prevalent, the maximized window state can lose some of its appeal in certain cases. E-mail is an example. Reading long lines of text across the screen is not ideal. Your eye simply cannot track a line all the way across. Web browsing is another example. Content will sometimes not fill the entire width of the screen, leaving a lot of unused white space on the side.

Now, with Aero Snap you can you can maximize a window in the vertical direction only. When you resize a window to the top of the screen, it will also resize all the way to the bottom. Great for reading long blog posts!

Vertically maximize a window with Aero Snap by resizing the window to the edge of the screen

Moving maximized windows from screen to screen

We realize there are a few multi-mon users out there, especially amongst the readers of this blog ;-). Ever wanted an easier way to move a maximized window to another screen? A way that’s quicker than clicking the restore caption button, moving the mouse to the title bar, dragging the window over, and finally clicking the maximized caption button again? With Aero Snap you can simply drag a maximized window down, move it over and snap it to the top, all in one gesture. Finally!

Arranging windows on laptops

Arranging windows on a desktop PC can sometimes involve excessive fiddling, fine mouse movements and lots of mouse mileage, as touched on above. On laptops this situation is further exacerbated by the lack of a mouse, making some of these movements even more cumbersome. For these scenarios, and our power users, we’ve introduced some convenient key combinations. Hold down the Windows key and one of your arrow keys to give it a try. You may want to try holding down Shift as well, especially if you’re in a multi-mon setup.

Design process

OK - So those are the scenarios, and the way we chose to address them. Seems straightforward enough, right? Especially for those of you that have been using Aero Snap in out Beta build. It all behaves as you’d expect. But how did we get here? Well, in this next bit we’d like to something that we don’t do that often and really give you a peek into our design process so far and some of the snags we ran into along the way. Keep in mind that this is a brief overview and by no means exhaustive. While we allude to usability testing for instance, this post is by no means meant to give insight into the scope of those efforts. There will certainly be opportunities to talk about some of those topics in the future.

Let’s have a look!

Sketching

We’re back in early 2007, and after we established window management as a potential area of interest, and identified several appealing scenarios (again, see our previous post for more detail on that stage of the process), we started with brainstorms to generate ideas. “How can we make window arranging more efficient?” “More direct?” “More fun?” are some of the questions we asked ourselves. This was a multidisciplinary process, with disciplines like design, user research, program management and development involved. All in all there were around a handful of us, certainly less than a dozen, thinking about this space at the time.

We imposed a significant constraint on ourselves: we wanted to achieve our goals without introducing any extra widgets in our UI. Imagine an extra caption button on the window title bar for instance: this may not seem too bad for one window, but when we’re talking about 10 windows or more, we’ve all of a sudden introduced a significant amount of clutter on your screen. And that’s something that we simply didn’t feel good about. After all, as we shared in our UX Principles talk at the PDC, we believe in “Solving Distractions, not Discoverability”.

We captured our, many, ideas in very quick sketches that we shared via an internal website. Transferred from the whiteboards in our offices and hallways, these took less than 5 minutes to sketch each. The sketches below are some actual examples in which you can start some of the Aero Snap ideas forming.

Early ideas are captured in quick and disposable sketches

Interactive prototyping in early code

With so many ideas on paper we were eager to try out the best ones. Now was the time to prototype. Note that we are still very early in the process. We wanted our prototypes to be interactive, and we wanted to be able to live with them in our day-to-day work. So we chose to implement the ideas using early code that we could run on our work machines. For example, the image below shows a “smart resizer” prototype running on Windows Vista. Of course these prototypes are not “done” features that we could actually ship: they merely get the basic ideas working, and they definitely have more than a few “quirks” (bugs ;-)). What’s important however, is that they allow us to experience just enough of the interactions ourselves, as well as get feedback in usability studies.

Early “smart resizer” prototype running on Windows Vista, note the taskbar button created by the prototype (and the date in the calendar to get a sense of where we are in the process)

We use this firsthand experience and early usability feedback to iterate on the ideas as we hone in on the final design. We approach this part of the process in a very open minded way and allow ourselves to be surprised. Sometimes ideas that don’t look like much on paper prove to be startlingly powerful. On the other hand, we found out that others look much better on paper than they were in practice! Since we’re not invested in any one idea or implementation yet, we freely refine, and drop ideas.

Finally, the prototypes ease us into thinking about design details. And we might stumble on some insights too (of course we tell ourselves the real feat is to recognize the insight and hold on to it). Here’s an example from an e-mail at the time from one of the team members about a new version of the “smart resizer” prototype:

I noticed something changed. In the original version if I resized it to the max it “supersized” the window. Then if I resized the window smaller, it jumped back to the normal restored state. It was as if the supersize state was different than restored state. With this version when I supersize the window and then resize it again later, it doesn’t jump back to the previous restored size. There was something kind of nice about the supersized state being different than the restored state. We should think about it more and consider making that a part of the design.

After many a prototype we settled on the concept of side-by-side windows and vertical maximized windows. We’re getting clearer on what we want to build.

Detailed design: state transitions

OK - We’ve whittled down our ideas to a good, but not fully specced, set of interactions and behaviors. Time to start filling in the blanks by asking detailed questions. “What does it mean to have a side-by-side window in a world where there used to be only minimized, restored and maximized windows?” “How exactly would you get to and from this new window state?” The e-mail snippet above already pointed to some of these questions.

Currently the common window states are (left to right) minimized, restored, and maximized, how would side-by-side and vertical maximized windows fit in?

Let’s look at the state problem in detail. Below is an example of two proposals made during this time that show how you can move from one window state to another, for all the different states. Which model is better?

Two proposals detailing the various ways we can transition between states

To answer that question we considered more specific questions like “What states do we want to link directly and how do we move between them?” “Is it compelling to go from a vertical maximized state directly to a maximized state?” “Should the vertical maximized and side-by-side states behave similar, as they look similar?” Our answers of course guided us to the model that you are now familiar with, which is model B.

But that’s not the end of it. More details need to be worked through, and more questions come up. “What if I want to move a vertical maximized window sideways?” “Resize its width?” “Then pull it down?”

Soon you’ll find yourself in elaborate sequences of events, many possible actions, and even more possible outcomes. Which would be the most expected when actually using the entire system?

To help guide our decision making process we established some guiding statements. Assumptions that we hold to be true. Examples are: “The intuitive way to undo an effect triggered by a mouse movement is to make the opposite mouse movement.” And: “It should always be effortless to go back to the previous “restored” state so as to avoid excessive work to get the window back to a reasonable size.” Or: “If the user specifies a width for a window in a given state, that size should be preserved across state changes when it makes sense.”

Using these statements we were able to answer questions like the ones above in a predictable way and as a result craft a predictable experience. And while the underlying state transitions and rules are fairly complex when added all together, the resulting behavior is, we hope, intuitively understood. That’s definitely something we’re aiming for.

Conflicting rules

Here’s an example of a sequence problem for the really attentive reader. When working through our many new state transitions, sometimes the rules that determine what should happen, conflict. Consider the following scenario. Two rules in our new window model are:

Dragging a window to the top of the screen maximizes it
The intuitive way to undo/cancel an effect triggered by a mouse movement is to make the opposite mouse movement

OK – Let’s try the following scenario in your Windows 7 build. Start with a restored window. Vertically maximize it by resizing it to the top of the screen. Release the mouse. Drag (don’t resize) down the window and drag it to the top again, all in one motion. Release the mouse. What happened?

Your window should be maximized. Which means in this case we chose to follow rule 1. We could have also followed rule 2, in which case your window would be vertically maximized. We figured rule 1 would more accurately reflect the user’s mental model for this scenario.

This is just one example of the decisions we had to make for each transition to and from a window state.

Throughout this process we made sure to preserve the subtleties in the current model. One small example that some of you may be familiar with that we did tweak is the scenario of dragging a window title bar off screen. In previous Windows releases we would snap the window back halfway in an attempt to provide you with just enough space to still move the window around, while optimizing vertical space as much as possible. We chose to be a little more deliberate and straightforward here by snapping back so that the entire title bar is visible. This way you can start to rely on the fact that all of your windows are always very easy to grab, also with touch, and move around. If we really felt half of a title bar is enough, why don’t we always half it, right? For our vertical maximized window states we of course chose to keep the entire title bar visible as well, leading to a solid story all around.

Storyboards and other visualizations

State diagrams are of course only one way to look at the world. We used various ways to communicate different aspects of the feature, picking our medium based on familiarity, availability and intent. We didn’t even shy away from the occasional ASCII art as you can see below! We’ll simply use whatever tool gets the point across. Most of all, interaction storyboards were a very valuable technique to help us understand the user flows, and even though this is only a small sample, you can see we did quite a few of those.

Feature details are communicated throughout using appropriate means

Accidental triggers

Besides figuring out the right state transitions, one or our biggest discussions was around when a state transition should exactly occur, or in other words: when the feature is triggered. We talked a lot about “accidental triggers”, i.e. running into the feature without deliberately setting out to do so.

Aero Snap is triggered by touching the edge of the screen with the mouse

From the very beginning we always made sure that our feature did not get in the way of current scenarios such as tucking a window off-screen to the side. After all, we don’t want to have a detrimental effect on your current, expected, way of managing your windows. That’s why you have to literally touch the edge of the screen with your mouse, not the window edge, to trigger the transitions.

However, at this time, the feature as you know it now was different in one very important, fundamental way. In our early builds, Aero Snap followed an “instant commit” model. When you moved your mouse to the top of the screen, your window would literally be maximized while you’re still dragging. That is, before you even release the mouse. Moving back in one motion would literally restore the window. We liked this approach as the “preview” was very accurate, i.e. the preview was the window, and there is a certain directness in not having a commit model.

Because our UI is invisible by design, we expected some accidental triggering. In fact in some sense we were relying on accidental triggers to help with the discoverability of the feature. However, after living with the builds for a while we got a little worried because accidental triggering seemed higher than we expected. From our telemetry data we saw people running into the feature, and then cancelling it nearly twice as often as committing. In our usability studies we observed confusion as to what exactly triggered the behavior. Was it the window touching the edge that did this? A gesture? Or something else?

We’re now in early 2008. What should we do? Cut the entire feature? We actually did consider this as an option. Again, we really respect our current window management behaviors, and the last thing we wanted to do is degrade the experience. More constructively, we took on the challenge to come up with a design tweak that would address these issues. We explored several solutions. Some conservatively centered on smoothing out the resize transitions, so an accidental trigger would at least be smooth. A conservative approach for sure, but probably not satisfying enough as a real solution. Others focused on trying to detect user intent more accurately, based on the angle of motion into the screen edge, or the speed of the motion. This proved much too complex to be predictable. Maybe we could trigger the transition only when double-bumping the edge? We were worried that this would degrade the experience of fluidity and flow of the current model.

In the end we settled on the implementation you’re familiar with. We don’t trigger until you release the mouse, making it easy to back out of the effect before anything happens to your window. In addition we provide you with a smooth preview animation, and a cursor effect to help you understand what just happened. This way you can be more deliberate in the future, and use the feature to your full advantage.

Did we solve the issues? Feel free to let us know :-)

Look and feel

It’s interesting to think back and realize that up to this point we had essentially designed a feature without any visible UI whatsoever. Now all of a sudden we have window previews, and a cursor effect. What should those look like, and how should they behave?

Well, luckily we had some things to go on. At this point we had already established a clear picture of our taskbar look and feel (we call it “personality” and will talk about it more in a later post). We had settled on using glass sheets for Aero Peek. We saw an opportunity to use the same visual representation for our preview windows. But how should the glass sheets appear? After experimentation, we settled on a scale animation that originates from the cursor. This gives a subtle hint as to where this preview window came from. We also made sure to animate our transitions. Try this in your build for instance: move a window to the top, and then to the side, in one motion without releasing the mouse. Notice the smooth morph of the preview? Why did we spend time on this? We believe “Small Things Matter, Good and Bad” of course.

Light effects are used to indicate the snap trigger, and glass sheets for snap previews

Finally, we tied into some of our ideas around “light” for the trigger indication. We tuned this to be noticeable, but not too loud and made sure to synch with other light effects in the system such as our touch feedback.

We hope this post has given you some insight in the Aero Snap feature, including our design process. We would love to hear your thoughts!

Stephan Hoefnagels

Engineering the Windows 7 Boot Animation

e7blog — Wed, 18 Feb 2009 11:00:00 GMT

As we connect through this blog and through all of those talking about Windows 7 it is clear that folks have a lot of passion around many topics. We learned early on about the passion around the boot/startup sequence and how important it was for that to go by quickly! At the same time, we know that it is really dull to watch a HDD light blink when resuming a machine from hibernate or powering up a machine. To improve this first connection with people, we set out to improve the boot sequence—jazz it up if you will. It sounds pretty easy, but as we looked into solving this we found it is a pretty significant engineering challenge. Our goal was to have fun while having no impact on the boot performance of the system. To explain this engineering and describe the boot sequence, Karen Wong, a program manager on our Core User Experience feature team, authored this post. --Steven

Design

We use the word “personality” to refer to some of the characteristics of software that connect emotionally with people. ‘Light’ and ‘energy’ are some of the terms we use to describe the personality of Windows 7. As we designed Windows 7 it became clear that in order to showcase these elements of Win7’s personality, we needed go above and beyond what we did with Vista’s boot visuals.

<\/embed><\/div>";" mce_src="http://blogs.msdn.com/blogfiles/e7/WindowsLiveWriter/EngineeringtheWindows7BootAnimation_F227/video4e0f79f2d526.jpg" galleryimg="no">

From a design perspective, we know that the visual presentation of a feature plays a key role in the user’s perception of performance and quality. Our objective was to make Windows boot beautiful and was inspired by our Windows 7 personality of light and energy; and the way these forms reveal themselves in nature became our design palette. Words such as “bioluminescence”, “organic”, “humble beauty”, and “atmosphere” came up frequently in our brainstorming sessions. We know that in isolation these might sound a bit corny, but this is all part of the overall goals of Windows 7.

Over two dozen boot sequence designs were created, reviewed, and user tested to evaluate them against our goals. Designs varied in the saturation and/or brightness of color, the complexity of motion, and lighting effects. Here are some sketches from our design journey:

The final design in Windows 7 shows energy approaching from four directions, that join to form a light that projects through a window (of course it is no coincidence that the Windows logo resembles a window!). A subtle pulse indicates progress thereafter; another design detail that reinforces the liveliness of Windows 7’s personality.

<\/embed><\/div>";" mce_src="http://blogs.msdn.com/blogfiles/e7/WindowsLiveWriter/EngineeringtheWindows7BootAnimation_F227/video925a71cad692.jpg" galleryimg="no">

From a design perspective, this new boot sequence met all of our design goals, and we were excited to send it out into the world. However, boot had to be more than just a pretty face. From an engineering perspective, we had some clear challenges to overcome, as we knew that “time to desktop” was still the most important thing to users. Visual delight could not trump getting to the desktop faster and many of you have been critical of features that are dubbed “eye candy” – the boot sequence is not going to be one of those features for sure.

No compromise on performance

If we had kept everything the same from Vista and simply updated the boot animation to the new Win7 look, we would not have achieved new levels performance and quality that we aspire to. In fact, significant code changes were required in order to make the new boot animation even possible in Win7.

In Vista, the boot loader is using a low resolution 640x480 screen, and file size required for the green animated progress bar is very small. Furthermore, the Vista boot screen had low color depth – 16 bits per pixel (bpp). We increased this in Win7 to 32 bpp, which enabled the color richness you see in the new boot animation. Updates to the Vista boot progress indicator were achieved via the CPU, which was susceptible to I/O time, therefore causing occasional glitches in the animation. With the low resolution screen, limited color depth, and susceptibility to glitches – we knew we had our work cut out for us if we wanted to build something fancier for Win7.

We started with the Win7 boot loader using a different mechanism to display the boot animation. It gets a pointer to the frame buffer from the firmware (either BIOS or UEFI firmware), and displays a higher resolution image (1024 x 768). It animates the image while the kernel and boot critical device drivers are loaded into memory. Since the native graphics driver for the display is not loaded into memory and initialized yet, the animation is run by using the CPU, and by updating the frame buffer for the graphics display. We made an additional optimization - to have the CPU use write-combined caching to accelerate performance.

Michael Fortin’s blog entry on boot performance describes how the early stage of boot is I/O bound, as it is loading the kernel, device driver files, and other system component files. We therefore limited the dimensions of the boot animation to a small region of the screen, to avoid introducing any delay during the early stage of boot. A larger animation area would require loading a larger set of animation images, which adds to the file I/O. The animation images are compressed by incorporating the bitmaps as resources, which are then compressed using WIM image compression. WIM image compression reduces the overall file size, thereby reducing the I/O required to read them in. It also reduces the on-disk footprint. Animating a smaller region of the screen, and using a slightly lower frame rate also keeps the CPU overhead of updating the frame buffer to a low enough level, that there is no added overhead to the boot time.

Another change we made that improved not only the performance of boot, but the quality, was the reduction of transitions in graphics mode. These transitions occur during initialization of the graphics subsystem and Windows shell. In Vista, these cause the boot experience to be less smooth, as the display changes (flashes black) a few times before presenting the user with a logon screen (or the user’s desktop if there is only one system user).

After looking deep into our boot architecture for performance and quality improvements to enable the new animation, we were pleasantly surprised that the act of beautifying the boot animation created a new opportunity to further decrease time to desktop. In Vista, when a customer powered on the machine, the boot sequence included an animation of the Windows flag, or ‘pearl’, before reaching the login screen (or the desktop if the user is set to auto-login). Due to the Vista boot architecture constraints, this pearl animation can only play after boot code has already completed.

Vista Boot Sequence, with Pearl Animation

Now that new boot visuals display a rich animation that reflects the Windows 7 personality, the pearl animation seemed out-of-date and redundant, and was removed. As a result, we saved the time it takes to play this animation after boot is complete.

Windows 7 Boot Sequence, Pearl Animation Removed

You may also be wondering what happened to the startup sound. In Vista, the sound had to be synchronized with the pearl animation to produce the highest quality experience. This has potential performance impact on some hardware, as we require the system’s sound stack to be loaded to complete the pearl sequence. In the cases when we are waiting for the system’s sound playback to be ready, a delay can occur in getting to the desktop. As such, we changed the sound to now play asynchronously, anytime after the logon screen loads. On most hardware that we tested, this is right when the logon screen displays. We heard customer feedback in Vista that the sound played and caught your attention, but boot was not yet complete. So in addition to performance benefits, this change also improves the user experience by letting users know when their machine is ready for use.

The sum of the boot code optimizations and removal of the pearl animation from Vista enabled us to add a rich, high-quality animation during boot, with no increase in the time it takes a user to reach the desktop.

Designing for a wide range of hardware

The boot experience varies depending on the user’s hardware. We made some design decisions to ensure the best visual experience across a wide range of hardware, however the time it takes a system to get to the desktop is mainly hardware-dependent.

For example, you may notice that there is a delay before the animation starts during boot, and this delay time varies depending on system hardware. To optimize for showing immediate feedback, we actually display text on the boot screen before Windows has had a chance to start all the processors on the system. It is only when that is complete that the animation can run asynchronously to the rest of the I/O during boot (which as discussed earlier is necessary for optimal performance and quality).

You may also notice that the Windows flag’s dimensions during boot may change slightly on different screen sizes. Due to technical constraints in Win7, boot is always displayed in our recommended minimum resolution – 1024x768, regardless of the system’s native resolution. Today, most hardware is set to stretch the boot sequence to fill the screen, as opposed to centering it. Consequently, the boot animation is usually stretched on screens that are of different aspect ratio than 1024x768; however, we did test the sequence on common aspect ratios to ensure that visual quality was preserved.

Boot, Reboot and Resume from Hibernate

With all this hard work to improve the boot experience, we couldn’t let it go to waste. As such, users will also have this experience when they resume from hibernate.

Personalization

We know many of you might be asking if you could include your own animation or customize this sequence. This is not something we will support in Windows 7. We’ve talked about and shown a great many “personalization” elements of Windows 7 already, such as the new themepacks which you can try out in the beta. The reasons for this should be pretty clear, which is that we cannot guarantee the security of the system to allow for arbitrary elements to be loaded into memory at boot time. In the early stages of starting Windows, the system needs to be locked down and execute along a very carefully monitored and known state as tools such as firewalls and anti-virus checking are not yet available to secure the system. And of course, even though we’re sure everyone would follow the requirements around image size, content, etc. due to performance we would not want to build in all the code necessary to guarantee that all third parties would be doing so. One of our design goals of Windows 7 was around making sure there are ample opportunities to express yourself and to make sure your PC is really your PC and so we hope that you’ll understand why this element is one we need to maintain consistently.

This was a quick behind the scenes look at something that we hope you enjoy. With Windows 7 we set out to make the experience of starting a Windows PC a little more enjoyable, and from the feedback we’ve seen here and in other forums, we think we’re heading in the right direction. In addition to our efforts to make boot fast, we also have a goal to make the system robust enough, such that most of you will not see this new boot animation that often and when you do it will be both enjoyable and fast!

--Karen

Update on UAC

e7blog — Thu, 05 Feb 2009 11:00:00 GMT

Hi, Jon DeVaan here to talk to you about the recent UAC feedback we’ve been receiving.

Most of our work finishing Windows 7 is focused on responding to feedback. The UAC feedback is interesting on a few dimensions of engineering decision making process. I thought that exploring those dimensions would make for an interesting e7 blog entry. This is our third discussion about UAC and for those interested in the evolution of the feature in Windows it is worth seeing the two previous posts (post #1 and post #2) and also reading the comments from many of you.

We are flattered by the response to the Windows 7 beta so far and working hard at further refining the product based on feedback and telemetry as we work towards the Release Candidate. For all of us working on Windows it is humbling to know that our work affects so many people around the world. The recent feedback is showing us just how much passion people have for Windows! Again we are humbled and excited to be a part of an amazing community of people working to bring the value of computing to a billion people around the world. Thank you very much for all of the thoughts and comments you have contributed so far.

UAC is one of those features that has a broad spectrum of viewpoints with advocates staking out both “ends” of the spectrum as well as all points in between, and often doing so rather stridently. In this case we might represent the ends of the spectrum as “security” on one end and “usability” on the other. Of course, this is not in reality a bi-polar issue. There is a spectrum of perfectly viable design points in between. Security experts around the world have lived with this basic tension forever, and there have certainly been systems designed to be so secure that they are secure from the people who are supposed to benefit from them. A personal example I have, is that my bank recently changed the security regimen on its online banking site. It is so convoluted I am switching banks. Seriously!

Clarifying Misperceptions

As people have commented on our current UAC design (and people have commented on those comments) it is clear that there is conflation of a few things, and a set of misperceptions that need to be cleared up before we talk about the engineering decisions made on UAC. These engineering decisions have been made while we carry forth our secure development lifecycle principles pioneered in Windows XP SP2, and most importantly the principle of “secure by default” as part of SD3+C. Windows 7 upholds those principles and does so with a renewed focus on making sure everyone feels they are in control of their PC experience as we have talked about in many posts.

The first issue to untangle is about the difference between malware making it onto a PC and being run, versus what it can do once it is running. There has been no report of a way for malware to make it onto a PC without consent. All of the feedback so far concerns the behavior of UAC once malware has found its way onto the PC and is running. Microsoft’s position that the reports about UAC do not constitute a vulnerability is because the reports have not shown a way for malware to get onto the machine in the first place without express consent. Some people have taken the, “it’s not a vulnerability” position to mean we aren’t taking the other parts of the issue seriously. Please know we take all of the feedback we receive seriously.

The word “vulnerability” has a very specific meaning in the security area. Microsoft has one of the leading security agencies in the world in the Microsoft Security Response Center (secure@microsoft.com) which monitors the greater ecosystem for security threats and manages the response to any threat or vulnerability related to Microsoft products. By any definition that is generally accepted across the world wide security community, the recent feedback does not represent a vulnerability since it does not allow the malicious software to reach the computer in the first place.

It is worth pointing out the defenses that exist in Windows Vista that keep malware from getting on the PC in the first place. In using Internet Explorer (other browsers have similar security steps as well) when attempting to browse to a .vbs file or .exe file, for example, the person will see the prompts below:

Internet Explorer 8 has also introduced many new features to thwart malware distribution (see http://blogs.msdn.com/ie/archive/2008/08/29/trustworthy-browsing-with-ie8-summary.aspx ). One of my favorites is the SmartScreen® Filter which helps people understand when they are about to visit a malicious site. There are other features visible and hidden that make getting malware onto a PC much more difficult.

A SmartScreen® display from IE 8

Additionally, if one attempts to open an attachment in a modern email program (such as Windows Live Mail) the malware file is blocked:

Much of the recent feedback has failed to take into account the ways that Windows 7 is better than Windows Vista at preventing malware from reaching the PC in the first place. In Windows 7 we have continued to focus on improving the ability to stop malware before it is installed or running on a PC.

The second issue to untangle is about the difference in behavior between different UAC settings. In Windows 7, we have four settings for the UAC feature: “Never Notify,” “Notify me only when programs try to make changes to my computer (without desktop dimming),” “Notify me only when programs try to make changes to my computer (with desktop dimming),” and “Always Notify.” In Windows Vista there were only two choices, the equivalent of “Never Notify” and “Always Notify.” The Vista UI made it difficult for people to choose “Never Notify” and thus choosing between extremes in the implementation. Windows 7 offers you more choice and control over this feature, which is particularly interesting to many of you based on the feedback we have received.

The recent feedback on UAC is about the behavior of the “Notify me only when programs try to make changes to my computer” settings. The feedback has been clear it is not related to UAC set to “Always Notify.” So if anyone says something like, “UAC is broken,” it is easy to see they are mischaracterizing the feedback.

The Purpose of UAC

We are listening to the feedback on how “Notify me only when…” works in Windows 7. It is important to bring in some additional context when explaining our design choice. We choose our default settings to serve a broad range of customers, based on the feedback we have received about improving UAC as a whole. We have learned from our customers participating in the Customer Experience Improvement Program, Windows Feedback Panel, user surveys, user in field testing, and in house usability testing that the benefit of the information provided by the UAC consent dialog decreases substantially as the number of notifications increases. So for the general population, we know we have to present only key information to avoid the reflex to “answer yes”.

One important thing to know is that UAC is not a security boundary. UAC helps people be more secure, but it is not a cure all. UAC helps most by being the prompt before software is installed. This part of UAC is in full force when the “Notify me only when…” setting is used. UAC also prompts for other system wide changes that require administrator privileges which, considered in the abstract, would seem to be an effective counter-measure to malware after it is running, but the practical experience is that its effect is limited. For example, clever malware will avoid operations that require elevation. There are other human behavior factors which were discussed in our earlier blog posts (post #1 and post #2).

UAC also helps software developers improve their programs to run without requiring administrator privileges. The most effective way to secure a system against malware is to run with standard user privileges. As more software works well without administrator privileges, more people will run as standard user. We expect that anyone responsible for a set of Windows 7 machines (such as IT Administrators or the family helpdesk worker (like me!)) will administer them to use standard user accounts. The recent feedback has noted explicitly that running as standard user works well. Administrators also have Group Policy at their disposal to enforce the UAC setting to “Always Notify” if they choose to manage their machines with administrator accounts instead of standard user accounts.

Recapping the discussion so far, we know that the recent feedback does not represent a security vulnerability because malicious software would already need to be running on the system. We know that Windows 7 and IE8 together provide improved protection for users to prevent malware from making it onto their machines. We know that the feedback does not apply to the “Always Notify” setting of UAC; and we know that UAC is not 100% effective at stopping malware once it is running. One might ask, why does the “Notify me only when…” setting exist, and why is it the default?

Customer-Driven Engineering

The creation of the “Notify me only when…” setting and our choice of it as the default is a design choice along the spectrum inherent in security design as mentioned above. Before we started Windows 7 we certainly had a lot of feedback about how the Vista UAC feature displayed too many prompts. The new UAC setting is designed to be responsive to this feedback. A lot of the recent feedback has been of the form of, “I’ll set it to ‘Always Notify,’ but ‘regular people’ also need to be more secure.” I am sure security conscious people feel that way, and I am glad that Windows 7 has the setting that works great for their needs. But what do these so called “regular people” want? How to choose the default, while honoring our secure design principles, for these people is a very interesting question.

In making our choice for the default setting for the Windows 7 beta we monitored the behavior of two groups of regular people running the M3 build. Half were set to “Notify me only when…” and half to “Always Notify.” We analyzed the results and attitudes of these people to inform our choice. This study, along with our data from the Customer Experience Improvement Program, Windows Feedback Panel, user surveys, and in house usability testing, informed our choice for the beta, and informed the way we want to use telemetry from the beta to validate our final choice for the setting.

A key metric that came out of the study was the threshold of two prompts during a session. (A session is the time from power up to power down, or a day, whichever is shorter.) If people see more than two prompts in a session they feel that the prompts are irritating and interfering with their use of the computer. In comparing the two groups we found that the group with the “Always Notify” setting was nearly four times as likely to have sessions with more than two prompts (a 1 in 6.7 chance vs a 1 in 24 chance). We gathered the statistic for how many people in the sample had malware make it onto their machine (as measured by defender cleaning) and found there was no meaningful difference in malware infestation rates between the two groups. We will continue to collect data during the beta to see if these results hold true in a much broader study.

We are very happy with the positive feedback we have received about UAC from beta testers and individual users overall. This helps us validate our “regular people” focus in terms of the trade-offs we continue to consider in this design choice. We will continue to monitor the feedback and our telemetry data to continue to improve our design choices on UAC.

So as you can see there is a lot of depth to the discussion of UAC and the improvements made in Windows 7 in UAC itself and in improving ways to prevent malware from ever reaching a PC. We are working hard to be responsive to the feedback we received from Vista to provide the right usability and security for people of all types. We believe we’ve made good progress and are listening carefully to the feedback on our UAC changes. Again please accept our most sincere thanks for the passion and feedback on Windows 7. While we cannot implement features the way each and every one of you might wish, we are listening and making a sincere effort to properly weigh all points of view. Our goal is to create a useful, useable, and secure Windows for all types of people.

Jon

Follow-up: Accessibility in Windows 7

e7blog — Wed, 21 Jan 2009 11:00:00 GMT

We’ve seen some comments recently posted on a previous post on accessibility and a member of the User Interface Platform team wanted to offer some thoughts on the topic. Brett is a senior test lead who leads our efforts testing the Accessibility of Windows 7. --Steven

Hi, my name is Brett and I am the test lead for the Windows 7 Accessibility team. Back in November my colleague Michael wrote a blog post about the work our team is doing for Windows 7, I’m following up to that and some recent comments about our new screen Magnifier. On a personal note I would like to mention that I’m a person with low vision and depend on some of the technologies that my team produces to help me in my work.

I’ve been using Windows 7 for my day-to-day work for several months, this is something we call “dogfooding”, which is using our own pre-release products long before the public ever sees a beta. I’ve been using Windows 7 as my primary operating system and have found our new Magnifier to be very useful to me.

Now, about our Magnifier, as you can imagine, the appeal of the many features in Windows varies from person to person, we often say that it is like making pizza for a billion people. The same is true for the features my team owns. I’ve read many comments since we released our Windows 7 beta about magnifier, some are from people that have really benefited from our new work, some have suggestions, and others have concerns. I will say thanks for the feedback, we appreciate all types. Those of you that have benefited are mostly people that need basic magnification and appreciate the easy ability to zoom in and out as needed; I fall into this category myself. Those of you that need magnification in combination with custom colors, high-contrast or some screen readers probably haven’t been able to benefit from the new Magnifier, for you we’ve made sure that the Vista magnifier continues to work. Let me explain a little more about what we’ve done in Windows 7.

To go into more detail about our implementation I need to start with our graphics system in Windows. Over the last several years GPU technology has made huge advances and in Vista we finally made the leap to a modern hardware accelerated graphics system, what we call Aero, which takes advantage of the GPU. We often use the term Aero to refer to the specific elements of Windows visuals, such as transparency and gradients. In practice it is more than that, the modern graphics rendering (technically the desktop window manager along with the DirectX APIs) is not just for aesthetics but for all forms of rendering including text, 2D, and 3D all using modern hardware assisted graphics and a much richer API. It takes time, however, for the diverse ecosystem to adopt this technology, perhaps even over the course of several OS releases. It also takes time for Windows and time for software developers and hardware manufacturers to adopt new technologies; so for a time we will have (and fully support) a mix of both old and new. For example, some screen readers do the great things they do by capturing the data that goes through the original Windows graphics system (GDI) and building their off-screen UI models which is why they need to turn off the new rendering. On the other hand, our new Magnifier is integrated deeply into the desktop window manager (“Aero”) to leverage this graphics horsepower and deliver smooth full-screen multi-monitor magnification.

While, as this demonstrates, these advances aren’t seamless, in Windows 7 my team has worked to make sure that we maintain Vista functionality and compatibility while making new investments. Magnifier is an example of this, we utilize the power of the GPU where we can to bring new capabilities to a broad spectrum of customers, and when Aero needs to be off, whether for screen readers, high-contrast or other needs, we maintain the existing capabilities in the product. And by maintaining compatibility as much as possible, many of the tools you depend on today will continue to work with Windows 7.

So, is Magnifier better for everyone? Not everyone, but certainly for many people, but more than that I can honestly say that we have made advances to accessibility for everyone in Window 7. As Michael noted in his posting, we invested in several areas, there’s not only the Magnifier and on-screen keyboard work, there is also significant work to the underlying accessibility APIs. We also actively support the community and recently made a grant to NV Access to help them improve their open source screen reader support for Windows 7 and Internet Explorer 8.

Thanks for reading, and thanks for your comments,

-Brett

Accessibility in Windows 7

e7blog — Sun, 30 Nov 2008 11:00:00 GMT

This post is from Michael Bernstein, a development lead on the User Interface Platform team where he focuses on accessibility. Accessibility is the term we apply to the APIs and features that enable Windows to be used, to be accessible, by as many people as possible so that, regardless of physical or cognitive abilities, everyone has the ability to access the functions of Windows. To enable this, Windows includes both built-in accessibility utilities as well as APIs used by third party assistive technology aids and by application developers to make sure their software is also accessible. This is a topic that is extremely important to Microsoft and one that is a key tenet in the engineering of Windows 7. Microsoft also has a corporate-wide group dedicated to making sure that PCs are easier to see, hear, and use. You can read more about Microsoft’s accessibility initiatives on http://www.microsoft.com/enable/. --Steven

Hi, I’m the development lead for Accessibility and Speech Recognition experiences in Windows 7, and I wanted to write about how we thought about Accessibility in Windows 7.

We wanted to make Windows 7 the most accessible operating system that Microsoft has ever produced. It became clear as we planned this release, however, that the notion of Accessibility is not as simple as it may appear. It is tempting to think about Accessibility like Security: either you have a known failure, or your system is believed to be secure/accessible. This definition turns out to be limited, though. How do you deal with the fact that the needs of customers who are blind are very different from the needs of customers who are deaf? The needs of customers who are blind are even different from those of customers with reduced vision: a magnification tool is useless for one group and crucial for the other. And what do we make of cases where something is technically accessible but practically frustrating, like a common user scenario that takes 36 keystrokes to execute? Clearly, Accessibility wasn’t going to boil down to a simple yes/no question. It is really more like a particular kind of usability, but usability for a specific set of audiences with individual needs.

Since the questions we were asking were complex, the answers ended up being complex, too. We chose a four-part strategy to improve Accessibility in Windows 7.

I. Build a firm foundation with UI Automation

In Windows Vista, Microsoft delivered a new core component for Accessibility called UI Automation. UI Automation enables a user’s assistive technology (AT) to programmatically drive the UI of an application, and allows applications to expose their accessible functionality in a richer way than was possible in previous versions of Windows. More questions can be asked about a piece of UI, and that UI can be manipulated in richer ways. UI Automation also introduced the idea of Control Patterns: any given piece of UI can decide how it should be controlled. Buttons expose the Invoke pattern, indicating that they can be pushed; Combo Boxes expose ExpandCollapse, indicating that they can be opened and closed. We let different controls be different, instead of trying to force them all into the same mold. All this was introduced in Windows Vista and adoption is still ongoing.

In Windows 7, we invested in improving the performance of the UI Automation system and created a new, native-code API for UI Automation to make sure that it can be used effectively by a wide range of assistive technology software. Now applications written in C++, as well as those written using the .NET Framework, can take advantage of UI Automation.

We also did a bunch of work to make sure that the UI Automation system was integrated even more closely with the legacy Microsoft Active Accessibility (MSAA) system and developed new bridging techniques between the best of the new and the old technologies. UI Automation Clients can read Accessibility information from MSAA applications, and vice versa, to ensure maximum Accessibility regardless of which accessibility API an application used originally. Since the UI Automation and MSAA systems cooperate closely in many scenarios, we decided to name the combination of the two, calling it the Windows Automation API. This architecture forms the foundation for the rest of our Accessibility effort, and we’re pleased to have this Accessibility foundation Windows 7.

II. Improve our included Accessibility utilities

We also improved the Accessibility utilities that we include in the box with Windows. Microsoft works closely with many different AT software companies who deliver software to make Windows more accessible to customers with disabilities, but we also include a set of utilities to make sure that our customers’ early experiences are accessible, even before installing any other software. We decided to enhance two of those utilities in Windows 7: the On-Screen Keyboard and the Magnifier.

The most noticeable change to the On-Screen Keyboard is the improved look and feel, but there are also more subtle enhancements. The appearance of this utility had not changed since Windows XP; our customers were also asking for it to be resizable. We addressed both of these by working closely with Tablet developers to share a common code base between the Tablet Soft Keyboard and the On-Screen Keyboard. Both keyboards now have an attractive appearance that is in tune with Windows 7 and both are now resizable. The keyboards still are distinct, though, because customers use them differently: Tablet users may want to switch dynamically between handwriting and typing, whereas On-Screen Keyboard users may need modes where they can hover or scan to keys, if they have disabilities that prevent them from clicking. Along these lines, we also added basic text prediction to help customers with disabilities enter text more quickly. If you have ever tried typing with an on-screen keyboard, you can appreciate how significantly text prediction can improve text entry speed.

The Magnifier came in for a deeper overhaul. The Magnifier in Windows Vista and Windows XP was not an intuitive experience: when you pointed at part of the screen, the magnified content appeared in a separate window, usually docked at top of the screen. You had to point at one place and look at another. We considered two basic solutions to this problem: you could zoom into the entire screen or you could make the magnified area follow the pointer while leaving the rest of the screen the same. These became our two primary modes for the Windows 7 Magnifier: Full-screen mode and Lens mode.

Full-screen mode is great when you want to increase the size of everything on the screen at once. As you move the mouse or keyboard focus around the middle of the screen, the view stays still; if you move towards the edge, the Magnifier scrolls the view to keep up. One downside of this mode is that you can lose track of your context. To address that usability issue, we added a context animation that zooms out to show you where your work area is relative to the whole screen, and then zooms back in.

Lens mode, on the other hand, is nice when you just want to zoom in on one particular thing. In this mode, the lens centers on the mouse pointer, which feels much like using a magnifying glass. You can re-size the lens to be very wide and short, which can be nice if you are reading a document and want to magnify it line by line. We based our design on the popular Microsoft IntelliPoint magnifier, a design you can now enjoy with any mouse.

We also addressed customer feedback about the Magnifier window taking up too much space on the screen. We moved the most commonly used controls like zoom in/out to a small toolbar, which fades out to a semi-transparent watermark when you aren’t using it. The remaining options are available in an Options dialog when you need them. Last, we gave almost everything a keyboard shortcut, so if you really don’t want to see the UI, you don’t have to use it. Win-+ will zoom you in any time you are using Windows 7.

These tools directly improve Accessibility for customers with low vision and dexterity disabilities. It should be obvious, but making the PC easier to see or interact with benefits everyone and so these two examples also show the broad appeal of AT tools – at the PDC we showed both the On-Screen Keyboard and the Magnifier and I think it is fair to see everyone saw the benefit of using these tools themselves, regardless of abilities.

III. Make it easier to build Accessible software

Windows APIs cannot provide Accessibility all by themselves; it is vital for Windows-based applications to do their part in providing Accessibility data for AT programs to use. For example, a screen reader may sound excellent, but if it can’t read your favorite web browser, what good is that? Assistive tools like screen readers and magnifiers are clients of the Accessibility system, while the applications that you want to use, like web browsers and word processors, are providers. It takes both to make the whole experience accessible--you need both a high-quality client and a well-written provider to have a good Accessible experience. There are more providers in the software ecosystem, so it is hard for us to work one-on-one with every provider to make sure they are well-written.

To address this challenge, our team developed the UI Accessibility Checker (AccChecker for short) and UI Automation Verify (UIA Verify) utilities, which can scan an application (a provider, really) and report on common Accessibility problems. Software developers can use AccChecker and UIA Verify to detect problems in their provider code before a customer ever uses it. Quality assurance engineers can use them to verify the quality of their firm’s work. We believe this is so important that we released AccChecker and UIA Verify as open-source software to make it available to the widest possible audience. If you are not a programmer, you may never use these utilities directly, but you may well benefit from the bugs they helped to eliminate before they ever reached you.

IV. Plan for Accessibility from Day 1

To make sure that Windows features themselves were good providers, we borrowed an idea from the Software Development Lifecycle, risk assessment. Before a line of code was written, each planned Windows 7 feature was rated on its Accessibility risk. Features that use more basic, off-the-shelf common controls are usually more accessible because Windows provides built-in providers for off-the-shelf components; features that do fancy, custom drawing have more work to do. This planning process made each team aware of how much accessibility risk it was taking on, so that they could plan appropriately. Once the features were all rated, the list was sorted by risk so that our team could reach out to teams with high-risk features and make sure that they had the resources and tools they needed to make their feature properly accessible. We also ensured that they received more hands-on testing and validation. As a result, most Windows features are more accessible than they have been in previous releases, making for a better overall customer experience.

To wrap up, we've emphasized Accessibility in engineering Windows 7. We’ve made good progress on improving the core architecture for Accessibility and enhancing the included tools like On-Screen Keyboard and Magnifier. The AccChecker and UIA Verify tools have made it much easier to validate applications to ensure that they will be compatible with current assistive tools as well as future tools based on the Windows Automation API. Our approach to Accessibility for the features and providers in Windows itself has become more thorough, consistent and integrated, thanks to the hard work of hundreds of engineers across the company. We’re proud of what we have accomplished in Windows 7 and hope that it will help customers with disabilities to realize their full potential and have a more enjoyable experience with Windows.

--Michael

From Idea to Feature: A view from Design

e7blog — Sat, 18 Oct 2008 10:00:00 GMT

Larry is very appreciative of the reception and comments his post received. Thank you! It is worth noting that we’ve surpassed over 2000 comments and I’ve received and equal amount of email. I am trying to reply as often as I can!

We’re 10 days from the PDC and so we might take a short break from the blog while we practice our demos of Windows 7…we’ll keep an eye on comments for sure and maybe a post or two on the way. :-)

Let's move "up" in the dev process and look at how we come up with what is in a release and how we think about taking a feature from an idea to feature.

As we’ve posted on various engineering challenges we’ve often distilled the discussion down to a few decisions, often between two options (make a feature optional or not, add a window management feature one of two ways, etc.) Yet this doesn’t quite get to the challenge of where does the product definition begin and how do we take an idea and turn it into a feature. Most choices in engineering Windows are not between two choices, but the myriad of considerations, variables, and possibilities we have before we even get to just a couple of options. This post looks a bit at the path from an idea to a feature.

A common thread we’ve seen in the feedback is to make “everything customizable and everything optional” (not a direct quote of course). Of course, by virtue of providing a platform we aim to offer the utmost in extensibility and customization by writing to the APIs we provide. There is an engineering reality that customization and extensibility have their cost—performance, complexity, and forward compatibility come to mind. One way to consider this is that if a feature has two “modes” (often enable the new feature or enable the old feature) in one release, then in a follow-up release if the feature is changed it potentially has four modes (old+old, old+new, new+old, new+new), and then down the road 8 modes, and so on. The complexity of providing a stable and consistent platform comes with the cost that we aren’t always able to “hook” everything and do have to make practical choices about how a feature should work, in an effort to plan for the future. Designing a feature is also about making choices, tough choices. At the same time we also want to provide a great experience at the core operating system functions of launching programs, managing windows, working with files, and using a variety of peripherals--to name just a few things Windows does. This experience should be one that meets the needs of the broadest set of people across different skill levels and different uses of PCs, and also providing mechanisms to personalize with user interface and to customize with code. Every release we plan is a blending of fixing things that just don’t work like we all had hoped and developing new solutions to both old and new problems, a blending of features and extensibility, and a blending of better support for existing hardware and support for new hardware.

This post is jointly written by Samuel Moreau the manager of the user experience design team for the Windows Experience, Brad Weed, Director of User Experience Design and Research for Windows and Windows Live, and Julie Larson-Green, the VP of Program Management for the Windows Experience. With the number of comments that describe a specific feature idea, we thought it would be good to give you an overview of how we approach the overall design process and how ideas such as the ones you mention flow into our process. Also for those of you attending the PDC, Sam will be leading a session on the design principles of Windows 7. –Steven

Designing Windows – from idea to feature

In general, we follow a reasonably well-understood approach to product design, but that doesn’t make it easy or “automatic”. Often this is referred to as a "design funnel" where ideas go from concept to prototype to implementation and then refinement. By reading the various design ideas in the comments of Chaitanya’s post on “Starting, Launching and Switching”, you can see how difficult it can be to arrive at a refined feature design. In those comments you can find equally valid, yet somewhat opposite points of view. Additionally, you can also find comments that I would paraphrase as saying “do it all”. It is the design process that allows us to work through the problem to get from idea to feature in the context of an overall product that is Windows.

From a product design perspective, the challenge of building Windows is the breadth of unique usage of just a single product. In a sense, one of the magic elements of software is that it is “soft” and so you can provide all the functionality to all customers with little incremental cost and little difference in “raw materials” (many comments have consistently suggested we have everything available along with options to choose components in use and we have talked about minimizing the cost when components and features are not used even if they are available). And at the same time, there is a broad benefit to developers when they can know a priori that a given PC has a common set of functions and can take advantage of specific APIs that are known to be there and known to behave a specific way--the platform. This benefit of course accrues to individuals too as you can walk up to any PC and not only have a familiar user experience, but if you want to do your own work, use a specific device, or run a certain program on the PC you can also do that. This breadth of functionality is a key part of the value of a Windows PC. Yet it also poses a pretty good design challenge. Learning, understanding, and acting on the broad set of inputs into designing Windows is an incredibly fun and challenging part of building Windows.

As Larry pointed out the design and feature selection happens takes place in his part of the organization (not way up here!). There’s another discussion we will have in a future post about arriving at the themes of the overall release and how we develop the overall approach to a release so that the features fit together and form a coherent whole and we address customer needs in an end-to-end fashion.

We have a group of product designers that are responsible for the overall interaction design of Windows, the sequence and visualization of Windows. Program Managers across the team work with product designers as they write the specifications. Along with designers we have UX Researchers who own the testing and validation of the designs as we’ve talked about before. The key thing is that we apply a full range of skills to develop a feature while making sure that ownership is clear and end-to-end design is clear. The one thing we are not is a product where there is “one person” in charge of everything. Some might find that to be a source of potential problems and others might say that a product that serves so many people with such a breadth of features could not be represented by a single point of view (whether that is development, testing, design, marketing, etc.). We work to make sure engineers are in charge of engineering, that the product has a clear definition that we are all working towards implementing and that product definition represents the goals across all the disciplines it takes to deliver Windows to customers around the world. And most importantly, with Windows 7 we are making renewed effort at "end to end" design.

Let’s look at the major phases of product design in Engineering Windows. What we’ll talk about is of course generalized and doesn’t apply to each specific incident. One thing we always say internally is that we’re a learning organization—so no process is perfect or done and we are always looking to make it better as we move through each and every iteration of building Windows.

Throughout this post when we say “we” what this really means is the individuals of each discipline (dev, test, pm, design) working together—there’s no big feature or design committee.

Pick the question or get an idea

We get an idea from somewhere of something to do—it could be big (build UX to support a new input method such as touch), wild (change the entire UI paradigm to use 3D), or an improvement / refinement of an existing feature (multi-monitor support), as some examples. There is no shortage of creative ideas, because frankly, that is the easy part. Ideas flow in from all corners of the ecosystem, ourselves included. We’ve talked a lot about comments and feedback from this blog and that is certainly one form of input. Product reviews, enterprise customers, customer support lines, PC makers, hardware and software developers, blogs, newsgroups, MVPs, and many others have similar input streams into the team.

The key is that working on Windows is really a constant stream of inputs. We start with a framework for the release that says what goals and scenarios we wish to make easier, better, faster. And with that program management builds up candidate ideas—that is ideas that will make their way through features. The job of getting a feature “baked” enough falls to program management and they do this work by working across the product and working with design, development, and testing (as Larry described).

With regard to where ideas come from, what we like to say is that the job of program management is not to have all the great ideas but to make sure all the great ideas are ultimately picked. The best program managers make sure the best ideas get done, no matter where they come from.

Gather information and data

Given any idea, the first step is to understand what data we have “surrounding” the idea. Sometimes the idea itself comes to us in a data-centric manner (customer support incidents) or other times it is anecdotal (a blog).

The first place we look is to see what data do we have based on real world usage that would support the development of a hypothesis, refute or support the conventional wisdom, or just shed some light on the problem. The point is that the feature starts its journey by adding more perspectives to the input.

Essentially, we need an objective view that illuminates the hypothesis. We gather this data from multiple sources including end users, customers, partners, and in various forms such as instrumentation, research, usability studies, competitive products, direct customer feedback, and product support.

As many (including us) have pointed out, telemetry data has limitations. First, it can never tell you what a person might have been trying to do—it only tells you what they did. Through usability, research, and observation, we are able to get more at the intent. For example, the way we talked about high dpi and how the telemetry showed one thing but the intent was different (and the impact of those choices was unintended). The best way to see this is to remember that a person using a PC is not interesting in “learning to use a PC” but is trying to get their own work done (or their own playtime). And when faced with a “problem” the only solutions available are the buttons and menu commands right there—the full solution set is the existing software. Our job is to get to the root of the problem and then either expand the solution set or just make the problem go away altogether.

What about unarticulated needs? The data plus intent shows the “known world” and “known solution space”, but one role we have is to be forward thinking and consider needs or desires that are not clearly articulated by those who do not have the full time job to consider all the potential solution spaces. The solution space could potentially be much broader than readily apparent from the existing and running product—it might involve a rearchitecture, new hardware, or an invention of a new user interface.

A great example of this was mentioned in one of the comments on the taskbar post. The comment (paraphrasing) indicated that the order of icons on the taskbar matters so sometimes he/she would simply close all the open programs and then restart them just so the programs were in the preferred order on the taskbar. Here the data would look like an odd sequence of launch/exit/launch/exit/launch/lauch. And only through other means would we learn why someone would be doing that, and for the most part if you just walked up without any context and said “how can we make Windows easier” it isn’t likely this would bubble up to the top of the list of “requests”. Thus we see a number of neat things in this one example—we see how the data would not show the intent, the “request” would not be at the top of any list, and the solution might take any number of forms, and yet if solved correctly could be a pretty useful feature. Above all, in hindsight this is one of those “problems” that seems extraordinarily obvious to solve (and I am sure many of you are saying—“you should have just asked me!”) So we also learn the lesson that no matter what data and information we gather or what design we’re talking about, someone always noticed or suggested it :-).

Hypothesize

The next step is where we propose a clear hypothesis – “people would benefit from rearranging icons on the taskbar because positional memory across different sessions will reduce the time to switch applications and provide a stronger sense of control and mastery of Windows”.

What is our hypothesis (in a scientific sort of way) as to what opportunity exists or what problem we would solve, and what the solution would look like, or why does the problem exist? Part of designing the feature is to think through the problem—why does it exist—and then propose the benefit that would come from solving the problem. It is important that we have a view of the benefit in the context of the proposed solution. It is always easy to motivate a change because it feels better or because something is broken so a new thing has to be better, but it is very important that we have a strong motivation for why something will benefit customers.

Another key part about the hypothesis is to understand the conventional wisdom around this area, especially as it relates to the target customer segment (end-user, enthusiast, PC maker, etc.) The conventional wisdom covers both the understanding of how/why a feature is a specific way today and also if there is a community view of how something should be solved. There are many historic examples where the conventional wisdom was very strong and that was something that had to be considered in the design or something that had to be considered knowing the design was not going to take this into account—a famous example is the role of keyboard shortcuts in menus that the “DOS” world felt would be required (because not every PC had a mouse) but on the Mac were “unnecessary” because there was always a mouse. Conventional wisdom in the DOS world was that a mouse was optional.

Experiment

For any hypothesis, there are numerous design alternatives. It is at this stage where we cast a broad net to explore various options. We sketch, write scenarios, story board, do wireframes and generate prototypes in varying fidelity. Along the way we are working to identify not just the “best answer” but to tease out the heart and soul of the problem and use the divergent perspectives to feed into the next step of validation.

This is a really fun part of the design process. If you walk our hallways you might see all sorts of alternatives in posters on the walls, or you might catch a program manager or designer with a variety of functional prototypes (PowerPoint is a great UI design tool for scenarios and click-thrus that balance time to create with fidelity, and Visio is pretty cool for this as well) or our designers often mock up very realistic prototypes we can thoroughly test in the lab.

Interpret and Validate

With a pile of options in front of us we then take the next step of interpreting our own opinions, usability test data and external (to the team) feedback. This is the area where we end up in conversations that, as an example, could go something like this… “Option ‘A’ is better at elevating the discovery of a new feature, but option ‘B’ has a stronger sense of integration into the overall user experience”.

As we all know, at the micro level you can often find a perfect solution to a specific problem. But when you consider the macro level you start to see the pros and cons of any given solution. It is why we have to be very careful not to fall into the trap of a “tests”. The trap here is that it is not often possible to test a feature within the full context of usage, but only within the context of a specific set of scenarios. You can’t test how a feature relates to all potential scenarios or usages while also getting rich feedback on intent. This is why designing tests and interpreting the results is such a key part of the overall UX effort led by our researchers.

A mathematic way of looking at this is the “local min” versus a “global min”. A local min is one you find if you happen to start optimizing at the wrong spot on the curve. A good example of this in software is when faced with a usability challenge you develop a new control or new UI widget. It seems perfectly rational and often will test very well, especially if the task asked of the subject is to wiggle the widget appropriately. However, what we’re after is a global optimization where one can see that the potential costs (in code, quality, and usability) of another widget by erase any potential benefits gained by introducing a new widget. Much has been written about the role of decision theory as it relates to choosing between options, but our challenge with design is the preponderance of qualitative elements.

Choosing

Ultimately we must pick a design and that choice is informed by the full spectrum of data, qualitative and quantitative.

Given a choice for a design and an understanding of how to implement it and the cost, there is still one more choice—should we do the feature at all. It sounds strange that we would go through all this work and then still maybe not build a specific feature. But like a movie director that shoots a scene that ends up on the cutting room floor, sometimes the design didn’t pan out as we had hoped, sometimes we were not able to develop an implementation plan within reason, or sometimes there were other ideas that just seemed better. And this is all before we get to the implementation, which as Larry pointed out has challenges as well.

We have two tools we use to assist us in prioritizing features and designs. First is the product plan—the plan says at a high level what we “require” the product to achieve in terms of scenarios, business goals, schedule, and so on. Most of the time features don’t make it all the way through prototyping and testing because they just aren’t going to be consistent with the overall goals of the release. These goals are important otherwise a product doesn’t “hang together” and runs the risk of feeling like a “bunch of features”. These high level goals inform us quite a bit in terms of what code we touch and what scenarios we consider for a release.

And second we have the “principles of design” for the release. These principles represent the language or vocabulary we use. These represent the core values—we often think of the design principles as anthropomorphizing the product—“if Windows were a person then it would be…”. This is the topic of Sam’s talk at the PDC.

As mentioned in the introduction, it isn’t possible to do everything twice. We do have to decide. This could be a whole series of posts—customization, compatibility modes, and so on. We definitely hear folks on these topics and always do tons of work to enable both “tweaking” and “staying put” and at the same time we need to balance these goals with the goals of providing a robust and performant platform and also moving the OS forward. Some of us were involved in Office 2007 and there is a fun case study done by Harvard Business School [note fee associated with retrieving the full text] about the decision to (or not to) provide a “compatibility mode” for Office 2007. This was a choice that was difficult at the time and a few folks have even mentioned it in some comments.

Implement and Integrate

Finally, we build and iterate to refine the chosen solution. Inevitably there are new discoveries in the implementation phase and we adjust accordingly. As we integrate the solution into its place in Windows, that discovery continues. The beta period is a good example of how we continue to expand and learn from usage and feedback. In a Windows beta we are particularly interested in compatibility and real-world performance as those are two aspects of the design that are difficult to validate without the breadth of usage we can get if we do a great beta.

It is important to keep in mind that we follow intensely all the feedback we receive from all forms—reviews, blogs, and of course all the telemetry about how the product is used (realizing that the beta is a select group of people).

One of the things we hope to do with the blog, as you might have seen on the IE 8 Blog, is to discuss the evolution of the product in real-time. We’re getting close to this transition and are looking forward to talking more about the design choices we made!

-- Sam, Brad, and Julie

The Windows Feedback Program

e7blog — Wed, 10 Sep 2008 10:00:00 GMT

Introducing Christina Storm who is a program manager on the Windows Customer Engineering feature team working on telemetry.

In a previous article Steven has introduced the Windows 7 Feature Teams. I am a program manager working on telemetry on the Windows Customer Engineering team. Our team delivers the Windows Feedback Program, one of several feedback programs in place today that allow us to work directly with customers and make them part of our engineering process.

The Windows Feedback Program (WFP) has been active for several years during the Windows XP and Windows Vista product cycles, and we are currently ramping up to get all aspects of this program ready for Windows 7. At the core of this program is a large research panel of customers who sign up via our website http://wfp.microsoft.com during open enrollment. Customers choose to be part of a survey program, an automated feedback program or both. They then complete a 20-minute profiling survey, which later allows us to look at their feedback based on their profile. We have customers spanning a wide spectrum of computer knowledge in our program, and we are constantly working on balancing the panel to staff up underrepresented groups. The majority of customers who are spontaneously willing to participate in a feedback program like ours are generally enthusiastic about technology. They are early adopters of consumer electronics, digital devices and new versions of software. In contrast, customers who see the PC as a tool to get a job done tend to be a bit more reluctant to join. And we also need more female participants!

Customers who participate in the automated feedback program install a data collection tool developed by the Windows Telemetry Team. The privacy agreement of this program describes the data collections our tool performs. Here are a few examples:

Windows usage behavior including installed and used applications.
File and folder structures on your computer, including number of types of files in folders, such as number of jpg files in the Pictures folder.
System-specific information, such as hardware, devices, drivers, and settings installed on your computer.
Windows Customer Experience Improvement Program (CEIP) data.

From the collected data we create reports that are consumed by a large number of Windows feature teams as well as planners and user researchers. This chart below shows the answer to the following question: What is the most common file type that customers who participate in our program store on their PCs and what are the most popular storage locations?

The results help us both with planning for handling the volumes of data customers store on their PCs as well as mimicking real-life scenarios in our test labs by setting up PCs with similar file numbers and file sizes and distribution of files on the PCs.

These data collections furthermore allow us to create reports based on profiled panelists. The above chart may look different if we created it based on data delivered only by developers and then compare it to data delivered only by gamers, just to name a couple of different profiles that participate in our program. The Windows knowledge level sometimes makes a difference, too. Therefore it is very important to us that customers participate in this program who consider themselves Windows experts as well as customers who don’t enjoy spending too much time with the PC, who just see the PC as a tool to get things done. Based on the data, we may decide to optimize certain functionality for a particular profile.

In general, we utilize this data to better understand what to improve in the next version of Windows. Let’s take a look at how the representative sample has their monitors configured. First what resolutions do customers run with on their PCs? The following table lists typical resolutions and the distribution based on the Windows Customer Experience Improvement Program, which samples all opt-in PCs (Note the numbers do not add to 100% because not every single resolution is included):

One thing you might notice is that about 10% of consumers are running with HD or greater resolution. In some of the comments, people were asking if our data represented the “top” or “power users”. Given this sample size and the number of folks with industry leading resolution I think it is reasonable to conclude that we adequately represent this and all segments. This sample is a large sample (those that opt-in) of an extremely large dataset (all Windows customers) so is statistically relevant for segmented studies,

We have found that a large percentage of our program participants lower their display resolution from the highest usable for their display. Looking at the data coming from the Windows Customer Experience Improvement Program to compare to, and noticed a similar trend: over 50% of customers with 1600x1200 screen resolution displays are adjusting their resolution down to 1024x768, likely because they find it uncomfortable to read the tiny text on high resolution displays. The negative effect of this resolution change is the loss of fidelity to the point where reading text in editors and web browsers is difficult. High definition video content also won’t be able to render properly.

Here is the data just for customers with displays capable of 1600x1200:

In a future blog post, one of the program managers from the Windows Desktop Graphics team is going to describe what we have done with that information to improve display quality and reading comfort in Windows 7.

We also frequently use our data to select appropriate participants for a survey. A researcher may be interested in sending out an online survey only to active users of virtual machine applications. We would first determine that group of users by looking at our “application usage” data and then create the list of participants for the researcher. Sometimes we combine automatically collected data with survey responses to analyze the relationship between a customer’s overall satisfaction and their PC configuration.

At the current point in time, 50% of our panel participants are using Windows XP and 50% are using Windows Vista. We are currently not offering open enrollment. If you are interested in being invited to this program, please send an email to winpanel@microsoft.com indicating “Notify me for enrollment” in the subject line. If you’d like to add a bit of information about yourself, including your Windows knowledge level, that would be much appreciated! We will add you to our request queue and make our best effort to invite you when we have capacity.

When we release the Windows 7 beta we will also be collecting feedback from this panel and asking for participation from a set of Windows 7 beta users. Our current plans call for signing up for the beta to happen in the standard Microsoft manner on http://connect.microsoft.com. Stay tuned!

-- Christina Storm

Reflecting on a few recent threads…

e7blog — Sat, 06 Sep 2008 10:00:00 GMT

When we kicked off this blog, the premise was a dialog – a two-way conversation about the engineering of Windows 7. We couldn’t be happier with the way things have been going in this short time. As we said we intended to do, we’ve started a discussion about how we build the product and have had a chance to have some back and forth in comments and in posts about topics that are clearly important to you. To put some numbers on things, I’ve personally received about 400 email messages (and answered quite a few) and all total we have had about 900 English language comments from about 500 different readers (with a few of you > 10 comments). Early numbers show we have about 10x that latter number in readers+page views.

A number of folks on the blog have asked for more details about how we build Windows—what’s the feature selection process, the daily build process, globalization, and so on. And in keeping with our new tradition of seeing the other “side” of an issue, many folks have also said they feel like they have enough of that information and want to know the features. So in this post I want to offer a perspective on a couple of features that have been talked about a bunch, and also a perspective on talking about features and feature selection.

We love the response. We have seen that some topics have created a forum for folks to do a lot of asking for features, and we will do our best to respond in the context of what we set out to do, which is to have a discussion about how Windows 7 is engineered, including how we make choices about what goes in the product. I admit that it might be tempting (for me) to blog a big long list of features and then say “give us feedback“. It is tempting because I have seen this in the past and it is a certainly an easy thing to do that might make people feel happier and more involved. However, there are some challenges with this technique that make these sorts of forums less than satisfying for all of us. First, it is “reactive” in that it asks you to just react to what you see. Absent a shared context we won’t be remotely on the same page in terms of motivations, priorities, and so on. This is especially the case when a feature is early and we aren’t really capable of “marketing” it effectively and telling the story of the feature. Second, a broad set of anecdotal feedback (that is free text) is not really actionable data and doesn’t capture the dialog and discussion we are having. Making decisions this way is almost certain to not go well with the “half” of the folks who don’t agree with the decision or prioritization. And third, there's a tendency to feel that feedback given yields action in that direction. These are some of the reasons why we have taken the approach of talking about how we are making Windows 7.

Some have suggested that we publish a list of features and then have a ranking/voting process. In fact some have gone as far as doing that for us on their own web sites. Thank you--these are interesting sites and we do look at them. But I think we can all agree that there is also a challenge that many folks are familiar with which is that a self-selected group provides one type of feedback which is likely to be different than a group that is selected intentionally as being representative. I was recalling an old episode of Saturday Night Live, “Larry the Lobster”, where for a toll call you could vote to save Larry from the stove or not. We all know that is a non-scientific poll, but we also don’t even know if it is a non-scientific poll of views of animal rights or of food preferences. I think the value of voting on specific features goes beyond just entertainment, but we also have to spend the energy making sure we are thinking about the issues within the same context. We also want any sample of customers we do to be representative of either the broad base of customers or the specific target customer “segment”.

Thus a big part of this blog is about creating a forum where we hear from each other about what is important and what our relative contexts are that we bring to the discussion. That’s why we think about this as a dialog—it is not a question and answer, request and response, point and counter-point, or announcement and comment. Personally, I am genuinely benefiting from the dynamic nature of what we are going to blog about based on those participating in the blog. So this is much more like a social where we all come to meet and talk, than a business meeting where we each have specific goals or a training class where one party does all the talking.

In that spirit, it seems good to continue a conversation about a few points that have come up quite a bit and I think folks have been asking for a point of view on these. Each is worthy of a post on its own, but I also wanted to offer a point of view about some specific feature requests. Let’s look at some topics that have come up as we have talked about performance or the overall Windows experience. Because this is “responding” to comments and input, there is a potential to delve into point/counter-point, I am hoping we can look back at the “context” discussions we have been having before we get too deep in debate.

Profile-based Setup

In terms of feature ideas, a number of you have suggested that we offer a way at setup time to configure Windows for a specific scenario. Some have suggested scenarios such as gaming, casual use, business productivity, web browsing, email, "lightweight usage", and so on. There is an implication in there that Windows could perform (speed, space, etc.) better if we tune it for a specific scenario along these lines, but in reality this assumption probably won’t pan out in a consistent or general way. There are many ways to consider this feature—it could be one where we tweak the contents of the Start Menu (something admins do in corporations all the time), or the performance metrics for some low level components (disk block size, tcp/ip frame sizes, etc.) or the level of user interface polish (aka “eye candy” as some have called it), and so on. We’ve seen scenario or role-based setup as a very popular feature for Windows Server 2008. In the server environment, however, each of these roles represents a different piece of hardware (likely with different configurations) or perhaps a specific VM on a very beefy machine, and also represent very clearly understood "workloads" (file server, print server, web server).

The desktop PC (or laptop) is different because there is only a single PC and the roles are not as well defined. Only in the rarest cases is that PC dedicated to a single purpose. And as Mike in product planning blogged, the reality is that we see very few PCs that run only a specific piece of software and in nearly every study we have ever done, just about every PC runs at least one piece of software that other people do not run. So we should take away from this the difficulty in even labeling a PC as being role specific. Now there are role-specific times when using a PC, and for that the goal of an OS is to adapt well in the face of changing workloads. As just one example of this in Windows Vista, consider the work on making the indexer a low priority activity using the new low-priority I/O APIs. I know some have mentioned that this is “something I always turn off” but the reality is that there is an upfront cost and then the ongoing cost of indexing is indeed very low. And this is something we have made significant improvements in for Desktop Search 4.0 (released as a download) and in Windows 7. The reality is that a general purpose OS should adjust to the workloads asked of it. We know things are not perfect, and we know many of you (particularly gamers) are looking for every single potential ounce of performance. But we also know that the complexity and fragility introduced by trying to “outsmart” core system services often overshadows the performance improvements we see across the broadest sampling of customers. There’s a little bit of “mythbusters” we could probably embark on so -- how about sharing the systematic results you have achieved and we can address those in comments?

Another challenge would be in developing this very taxonomy. This is something I personally tried hard to do for Office 95 and Office 97. We thought we could have a setup “wizard” ask you how much you used Word, Excel, PowerPoint, and Access, or a taxonomy that asked you a profession (lawyer, accountant, teacher). From that we were going to pick not just which applications but which features of the applications we would install. We consistently ran into two problems. First, just arriving at descriptors or questions to “categorize” people failed consistently in usability tests—the classic problem when given a spectrum of choices people would peg all of them in the middle or would just “freeze up” feeling that none fit them (people don't generally like labels). Second, we always had the problem of either multiple users of the same PC or people who would change roles or usage patterns. It turns out our corporate customers learned this same thing for us and it became routine to “install everything” and thus began an era of installing the full suite of products and then training was used to narrow the usage scenarios.

The final challenge has been just how do you present this to customers and when. This sequence of steps, the out of box experience, or OOBE, is what you go through when you unbox a PC (the overwhelming majority of Windows customers get it this way) or run setup from a DVD (the retail “packaged product” customer). This leads to the next item which is looking to the OOBE as a place to do performance optimizations. Trying to solve performance at this step is definitely a challenge and leads to our “context” for the out of box experience.

Out of Box Experience - “OOBE”

The OOBE is really the place that customers first experience Windows on a new PC. As many have read in reviews of competitive (to Windows PCs) products the experience goals most people have relate to “how fast can I get from packing knife to the web”. For Windows 7 we are working closely with our OEM partners to make sure it is possible to deliver the most streamlined experience possible. Of course OEMs have a ton of flexibility and differentiation opportunties in what they offer as part of setting up a new PC, and what we want to do is make sure that the “core OS” portion of this is the absolute minimum required to get to the fun of using your PC.

By itself, this goal would run counter to introducing a “profiling” or “wizard” help gauge the intended (at time of purchase) uses/usage of a PC. That doesn’t mean that an OEM could not offer such a profiled experience that could provide a differentiated OOBE experience, but it isn’t one we would ask all customers to go through as part of the “core OS” installation.

I recognize many of you as PC enthusiasts have gone through the experience of setting up a Linux PC using one of the varieties of package managers—probably many times just to get one installation working right. As you’ve seen with these installs (especially as things have recently converged on one particular end-user focused disti), the number of ways you can produce a poorly running system exceeds the number of ways you can produce a fully functional (for your needs) setup In practice, we know that many components end up depending on many others and ultimately this dependency graph is a challenge to manage and get right, even with a software dependency manager (like Windows Installer). As a result, we generally see customers benefitting from a broad base of software on the machine so long as that does not have a high cost—developing that install is a part of developing the product, balancing footprint, architectural connections, system reliability, etc.

So our context for the out of box experience would be that we don’t want to introduce complexity there, where customers are least interested in dealing with it as they want to get to the excitement of using their new PC. I think of it a bit like the car dealers who won’t hand you the keys to your car until you sit and watch a DVD about the car and then get a guided tour of the car—if you’re like me you’re screaming “give me the keys and let me out of here”. We think PC buyers are pretty much like that and our research confirms that around the world.

We also recognize that there are expert users who might want to adjust the running system for any variety of reasons (performance, footprint, surface area, etc.) We call this the “Turning Windows Features On or Off” which is the next item we’ve heard from you about.

Windows Features

If we install the typical installation of Windows as one that is basically all the features in the particular SKU a customer purchased, then what about the customer that wants to tweak what is installed and remove things? Customers might want to remove some features because they just never use them and don’t want to accidently use them or carry with them the “code” that might run. Customers might be defining a role for the PC (cash register) and so making sure that specific features are never there. There are many reasons for this. For many releases Windows has had the ability to install or uninstall various features that are part of Windows. In Windows Vista this was made more robust as the features are removed from the running system but also remained available for reuse without the original DVD. We also made the list of features longer in Windows Vista.

For Windows 7, many have asked for us to make this list longer and have more features in it. This is something we are strongly considering for Windows 7 as we think it is consistent with the design goals of “choice and control” that you have seen us talk about here and quite a bit with Internet Explorer 8.0 beta 2.

Of course we have the same challenge that Linux distributions have which is you can quickly remove things could break other features by being removed, and then you have to have all the complexity of informing the customer of these “dependencies” and ultimately you end up feeling like everything is connected to everything else. On some OS installations this packaging works reasonably well because there is duplication of features (you pick from several file browsers, several web browsers, several office suites, several GUIs even). The core Windows OS, while not free from some duplication, does not have this type of configuration. Rather we ship a platform where customers can add many components as they desire.

For customers that wish to remove, replace, or just prevent access to Windows components we have several available tools:

Set Your Default Programs (or Set Program Access and Defaults). In Vista these features allow you to set the default programs/handlers by file type or protocol. This was introduced in Windows XP SP1. In Vista the SYDP was expanded and we expect all Microsoft software to properly register and employ this mechanism. So if you want to have a default email program, default handler for GIF, or your choice of web browser this is the user interface to use. Windows itself respects these defaults for all the file types it manages.
Customizing the start menu or group policy. For quite some time, corporate admins have been creating “role-based” PCs by customizing the start menu (or even going way back to progman) to only show a specific set of programs. We see this a lot in internet cafes these days as well. The SPAD functionality takes this a step further and provides an end-user tool for removing access to installed email programs, web browsers, media players, instant messengers, and virtual machine runtimes.
Removing code. Sometimes customers just want to remove code. With small footprint disks many folks have looked to remove more and more of Windows just to fit on SSDs. I’ve certainly seen some of the tiny Windows installations. The supported tool for removing code from Windows is to use the “Turn Windows Features on and off” (in Vista) user interface. There are over 80 features in this tool in premium Vista packages today.

Many folks want the list of Windows features that can be turned on / off to be longer and there have been many suggestions on the site for things to make available this way. This is more complex because of the Windows platform—that is many developers rely on various parts of the Windows platform and just “assume” those parts are there. Whether it is a media player that uses the windows address book, a personal finance package that uses advanced print spooling, or even a brand new browser that relies on advanced networking features. These are real-world examples of common uses of system APIs that don’t seem readily apparent from the end-user view of the software.

Some examples are quite easy to see and you should expect us to do more along these lines, such as the TabletPC components. I have a PC that is a very small laptop and while it has full tablet functionality it isn’t the best size for doing good ink work for me (I prefer a 12.1” or greater and this PC is a 10” screen). The tablet code does have a footprint in memory and on the 1GB machine if I go and remove the tablet components the machine does perform better. This is something I can do today. Folks have asked about Photo Gallery, Movie Maker, Windows Mail, Windows Calendar…this is good feedback and good things for us to consider for Windows 7.

An important point is that a vast majority of things you remove this way consume little or no resources if you are not using them. So while you can reduce the surface area of the PC you probably don’t make it perform better. As one example, Windows Mail doesn’t slow you down at all if you don’t have any mail (or news) accounts configured. And to be certain you could hide access with SPAD or just change the default protocol handler to your favorite mail program. Another example is you can just change the association and never see photogallery launched for images if that is your preference. That means no memory is taken by these features.

This was a chance to continue our discussion around how we are learning from our discussion and some specifics that have come up quite a bit. I hope we are gaining a shared view of how we look at some of the topics folks have brought up.

So this turned into a record long post. Please don’t expect this too often :-)

--Steven