The Windows 7 Taskbar

Happy Birthday Windows!  Given all the interest in the most used user-interface of Windows we thought it would be good to take a look back and see how we got to Windows 7.  --Steven

We were very excited to unveil elements of the Windows 7 desktop at this year’s Professional Developers Conference (as seen in the Welcome to the Windows 7 Desktop session, among others). In previous posts (User Interface: Starting, Launching, and Switching and Follow-up: Starting, Launching, and Switching) we looked at the history, anatomy and areas for improvement of the taskbar. In this post, we will continue the conversation. Don’t let looks fool you though—the UI may feel new to Windows for some of you or old hat for some of you, but rest assured it represents a careful evolution that strives to address customer feedback while retaining its familiar Windows DNA.

It was 23 years ago on November 20, 1985 when Windows first shipped. As it just so happens, this first Microsoft graphical shell actually holds relevance to this post as it surfaced one of the industry’s first taskbar-like concepts.

Fig 1 Windows 1.01: Icons at the bottom of the screen represent running windows

Windows 1.0 supported zoomed (full-screen), tiled and icon (minimized) windows. Since there was no support for overlapping [that big debate between charless and billg, Steven], a dedicated portion of the desktop was kept visible at the bottom of the screen to surface non-tiled and non-zoomed windows. By minimizing a window or dragging it to the bottom of the screen, the person was able to populate this rudimentary taskbar with a large icon corresponding to the running window. She could then get back to this window by clicking or dragging this icon to the desktop. As simple as this mechanism seems today, it cemented an important concept that is with us even in Windows 7—when people switch between tasks, they are really switching between windows. Although it took Windows 95 to introduce a mature taskbar with launching, switching and notification functionality, the experience of surfacing and switching between windows via a dedicated region at the bottom of the screen is as ancient as Windows 1.0.

Setting Goals

In the previous taskbar posts, we discussed some high-level principles we defined after digesting the mountain of data and feedback on the taskbar. Here’s a more detailed look at the goals we identified and how we began to frame feature concepts.

Things you use all the time are at your fingertips

It is easy to get to the programs and destinations you use all the time, with less mouse movement and fewer clicks.

Accessing commonly used programs within a single click required us to enrich Quick Launch by increasing its presence on the taskbar and making more top-level room for pinned items. We began looking into how Quick Launch interacted with the taskband and how launching and switching were sometimes separate and other times duplicative. For example, almost all single-instance programs in Windows interpret an attempt to re-launch them as a switch if they are already running. So, clicking Outlook’s icon in Quick Launch would merely switch to the program if it was already running and present in the taskband. To make room for more items on the taskbar, we knew we had to remove some of the redundancy and free up valuable real-estate.

When researching and modeling a person’s workflow, we came to realize that there were three basic steps that a person frequently seems repeats. First, she finds the program and launches it. Then, she uses the program’s UI to open a file she wants to work on. Then finally, she gets to work. We asked ourselves whether we could help people jump directly to these items by skipping the first two steps. We called these files, folders, links, websites and other items that programs create or consume “destinations” as they represent where the person is ultimately is navigating to. We decided that these destinations should also be easily accessible from the taskbar. However, for real success and adoption, we needed to think through how destinations could be effectively surfaced to the person without the need for manual customization or by requiring developers to do lots of work.

Manage your windows with confidence

You can switch to the right window quickly without mistakes and effortlessly position windows the way you want them.

This goal spoke to the very heart of the taskbar—the ability to switch between windows. This challenged us with seeking a more predictable method of surfacing windows on the taskbar, meaningful use of text and a reliable method of helping people consistently switch with confidence. We’ve had text on the taskbar for years and Vista introduced thumbnails, but customer feedback informed us that there was room for improvement. Interestingly, we found inspiration in old features such as Windows XP’s window grouping and Alt-Tab’s visual layout of individual windows.

During our investigation, we also spent time looking into why a person would switch windows in the first place. Two interesting scenarios emerged—one in which she needs to get some information from a window (e.g. getting a phone number) and to interact with a window’s options (e.g. controlling background music). We wondered whether we could address these task switching cases in a novel way—by actually removing the need to switch completely.

You are in control

The desktop reflects your style. You get to personalize the experience, choosing what is important to you, including how and when you receive notifications.

By far the biggest target of feedback, the Notification Area had to put control back in the hands of people. It was decided that instead of the opt-out model that required the person to clean up this area, we would start with a clean experience. Only system icons would appear by default and then people can to customize this area to their liking.

Clean and lightweight

The desktop experience feels organized, lightweight, open and is a pleasure to use. Visuals and animations are delighters the first time and every time.

A successful product is more than the utility it serves—it is also an experience. From the very start we wanted the taskbar, and the desktop as a whole, to draw an emotional response from the person. This required a set of scoped delighters that demoed well and retained their appeal over time. We began to define a personality for the UI using terms such as “glass and energy,” Chi, authenticity and many others. These investigations helped define a visual and animation language that we could then apply to several aspects of Windows 7. Expect a future blog post that delves much deeper into this important design process—much of which Sam discussed in his PDC session.

The Taskbar, Evolved

The Windows 7 taskbar is about launching with ease, switching with confidence and all the while remaining in control. The UI is made up of several key features that complete common end-to-end scenarios. Let’s dive into each of these elements and how they work.

Refreshed Look

The taskbar has undergone a facelift. We’ve enabled large icons by default (as seen in Windows 1.0 and also an option of Quick Launch since Windows 95 with IE 4). This affords a richer icon language, improves identification of programs and improves targeting for both the mouse and touch. Yet, one of the most important advantages large icons provide is a means to promote the taskbar as the central place to launch everyday tasks. We joke that the new taskbar is the “beachfront property of the Windows OS” and in turn, we are already seeing many people populating the UI with their commonly used programs. Somewhat if a visual trick, the taskbar is only 10 pixels (at 96 DPI) higher than its Vista counterpart (when used as a single row, since multiple rows are still supported, along with positioning around the screen edges).

Fig 2. The Windows 7 taskbar: Default settings include large icons, no text and glass surface

To mitigate its slightly increased height and the larger icons, we decided to impart the UI with a more prominent glass treatment. This also allows us to better showcase the person’s color preference (you’ll recall that in a previous post we revealed that almost 30% of sessions have personalized glass). We also changed the Vista behavior so that when a window is maximized, both the taskbar and the window’s title bar continue to remain open and translucent. We received lots of feedback on Vista that many people didn’t like these UIs turning opaque and dark.

Pinning

You can still pin programs to the taskbar by dragging them or via a context menu, just like you have always done with Quick Launch. Destinations can also be pinned via a drag/drop, but they are designed to be surfaced differently as we’ll see under the Jump List section.

Unification

If one increases the size of Quick Launch, one must then determine what to do with the taskband. As previously discussed, we observed that under many scenarios of single-instance programs, launching and switching were equivalent. Hence, we decided to standardize this behavior and have program launchers turn into window switchers when they are launched. Effectively, we unified Quick Launch and the taskband. While some other operating systems have similar concepts, one difference with our approach is that our default experience always optimizes for a single representation on the taskbar. This means that regardless of a window’s state (e.g. minimized, maximized or restored) there are no new or duplicate buttons created. Also, the default taskbar doesn’t allow destinations to be pinned to the top-level which prevents duplication of a pinned file and a running window with that same file open. When we say there is “one button to rule them all” we’re serious. This approach to a single, unified button keeps the taskbar uncluttered and gives the person a single place to find what she’s looking for.

Combining launching and switching also made it easier to provide the most requested feature—the ability to move taskbar buttons. Quick Launch as always allowed this, but combining this mechanism with the taskband naturally extended rearrange functionality to running windows.

Interactive, Grouped Thumbnails

Vista showed thumbnails when the user hovers on a taskbar button and Windows 7 improves upon this design. Unlike Vista, these thumbnails are now an extension of their corresponding button so the person can click on these visual aides to switch to a given window. The thumbnail is also is a more accurate representation of a window complete with an icon in the top left corner, window text and even the ubiquitous close button in the top right.

Fig 3. Thumbnails: Grouped, interactive thumbnails make it easier to manage windows

One of the most important functions of the taskbar is to surface individual windows so people can easily switch between them. Having unified a program launcher and a single window switcher, the next logical step was to determine how multiple windows of a program could be combined and presented. We looked no further than a feature introduced in Windows XP called window grouping. When the taskbar became full, windows of a program could collapse into a single menu. However, there were a few challenges with the design. First, the behavior isn’t predictable. People don’t really understand when this scaling mechanism is triggered. Second, a listview of windows isn’t always the best way to represent these items. Finally, opening the menu always required a click, which slowed some people down. Our solution was to combine buttons by default for a predictable experience, to use grouped thumbnails and to have these thumbnails appear on hover as well as on click. Think of this approach as a contextual Alt-tab surfaced directly off the taskbar. When the person brings her mouse to a taskbar button, all the thumbnails of a program appear simultaneously making for a organized, light-weight switching model. To polish off the experience, we show a visual cue of stacked tiles that provides feedback on whether there are multiple windows running for a program. We also recognized that a set of people may still wish to see an individual buttons for each window and an option permits this behavior.

With the Windows 7 taskbar, there is a single place to go regardless of whether the program is not running, running with one window or running with several windows. Rich thumbnails provide more intuitive ways of managing and switching between windows.

Aero Peek

Here’s a riddle for you—what’s the best size for a window’s preview that will guarantee that the you can accurately identify it? Grouped thumbnails look and feel great, but we know these small previews don’t always provide enough information to identify a window. Sure they work great for pictures, but not so for emails or documents. The answer is simply to show the actual window—complete with its real content, real size and real location. That’s the concept behind Aero Peek.

When the taskbar doesn’t offer enough information via text or a thumbnail, the person simply moves the mouse over a taskbar thumbnail and voilà—the corresponding window appears on the desktop and all other windows fade away into glass sheets. Once you see the window you want, just click to restore it. Not only does this make finding a window a breeze, it may also remove the need to switch altogether for scenarios in which one just needs a quick glance to glean information. Peek also works on the desktop too. Show Desktop has been moved to the far right of the taskbar where one can still click on this button to switch to the desktop. The control enjoys a Fitts magic corner which makes it very easy to target. If you just move your mouse over the control, all windows on the desktop turn to glass allowing the desktop to be seen. It’s easy to now glance at a stock or the weather gadget or to check to see if a file is on the desktop.

Fig 4. Aero Peek: Hovering over a thumbnail peeks at its corresponding window on the desktop

We spent a lot of time analyzing different aspects of Peek. For example, we recognized that when people are using the feature, they won’t be necessary focused on the taskbar as they look at windows on the desktop. An early prototype triggered Peek directly off the top-level of the taskbar but this revealed issues. Moving the mouse across a small a region to trigger different previews exited Peek since the natural arc of hand motion resulted in the mouse falling off the taskbar. By only triggering Peek off the thumbnails, we gained much more room for the mouse to arc and we also reduced accidental triggers.

Jump Lists

As far back as Windows 1.0, there has always been a system menu that shows contextual controls for running windows and their programs. This menu is accessible by right-clicking on a taskband button or in the top left corner of most windows. By default, the menu exposes windows controls such as close. (Random trivia—ever wonder why the system menu off a taskbar button always shows close in bold when close isn’t the double-click behavior? Well, the answer is that double-clicking the top left region of most windows will close it and the bolded option makes sense in this context. The same menu just happens to be hosted in both locations.) Over the years, some programs have extended the system menu to surface relevant tasks. For example, Command Prompt reveals tasks such as editing options, defaults and properties in its system menu. However, this is a bit of a free-for-all for programs to opt in or not, resulting in an inconsistent experience for people. Another blow to this scenario is that the system menu is only accessible when the program is running. This makes sense since the default commands are about window management, but what if you wanted to access a program’s tasks even it isn’t running?

As we discussed under the goals section, we thought about the various steps people have to take to accomplish tasks and whether we could reduce them. Be it getting to a destination or accessing the commands of a program, we wanted to make it easier for people to jump to the things they are trying to accomplish. Jump Lists are a new feature of the Windows 7 taskbar that accomplish just this. Think of this feature as a mini Start Menu for each program or an evolved version of the system menu. Jump Lists surface commonly used nouns (destinations) and verbs (tasks) of a program. There are several advantages this new approach provides. First, the you don’t need to even start the program to quickly launch a file or access a task. Second, destinations don’t take up valuable space on the taskbar; they are automatically organized by their respective program in a simple list. Should one have ten programs pinned or running on her taskbar, this means she could have quick access to over 150 destinations she uses all the time, without even the need to customize the UI! Since the Jump List shows lots of text for each of its items, gone are the days of having identical icons on your taskbar that are indistinguishable without a tooltip. Should you wish to keep a specific destination around, you can simply pin it to the list.

Fig 5. Jump List: Right-clicking on Word gives quick access to recently used documents

To make sure we provide a consistent and valuable experience out-of-the-box, we decided to pre-populate Jump Lists and also allow programs to customize the experience. By default, the menu contains the program’s shortcut, the ability to toggle pinning, the ability to close one or all windows and a program’s recent destinations (assuming they use the Common File Dialog, register their file type or use the Recent Items API). Programs are able to replace the default MRU (Most Recently Used) list with a system-maintained MFU (Most Frequently Used) list, should their destinations be very volatile. For example, while Word will benefit from a MRU just like the one in their File Menu, Windows Explorer has opted to enable the MFU because people tend to visit many paths throughout a session. Programs are also able to provide their own custom destination list when they have a greater expertise of the person’s behavior (e.g. IE exposes their own history). Still others like Windows Live Messenger and Media Player surface tasks or a mix of tasks and destinations.

In case we haven’t yet impressed it upon you, the taskbar is about a single place to launch and switch. Jump Lists offer another important piece of the puzzle as it surfaces valuable destinations and tasks off a program’s unified taskbar button.

Custom Window Switchers

All the major web browsers offer tabs and a method of managing these tabs. One could argue tab toolbars are really like taskbars since they facilitate switching. These TDI (Tabbed Document Interface) and MDI (Multiple Document Interface) programs have always resorted to creating their own internal window management systems as the Windows taskbar was not optimized to help their scenarios. Some programs like Excel did custom work to surface their child windows on the taskbar, but this approach was somewhat of a hack.

Since the new taskbar already groups individual windows of a program under a single button, we can now offer a standard way for programs that have child windows to expose them. Again, the taskbar offers a single, consistent place to access real windows as well as child windows. These custom window switchers also behave as regular windows on the taskbar with rich thumbnails and even Aero Peek.

Thumbnail Toolbars

In the earlier taskbar posts, we discussed how Windows Media Player’s deskband offers valuable background music controls, but only a mere 3% of sessions ever enjoy the functionality. The new taskbar exposes a feature called Thumbnail Toolbars that surface up to seven window controls right in context of taskbar buttons. Unlike a Jump List that applies globally to a program, this toolbar is contextual to just a specific window. By embracing this new feature, Media Player can now reach a majority of people.

Fig 6. Thumbnail Toolbar: Window controls easily accessible in context of a taskbar thumbnail

Thumbnail Toolbars leave the taskbar uncluttered and allow relevant tasks to be conveniently accessible directly from a taskbar thumbnail. Surfacing tasks reduces the need to switch to a window.

Notification Area

We’re happy to announce that the Notification Area is back under your control. By default, only a select few system icons are shown while all others appear in a menu. Simply drag icons on or off the taskbar to control the experience. Better yet, every balloon tip that appears in the system has a little wrench icon that allows one to quickly “swat” an annoying alert by immediately seeing what is causing the notification and a direct way to disable it.

Fig 7. Notification Overflow: By default icons appear in an overflow area that you can then promote

Interestingly a very popular change to Notification Area isn’t about reducing noise, but rather showing more information. The default taskbar now reveals both the time and the date. Finally!

Overlay Icons and Progress Bars

Cleaning the Notification Area warrants us to consider other ways that programs can surface important information. We’ll always had overlay icons throughout Windows (e.g. to show shortcuts in Explorer) so we decided to bring this functionality to the taskbar. An icon can now be shown over a program’s taskbar button. Furthermore, programs can also give feedback about progress by having their taskbar button turn into a progress bar.

Fig 8. Progress Bars: Explorer utilizes taskbar progress to show a copy operation in process

A program can now easily show an icon or progress in context of its taskbar button which furthers the one place, one button philosophy of the taskbar.

Color Hot-track

Color hot-track is a small touch that typifies the new taskbar’s personality. When a person moves her mouse over a running program on the taskbar, she will be pleasantly surprised to find that a light source tracks her mouse and the color of the light is actually based on the icon itself. We calculate the most dominant RGB of the icon and dynamically paint the button with this color. Color hot-track provides a delight factor, it offers feedback that a program is running and it showcases a program’s icon. We’ve always believed that programs light up the Windows platform and now, we’re returning the favor.

