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 idx-help@microsoft.com 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 th