Fig 9. Color Hot-track: moving the mouse across a running window reveals a dynamically colored light effect

Start Menu

Vista introduced several changes to the Start Menu so we decided to minimize churn to this UI in Windows 7. Notable improvements include the availability of Jump Lists and a better power button that defaults to Shutdown, but makes it easy to customize.

Different, Yet Familiar

Despite all the features of the new taskbar, it is worthwhile noting the UI retains its familiarity. We like to describe our work as evolutionary, not revolutionary. The taskbar continues to be a launch surface, a window switcher and a whisperer of notifications. Whether one is relatively new to Windows or a seasoned pro, we realize change comes at a cost. It is for this reason that we took the time to carefully evaluate feedback, we performed numerous studies to validate our designs and finally, we will continue to provide scoped settings that keep the UI flexible.

We hope this post provided more insight into the new Windows 7 taskbar. Expect future discussions on our design process, how we tested our features and advanced functionality for all you enthusiasts.

- Chaitanya

Disk Space

This post is about disk space and the disk space “consumed” by Windows 7. Disk space is the sort of thing where everyone wants to use less, but the cost of using a bit more relative to the benefits has generally been a positive tradeoff. Things have changed recently with the availability of solid-state drives in capacities significantly smaller than the trend in spinning drives. Traditionally most all software, including Windows, would not hesitate to consume a 100MB on a specific (justified) need when looking at a 60GB (or 1,500GB) drive; with desirable machines shipping with 16GB of solid-state storage, we are looking carefully at the disk space used by Windows—both at setup time and also as a PC “ages”. We also had a specific session at WinHEC on solid-state drives that might be interesting to folks. This post is authored by Michael Beck, a program manager in the core OS deployment feature team. --Steven

Let’s talk about “footprint”. For the purposes of this post, when I say “footprint” I’m talking about the total amount of physical disk space used by Windows. This includes not only the Windows binaries, but all disk space consumed or reserved for system operations. Later in this entry, I’ll discuss in detail how the disk footprint is consumed by various Windows technologies.

A number of comments have asked about disk footprint and what to expect in terms of Windows 7’s usage of disk space. Like many of the design issues we have talked about, disk space is also one where there are tradeoffs involved so this post goes into the details of some of those tradeoffs and also discusses some of the feedback we have received. It should be noted, that we are not at the point where we are committing to system requirements for Windows 7, so consider this background and engineering focus.

To structure this post we’ll take two important points of feedback or questions we have received:

• What does the WinSxS directory contains and why is it so big, and can I just delete it?
• Where does all the disk space go for Windows components?

We’ll then talk about the focus and engineering of Windows 7.

WinSxS directory

We definitely get a lot of questions about the new (to Vista) Windows SxS directory (%System Root%\winsxs) and many folks believe this is a big consumer of disk space as just bringing up the properties on a newly installed system shows over 3000 files and over 3.5 GB of disk consumed. Over time this directory grows to even higher numbers. Yikes--below is an example from a Steven's home PC.

“Modularizing” the operating system was an engineering goal in Windows Vista. This was to solve a number of issues in legacy Windows related to installation, servicing and reliability. The Windows SxS directory represents the “installation and servicing state” of all system components. But in reality it doesn’t actually consume as much disk space as it appears when using the built-in tools (DIR and Explorer) to measure disk space used. The fact that we make it tricky for you to know how much space is actually consumed in a directory is definitely a fair point!

In practice, nearly every file in the WinSxS directory is a “hard link” to the physical files elsewhere on the system—meaning that the files are not actually in this directory. For instance in the WinSxS there might be a file called advapi32.dll that takes up >700K however what’s being reported is a hard link to the actual file that lives in the Windows\System32, and it will be counted twice (or more) when simply looking at the individual directories from Windows Explorer.

The value of this is that the servicing platform (the tools that deliver patches and service packs) in Windows can query the WinSxS directory to determine a number of key details about the state of the system, like what’s installed, or available to be installed (optional components, more on those later), what versions, and what updates are on the system to help determine applicability of Windows patches to your specific system. This functionality gives us increased servicing reliability and performance, and supports future engineering efforts providing additional system layering and great configurability.

The WinSxS directory also enables offline servicing, and makes Windows Vista “safe for imaging”. Prior to Windows Vista, inbox deployment support was through “Setup” only. IT professionals would install a single system, and then leverage any number of 3^rd party tools to capture the installed state as a general image they then deployed to multiple systems. Windows wasn’t built to be “image aware”. This meant that greater than 80% of systems were deployed and serviced using a technology that wasn’t supported natively, and required IT departments to create custom solutions to deploy and manage Windows effectively. In addition, state stored in the WinSxS directory can be queried “offline”, meaning the image doesn’t have to be booted or running, and patches can be applied to it. These two features of WinSxS give great flexibility and cost reductions to IT departments who deploy Windows Vista, making it easier to create and then service standard corporate images offline.

While it’s true that WinSxS does consume some disk space by simply existing, and there are a number of metadata files, folders, manifests, and catalogs in it, it’s significantly smaller than reported. The actual amount of storage consumed varies, but on a typical system it is about 400MB. While that is not small, we think the robustness provided for servicing is a reasonable tradeoff.

So why does the shell report hard links the way it does? Hard links work to optimize disk footprint for duplicate files all over the system. Application developers can use this functionality to optimize the disk consumption of their applications as well. It’s critical that any path expected by an application appear as a physical file in the file system to support the appropriate loading of the actual file. In this case, the shell is just another application reporting on the files it sees. As a result of this confusion and a desire to reduce disk footprint, many folks have endeavored to just delete this directory to save space.

There have been several blogs and even some “underground” tools that tell you it’s ok to delete the WinSxS directory, and it’s certainly true that after installation, you can remove it from the system and it will appear that the system boots and runs fine. But as described above, this is a very bad practice, as you’re removing the ability to reliably service, all operating system components and the ability to update or configure optional components on your system. Windows Vista only supports the WinSxS directory on the physical drive in its originally installed location. The risks far outweigh the gains removing it or relocating it from the system, given the data described above.

Where does the disk space go?

As we all know adding new functionality consumes additional disk space--in Windows or any software. In reality, “code” takes up a relatively small percentage of the overall Windows footprint.  The actual code required for a Windows Vista Ultimate install is just over 2GB, with the rest of the footprint going to “data” broadly defined. Let’s dig deeper into the use of storage in a Windows Vista installation and what we mean by "data".

Reliability and security were core considerations during the engineering process that built Windows Vista. Much of the growth in footprint comes from a number of core reliability features that users depend on for system recovery, performance, data protection, and troubleshooting. Some of these include system restore, hibernation, page file, registry back up, and logging. Each of these represent “backup state” that is available to the system to recover from any number of situations, some planned and others not. Because we know that different customers will want to make different tradeoffs of disk space relative to recovery (especially on small footprint devices) with Windows 7 we want to make sure you have more control than you currently do to decide ahead of time how much disk space to use for these mechanisms, and we will also tune our defaults to be more sensitive to overall consumption due to the changing nature of storage.

System restore and hibernation are features that help users to confidently recover their system and prevent data loss, in a number of situations such as low battery (hibernation), bad application installation or other machine corruption (system restore). Combined, these features consume a large percentage of the footprint. Because of the amount of space these use, they are easy to identify and make decisions regarding.

System restore protects users by taking snapshots of the system prior to changes and on regular intervals. In Windows Vista, system restore, is configured to consume 300mb minimally, and up to 15% of the physical disk. As the amount of space fills up with restore points, System Restore will delete older restore points to make room for new ones. The more space you have, the greater the number of restore points you have available to “roll back” to. We have definitely heard the feedback from Windows Vista customers around system restore and recognize that the it takes significant space and is not easy to tune. Some have already seen the pre-beta for Windows 7 provides an interface to manage the space better.

Hibernate is primarily used on mobile PCs and saves your work to the hard disk and puts the computer in an extremely low power state.  Hibernate is used on mobile PCs when the battery drains below a certain threshold or when turning the computer off without using Shut Down to extend battery life as much as possible.  On Windows Vista, Hibernate is also automatically used with Sleep on desktop PCs to keep a backup copy of open programs and work. This feature is called Hybrid Sleep and is used to save state to the hard disk in case power fails while the computer is sleeping.  Hibernate writes all of the content in memory (RAM) to a file on the hard drive named Hiberfil.sys.  Therefore, the size of the reserved Hiberfil.sys is equal to the amount of RAM in the machine.  In the Windows Vista timeframe, the amount of RAM being built into computers has increased significantly, thus the disk footprint of Hibernate is more noticeable than before. This space must be reserved up front to guarantee that in a critical low battery situation, the system can easily write memory contents to the disk.  Any mobile PC user that has experienced their computer automatically entering Hibernate when the battery is critically low can appreciate the peace of mind this footprint growth provides. While we're talking about RAM and disk footprint in the same paragraph, Mark Russinovich has a post this week on virtual memory and how big the swapfile could/should/can be that you might find interesting.

Now it’s clear that in the description above, I don’t account for the entire footprint required by Windows Vista. For instance, we also include many sample files, videos, high resolution backgrounds that allow users to easily customize their experience, and try out new features, but we’ve covered a couple of the more common questions out there.

It’s important that we consider more than just the size of the system once deployed, but we must also look at how the system grows over time as services write logs, updates, and service packs are installed, system snapshots are taken etc. For many, the “growth” over time of the installation proves to be the most perplexing—and we hear that and need to do better to (a) make smarter choices and (b) make it clearer what space is being consumed and can be reclaimed.

The following table provides one view of the installation footprint of a Windows Vista Premium/Ultimate installation. This includes the full installation, but to make it digestible this has been broken down into some logical categories and also highlights some specific features. Part of the reason to highlight specific feature is to illustrate the “costs” for items that have been raised as questions (or questionable).

Here are some items worth calling out:

• ~1GB driver support. Windows Vista works with thousands and thousands of different devices. The ability to plug in almost any device, even your old printer and have it get recognized and install automatically is something customers have come to expect from Windows. We receive lots of feedback wanting to remove some or all of these and each release we carefully scrub the “in-box” device support relative to what we see from telemetry in terms of used devices. The ability to install a printer or USB device while offline is a key value, especially with laptops representing over half of all PCs being sold. In the future we can possibly assume “always go to Windows Update” but we’re not there yet in most places in the world.
• ~1GB of system growth in serviced and superseded components to support robust rollback and recovery, after installing critical security and functionality updates. We receive a lot of positive feedback about the robustness of servicing but at the same time, the desire to rollback a specific fix for any variety of reasons remains an important robustness and reliability measure. We also understand the feedback we have received regarding the disk requirements to install SP1 on top of RTM. We hope folks are aware of the vsp1cln.exe utility in the system32 directory, for those that are in need of disk space.
• ~1GB hibernation support is necessary in order to prevent data loss when a machine has been in standby for many hours. This can be removed via the Disk Cleanup wizard or via an elevated command prompt (powercfg /h off).
• ~315mb of Fonts. Windows users speak many different languages, often on the same PC, and wish Windows to “speak” to them. Windows Vista contains native font support to allow users with systems defaulted to one language to be able to read documents, or websites in another. As we know, however, fonts are east to delete should you desire.
• ~52MB of log files. Whether it is the event log, servicing logs, or device installation logs (or more) this space is consumed and becomes critical when trying to diagnose a failure. These logs are often used by our support personnel or corporate helpdesks to diagnose a specific failure.

Engineering Windows 7

Windows disk space consumption has trended larger over time. While not desirable, the degree to which it’s been allowed is due in large part to ever-increasing hard drive capacity, combined with a customer need and engineering focus that focused heavily on recoverability, data protection, increasing breadth of device support, and demand for innovative new features. However, the proliferation of Solid State Drives (SSDs) has challenged this trend, and is pushing us to consider disk footprint in a much more thoughtful way and take that into account for Windows 7.

This doesn’t mean that we’re going to stop adding great features or make Windows less reliable or recoverable. As we look to the future, it’s critical that as we innovate, we do so treating the disk space consumed by our work as a valuable resource, and have a clearer design for how Windows uses it. We want to make sure that we are making smart choices for the vast majority of customers and for those desiring more control providing places to fine tune these choices as appropriate. This design goal isn’t about a type of machine, or specific design, all Windows editions benefit from efforts that focus on a reduction of the overall footprint.

For example, as we consider the driver support discussed above, Windows Vista with SP1 installs almost 1GB of drivers on the system to support plug and play of devices. This local cache can get out of date as IHVs release updates to their drivers, and as a result, users are pushed to Windows update to get the latest version once the device is installed.

Why not extend the PnP user experience to include (or only use) the Windows Update cache of drivers and save some disk space? This has several benefits:

1. Because MobilePCs rarely lack a network connection, they can simply get the new driver from the web.
2. People don’t have to install the driver twice on updated devices because they do the round trip to the web anyways.

With this example it’s easy to see how engineering for a minimal footprint might actually deliver a better experience for people when attaching new devices to their systems. At the same time, we want to be careful about going too far too soon. We get a tremendous amount of feedback regarding the “plug and play” experience or feedback about costly download times (if download is at all possible). For Windows 7 we are going to continue to be deliberate in what we include based on the telemetry of real world devices and reducing the inbox set to cover the most popular devices around the world. At the same time we will continue a very significant effort around having the best available Windows Update site for all devices we can possibly support.

Windows features installed by default make sense in most cases to support many scenarios. We should consider how we make some features/components (such as Media Center) optional when they are not required rather than installing them by default on every system. We’re committed to make more features of Windows optionally installed. As you might notice today in Windows, when you choose to add a feature that was not installed Windows does not require a source (a DVD or network location). This is because the feature is stashed away as part of a complete Windows install—this is itself a feature. We will always keep features available and will always service them even when components are not installed—that way if you add a component later you do not risk adding a piece of code that might have been exploited earlier. This is another important way we keep Windows up to date and secure, even for optional features.

System growth over time is an area where we need to provide more “transparency”. For instance, Windows will archive previous versions of updated system components to allow robust rollback. A new system will install patches as Windows Update makes them available, just as expected by design. As a Service Pack or other large update is installed that contains or supersedes any of the previous patches; we can simply recover the space used by the old updates sometime after the update is successfully installed.

Windows writes logs in many places to aid in troubleshooting and these logs can grow very large. For instance, when an application crashes, Windows will archive a very large dump file to support analysis of the failure. There are many good reasons for this behavior, but as we change our mindset towards footprint, we need to extend our scenarios to include discussions of how to manage the growth, and recover the disk space consumed whenever possible. Other areas where we are considering the default disk space reserved include System restore and hibernation. On a disk constrained system, the 1GB or more reserved to support hibernation is costly and there may be ways to shrink the size of hiberfil.sys. System restore should be configurable, and default in all cases to the minimally useful number of snapshots vs. a blanket 15% of the system disk.

At WinHEC we had several machines on display with 16GB drives/partitions and on those you could see there was plenty of free disk space. Like all the benchmarks, measuring disk space on the pre-beta is not something we’re encouraging at this time.

In conclusion, as we develop Windows 7 it’s likely that the system footprint will be smaller than Windows Vista with the engineering efforts across the team which should allow for greater flexibility in system designs by PC manufacturers. We will do so with more attention to defaults, more control available to OEMs, end-users and IT pros, and will do so without compromising the reliability and robustness of Windows overall.

-Michael Beck

Action Center

We’re back! We’ve had a pretty incredible couple of weeks at the PDC and WinHEC. Based on what we talked about you can imagine we are all rather busy as we transition from milestone 3 to beta. We trust many of you are enjoying 6801 (or perhaps we should say 6801+). Over the next few weeks we’re going to start posting on the engineering and design of the specifics of different aspects of Windows 7 that we’ve talked about. Some posts will be very detailed and others will be a bit more high level and cover more territory. In all cases, we’ll be watching the comments carefully and also looking for opportunities on follow up posts. Thank you!

One of the big themes of Windows 7 from a design perspective (as you might have seen in Sam’s PDC session and certainly a topic we have talked about here) is making sure that you are “in control” of what is happening on your PC. This post, by senior program manager Sean Gilmour, is about “notifications” or the balloon popups that come from the system tray. In Vista we offered some controls over this area and in Windows 7 we have worked hard to make this an area that defaults to more well-behaved functionality and is also much more tunable to your needs. By improving how Windows itself uses the APIs and “guidelines” we want to encourage other ISVs to do the same. This topic is a great example of how the whole ecosystem comes into the picture as well and so we hope developers reading this will see the passion around the topic and the desire for software on Windows to take the steps necessary to honor the your intent. --Steven

The notification area has been talked about a couple times in previous posts (User Interface: Starting, Launching, and Switching and Follow-up: Starting, Launching, and Switching). This post is going to go into a bit more detail regarding notification balloons as well as one of the ways we’re working to quiet the system in Window 7.

Where We're At Today

Windows can be a busy place – with many things vying for your attention, even while you’re trying to do work. One we hear a lot about from you is the system notification balloons – those little pop-ups that appear above icons in the notification area (typically right side of the taskbar near the clock). In this post I’ll be talking to notifications sent utilizing Shell_NotifyIcon function provided in Windows, not custom notifications, often called “toast”, like the notifications presented by many applications (some like Outlook even from Microsoft). We see these in instant messenger programs, printer notifications, auto updaters, wifi and Bluetooth utilities, and more – these often use custom methods to present these “balloons” from the system tray, not necessary the Windows API. People have made their feelings loud and clear – Windows is too noisy and the noise distracts from the work at hand. Here are some quotes from the Windows Feedback Panel that illustrate that point.

“Too many notification messages, esp. re: security (eg. Firewall), activation”

“Notifications telling me my system is secure, when I know it is secure, are annoying”

“I'm tired of error messages and pop ups.”

And some posts from the blog discussions

@Jalf writes “Having 20 icons and a balloon notification every 30th second taking up space at the taskbar where it's *always* taking up space is just not cool.

@Lyesmith writes “The single biggest annoyance in the taskbar is notification balloons.”

So how noisy is the system? First a quick definition - a ‘session’ is the period of time between log-on and log-off or 24 hours whichever is shorter. As you can see from the following chart, 60% of sessions experience at least one notification. That doesn’t sound all that bad, but if you dig a bit deeper you realize that 37% of sessions see two or more notifications and 25% of sessions see three or more notifications. That’s a lot of distractions interrupting your work.

 

Figure 1: Number of notification sent per session as a percentage of total sessions - August through September, 2008

So we know how much noise notifications create but how effective are notifications? Well, as the following chart, notification click-through rate shows the more notifications the less effective they become.

Figure 2: Notification click-through rate - August through September, 2008

So, as shown in the above chart, used sparingly and in the right context, notification balloons can be rather useful. Unfortunately, that isn’t what is happening today. Instead the notification area often feels like a constant scrolling billboard of messages some important, many not. So what’s the answer? It’s a big area to tackle – there are system notifications, third party notification, and custom notifications. For Windows 7 we chose to focus on making sure Windows and its in-box components notify you responsibly and don’t contribute to the noise in the system. Ideally the ISV community will follow suit and as you’ve seen in some sessions, we’re doing this work in Windows Live for example. One of the reasons we focused internally was data showing that Windows components are responsible for at least 28% of the notifications presented. Additionally, we were able to identify seven Windows components that are mostly responsible for that noise. In all, 20 applications account for 62% of the notifications presented. The following chart shows the break-out.

Figure 3: Which software accounts for notifications - August through September, 2008

 

Windows 7

Our effort to quiet the system and make sure you are in control took the following approach:

• Working across Windows 7 to reduce unnecessary notifications
• Put you in control of the notifications you see
• Creating Action Center with the following goals
  • Reduce the number of notification balloons sent to you and make the ones that are sent more meaningful
  • Provide a contextual way to address the issues with a single click
  • Reduce the user-interface clutter in the system to streamline solving system issues

While there are many other efforts going around notifications and the notification area I’m going to focus on Action Center. In a nutshell, Action Center is a central location for dealing with messages about your system and the starting point for diagnosing and solving issues with your system. You can think of Action Center as a message queue displaying the items that need your attention that you can manage on your schedule. It serves as an aggregate for ten components in Windows Vista that contributed a large number of somewhat questionably effective notification balloons, but notifications that could not just be eliminated. At the heart of the Action Center effort is the idea that your time is extremely valuable it should never be wasted. To that end we took three steps.

First we looked hard at the messages we were sending and worked to reduce balloons and clarify messages. We took the following steps:

• Putting messages into one of two categories – normal or important. Normal messages simply appear in the Action Center control panel. Important messages send a notification balloon as well as appearing in the Action Center.
• Setting a high bar for important messages. A message is only deemed important if the security of the system or the integrity of your data is at risk.
• Reducing the frequency of notifications so that you’re not seeing them pop-up “all the time”
• Looking at all the messages and asking the hard questions –“is this something you really need to know about?”

The last filter led to our second step. We decided that all messages need to have an action associated with them - a solution, if you will, to whatever problem we were presenting to you. This meant cutting any FYI, Action Success, and Confirmation messages. It also meant that the way we presented these messages would be action based. For example, we replaced, “Antivirus is out of date”, with “Update Antivirus Signatures.” We believe that we should let people know specifically how to resolve an issue instead of making them guess or read lots of text. This is the heart of the other goal of Action Center – to help people solve system issues quickly and conveniently.

Finally, we designed the user experience (UX) of the Action Center in two parts. The first and most immediately visible is system icon in the notification area, which is a "lighthouse" in 6801. In the spirit of our efforts, this icon replaces five notification area icons from Vista, further reducing the clutter and noise in the system. The lighthouse icon provides a high level view of the number of messages in Action Center and their importance. It also has a fly-out menu on single left click which lists the four most recent notifications and supports you acting on messages contextually. We give the people the ability to click on a notification in that fly-out menu and immediately go to the UI to solve the issue. Again, the focus is solving issues instead of simply notifying.

Figure 4: Action Center notification area icon and fly-out menu

The second part of the UX is the control panel, which builds upon the icon and fly-out by serving as a repository for all messages as well as providing more details about the issue and the solution. It is also action based so the layout emphasizes messages and the corresponding solutions with even more detail. Additional actions are available if you expand the UI to view them. Finally, we know that we won’t always have messages about the issues a person might be having on their machine. To make sure you can solve those issues, we provide top level links to Troubleshooter and Recovery options.

Figure 5: Action Center Control Panel with a few messages queued up

Action Center boils down to understanding that your time is valuable and that it is your PC you want to control, not be controlled by your PC. We reduced messages, focused on solving issues not just telling you about them, and streamlined the experience so you can focus on what you what to do not want Windows needs you to do. We are aiming to get most sessions down to zero notifications from Windows itself. This reduction in notifications could significantly increase the possibility that the notification balloon will be effective in delivering its message and prompting user action as shown in the Figure 2 (notification click through).

We will of course be evangelizing to ISV the goal of following this direction and reducing notification balloons – and we believe we’ve taken the first steps to making Windows a quieter place. Hopefully you will find it less distracting and easier to work with.

Sean Gilmour, senior program manager

Back from the PDC…next up, WinHEC

This has been an amazingly special week for the Windows 7 team.  We’re all incredibly appreciative of the reception of Windows 7 this week at the PDC.  Thank you!

All of us on the team have been closely watching the news reports and blogs of those who have been “kicking the tires” of the Windows 7 pre-beta.  The reception has been fantastic and we’re humbled by the excitement and enthusiasm for the release.  We know we have a ton of work ahead of us to get to beta and then the path to RTM, and the reception has definitely given us an extra special motivation (though we were already pretty motivated).

Next week is our conference dedicated to the hardware partners in the ecosystem we have talked about.  Called WinHEC (Windows Hardware Engineering Conference), we’ll have another series of sessions and keynotes.  Jon DeVaan will be taking the lead as we dive into the details of “fundamentals” and the work we are doing with some of the many partners involved in Windows 7.  WinHEC also has a strong focus on Windows Server 2008 R2 (the server built off the Windows 7 kernel).  These sessions will all be available online as well.

So with all the shows we’re taking a short break from the blog as the folks that do the presenting are also the writers (myself included).

Below is a list of all the sessions on Windows 7 from the PDC.  Please take some time to have a look as the information is very detailed for sure.  How about using the comments on this post to ask questions of the sessions that you’d like to see more details on down the road?  That would be really helpful for us to target our posts.

Many of you have written asking about the beta and how to sign up or download it.  The best source for information on that will be the site http://www.microsoft.com/windows/windows-7 which our product marketing team owns and will keep up to date as the beta information is available.  Also note that the Windows Vista blog which is where you will see announcements / news has been updated to reflect the inclusion of Windows 7.  This blog is now known as the Windows Blog.

One of the very fun moments for me at the PDC was an “Open Space” session on the floor of the “Big Room” which was an open-microphone discussion.  Channel9 captured this and might be a fun watch.  See http://channel9.msdn.com/posts/Charles/Steven-Sinofsky-at-the-PDC2008-Open-Space/

For those of you interested in the Windows 7 APIs and what’s new for developers there is an overview document that you might find valuable.  See Windows 7 Developer Guide on MSDN.

Thank you very much for all the emails you have sent.  I always share them with the team and really appreciate it.

Presentation	URL
KYN02 Day Two #1 - Ray Ozzie, Steven Sinofsky, Scott Guthrie and David Treadwell (Windows 7 starts +17:00 minutes)	http://channel9.msdn.com/pdc2008/KYN02/
PC01 Windows 7: Web Services in Native Code	http://channel9.msdn.com/pdc2008/PC01/
PC02 Windows 7: Extending Battery Life with Energy Efficient Applications	http://channel9.msdn.com/pdc2008/PC02/
PC03 Windows 7: Developing Multi-touch Applications	http://channel9.msdn.com/pdc2008/PC03/
PC04 Windows 7: Writing Your Application to Shine on Modern Graphics Hardware	http://channel9.msdn.com/pdc2008/PC04/
PC13 Windows 7: Building Great Audio Communications Applications	http://channel9.msdn.com/pdc2008/PC13/
PC14 Windows 7 Scenic Ribbon: The next generation user experience for presenting commands in Win32 applications.	http://channel9.msdn.com/pdc2008/PC14/
PC15 Windows 7: Benefiting from Documents and Printing Convergence	http://channel9.msdn.com/pdc2008/PC15/
PC16 Windows 7: Empower users to find, visualize and organize their data with Libraries and the Explorer	http://channel9.msdn.com/pdc2008/PC16/
PC18 Windows 7: Introducing Direct2D and DirectWrite	http://channel9.msdn.com/pdc2008/PC18/
PC19 Windows 7: Designing Efficient Background Processes	http://channel9.msdn.com/pdc2008/PC19/
PC22 Windows 7: Design Principles for Windows 7	http://channel9.msdn.com/pdc2008/PC22/
PC23 Windows 7: Integrate with the Windows 7 Desktop	http://channel9.msdn.com/pdc2008/PC23/
PC24 Windows 7: Welcome to the Windows 7 Desktop	http://channel9.msdn.com/pdc2008/PC24/
PC25 Windows 7: The Sensor and Location Platform: Building Context-Aware Applications	http://channel9.msdn.com/pdc2008/PC25/
PC42 Windows 7: Deploying Your Application with Windows Installer (MSI) and ClickOnce	http://channel9.msdn.com/pdc2008/PC42/
PC43 Deep Dive: What's New with user32 and comctl32 in Win32	http://channel9.msdn.com/pdc2008/PC43/
PC44 Windows 7: Programming Sync Providers That Work Great with Windows	http://channel9.msdn.com/pdc2008/PC44/
PC50 Windows 7: Using Instrumentation and Diagnostics to Develop High Quality Software	http://channel9.msdn.com/pdc2008/PC50/
PC51 Windows 7: Best Practices for Developing for Windows Standard User	http://channel9.msdn.com/pdc2008/PC51/
PC52 Windows 7: Writing World-Ready Applications	http://channel9.msdn.com/pdc2008/PC52/
ES20 Developing Applications for More Than 64 Logical Processors in Windows Server 2008 R2	http://channel9.msdn.com/pdc2008/ES20/

See you on this blog soon enough!

--Steven

Follow-up: Windows Desktop Search

The discussion and email about desktop search offered an opportunity for us to have a deeper architectural discussion about engineering Windows 7.  There were a number of comments suggesting alternate implementation methods so we thought we’d discuss another approach and the various pros and cons associated with it.  It offers a good example of the engineering balance we are striving for with Windows 7.  Chris McConnell wrote this follow-up.  --Steven (See you at the PDC in a week!)

Thanks for all the great feedback on our first blog post on Windows Desktop Search.  I’ve summarized a number of points that have been made and added some comments about the architectural choices we have made and why.

Integration with the File System

As some posters have pointed out, one possible implementation is to integrate indexing with the file system so that updating a file immediately updates the indices.  Windows Desktop Search takes a different approach.   There are two aspects of file system integration: knowing when a file changes and actually updating the indices before a file is considered “closed” and available.   On an NTFS file system, the indexer is notified whenever a file changes.   The indexer never scans the NTFS file system except during the initial index.  It is on the second point—updating the indices immediately when a file is closed that we made a different choice.  Updating immediately has the benefit that a file is not available until it is indexed, but it also comes with a number of potential disadvantages.  We chose to decouple indexing from file system operations because it allows for more flexibility while still being almost real-time.   Here are some of the benefits we see in the approach we took:

1. Fewer resources are used.  Inverted indices are global.  An inverted index maps from a word found in a property to a list of every document that contains that word.  Indexing a single file requires updating an index for every single unique word found in the file.   A single document might then update a very large number of individual indices.  Making these changes and committing them with the same robustness found on individual files would be very expensive.  The design of the indexer allows scheduling and aggregating these changes so that much less work is done overall—that means less CPU and less disk I/O.  The system can be more robust because indexing doesn’t only happen when a file is closed—and it can even be retried if necessary.
2. File system operations are prioritized over indexing.  Getting files robustly updated and available is necessary for applications to use them.  We don’t want to delay that availability by forcing the cost of indexing into file close operations.   Searching over files is important, but is less important than actually working with files.  We wouldn’t want applications to decide individually if the indexer should be turned on or off just because they were seeking the best performance with respect to the file system.
3. There are lots of file types.  Microsoft supplies extractors (IFilter/IPropertyHandler) for many common file types as part of Windows.  There are many other file types as well so it is important to allow non-Microsoft developers to write their own extractors.  In Vista (and Windows 7), these extractors run in a locked down process that ensures that they are secure and do not affect the performance of the whole system.  If indexing had to happen before a file was available, then an extractor could impact (intentionally or not) all file system operations.  
4. Some files are more valuable to index then others.  If indexing happened when a file is closed, then there is no control over the order files are indexed.  Decoupling allows prioritizing indexing some files over others.  For example, searching for music is much more likely than searching for binary files.  If both music files and binary files have changed, then the indexer ensures it indexes the music files first.  Some files are not worth indexing at all for most people.  Several comments suggested that we should index the whole drive.  We can do that—and for those who would find it valuable it easy to add folders to be indexed.  (You can also remove them, but that is much less common so that is controlled through the control panel “Indexing Options.”)  For most people indexing system files is just a cost—they would never search for them and would be confused if they showed up as the result of a search. 
5. Not everything is a file in single file system.  Windows is all about supporting diversity.  There are many different file systems like FAT32 and CDFS and we would like to be able to search over those as well.   If we integrated with only NTFS, then we would have to still have a loosely coupled system for other file systems.  Many applications also have databases optimized for their own needs.  For example, Outlook has a database of email.  If only files were indexed, then the email in the database could not be indexed unless Outlook either compromised their experience by using files only, or complicated their implementation by duplicating everything in both the file system and the database.

Advanced Queries

A number of people expressed frustration with the lack of an advanced query UI.  Microsoft has many advanced query user-interfaces in many products, but these are generally focused on well-defined query languages (SQL) or on specific domains (like the Advanced Find in Outlook).  With Vista we wanted to address the query problem in a manner more familiar to people today—a single edit control.  Our implementation supports a rich query language within that edit control.  This is the same approach people are familiar with for web searching for both standard and advanced queries.

We had two observations that led to this approach:

1. The most important part of a search are the search terms.  Usually a single term is enough (and as we know from web searching, the majority of searches are one or two words).   And for refinement the file system tools of thumbnails, sorting, and/or type ahead can be used to narrow the search.  
2. It is reasonable to consider a design for an advanced query UI covering property based search, but it will generally be unwieldy for all but the bravest people.  As we mentioned, Windows Search covers over 300 properties by default so if you show every property then the UI is unusable.  If we only show the most commonly used properties then how do you handle all of the other properties?  Would properties be grouped by the common application or by attributes such as times, names, file attributes, etc.?  Some of you might value the Outlook Advanced Find… interface, but there you see some of the challenges and that is within a specific domain where the grouping or related properties probably can be understood. 

In designing Vista we incorporated the feedback that it is desirable to do precise queries.  The approach taken in Vista was to support a rich query language which allows all properties and a fairly natural syntax.  For example typing “from:gerald sent:today” will find all email from “Gerald”  sent today!   The big issue is that people do not know or the query language.  In Windows 7, we have focused on helping people see how to use the query language in context. For now, you can see the following for some information on Vista’s query syntax.  Much of this syntax and experience is similar to web search that we all use today.

A number comments were about substring matches in filenames, which we do not currently support.  This is part of the overall discussion about advanced queries.  In order to efficiently execute queries, the indexer builds indices that are based on individual words.  In Vista we introduced “searching as you type” to our search UI.  Under the hood this is implemented as prefix matches on the indexed words.  So when you type, ‘foo’, we look for all terms that start with those letters including ‘food’ and ‘football’.    Even more interesting if you type ‘foo net’ we will match on items that have the words ‘food’ and ‘network’ in them.   (If what you really want is to match the phrase “foo net” then typing those words inside quotes will do that—another example of advanced query syntax)   We have focused primarily on searching for terms found in any property, but there is no question that filenames are special.  In recognition of that we support suffix queries on filenames.  If you type ‘*food’ then we will return files that end in ‘food’ like “GoodFood”.  We do this by reversing the filename and then indexing it as a word.  For example, the reverse filename of “GoodFood” would be “DooFdooG” which we index as a word.  The suffix query ‘*food” is transformed into a prefix query “doof*” over the reverse filename index—clever, no?   So we support prefix matches for all properties and suffix matches for filenames, but we do not support substring matches. 

Performance and Citizenship

A number of comments focused on improving performance and citizenship—and we definitely agree on this input.   We are always striving to make Windows do more with fewer resources.  For those who have turned off indexing all together we hope that our continued improvements will make you reconsider.  Even if you organize all of your files and don’t find search useful for files, perhaps you will find start menu search, email search or Internet Explorer 8 address bar search useful.  We have worked hard at improving performance and citizenship across Windows.  Some of this progress is visible in WS4 and soon in Windows 7.  We have improved along all of our dimensions including indexing cost, battery life, citizenship, query speed and scrolling speed.  We have some tremendous tools that help us track down performance problems.  If you want to help, please contact [email protected] and we will tell you how to collect performance traces we can analyze so that we can continue to make improvements.

Chris McConnell

Find and Organize

From Idea to Feature: A view from Design

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

Engineering 7: A view from the bottom

Aka: A developers view of the Windows 7 Engineering process

This post is by Larry Osterman.  Larry is one of the most “experienced” developers on the Windows team and has been at Microsoft since the mid 1980’s.  There are only three other folks who have worked at Microsoft longer on the entire Windows team!  Personally, I remember knowing about Larry when I started at Microsoft back in 1989—I remember he worked on “multimedia” (back when we used to host the Microsoft CD-ROM Conference) and he was one of those people that stood up and received a “5 Year” award from Bill Gates at the first company meeting I went to—that seemed amazing back then!  For Windows 7, Larry is a developer on the Devices and Media team which is where we work on audio, video, bluetooth, and all sorts of cool features for connecting up devices to Windows. 

Larry wrote this post without any prodding and given his experience on so many Windows releases these thoughts seemed really worthwhile in terms of sharing with folks.  This post goes into “how” we work as a team, which for anyone part of a software team might prove pretty interesting.  While this is compared and contrasted with Vista, everyone knows that there is no perfect way to do things and this is just a little well-informed perspective.

So thank you Larry!  --Steven

Thanks to Steven and Jon for letting me borrow their soapbox :-).

I wanted to discuss my experiences working on building Windows 7 (as opposed to the other technical stuff that you’ve read on this blog so far), and to contrast that with my experiences building Windows Vista. Please note that these are MY experiences. Others will have had different experiences; hopefully they will also share their stories here.

The experience of building Windows 7 is dramatically different from the experience of building Vista. The rough outlines of the product development process haven’t changed, but organizationally, the Windows 7 process is dramatically better.

For Windows Vista, I was a part of the WAVE (Windows Audio Video Excellence) group. The group was led by a general manager who was ultimately responsible for the deliverables. There was a test lead, a development lead and a program management lead who reported to the general manager. The process of building a feature roughly worked like this: the lead program managers decided (based on criteria which aren’t relevant to the post) which features would be built for Windows and which program managers would be responsible for which feature. The development leads decided which developers on the team would be responsible for the feature. The program manager for the feature wrote a functional specification (which described the feature and how it should work) in conjunction with development. Note that the testers weren’t necessarily involved in this part of the process. The developer(s) responsible for the feature wrote the design specification (which described how the feature was going to be implemented). The testers associated with the feature then wrote a test plan which described how to test the feature. The program manager or the developer also wrote the threat model for the feature.

The developer then went off to code the feature, the PM spent their time making sure that the feature was on track, and when the developer was done, the tester started writing test cases.

Once the feature was coded and checked into the source tree, it moved its way up to the “winmain” branch. Aside: The Windows source code has been arranged into “branches” – the root is “winmain”, which is the code base that would ultimately become Windows Vista. Each developer works in what are called “feature branches”, which merge changes into “aggregation branches”, the aggregation branches move into winmain.

After the feature was coded, the testers tested, the developers fixed bugs and the program managers managed the program :-). As the product moved further along, it got harder and harder to get bug fixes checked into winmain (every bug fix carries with it a chance that the fix will introduce a regression, so the risk associated with each bug fix needs to be measured and the tolerance for risk decreases incrementally). The team responsible for managing this process met in the “ship room” where they made decisions every single day about which changes went into the product and which ones were left out. There could be a huge amount of acrimony associated with that – often times there were debates that lasted for hours as the various teams responsible for quality discussed the merits associated with a particular fix.

All-in-all, this wasn’t too different from the way that features have been developed at Microsoft for decades (and is basically consistent with what I was taught back in my software engineering class back in college).

For Windows 7, management decided to alter the engineering structure of the Windows organization, especially in the WEX [Windows Experience] division where I work. Instead of being fairly hierarchical, Steven has 3 direct reports, each representing a particular discipline: Development, Test and Program Management. Under each of the discipline leads, there are 6 development/test/program management managers, one for each of the major groups in WEX. Those 2nd level managers in turn have a half a dozen or so leads, each one with between 5 and 15 direct reports. This reporting structure has been somewhat controversial, but so far IMHO it’s been remarkably successful.

The other major change is the introduction of the concept of a “triad”. A “triad” is a collection of representatives from each of the disciplines – Dev, Test and PM. Essentially all work is now organized by triads. If there’s ever a need for a group to concentrate on a particular area, a triad is spun off to manage that process. That means that all three disciplines provide input into the process. Every level of management is represented by a triad – there’s a triad at the top of each of the major groups in WEX, each of the second level leads forms a triad, etc. So in my group (Devices and Media) there’s a triad at the top (known as DKCW for the initials of the various managers). Within the sound team (where I work), there’s another triad (known as SNN for the initials of the various leads). There are also triads for security, performance, appcompat, etc.

Similar to Windows Vista, the leads of all three disciplines get together and decide a set of features that go in each release. They then created “feature crews” to implement each of the features. Typically a feature crew consists of one or two developers, a program manager and one or two testers.

This is where one of the big differences between Vista and Windows 7 occurs: In Windows 7, the feature crew is responsible for the entire feature. The crew together works on the design, the program manager(s) then writes down the functional specification, the developer(s) write the design specification and the tester(s) write the test specification. The feature crew collaborates together on the threat model and other random documents. Unlike Windows Vista where senior management continually gave “input” to the feature crew, for Windows 7, management has pretty much kept their hands off of the development process. When the feature crew decided that it was ready to start coding (and had signed off on the 3 main documents), the feature crew met with the second level triad (in my case with DKCW) to sanity check the feature – this part of the process is critical because the second level triad gets an opportunity to provide detailed feedback to the feature crew about the viability of their plans.

And then the crew finally gets to start coding. Sort-of. There are still additional reviews that need to be done before the crew can be considered “ready”. For instance, the feature’s threat model needs to be reviewed by one of the members of the security triad. There are other parts of the document that need to be reviewed by other triads as well.

A feature is not permitted to be checked into the winmain branch until it is complete. And I do mean complete: the feature has to be capable of being shipped before it hits winmain – the UI has to be finished, the feature has to be fully functional, etc. In addition, when a feature team takes a dependency on another Windows 7 feature, the feature teams for the two features MUST sign a service level agreement to ensure that each team knows about the inter-dependencies. This SLA is especially critical because it ensures that teams know about their dependants – that way when they change the design or have to cut parts of the feature, the dependent teams aren’t surprised (they may be disappointed but they’re not surprised). It also helps to ensure tighter integration between the components – because one team knows the other team, they can ensure that both teams are more closely in alignment.

Back in the Vista day, it was not uncommon for feature development to be spread over multiple milestones – stuff was checked into the tree that really didn’t work completely. During Win7, the feature crews were forced to produce coherent features that were functionally complete – we were told to operate under the assumption that each milestone was the last milestone in the product and not schedule work to be done later on. That meant that teams had to focus on ensuring that their features could actually be implemented within the milestone as opposed to pushing them out.

For the nuts and bolts, The Windows 7 development process is scheduled over several 3-month long milestones. Each milestone allowed for 6 weeks of development and 6 weeks of integration – essentially time to fine-tune the feature and ensure that most of the interoperability problems were shaken out.

Ok, that’s enough background (it’s bad when over half a post on Windows 7 is actually about Windows Vista, but a baseline needed to be established). As I said at the beginning, this post is intended to describe my experiences as a developer on Windows 7. During Windows 7, I worked on three separate feature crews. The first crew delivered two features, the second crew delivered about 8 different features all relatively minor and the third crew delivered three major features and a couple of minor features. I also worked as the development part of the WEX Devices and Media security team (which is where my series of post on Threat Modeling came from – I wrote them while I was working with the members of D&M on threat modeling). And I worked as the development part of an end-to-end scenario triad that was charged with ensuring that scenarios that the Sound team defined at the start of the Windows 7 planning process were actually delivered in a coherent and discoverable way.

In addition, because the test team was brought into the planning process very early on, the test team provided valuable input and we were able to ensure that we built features that were not only code complete but also test complete by the end of the milestone (something that didn’t always happen in Vista). And it ensured that the features we built were actually testable (it sounds stupid I know, but you’d be surprised at how hard it can be to test some features). As a concrete example, we realized during the planning process that some aspect of one of the features we were working on in M2 couldn’t be completed during the milestone. So before the milestone was completed, we ripped the feature out (to be more accurate, we changed the system so that the new code was no longer being built as a part of the product). During the next milestone, after the test team had finished writing their tests, we re-enabled the feature. But we remained true to the design philosophy – at the end of the milestone everything that was checked into the “main” branch was complete – it was code AND test complete, so that even if we had to ship Windows 7 without M3 there was no test work that was not complete. This is a massive change from Vista – in Vista, since the code was complete we’d have simply checked in the code and let the test team deal with the fallout. By integrating the test teams into the planning process at the beginning we were able to ensure that we never put the test organization into that bind. This in turn helped to ensure that the development process never spiraled out of control. Please note that features can and do stretch across multiple milestones. In fact one of the features on the Sound team is scheduled to be delivered across three milestones – the feature crews involved in that feature carefully scheduled the work to ensure that they would have something worth delivering whenever Windows 7 development was complete.

Each of the feature crews I’ve worked on so far has had dramatically different focuses – some of the features I worked on were focused on core audio infrastructure, some were focused almost entirely on UX (user experience) changes, and some features involved much higher level components. Because each of the milestones was separate, I was able to work on a series of dramatically different pieces of the system, something I’ve really never had a chance to do before.

In Windows 7, senior management has been extremely supportive of the various development teams that have had to make the hard decisions to scale back features that were not going to be able to make the quality bar associated with a Windows release – and there absolutely are major features that have gone all the way through planning only to discover that there was too much work associated with the feature to complete it in the time available. In Vista it would have been much harder to convince senior management to abandon features. In Win7 senior management has stood behind the feature teams when they’ve had to make the tough decisions. One of the messages that management has consistently driven home to the teams is “cutting is shipping”, and they’re right. If a feature isn’t coming together, it’s usually far better to decide NOT to deliver a particular feature then to have that feature jeopardize the ability to ship the whole system. In a typical Windows release there are thousands of features and it would be a real shame if one or two of those features ended up delaying the entire system because they really weren’t ready.

The process of building 7 has also been dramatically more transparent – even sitting at the bottom of the stack, I feel that I’ve got a good idea about how decisions are being made. And that increased transparency in turn means that as an individual contributor I’m able to make better decisions about scheduling. This transparency is actually a direct fallout of management’s decision to let the various feature teams make their own decisions – by letting the feature teams deeper inside the planning process, the teams naturally make better decisions.

Of course that transparency works both ways. Not only were teams allowed to see more about what was happening in the planning process, but because management introduced standardized reporting mechanisms across the product, the leads at every level of the hierarchy were able to track progress against plan at a level that we’ve never had before. From an individual developer’s standpoint, the overhead wasn’t too onerous – basically once a week, you were asked to update your progress against plan on each of your work items. That status was then rolled up into a series of spreadsheets and web pages that allowed each manager to track all the teams’ progress against plan. This allowed management to easily and quickly identify which teams were having issues and take appropriate action to ensure that the schedules were met (either by simplifying designs, assigning more developers, or whatever).

In general, it’s been a total blast building 7. We’ve built some truly awesome features into the operating system and we’ve managed to keep the system remarkably stable during that entire process.

--Larry Osterman

Windows Desktop Search

One of the points of feedback has been about disabling services and optionally installing components—we’ve talked about our goals in this area in previous posts.  A key driver around wanting this type of control (but not the only driver) is a perception around performance and resource consumption of various platform components.  A goal of Windows is to provide a reliable and consistent platform for developers—one where they can count on system services as being available, as well as a set of OS features that all customers have the potential to benefit from.  At the same time we must do so in a way that is efficient in system resource usage—efficient enough so the benefit outweighs the cost.  We recognize that some percentage of customers believe solving this equation can only be done manually—much like some believe that the best car performance can only come from manual transmission.  For this post we’re going to look into the desktop search functionality from the perspective of the work we’re doing as both a broadly available platform component and to provide the rich end-user functionality, and also look at the engineering tradeoffs involved and techniques we use to build a great solution for everyone.  Chris McConnell, a principal SDE on the Find and Organize team, contributed this post.  --Steven

Are you one of those folks who believes that search indexing is the cause of your drive light flashing like mad? Do you believe this is the reason you’re getting skooled when playing first person shooters with friends? If so, this blog post is for you! The Find and Organize team owns the ‘Windows Search’ service, which we simply refer to as the ‘indexer’. A refrain that we hear from some Vista power-users is they want to disable the indexer because they believe it is eating up precious system resources on their PC, offering little in return. Per our telemetry data, at most about 1.5% of Vista users disable the indexing service, and we believe that this perception is one motivator for doing so.

The goal of this blog post is to clarify the role of the indexer and highlight some of the work that has been done to make sure the indexer uses system resources responsibly. Let’s start by talking about the function of the indexing service – what is it for? why should you leave it running?

Why Index?

Today’s PCs are filled with many rich types of files, such as documents, photos, music, videos, and so on. The number of files people have on their PC is growing at a rapid pace, making it harder and harder for them to find what they’re looking for, no matter how organized their files may (or may not) be. Increasingly, these files contain a good deal of structure, with metadata properties which describe their contents. A typical music file contains properties which describe the artist, album name, year of release, genre, duration of the song, and others which can be very useful when searching for music.

Although search indexing technologies date back to the early days of Windows, With Windows Vista Microsoft introduced a consumer operating system that brought this functionality to mainstream users more prominently. Prior to Vista, searching was pretty rudimentary – often a brute force crawl through the files on your machine, looking only at simple file properties such as file name, date modified, and size, or an application specific index of application specific data. Within Windows, a more comprehensive search option allowed you to also examine the contents of the files, but this wasn’t widely used. It was fairly basic functionality – it treated all files just the same, without the tapping in to the rich metadata properties available in the files.

In Windows Vista, the indexing service is on by default and includes expanded support in terms of the number of file formats and properties which are indexed. The indexer watches specific folders on your PC and catalogues their contents to facilitate fast searching of those files. When Windows indexes your music files, it also knows how to extract the music-specific properties which you’re most likely to search for. This enables support for more powerful searches and richer views over your files which wasn’t possible before. But this indexing doesn’t come free, and this is where engineering gets interesting. There’s a non-zero cost (in terms of system resources) that has to be paid to enable this functionality, and there are trade-offs involved in when and how you pay that price. There is nothing unique to indexing—all features have this cost-benefit tradeoff. 

Trade-Offs

Many search solutions follow(ed) the traditional “grep” model which means every search will read all of the files you wanted to search. In this case, you paid with your time as you waited for the search to execute. The more files you searched, the longer you waited each time you searched. If you wanted to perform the same search again, you would “pay” again. And the value you were getting in return wasn’t very good since the search functionality wasn’t particularly powerful. With Windows Vista , the indexer tries to read all of your files before you search so that when you search, it’s generally quicker and more responsive. This requires the indexer to scan all of your files just once initially, and not each and every time you perform a search. If the file were to change, the indexer would receive a notification (a “push” event) so that it could read that file again. When the indexer reads a file, it extracts the pertinent information about the file to enable more powerful searches and views. The challenge is to do this quickly enough so that the index is always up to date and ready for you to search, but also doing so in such a way that it doesn’t impact the performance of your system in a negative way. This is always a balancing act requiring trade-offs, and there are a number of things the indexer does to maintain its standing as a good Windows citizen while working to make sure that the index is always up-to-date.

A Model Citizen

A lot of work has gone into making the indexer be a model Windows citizen. We’ve written an extensive whitepaper on the issue, but it’s worth covering some of the highlights here. First and foremost, the indexer only monitors certain folders, which limits the amount of work it needs to do to just those files that you’re most likely to search. The indexer also “backs off” when you are actively using your PC. It indexes files more slowly, or stops entirely depending on the level of activity on the PC. When the indexer is reading files it uses low priority I/O and CPU and immediately releases the file if another application needs access.

It’s critical that we get all of these issues right for the indexer, because it’s not only important for the features that our team builds (like Windows Search), but it’s important to the Windows platform as a whole. There are a host of applications which require the ability to search file contents on the PC. Imagine if each one of those applications built their own version of the indexer! Even if all of these applications did a great job, there will be a lot of unnecessary and redundant activity happening on your PC. Every time you saved one of your documents there will be a flurry of activity as these different indexers rushed to read the new version. To combat that, the indexer is designed to do this work for any application which might choose to use it and provide an open platform and API with flexibility and extensibility for developers. The API designed to be flexible enough to meet needs across the Windows ecosystem. Out of the box, the indexer has knowledge of about 200 common file types, cataloging nearly 400 different properties by default. And there is support for applications to add new file types and properties at any time. Applications can also add support for indexing of data types that aren’t file-based at all, like your e-mail. Just a few of the applications that are leveraging the indexer today are Microsoft Office Outlook and OneNote, Lotus Notes, Windows Live Photo Gallery, Internet Explorer 8, and Google Desktop Search. As with all extensible systems, developers often find creative uses for components for the system services. One example of this is the way the Tablet PC components leverage the index contents to improve handwriting accuracy.

Constantly Improving

We’re constantly working to improve the indexer’s performance and reliability. Version 3 shipped in Windows Vista.  Major improvements in this version included:

• The indexer runs as a system service vs. as a per user process.  This minimizes impact on multi-user scenarios e.g. only one catalog per system results in reduction in catalog size and prevents re-indexing of the same content over and over.  Additional benefit is gained from the robust nature of services.
• The indexer employs low priority I/O to minimize impact of indexing on responsiveness of PC.  Before Windows Vista, all I/O was treated equally.

We’ve already released Windows Search version 4 as an enhancement to either Windows XP or Vista which goes even further in terms of performance and stability improvements, such as:

• Significant improvements across the board for queries which involve sorting, filtering or grouping. Example improvements on Vista include:
  1. Getting all results while sorting or grouping has been improved. Typical query improvements  are up to 38% faster.
  2. CPU time has been reduced by 80%
  3. Memory usage has been reduced by 20%
• Load on Exchange servers is reduced over 95% when Outlook is running in online mode.  With previous versions of Windows Search, large numbers of Outlook clients running in online mode could easily overwhelm the Exchange server.
• Reliability improvements including:
  1. We made a number of fixes to address user-reported situations that previously caused indexing to stop working.
  2. We improved the indexer’s ability to both prevent and recover from index corruptions.  Now, when catalog corruption is detected it is always rebuilt automatically – previously this only happened in certain cases.
  3. We added new logging and events to help track down and fix reliability issues.

And we’ve done even more to improve performance and reliability for the indexer in Windows 7 which you’ll soon see at the PDC. If you still believe that the indexer is giving you trouble, we’ve got a few things for you to try:

• Download and install Windows Search 4 (on Vista or XP).
• Download and install the Indexer Gadget from the Windows Live Gadget Gallery (Vista only). This gadget was written by one of our team members, and gives you a quick way to view the number of items indexed. It also allows you to pause indexing, or to make it run full-speed (without backing off).
• If you‘re one of those people who like to get under the hood of the car and poke around the engine, you can use the Windows Task manager and/or Resource Monitor to monitor the following processes: SearchIndexer, SearchFilterHost, SearchProtocolHost.

If you feel as though your system is slow, and you suspect the indexer is the culprit, watch the gadget as you work with your PC. Is the number of indexed items changing significantly when you’re experiencing problems? If you pause the indexer, does your system recover? We’re always looking to make our search experience better, so if you are still running into issues, we want to hear about them. Send your feedback to [email protected].

Chris McConnell

Find and Organize

User Account Control

We promised that this blog would provide a view of Engineering Windows 7 and that means that we would cover the full range of topics—from performance to user interface, technical and non-technical topics, and of course easy topics and controversial topics.  This post is about User Account Control.  Our author is Ben Fathi, vice president for core OS development.  UAC is a feature that crosses many aspects of the Windows architecture—security, accounts, user interface, design, and so on—we had several other members of the team contribute to the post. 

We continue to value the discussion that the posts seem to inspire—we are betting (not literally of course) that this post will bring out comments from even the most reserved of our readers.  Let’s keep the comments constructive and on-topic for this one.

FWIW, the blogs.msdn.com server employs some throttles on comments that aim to reduce spam.  We don’t control this and have all the “unmoderated” options checked.  I can’t publish the spam protection rules since that sort of defeats the purpose (and I don’t know them).  However, I apologize if your comment doesn’t make it through.  --Steven

User Account Control (UAC) is, arguably, one of the most controversial features in Windows Vista. Why did Microsoft add all those popups to Windows? Does it actually improve security? Doesn’t everyone just click “continue”? Has anyone in Redmond heard the feedback on users and reviewers? Has anyone seen a tv commercial about this feature? 

In the course of working on Windows 7 we have taken a hard look at UAC – examining customer feedback, volumes of data, the software ecosystem, and Windows itself. Let’s start by looking at why UAC came to be and our approach in Vista.

The Why of UAC

Technical details aside, UAC is really about informing you before any “system-level” change is made to your computer, thus enabling you to be in control of your system. An “unwanted change” can be malicious, such as a virus turning off the firewall or a rootkit stealthily taking over the machine. However an “unwanted change” can also be actions from people who have limited privileges, such as a child trying to bypass Parental Controls on the family computer or an employee installing prohibited software on a work computer. Windows NT has always supported multiple user account types – one of which is the “standard user,” which does not have the administrative privileges necessary to make changes like these. Enterprises can (and commonly do) supply most employees with a standard user account while providing a few IT pros administrative privileges. A standard user can’t make system level changes, even accidentally, by going to a malicious website or installing the wrong program. Controlling the changes most people can make to the computer reduces help desk calls and the overall Total Cost of Ownership (TCO) to the company. At home, a parent can create a standard user account for the children and use Parental Controls to protect them.

However, outside the enterprise and the Parental Controls case, most machines (75%) have a single account with full admin privileges. This is partly due to the first user account defaulting to administrator, since an administrator on the machine is required, and partly due to the fact that people want and expect to be in control of their computer. Since most users have an Administrator account, this has historically created an environment where most applications, as well as some Windows components, always assumed they could make system-level changes to the system. Software written this way would not work for standard users, such as the enterprise user and parental control cases mentioned above. Additionally, giving every application full access to the computer left the door open for damaging changes to the system, either intentionally (by malware) or unintentionally (by poorly written software.)

Figure 1. Percentage of machines (server excluded) with one or more user accounts from January 2008 to June 2008.

User Account Control was implemented in Vista to address two key issues: one, incompatibility of software across user types and two, the lack of user knowledge of system-level changes. We expanded the account types by adding the Protected Admin (PA), which became the default type for the first account on the system. When a PA user logs into the system, she is given two security tokens – one identical to the Standard User token that is sufficient for most basic privileges and a second with full Administrator privileges. Standard users receive only the basic token, but can bring in an Administrator token from another account if needed.

When the system detects that the user wants to perform an operation which requires administrative privileges, the display is switched to “secure desktop” mode, and the user is presented with a prompt asking for approval. The reason the display is transitioned to “secure desktop” is to avoid malicious software attacks that attempt to get you to click yes to the UAC prompt by mimicking the UAC interface (spoofing the UI.) They are not able to do this when the desktop is in its “secure” state. Protected Admin users are thus informed of any system changes, and only need to click yes to approve the action. A standard user sees a similar dialog, but one that enables her to enter Administrative credentials (via password, smart card PIN, fingerprint, etc) from another account to bring in the Administrator privileges needed to complete the action. In the case of a home system utilizing Parental Controls, the parent would enter his or her login name and password to install the software, thus enabling the parent to be in control of software added to the system or changes made to the system. In the enterprise case, the IT administrator can control the prompts through group policy such that the standard user just gets a message informing her that she cannot change system state.

What we have learned so far

We are always trying to improve Windows, especially in the areas that affect our customers the most. This section will look at the data around the ecosystem, Windows, and end-users—recognizing that the data itself does not tell the story of annoyance or frustration that many reading this post might feel. 

UAC has had a significant impact on the software ecosystem, Vista users, and Windows itself. As mentioned in previous posts, there are ways for our customers to voluntarily and anonymously send us data on how they use our features (Customer Experience Improvement Program, Windows Feedback Panel, user surveys, user in field testing, blog posts, and in house usability testing). The data and feedback we collect help inform and prioritize the decisions we make about our feature designs. From this data, we’ve learned a lot about UAC’s impact.

Impact on the software ecosystem

UAC has resulted in a radical reduction in the number of applications that unnecessarily require admin privileges, which is something we think improves the overall quality of software and reduces the risks inherent in software on a machine which requires full administrative access to the system.

In the first several months after Vista was available for use, people were experiencing a UAC prompt in 50% of their “sessions” - a session is everything that happens from logon to logoff or within 24 hours. Furthermore, there were 775,312 unique applications (note: this shows the volume of unique software that Windows supports!) producing prompts (note that installers and the application itself are not counted as the same program.) This seems large, and it is since much of the software ecosystem unnecessarily required admin privileges to run. As the ecosystem has updated their software, far fewer applications are requiring admin privileges. Customer Experience Improvement Program data from August 2008 indicates the number of applications and tasks generating a prompt has declined from 775,312 to 168,149.

Figure 2. Number of unique applications and tasks creating UAC prompts.

This reduction means more programs work well for Standard Users without prompting every time they run or accidentally changing an administrative or system setting. In addition, we also expect that as people use their machines longer they are installing new software or configuring Windows settings less frequently, which results in fewer prompts, or conversely when a machine is new that is when there is unusually high activity with respect to administrative needs. Customer Experience Improvement Program data indicates that the number of sessions with one or more UAC prompts has declined from 50% to 33% of sessions with Vista SP1.

 

Figure 3. Percentage of sessions with prompts over time.

Impact on Windows

An immediate result of UAC was the increase in engineering quality of Windows. There are now far fewer Windows components with full access to the system. Additionally, all the components that still need to access the full system must ask the user for permission to do so. We know from our data that Windows itself accounts for about 40% of all UAC prompts. This is even more dramatic when you look at the most frequent prompts: Windows components accounted for 17 of the top 50 UAC prompts in Vista and 29 of the top 50 in Vista SP1. Some targeted improvements in Vista SP1 reduced Windows prompts from frequently used components such as the copy engine, but clearly we have more we can (and will) do. The ecosystem also worked hard to reduce their prompts, thus the number of Windows components on the top 50 list increased. Windows has more of an opportunity to make deeper architectural changes in Windows 7, so you can expect fewer prompts from Windows components. Reducing prompts in the software ecosystem and in Windows is a win-win proposition. It enables people to feel confident they have a greater choice of software that does not make potentially destabilizing changes to the system, and it enables people to more readily identify critical prompts, thus providing a more confident sense of control.

One important area of feedback we’ve heard a lot about is the number of prompts encountered during a download from Internet Explorer. This is a specific example of a more common situation - where an application’s security dialogs overlap with User Account Control. Since XP Service Pack 2, IE has used a security dialog to warn users before running programs from the internet. In Vista, this often results in a double prompt – IE’s security dialog, followed immediately by a UAC dialog. This is an area that should be properly addressed.

Figure 4. Number of Microsoft prompters in the top 50 over time.

Impact on Customers

One extra click to do normal things like open the device manager, install software, or turn off your firewall is sometimes confusing and frustrating for our users. Here is a representative sample of the feedback we’ve received from the Windows Feedback Panel:

• “I do not like to be continuously asked if I want to do what I just told the computer to do.”
• “I feel like I am asked by Vista to approve every little thing that I do on my PC and I find it very aggravating.”
• “The constant asking for input to make any changes is annoying. But it is good that it makes kids ask me for password for stuff they are trying to change.”
• “Please work on simplifying the User Account control.....highly perplexing and bothersome at times”

We understand adding an extra click can be annoying, especially for users who are highly knowledgeable about what is happening with their system (or for people just trying to get work done). However, for most users, the potential benefit is that UAC forces malware or poorly written software to show itself and get your approval before it can potentially harm the system.

Does this make the system more secure? If every user of Windows were an expert that understands the cause/effect of all operations, the UAC prompt would make perfect sense and nothing malicious would slip through. The reality is that some people don’t read the prompts, and thus gain no benefit from them (and are just annoyed). In Vista, some power users have chosen to disable UAC – a setting that is admittedly hard to find. We don’t recommend you do this, but we understand you find value in the ability to turn UAC off. For the rest of you who try to figure out what is going on by reading the UAC prompt , there is the potential for a definite security benefit if you take the time to analyze each prompt and decide if it’s something you want to happen. However, we haven’t made things easy on you - the dialogs in Vista aren’t easy to decipher and are often not memorable. In one lab study we conducted, only 13% of participants could provide specific details about why they were seeing a UAC dialog in Vista.  Some didn’t remember they had seen a dialog at all when asked about it. Additionally, we are seeing consumer administrators approving 89% of prompts in Vista and 91% in SP1. We are obviously concerned users are responding out of habit due to the large number of prompts rather than focusing on the critical prompts and making confident decisions. Many would say this is entirely predictable.

Figure 5. Percentage of prompts over time per prompt type.

Figure 6. Percentage of UAC prompts allowed over time.

Looking ahead…

Now that we have the data and feedback, we can look ahead at how UAC will evolve—we continue to feel the goal we have for UAC is a good one and so it is our job to find a solution that does not abandon this goal. UAC was created with the intention of putting you in control of your system, reducing cost of ownership over time, and improving the software ecosystem. What we’ve learned is that we only got part of the way there in Vista and some folks think we accomplished the opposite.

Based on what we’ve learned from our data and feedback we need to address several key issues in Windows 7:

• Reduce unnecessary or duplicated prompts in Windows and the ecosystem, such that critical prompts can be more easily identified.
• Enable our customers to be more confident that they are in control of their systems.
• Make prompts informative such that people can make more confident choices.
• Provide better and more obvious control over the mechanism.

The benefits UAC has provided to the ecosystem and Windows are clear; we need to continue that work. By successfully enabling standard users UAC has achieved its goal of giving IT administrators and parents greater control to lock down their systems for certain users. As shown in our data above, we’ve seen the number of external applications and Windows components that unnecessarily require Admin privileges dramatically drop. This also has the direct benefit of reducing the total amount of prompts users see, a common complaint we hear frequently. Moving forward we will look at the scenarios we think are most important for our users so we can ensure none of these scenarios include prompts that can be avoided. Additionally, we will look at “top prompters” and continue to engage with third-party software vendors and internal Microsoft teams to further reduce unnecessary prompts.

More importantly, as we evolve UAC for Windows 7 we will address the customer feedback and satisfaction issues with the prompts themselves. We’ve heard loud and clear that you are frustrated. You find the prompts too frequent, annoying, and confusing. We still want to provide you control over what changes can happen to your system, but we want to provide you a better overall experience. We believe this can be achieved by focusing on two key principles. 1) Broaden the control you have over the UAC notifications. We will continue to give you control over the changes made to your system, but in Windows 7, we will also provide options such that when you use the system as an administrator you can determine the range of notifications that you receive. 2) Provide additional and more relevant information in the user interface. We will improve the dialog UI so that you can better understand and make more informed choices. We’ve already run new design concepts based on this principle through our in-house usability testing and we’ve seen very positive results. 83% of participants could provide specific details about why they were seeing the dialog. Participants preferred the new concepts because they are “simple”, “highlight verified publishers,” “provide the file origin,” and “ask a meaningful question.” 

In summary, yes, we’ve heard the responses to the UAC feature – both positive and negative. We plan to continue to build on the benefits UAC provides as an agent for standard user, making systems more secure. In doing so, we will also address the overwhelming feedback that the user experience must improve.

Ben Fathi

Follow-up: Managing Windows windows

There’s a lot of great discussion from the window arranging post.  This really shows how important these details are to people.  Being able to arrange how apps are shown on screen is key for productivity because it impacts almost every task.  It’s also very personal – people want to be in control of their work environment and have it set up the way that feels right. 

One thing that should be clear is that it would not be possible for us to provide solutions to all the different ways people would like to work and all of the different tools and affordances people have suggested--I think everyone can see how overloaded we would be with options and UI absorbing all the suggestions!  At first this might seem to be a bit of a bummer, but one thing we loved was hearing about all the tools and utilities you use (and you write!) to make a Windows PC your PC.  Our goal is not to provide the solution to every conceivable way of potentially managing your desktop, but rather to provide an amazing way to manage your desktop along with customizations and personalizations plus a platform where people can develop tools that further enhance the desktop in unique and innovative ways.  And as we have talked about, even that is a huge challenge as we cannot provide infinite customization and hooks—that really isn’t technically possible.  But with this approach Windows provides a high degree (but not infinite) flexibility, developers provide additional tools, computer makers can differentiate their PCs, and you can tune the UI to be highly personalized and productive for the way you want to work using a combination of thos elements and your own preferences. 

One other thing worth noting is that a lot of the comments referred to oft discussed elements in Windows, such as stealing the focus of windows, the registry, or managing the z-order of windows—a great source of history and witticisms about Windows APIs is from Raymond Chen’s blog.  Raymond is a long-time developer on the Windows team and author of Old New Thing, The: Practical Development Throughout the Evolution of Windows.  This is also a good source to read where the boundaries are between what Windows does and what developers of applications can choose to be responsible for doing (and what they are capable of customizing).

With that intro, Dave wanted to follow up with some additional insights the team has taken away from the discussion.  --Steven

We saw several pieces of feedback popping up consistently throughout the comments.  Paraphrasing the feedback (more details below), it sounds like there’s strong sentiment on these points:

• The size of windows matters, but wasting time resizing windows is annoying.
• Just let me decide where the windows go – I know best where my windows belong.
• Dragging files around is cumbersome because the target window (or desktop) is often buried.
• Desire for better ways to peek at the running windows in order to find what we’re trying to switch to.
• Want a predictable way to make the window fit the content (not necessarily maximized).
• Want to keep my personalized glass color, even when a window is maximized.

For each of these needs, there’s a lot of great discussion around possible solutions – both features from other products, and totally novel approaches.  It’s clear from these comments that there’s a desire for improvement, and that you’ve been thinking about this area long enough to have come up with some fairly detailed recommendations!  Below are a excerpts from some of the conversations ongoing in the comments.

Put the windows where I want them

It’s super interesting to see people discussing the existing features, and where they work or don’t work.

For example, @d_e is a fan of the existing tiling options in the taskbar:

Arranging windows in a split-window fashion is actually quite easy: While pressing CTRL select multiple windows in the taskbar. Then right-click them and select one of the tiling options...

But that approach doesn’t quite meet the goal for @Xepol:

As for the window reorder buttons on the taskbar -> I've known they were there since Win95, but I never use them.  They never do what I want.  If they even get close to the right layout, its the wrong window order.  Since I have to drag stuff around anyways, its just easier to get exactly what I want the first time.

@Aengeln suggests taking the basic idea of tiled windows to the next level in order to make them really useful:

A very useful feature would be the ability to split the deskotop into separate portions, especially on larger screens.  For example, I might want to maximize my Messenger window to a small part on the right hand side of the desktop and still have the ability to maximize other windows into the remaing space. Non-maximized windows would be able to float across both (all) parts of the desktop.

It sounds like there’s agreement that optimizing the screen space for more than one window would be super useful, if it would only let you stay in control of where windows ended up, and was easy and quick to use every day.  The current tiling features in the taskbar give hints at how this could be valuable, but aren’t quite fast and easy enough to be habit forming.

Open at the right size

We saw a lot of comments on the “default size” of windows, and questions about how that’s decided.  Applications get to choose what size they open at, and generally use whichever size they were at the last time they were closed (or they can choose not to honor those settings).  One of the cases that can trip people up is when IE opens a small window (websites will do this sometimes), because once you close it that will be the new “last size”. 

@magicalclick suggested a solution:

I wish I have one more caption button, FIXED SIZE. Actually it is a checkbox. When I check the box, it will save the window state for this application. After that, I can resize/move around. When I close window, it will not save the later changes.

@steven_sinofsky offered this advanced user tip that you can use to start being more click-efficient right away:

@magicalclick I dislike when that one happens!  Rather than add another button or space to click, I do the same thing in one click with a "power user" trick which is when you see the small window open don't close it until you first open up another copy of the application with the "normal" window size.  Then close the small one and then the normal one. 

Of course this is a pain and close to impossible for anyone to find, but likely a better solution than adding a fourth UI affordance on the title bar.

–steven

Finding the right window

The word being used is “Expose”:

@Joey_j: Windows needs an Exposé-like feature. I want to see all of my windows at once.

@Dan.F: one word - expose.  copy it.

@GRiNSER : Expose has its own set of drawbacks: Like having 30 windows on a macbook pro 1400x1050 screen is really not that helpful. Though its way more helpful than Crap Flip 3D. Expose would be even more useful with keyboard window search...

Regardless of the name, there’s a desire to visually find the window you’re looking for.  Something more random-access than the timeline approach of Alt-Tab or Flip-3d, and something that lets you pick the window visually from a set of thumbnails.  This is very useful for switching when there are a lot of windows open – but some current approaches don’t scale well and it is likely scaling will become an even more difficult problem as people run even more programs.

Dragging files

There were several comments (and several different suggestions) on making it easier to drag between windows:

@Manicmarc:  I would love to see something like Mac OS's Springloaded folders. Drag something over a folder and hover, it pops up, drag over to the next folder, drop it.

@Juan Antonio: It would be useful that when I´m dragging an object I could to open a list or thumbnail of the windows ( maybe a right- click )to select what window use to drop the object.

On this topic, I loved @Kosher’s comment on the difference between being able to do something, and it feeling right.

The UI could be enhanced quite a bit to make it much easier to do things. It's not just about how easy it is but it's also about how smoothly the user transitions between common UI workflows and tasks.  This is a bit like explaining the difference between a Ferrari and a Toyota to someone that has never driven a Ferrari though, so I don't know if it will ever happen.

In designing Windows 7, we’ve really been taking the spirit of this comment to heart.  I can’t wait to hear what car Windows 7 is compared to once it’s available for a test drive.

- Dave

User Interface: Managing Windows windows

We’ve booted the machine, displayed stuff on the screen, launched programs, so next up we’re going to look at a pretty complex topic that sort of gets to the core role of the graphical user interface—managing windows.  Dave Matthews is program manager on the core user experience team who will provide some of the data and insights that are going into engineering Windows 7.  --Steven

The namesake of the Windows product line is the simple “window” – the UI concept that keeps related pieces information and controls organized on screen.  We’ll use this post to share some of the background thinking and “pm philosophy” behind planning an update to this well established UI feature.

The basic idea of using windows to organize UI isn’t new – it dates back (so I hear) to the first experiments with graphical user interfaces at Stanford over 40 years ago.  It’s still used after all this time because it’s a useful way to present content, and people like having control over how their screen space is used.  The “moveable windows” feature isn’t absolutely needed in an operating system – most cell phones and media center type devices just show one page of UI at a time – but it’s useful when multi-tasking or working with more than one app at a time.  Windows 2.0 was the first Windows release that allowed moveable overlapping windows (in Window 1.0 they were only able to be tiled, not overlapping.  This “tiled v. overlapping” debate had famous proponents on each side—on one side was Bill Gates and on the other side was Charles Simonyi).  In addition, Windows also has the unique notion of "the multiple document interface” or MDI, which allows one frame window to itself organized multiple windows within it.  This is somewhat of a precursor to the tabbed interfaces prevalent in web browsers. 

As a side note, one of the earlier debates that accompanied the “tiled v. overlapping” conversations in the early Windows project was over having one menu bar at the top of the screen or a copy of the menu bar for each window (or document or application).  Early on this was a big debate because there was such limited screen resolution (VGA, 640x480) that the redundancy of the menu bar was a real-estate problem.  In today’s large scale monitors this redundancy is more of an asset as getting to the UI elements with a mouse or just visually identifying elements requires much less movement.  Go figure!

From Windows 2.0 to Vista.

An area I’ve been focusing on is in the “window management” part of the system – specifically the features involved in moving and arranging windows on screen (these are different than the window switching controls like the taskbar and alt-tab, but closely related).  In general, people expect windows to be moveable, resizable, maximizable, minimizable, closeable; and expect them to be freely arranged and overlapping, with the currently used window sitting on top.  These transformations and the supporting tools (caption buttons, resize bars, etc) make up the basic capabilities that let people arrange and organize their workspace to their liking. 

In order to improve on a feature area like this we look closely at the current system - what have we got, and what works?  This means looking at the way it’s being used in the marketplace by ISVs, and the way it’s used and understood by customers.

Caption buttons give a simple way to minimize, maximize, and close.  Resizable windows can be adjusted from any of their 4 edges.

Data on Real-World Usage 

As pointed out in the previous Taskbar post, on average people will have up to 6 – 9 windows open during a session.  But from looking at customer data, we find that most time is spent with only one or two windows actually visible on screen at any given time.  It’s common to switch around between the various open windows, but for the most part only a few are visible at once.

Windows Feedback Panel data

As part of our planning, we looked at how people spend their time and energy in moving and sizing their windows. This lets us understand what’s working well in the current system, and what could be improved.

For example, we know that maximize is a widely used feature because it optimizes the work space for one window, while still being easy to switch to others.  Users respond to that concept and understand it.  Since most of the time users just focus on one window, this ends up being very commonly used.  We know that for many applications people ask for every single pixel (for example spreadsheets where a few pixels gain a whole extra row of column) and thus the beyond maximize features for “full screen” become common, even for everyday productivity.

An issue we've heard (as recently as the comments on the taskbar post!) with maximize in Vista is that the customized glass color isn’t very visible, because the windows and taskbar become dark when a window is maximized. (In Vista you can customize the glass window color – and in 29% of sessions a custom color has been set).  The darker look was used to help make it clear that the window is in the special maximized state.  This was important because if you don’t notice that a window is maximized and then try to move it, nothing will happen - and that can be frustrating or confusing.  For Windows 7 we’re looking at a different approach so that the customized color can be shown even when a window is maximized.

Interestingly, people don’t always maximize their windows even when they’re only using one window at a time.  We believe one important reason is that it’s often more comfortable to read a text document when the window is not too wide.  The idea of maximizing is less useful on a wide monitor when it makes the sentences in an email run 20+ inches across the screen; 4 or 5 inches tends to be a more pleasant way to read text.  This is important because large desktop monitors are becoming more common, and wide-aspect monitors are gaining popularity even on laptops.  Since Windows doesn’t have a maximize mode designed for reading like this, people end up manually resizing their windows to make them as tall as possible, but only somewhat wide.  This is one of the areas where a common task like reading a document involves excessive fiddling with window sizes, because the system wasn’t optimized for that scenario on current hardwarwe.

Resolution data suggests wide aspect-ratio monitors will become the norm.

Being able to see two windows side by side is also a fairly common need.  There are a variety of reasons why someone may need to do this – comparing documents, referring from one document into another, copying from one document or folder into another, etc.  It takes a number of mouse movements to set up two windows side by side – positioning and adjusting the two windows until they are sized to roughly half the screen.  We often see this with two applications, such as comparing a document in a word processor with the same document in a portable reader format. 

Users with multiple monitors get a general increase in task efficiency because that setup is optimized for the case of using more than one window at once.  For example, it’s easy to maximize a window on each of the monitors in order to efficiently use the screen space.  In a Microsoft Research study on multi-tasking, it was found that participants who had multiple monitors were able to switch windows more often by directly clicking on a window rather than using the taskbar, implying that the window they want to switch to was already visible.  And interestingly, the total number of switches between windows was lower.  In terms of task efficiency, the best click is an avoided click.  

MSR research report

Single monitor machines are more common than multi-mon machines, but the window managing features aren’t optimized for viewing multiple windows at once on one monitor.  The taskbar does has context menu options for cascade, stack, or side-by-side, but we don't believe they're well understood or widely used, so most people end up manually resizing and moving their windows whenever they want to view two windows side by side.

An interesting multiple window scenario occurs when one of the windows is actually the desktop.  The desktop is still commonly used as a storage folder for important or recent files, and we believe people fairly often need to drag and drop between the desktop and an explorer window, email, or document.  The “Show Desktop” feature gives quick access to the desktop, but also hides the window you're trying to use.  This means you either have to find and switch back to the original window, or avoid the Show Desktop feature and minimize everything manually.  It’s very interesting to see scenarios like this where the people end up spending a lot of time or effort managing windows in order complete a simple task.  This kind of experience comes across in our telemetry when we see complex sequences repeated.  It takes further work to see if these are common errors or if people are trying to accomplish a multi-step task.

Evolving the design

To find successful designs for the window management system, we explore a number of directions to see which will best help people be productive.  From extremes of multi-tasking to focusing on a single item, we look for solutions that scale but that are still optimized for the most common usage.  We look at existing approaches such as virtual desktops which can help when using a large number of different windows (especially when they are clustered into related sets), or docking palettes that help efficiently arrange space (as seen in advanced applications such as Visual Studio).  And we look at novel solutions tailored to the scenarios we're trying to enable.

We also have to think about the variety of applications that the system needs to support.  SDI apps (single document interface) rely heavily on the operating system to provide window management features, while MDI apps (multiple document interface)  provide some of the window management controls for themselves (tabbed UI is an increasingly popular approach to MDI applications).  And some applications provide their own window sizing and caption controls in order to get a custom appearance or behavior.  Each of these approaches is valuable, and the different application styles need to be taken into account in making any changes to the system.

For Window 7 our goal is to reduce the number of clicks and precise movements needed to perform common activities.  Based on data and feedback we've gotten from customers,  a number of scenarios have been called out as important considerations for the design.  As with all the designs we’re talking about—it is important to bring forward the common usage scenarios, make clear decisions on the most widely used usage patterns, address new and “unarticulated needs”, and to also be sure to maintain our philosophy of “in control”.  Some of the scenarios that are rising to the top include:

• Can efficiently view two windows at once, with a minimal amount of set up.
• Simple to view a document at full height and a comfortable reading width.
• Quick and easy to view a window on the desktop.
• The most common actions should require the least effort - quicker to maximize or restore windows with minimal mouse precision required.
• Keyboard shortcuts to replace mouse motions whenever possible for advanced users.
• Useful, predictable, and efficient window options for a range of displays: from small laptops to 30” or larger screens; with single or multiple monitors.
• Easy to use different input methods: mouse, keyboard, trackpad, pen, or touch screens.
• Customized window glass color visible even when maximized.
• Overall - customers feel in control, and that the system makes it faster and easier to get things done.

This last point is important because the feeling of responsiveness and control is a key test for whether the design matches the way people really work.  We put designs and mockups in the usability lab to watch how people respond, and once we see people smiling and succeeding easily at their task we know we are on the right track. The ultimate success in a design such as this is when it feels so natural that it becomes a muscle memory.  This is when people can get the feeling that they’ve mastered a familiar tool, and that the computer is behaving as it should.

This is some of the background on how we think about window management and doing evolutionary design in a very basic piece of UI.  We can’t wait to hear feedback and reactions, especially once folks start getting their hands on Windows 7 builds.

- Dave

Follow-up: Starting, Launching, and Switching

Lots of discussion on the taskbar and associated user interface.  Chaitanya said he thought it would be a good idea to summarize some of the feedback and thoughts.  --Steven

We’d like to follow up on some themes raised in comments and email.  This post looks at some observations on consistent feedback expressed (though not universal) and also provides some more engineering / design context for some of the challenges expressed.

First it is worth just reinforcing a few points that came up that were consistently expressed:

• Many of you agree that the Notification Area needs to be more manageable and customizable. 
• We received several comments about rearranging taskbar buttons.  This speaks to the need for a predictable place where taskbar buttons appear as well as your desire for more control over the taskbar.
• There were comments that talked about Quick Launch being valuable, but that it could stand to be an even better launching surface (e.g. larger by default or more room).
• Thumbnails are valuable to many of you, but their size doesn’t always help you find the window you are looking for.  There is interest in a better identification method of windows that consistently provided the right amount of information.
• Better scaling of supported windows was discussed.  This includes optimizing the taskbar for more windows and spanning multiple displays. 

Data

Several of you asked about the conclusions we are drawing from the data we collect and how we will proceed.

@Computermensch writes “The problem with this "analysis" (show me the data) is that you're only managing current activities surrounding the taskbar. So with respect "to evolving the taskbar" you're only developing it within its current operational framework while developing or evolution of really should refer to developing the taskbars concept.” 

@Bluvg posts “What if the UI itself was a reason that people didn't run more than 6-9 windows?  In other words, what if the UI has a window number upper bound of effectiveness?  Prioritizing around that 6-9 scenario would be taking away the wrong conclusion from the data, if that were the case.  The UI itself would be dictating the data, rather than being driven by user demand.”

As we’ve said in all our posts around the data we collect and how we use it, data do not translate directly into our features, but informs the decisions.  Information we collect from instrumentation as well as from customer interviews merely provides us with real-world accuracy of how a product is currently used.  The goal is not necessarily to just design for the status quo.  However, we must recognize that if a new design emerges that does not satisfy the goals and behavior of our customers today, we risk resistance.  This is not to say one should never innovate and change the game—just that to do so must be respectful of the ultimate goal of the customer.  Offering a new solution to a problem is great; just make sure you’re solving the right problem and that there is a path from where people are today to where you think the better solution resides.  With that said, rest assured that our design process recognizes the need for the taskbar to scale more efficiently for larger sets of windows.  This would allow those who possibly feel “trapped” in the 6-9 window case to more comfortably venture to additional windows, if they really require it.  Also, the improvements we make to the 90% case should still hold benefits to the current outliers. 

Notification Area

With so much feedback, it is always valuable to recognize when customer comments converge.  The original post called out the problems with the Notification Area and these issues were further emphasized with your thoughts.

@Jalf writes “Having 20 icons and a balloon notification every 30th second taking up space at the taskbar where it's *always* taking up space is just not cool. By all means, the information should be there if I need it, but can't we just assume that if I don't actively look for the information, it's probably because I don't want it.

Jalf’s comment is particularly interesting because it speaks to both the pros and cons of notifications.  They certainly can be valuable, but they can also very easily overwhelm the customer as many of you note.  A careful balance therefore must be reached such that the customer is kept informed of information that is relevant while she continues to remain in control.  Since relevant is relative, the need for control is fundamental.  Rest assured we are aware of the issues and we are taking them very seriously.

Multi-mon Support

It comes as no surprise that many of you wrote to discuss multi-monitor support for the taskbar. This is a popular request from our enthusiasts (and our own developers) and was called out as an area of investigation in the original post. 

@Justausr is very direct with this comment: “The lack of multi-monitor support is just about a crime.  We've seen pictures of Bill Gate's office and his use of 3 monitors.  Most developers have 2 monitors these days.  Why was multi-monitor support for the taskbar missing?  Once again, this is an example of the compartmentalization of the Windows team and the lack of a user orientation in defining and implementing features.  The fact that this is even a "possible" and not an "of course we're going to..." shows that you folks STILL don't get it.”

At least in this particular case we tend to think we “get it”, but we also tend to think that the design of a multi-mon taskbar is not as simple as it may seem.  As with many features, there is more than one way to implement this one.  For example, some might suggest a unique taskbar that exists on each display and others suggest a taskbar that spans multiple displays.  Let’s look at both of these approaches.  While doing so also keep in mind the complexities of having monitors of different sizes, orientations, and alignments. 

If one was to implement a taskbar for each display where each bar only contained windows for its respective portion of the desktop, some issues arise.  Some customers will cite advantages of less mouse travel since there is always a bar at the bottom on their screen.  However, such a design would now put the onus on the customer to track where windows are.  Imagine looking for a browser window and instead of going to a single place, you now had to look across multiple taskbars to find the item you want.  Worse yet, when you move a window from one display to another, you would have to know to look in a new place to find it.  This might seem at odds with the request to rearrange taskbar buttons because customers want muscle memory of their buttons.  It would be like having two remotes with dynamically different  functionality for your TV. This is one of the reasons that almost every virtual desktop implementation keeps a consistent taskbar despite the desktop you are working on.  

Another popular approach is a taskbar that spans multiple desktops.  There are a few third-party tools that attempt to emulate this functionality for the Windows taskbar.  The most obvious advantage of this approach (as well as the dual taskbar) is that there is more room offered for launching, switching and whispering.  It is fairly obvious that those customers with multiple displays have more room to have more windows open simultaneously and hence, require even more room on their taskbar.  Some of our advanced customers address this issue by increasing the height of the taskbar to reveal multiple rows.  Others ask for a spanning taskbar.  The key thing to recognize is that the problem is not necessarily that the taskbar doesn’t span, but that more room is required to show more information about windows.  So, it stands to reason that we should come up with the best solution to this problem, independent of how many displays the customer has. 

We thought it would be good to just offer a brief discussion on the specifics of solving this design problem as it is one we have spent considerable time on.  One of the approaches in general we are working to do more of, is to change things when we know it will be a substantial improvement and not also introduce complexities that outweigh the benefits we are trying to achieve.

Once again, many thanks for your comments.  We look forward to talking soon.

- Chaitanya

User Interface: Starting, Launching, and Switching

Where to Start?  In this post, Chaitanya Sareen, a senior program manager on the Core User Experience team, sets the engineering context for the most frequently used user-interface elements in Windows – the Windows Taskbar.  -- Steven

It should come as no surprise that we receive lots of feedback about the taskbar and its functionality in general. It should also come as no surprise that we are constantly trying to raise the bar and improve the taskbar experience for our customers, while making sure we bring forward the familiarity and benefits (and compatibility) of the existing implementation and design. In this post, the we would like to provide some insight into that unassuming bar most likely at the bottom of your Windows desktop. Let’s take a closer look at its various parts, data we’ve collected and how this learning will inform the engineering of Windows 7.

Taskbar Basics

Our taskbar made its debut way back in Windows 95 and its core functionality remains the same to this day. In short, it provides launching, switching and “whispering” functionality. Figure 1 shows the Vista taskbar and calls out its basic anatomy. Notable pieces are the taskband, Quick Launch, the Start Menu, Desktop Toolbars (aka Deskbands) and the Notification Area. Collectively, these components afford some of the most fundamental controls for customers to start, manage and monitor their tasks.

Fig. 1: Windows Taskbar Anatomy

Taskband: The faithful window switcher

The taskband is one of the most important parts of the taskbar. It hosts buttons which represent most of the windows open on the desktop. Think of the taskband as a remote control for your computer—you can switch windows just like switching channels on a TV. The idea of switching windows is the most fundamental aspect of the Windows taskbar. Other operating systems also have bars at the bottom of their screen, although theirs may have different goals. For example, Mac OS X has a Dock which is primarily a program launcher and a program switcher. Clicking on an icon on the Dock usually brings up all the windows of a running program. In 2003 Apple introduced a window switcher known as Exposé which provides a different visual approach to our long-standing Alt-tab interface (Vista’s Flip 3D is yet another visual approach). These dedicated window switchers all aim to provide customers with a broad view of their open windows, but they each require the customer to first invoke them. The taskband on the other hand, is designed to always be visible so that windows remain within quick access of the mouse. This makes the taskbar the most prominent window switcher of the Windows operating system.

Two noteworthy taskbar changes were introduced in the last eight years. Windows XP ushered in grouping which allows taskbar buttons to collapse into a single button to save space and organize windows by their process. Vista presented taskbar thumbnails. These visual representations give customers more information about the window they are looking for. While valuable, interfaces like the taskbar, Alt-tab and even Apple’s own Exposé reveal that thumbnails are not always large enough to guarantee recognition of a window. Their value further degrades when they have to shrink to accommodate many open windows, which is feedback we receive from those that often have lots of running programs x lots of open windows.

The Start Menu: the Windows launch pad

The Start Menu has always been anchored off the taskbar as a starting point for the customer’s key tasks such as launching or accessing system functionality. Microsoft of course used term “Start” and prominently labeled the Start Menu’s button as such. You may even recall the huge marketing campaign for Windows 95 which featured the Rolling Stone’s “Start Me Up”. In all seriousness though, our research showed that many customers didn’t always know where to go on their computer to start a task. When a customer was placed in front of a Windows 95 machine she now had a clearly labeled place to start. And yes, we’ve heard the joke that you click start to shutdown your machine. Speaking of shutdown, we did encounter some challenges with the power options in Vista’s Start Menu. The goal was to bubble-up and advertise the sleep option so that customers enjoy a faster resume. However, we now know despite our good intentions, customers are opening that fly-out menu and selecting other options. We’re looking into improving this experience.

The Start Menu has undergone many changes over the years. One notable change was the appearance of a MFU (most frequently used) section in Windows XP that suggests commonly (well frequently) used programs. The goal here was to save the customer time by not having to always go to All Programs. Since these items appear automatically based on usage, no manual customization was even required. All Programs itself has undergone several iterations. Customer feedback revealed that people encountered difficulty in traversing the original All Programs fly-out menu. It wasn’t uncommon to have your mouse “fall off” the menu and then you’d have your restart the task all over again. This was particularly the case for laptop customers using a trackpad. It also didn’t help that expanding this menu suddenly filled the entire desktop which looked visually noisy and it also required lots of mouse movement. And of course, for machines with large number of items and/or groups it was especially complex, and even more so on small screens.  Vista introduced a single menu that requires less mouse acrobatics.

Search was another important addition to the Start Menu that makes launching even easier. This new feature in Vista provides fast access to programs and files without the need to use a mouse at all. Typing in a phrase quickly surfaces programs, files and even e-mails. We’ve received many positive comments from enthusiasts who feel this is a key performance win in terms of “time to launch”.  It may be interesting to note that Start Menu’s search is optimized to first return program results as this was viewed as the most common scenario among our customers (using some of the Desktop Search technology). Search even permits customers to use parameters to further scope their queries. For instance, one can use “to:john” or “from:jane” to find a specific mail directly from the Start Menu. Our advanced customers also enjoy the benefit of using the Start Menu’s search as a replacement of the Run Dialog. Just as they would type the name of an executable along with some switches in the dialog, they can now just type this directly into the search field. We could (and will) dedicate an entire blog post to search alone, but hopefully you get a sense of how search certainly provides a powerful launch alternative to mouse navigation.

Quick Launch: Launching at your fingertips

Quick Launch provides a way for customers to launch commonly used programs, files, folders and websites directly off the taskbar. It was introduced to Windows 95 by Internet Explorer 4.0 with the Windows Desktop Update. Customizing Quick Launch is as simple as dragging shortcuts into to this area. It saves you a trip to the Start Menu, the desktop or a folder when you want to launch something. An interesting feature of Quick Launch that you may not be aware of is that it has always supported large icons (unlock the taskbar, right-click on Quick Launch and click on large icons under “View”) as seen in figure 2. Of course growing the icons begins to intrude on the real-estate of the taskband which is one of the reasons we have not enabled this configuration by default. As an aside, Windows XP had Quick Launch turned off by default in an attempt to reduce the number of different launching surfaces throughout Windows. Based on your feedback, we quickly rectified this faux pas and Quick Launch was turned on by default again. Don’t mess with quick access to things people use every day! We heard you loud and clear.

Fig. 2: Large Icons in Quick Launch. Large icons on the taskbar have been supported since Windows 95 with IE 4

Desktop Toolbars (aka Deskbands): Gadgets for your taskbar

Desktop Toolbars offer extensible and specialized functionality at the top-level of the taskbar. This functionality also came to the taskbar via Internet Explorer 4.0 back in the ‘90s. You can access toolbars by right-clicking on your taskbar and expanding “Toolbars”. Personally, I like to think of Desktop Toolbars as an early type of gadgets for the Windows platform. Over the years developers have written various toolbars including controls for background music (e.g. Windows Media Player’s mini-mode shown in figure 1), search fields, richer views of laptop batteries, weather forecasts and many more.

One of the original scenarios of Desktop Toolbars was to allow customers to launch items directly off the taskbar. In fact, Quick Launch itself is a special type of toolbar that surfaces shortcuts in the Quick Launch folder. Did you know you can even create your own toolbar for any folder on your computer so that you have quick access to its contents (from the Toolbar menu, select “New Toolbar” and just choose the folder you’d like to access)? Apple’s latest OS introduced similar functionality to the Dock called Stacks. While I think their implementation of this feature is generally more visually appealing, it is interesting to note they recently released a new list representation that matches our original functionality. Seems like we both agree a simple list is usually the most efficient way to parse and navigate lots of items.

After extolling all the greatness of Desktop Toolbars, we must also admit they introduce several challenges. For starters, they aren’t the easiest thing to discover. They also take up valuable space on an already busy taskbar. Most importantly though, they don’t always solve the customer goal. Sure you can have a folder’s contents accessible off your taskbar, but what if the files you want quick access to aren’t located in a single place? These are design challenges we intend to tackle.

Notification Area: The whisperer

The Notification Area is pretty much what you expect—an area for notifications. It was an original part of the taskbar and it was designed to whisper information to the customer. Here you can easily monitor the system, be alerted to the state of a program or even check the time. Icons were the predominant way to convey information until later versions of Windows introduced notification balloons that provide descriptive alerts with text. Also added was a collapsible UI that hid inactive icons so the taskbar would appear cleaner.

With more developers leveraging its functionality, the Notification Area has grown in popularity over the years. Some may observe that it has changed from a subtle whisperer to something louder. Based upon the feedback we’ve collected from customers, we recognize the Notification Area could benefit from being less noisy and something more controllable by the end-user.

Show Me the Data

Earlier posts to this blog discussed how customers can voluntarily and anonymously send us data on how they use our features. We use these findings to help guide our designs. Please note that data do not design features for us, but they certainly help us prioritize our investments as well as validate our approach.  All to often we’re all guilty of saying something like “we know everyone does <x>” or “all users do <y>”.  Given the reliability and statistical accuracy of this data, we can speak with more real-world accuracy about how things are in used in practice.  Let’s look at some interesting information we have collected about how our customers use the taskbar.

Figure 3 provides some of the most important data about the taskbar—window count. On average, we know that a vast majority of our customers encounter up to 6-9 simultaneous windows during a session (a session is defined as a log in / log out or 24 hours—whichever occurs first). It goes without saying that the taskbar should work for the entire distribution of this graph, but identifying the “sweet spot” helps focus our efforts on the area that matters most to the most amount of customers. So, we know that if we nail the 6-9 case and we work well for the 0-5 as well as the 10-14 scenarios, we’ve addressed almost 90% of typical sessions.

Fig. 3: What’s the maximum number of windows opened at a time?

Figures 4 and 5 help us understand how customers customize their taskbars. We could probably spend an entire post focused solely on how we determine the options we expose. Perhaps another time we’ll tackle the paradox of choice and how options stress our engineering process yet also make the product more fun for a set of customers. Until then, let’s see what conclusions we can draw from these findings. The most obvious takeaway is that most customers do not change the default settings, which are a simple right-click Properties away. For example, it may be interesting to note how often end-users relocate the taskbar to other regions of the screen—less than 2% of sessions have a taskbar that’s not at the bottom of the screen. We also know that some small percentage of machines accidently relocate the taskbar and more often than not end-users have difficulty undoing such a state—though our data does not differentiate this situation.  This data does not necessarily mean we would remove relocation functionality, but rather we could prioritize investments in a default horizontal taskbar over other configurations.

Fig. 4: How do people customize their taskbar? The red number indicates percentage of sessions in which the corresponding checkbox is enabled.

LOCATION	SESSION PERCENT
Bottom (default)	98.4%
Top	1.02%
Left	0.36%
Right	0.21%

Fig. 5: Where do people put their taskbar?

Figure 6 provides some insight into the Windows Media Player Desktop Toolbar. The Windows UX Guidelines prescribe that to create a toolbar on the customer’s taskbar, you must call a Windows Shell API that asks the customer for permission. Looking at the Windows Media Player usage we found that only 10% sessions show that the customer consented. Even more surprising is that only 3% of sessions see the toolbar at all (you still need to minimize Media Player to see the controls). In other words, 97% of sessions aren’t even enjoying this functionality at all! Since we do believe the scenario has value, we know to look into alternative designs. We’d like to surface this functionality to a larger set of customers while making sure the customer remains in control of her experience.

STATE	SESSION PERCENT
Toolbar enabled	10%
Toolbar enabled and visible	3%

Fig. 6: How many people use the Windows Media toolbar? Enabled means user consented to the toolbar, visible means the toolbar actually appeared on the taskbar.

Evolving the Taskbar

Before the team even sat down to brainstorm ideas about improving the taskbar, we all took time to first respect the UI. The taskbar is almost 15 years old, everyone uses it, people are used to it and many consider it good enough. We also recognized that if we were to improve it, we could not afford to introduce usability failures where none existed. This automatically sets a very high bar. We proceeded carefully by first looking into areas for improvement.

Here’s a small sample of some things we’ve learned from our data, heard from our customers and what we’ve observed ourselves. One of favorite ways of gaining verbatim comments in a lab setting where we can validate the instrumented data but also gain in-depth context via interviews and questionnaires.  In engineering Windows 7 we have hundreds of hours of studies like these.  Please remember this is just a glimpse of some feedback—this is not an exhaustive list nor it is implied that we will, or should, act upon all of these concepts.

• Please let me rearrange taskbar buttons! Pretty please?
• I sometimes accidently click on the wrong taskbar button and get the wrong window.
• It would be great if the taskbar spanned multiple monitors so there’s more room to show windows I want to switch to.
• There isn’t always enough text on the taskbar to identify the window I’m looking for.
• There’s too much text on the taskbar. (Yes, this is the exact opposite of the previous item—we’ve seen this quite a bit in the blog comments as well.)
• It may take several clicks to get to some programs or files that I use regularly.
• Icons of pinned files sometimes look too much alike—I wish I could tell them apart better.
• The bottom right side of my screen is too noisy sometimes. There are lots of little icons and balloons competing for my attention.
• How do I add/remove “X” from the taskbar?
• I would like Windows to tuck away its features cleverly and simplify its interface.

In the abstract, we can summarize this feedback with a few principles:

• Customers can switch windows with increased confidence and ease.
• Commonly used items and tasks should be at the customer’s fingertips.
• Customers should always feel in control.
• The taskbar should have a cleaner look and feel.

We hope this post provides a little more insight into the taskbar as well as our process of collecting and reacting to customer feedback. Stay tuned for more details in the future.

- Chaitanya

The "Ecosystem"

In the emails and comments, there are many topics that are raised and more often than not we see the several facets or positions of the issue. One theme that comes through is a desire expressed by folks to choose what is best for them. I wanted to pick up on the theme of choice since that is such an incredibly important part of how we approach building Windows—choice in all of its forms. This choice is really because Windows is part of an ecosystem, where many people are involved in making many choices about what types of computers, configuration of operating system, and applications/services they create, offer, or use. Windows is about being a great component of the ecosystem and what we are endeavoring to do with Windows 7 is to make sure we do a great job on the ecosystem aspects of building Windows 7.

Ecosystem and choice go hand in hand. When we build Windows we think of a number of key representatives within the ecosystem beyond Windows:

• PC makers
• Hardware components
• Developers
• Enthusiasts

Each of these parties has a key role to play in delivering on the PC experience and also in providing an environment where many people can take a PC and provide a tailored and differentiated experience, and where companies can profit by providing unique and differentiated products and services (and choice to consumers). For Windows 7 our goals have been to be clearer in our plans and stronger in our execution such that each can make the most of these opportunities building on Windows.

PC Makers (OEMs) are a key integration point for many aspects of the ecosystem. They buy and integrate hardware components and pre-install software applications. They work with retailers on delivering PCs and so on. The choices they provide in form factors for PCs and industrial design are something we all value tremendously as individuals. We have recently seen an explosion in the arrival of lower cost laptops and laptops that are ultra thin. Each has unique combinations of features and benefits. The choice to consumers, while sometimes almost overwhelming, allows for an unrivaled richness. For Windows 7 we have been working with OEMs very closely since the earliest days of the project to develop a much more shared view of how to deliver a great experience to customers. Together we have been sharing views on ways to provide differentiated PC experiences, customer feedback on pre-loaded software, and partnering on the end-to-end measurement of the performance of new PCs on key metrics such as boot and shutdown.

Hardware components include everything from the CPU through the “core” peripherals of i/o to add-on components. The array of hardware devices supported by Windows through the great work of independent hardware vendors (IHVs) is unmatched. Since Windows 95 and the introduction of plug-and-play we have continued to work to improve the experience of obtaining a new device and having it work by just plugging it in—something that also makes it possible to experience OS enhancements independent of releases of Windows. This is an area where some express that we should just support fewer devices that are guaranteed to work. Yet the very presence of choice and ever-improving hardware depends on the ability of IHVs to provide what they consider differentiated experiences on Windows, often independent of a specific release of Windows. The device driver model is the core technology that Microsoft delivers in Windows to enable this work. For Windows 7 we have committed to further stabilization of the driver model and to pull forward the work done for Windows Vista so it seamlessly applies to Windows 7. Drivers are a place where IHVs express their differentiated experience so the breadth of choice and opportunity is super important. I think it is fair to say that most of us desire the experience where a “clean install” of Windows 7 will “just work” and seamlessly obtain drivers from Windows Update when needed. Today with most modern PCs this is something that does “just work” and it is a far cry from even a few years ago. As with OEMs we have also been working with our IHV partners for quite some time. At WinHEC we have a chance to show the advances in Windows 7 around devices and the hardware ecosystem.

Developers write the software for Windows. Just as with the hardware ecosystem, the software ecosystem supports a vast array of folks building for the Windows platform. Developers have always occupied a special place in the collective heart of Microsoft given our company roots in providing programming languages. Each release of Windows offers new APIs and system services for developers to use to build the software they want to build. There are two key challenges we face in building Windows 7. First, we want to make sure that programs that run on Windows Vista continue to run on Windows 7. That’s a commitment we have made from the start of the project. As we all know this is perhaps the most critical aspect of delivering a new operating system in terms of compatibility. Sometimes we don’t do everything we can do and each release we look at how we can test and verify a broader set of software before we release. Beta tests help for sure but lack the systematic rigor we require. The telemetry we have improved in each release of Windows is a key aspect. But sometimes we aren’t compatible and then this telemetry allows us to diagnose and address post-release the issue. If you’ve seen an application failure and were connected to the internet there’s a good chance you got a message suggesting that an update is available. We know we need to close the loop more here. We also have to get better at the tools and practices Windows developers have available to them to avoid getting into these situations—at the other end of all this is one customer and bouncing between the ISV and Microsoft is not the best solution.

Our second challenge is in providing new APIs for developers that help them to deliver new functionality for their applications while at the same time provide enough value that there is a desire to spend schedule time using these APIs. Internally we often talk about “big” advances in the GUI overall (such as the clipboard or ability to easily print without developing an application specific driver model). Today functionality such as networking and graphics play vital roles in application development. We’ve talked about a new capability which is the delivery of touch capabilities in Windows 7. We’ve been very clear about our view that 64-bit is a place for developers to spend their energy as that is a transition well underway and a place where we are clearly focused.

Enthusiasts represent a key enabler of the ecosystem, and almost always the one that works for the joy of contributing. As a reader of this blog there’s a good chance you represent this part of the ecosystem—even if we work in the industry we also are “fans” of the industry. There are many aspects to a Windows release that need to appeal the enthusiasts. For example, many of us are the first line of configuration and integration for our family, friends, and neighbors. I know I spent part of Saturday setting up a new wireless network for a school teacher/friend of mine and I’m sure many of you do the same. Enthusiasts are also the most hardcore about wanting choice and control of their PCs. It is enthusiasts sites/magazines that have started to review new PCs based on the pre-installed software load and how “clean” that load is. It is enthusiasts that push the limits on new hardware such as gaming graphics. It is enthusiasts who are embracing 64-bit Windows and pushing Microsoft to make sure the ecosystem is 64-bit ready for Windows 7 (we’re pushing of course). I think of enthusiasts as the common thread running through the entire ecosystem, participating at each phase and with each segment. This blog is a chance to share with enthusiasts the ins and outs of all the choices we have to make to build Windows 7.

There are several other participants in the ecosystem that are equally important as integration points. The system builders and VARs provide PCs, software, and service for small and medium businesses around the world. Many of the readers of this blog, based on the email I have received, represent this part of the ecosystem. In many countries the retailers serve as this integration point for the individual consumer. For large enterprise customers the IT professionals require the most customization and management of a large number of PCs. Their needs are very demanding and unique across organizations.

Some have said that the an ecosystem is not the best approach that we could do a much better job for customers if we reduce the “surface area” of Windows and support fewer devices, fewer PCs, fewer applications, and less of Windows’ past or legacy. Judging by the variety of views we've seen I think folks desire a lot of choice (just in terms of DPI and monitor size).  Some might say that from an engineering view less surface area is an easier engineering problem (it is by definition), but in reality such a view would result in a radical and ever-shrinking reduction in the choices available for consumers. The reality is engineering is about putting constraints in place and those constraints can also be viewed as assets, which is how we view the breadth of devices, applications, and “history” of Windows. The ecosystem for PCs depends on opportunities for many people to try out many ideas and to explore ideas that might seem a bit crazy early on and then become mainstream down the road. With Windows 7 we are renewing our efforts at readying the ecosystem while also building upon the work done by everyone for Windows Vista.

The ecosystem is a pretty significant in both the depth and breadth of the parties involved. I thought for the purposes of our dialog on this blog it is worth highlighting this up front. There are always engineering impacts to balancing the needs each of the aspects of the ecosystem. Optimizing entirely along one dimension sometimes seems right in the short term, but over any period of time is a risky practice as the benefits of a stable platform that allows for differentiation is something that seems to benefit many.

With Windows 7 we committed up front to doing a better job as part of the PC ecosystem.

Does this post reflect your view of the ecosystem? How could we better describe all those involved in helping to make the PC experience amazing for everyone?

--Steven

More Follow up to discussion about High DPI

 

Excellent!  What a fun discussion we’ve been having on High DPI.  It has been so enriching that Ryan wrote up a summary of even more of the discussion.  Thanks so much!  --Steven

There have been quite a few comments posted regarding high DPI, along with some lively discussion. Most of what has been said has been good anecdotal examples which are consistent with the data we have collected. For the areas where we didn’t have data, the comments have helped to validate many of our assumptions for this group. It is also clear that there are some areas of this feature which are confusing, and in some cases there is a bit of “myth” around what is ideal, what is possible, and what is there. This follow up post is mostly to summarize what we have heard, and to provide some details around the areas where there has been a bit of confusion.

Here is a list of our top “assumptions” which have been echoed by the comments posted:

• Most people adjust the screen resolution either to get larger text, or because it was an accident
• There is a core of people who know about high DPI and who use it
• Some people prefer more screen real-estate while others people prefer larger UI
• Discoverability of the DPI configuration is a concern for some
• App compat is a common issue, even a “deal breaker” in some cases
• IE Scaling is one of the top issues listed (see IE8 which fixes many of these!)
• Lots of complexities/subtleties and it is pretty hard to explain this feature to most people

There have also been a number of areas where there has been a bit of confusion:

• Is it true that if everything were vector-based, these problems would all go away?
• Shouldn’t this just work without developers having to do anything?
• How is this different from per-application scaling like IE zooming?
• Should DPI be for calibration or for scaling?

Most of these topics have been covered to some degree in the comments, but since there has been so much interest, we decided to go into a bit more details around a few of the top issues/concerns.

Vector Graphics vs. Raster Graphics

With PCs, there is always the hope of a “silver bullet” technology which solves all problems making life easy for users, developers, and designers across the board. As an example, some of the comments to the original posting suggested that if we just made the OS fully vector based, these scaling problems would go away. It turns out that there are several issues with using vector graphics which are worth explaining.

The first issue is that oftentimes when an icon gets to be small in size, it is better to use an alternate representation so that the meaning is clearer. Notice the icons below. In this case, the designer has chosen a non-perspective view for the icon when it is rendered at it’s smallest size.

This is because the designer felt that the information expressed by the icon was clearer with a straight-on view at the smallest size. Here is another example illustrating this point:

Of course, this means that the designer must create multiple versions of the source image design, so there is additional complexity. The point here is that there is a tradeoff that must be made and the tradeoff is not always clear.

Even when one vector source is used, it is common to have size-dependent tweaking to make sure that the result is true to what the designer had in mind. Imagine a vector graphic which has a 1-pixel line at 128x128 that gets scaled down by 1/2 to 64x64. The display has no way of rendering a perfect 1/2 pixel line! In many cases the answer is that the renderer will “round” to a nearby pixel line. However, doing this inherently changes the layout of the sub-elements of the image. And there is the question of, “which pixel line to round to?” If the designer does not hand tune the source material, it will be up to the rendering engine to make this decision, and that can result in undesirable effects. One could say that this should therefore define rules about what elements should be use in a vector, but that only further restricts what concepts can be represented.

It turns out that even the TrueType fonts which we use in Windows are hand-tuned with size-dependant information in order to make the result as high quality as possible. Most of the TrueType rendering pipeline is based on algorithmic scaling of a vector source, but there are size-dependent, hand-coded “hints” in TrueType which the designer specifies to direct the system how to handle edge cases, such as lines falling between pixel boundaries. Here is a link describing this in more detail: http://blogs.msdn.com/fontblog/archive/2005/10/26/485416.aspx

It is not even true that vector graphics are necessarily smaller in size (especially for small images). Most designers create graphics using an editor which builds up an image using many layers of drawings and effects. With bitmap based graphics, designers will “flatten” the layers before adding it to a piece of software. Most designers today pay little attention to the size of the layers because the flattening process essentially converts it to a fixed size based on the image resolution. With vector graphics, there is no such flattening technique so designers need to carefully consider the tools that they use and the effects that they add to make sure that their icon is not extremely large. I spent some time with one of our designers who had a vector graphic source for one of our bitmaps in Windows and the file was 622k! Of course that file size is fixed regardless of the resulting resolution, but that huge file flattens into this 23k PNG bitmap.

Of course, a hand-tuned vector based representation of this could be probably made smaller if the size constraints were part of the design time process. But that would be an additional constraint put on the designer, and one which they would need to learn how to do well.

How do we help developers?

For applications that need to carefully control the layout and graphics, or scale the fidelity of the images based on the available resolution, having a way of specifying specific pixel locations for items is important to get the best result. This is as true on the Mac as it is on the PC (see http://developer.apple.com/releasenotes/GraphicsImaging/RN-ResolutionIndependentUI/). There is often a belief that if we just provided the right tools or the right framework then all these problems would go away. We all know that each set of tools and each framework have their own set of tradeoffs (whether that is Win 32, .net, or HTML). While there is no silver bullet, there are things we can do to make writing DPI aware applications easier for developers. As an example, there are two important upcoming ecosystem events in which we will be talking in detail about High DPI. We will also have materials which we will be making available to developers which will help educate them on how to convert existing applications to be DPI aware. The first event is Microsoft Professional Developer Conference, where we will talk about High DPI as part of the talk “Writing your Application to Shine on Modern Graphics Hardware (link)”. The second is the Windows Hardware Engineering Conference, in which we will be discussing high DPI as part of the “High Fidelity Graphics and Media” track (link).

Help with App Compat Issues

There have been several posts on app compat and high DPI (for example bluvg’s comment). There have also been comments talking about the complexity and understandability of the High DPI configuration. In some cases the app compat issues can be mitigated by enabling or disabling the automatic scaling feature. This can be changed globally by going to the DPI UI, clicking the button labeled “Custom DPI” and changing the checkbox labeled, “Use Windows XP style DPI scaling”. When this checkbox is unchecked, applications which are not declared to be DPI aware are automatically scaled by the window manager. When it is checked, automatic scaling is disabled globally. It is interesting to note that for DPI settings < 144 DPI, this box is checked by default, and for DPI settings >= 144 it is unchecked by default. In some cases, changing the default settings can result in a better experience depending on the applications that you use and your DPI setting. It is also interesting to note that automatic scaling can be turned off on a per application basis using the Vista Program Compatibility properties. Here is a link for more info on how to do that: http://windowshelp.microsoft.com/Windows/en-US/help/bf416877-c83f-4476-a3da-8ec98dcf5f101033.mspx. (Look at the section for “Disable Display Scaling on high DPI settings”.)

How is DPI scaling different from per-application scaling (like IE Zoom?)

A typical application UI is made up of a content window and a frame UI. The frame UI is where the menu items and toolbar buttons are. The content window is the “document view”. For example, in IE the content window is the actual webpage. It turns out the code required to support high DPI scaling for the content windows is the same code required to do the zooming feature. In fact, for the content window, IE8 simply uses the high DPI setting to configure the default zoom factor (see DPI Scaling and Internet Explorer 8 for more details). However, high DPI has the additional side effect of scaling the size of the frame UI. Since most people use the scaling feature to make text larger to be more readable, it makes sense to scale the frame UI as well, since the text in the menu items and toolbar tooltips will also scale. In a sense if there is per-application scaling that is really about the content area, and applications will support that as developers see the customer need. DPI scaling makes the UI elements of all applications render similarly.

Shouldn’t DPI really be used for calibrating the screen (so “an inch is an inch”)?

Some have suggested that we should just use high DPI as a way to calibrate the screen so that the physical size of an object is the same regardless of the display. This makes a ton of sense from a logical perspective. The idea would be to calibrate the display so “in inch is an inch”. We thought about doing this, but the problem is that it does not solve the end user need of wanting to have a way to configure the size of the text and the UI. If we then had a separate “global scale” variable, this would mean that application developers would need to pay attention to both metrics, which would add complexity to the developer story. Furthermore, if a user feels that the UI is too small, should it be up to the developer or the user to set the preference of how big the UI should be? In other words if the designer wants the button to be an inch, but the user wants the button to be 1.5 inches to make it easier to use, who should decide? The way the feature works today, it is up to the user to set their preference, but it is up to the application developer to make sure that the user preference is honored.

Once again, it is really great to see so much interest in high DPI. We certainly have some challenges ahead of us, but in many ways it seems like the ecosystem is ripe for this change. Hopefully this follow up post helped to consolidate some of feedback which we have heard on the previous post and explain some of the complexities of this feature in more detail.

--Ryan Haveson