Engineering Windows 7 : Feedback

A few more changes from Beta to RC…

e7blog — Fri, 13 Mar 2009 10:00:00 GMT

Hey folks, just wanted to provide another update (building on the recent post on some changes since Beta) on some of the changes you will see in the Release Candidate. Again, there are many and this is not an exhaustive list. Of course we continue to gather telemetry from the large number of people running the Beta full time. Just a reminder, the Beta is the only official build from Microsoft. Chaitanya compiled this list from a broad set of feature teams focused on visible changes based on feedback that go beyond “bug fixes”, though we included some of the more widely reported bugs on this list as well. –Steven

Desktop Experience

1. Improved taskbar thumbnail overflow

Our customers are enjoying how windows are grouped and revealed on the enhanced taskbar. Some enthusiasts who have a significant number of open windows for a program encounter our scaling mechanism; the thumbnail view turns into a list view. Although this UI is virtually identical to experience in XP and Vista, customers still want to enjoy new functionality of the thumbnail view. Bentronic wrote, “It's nice that there's a little close button on the thumbnail previews--why not have a similar button for when it's showing as a list? Being able to run down the list clicking the close button instead of right-clicking would be great.” For RC we’ve made the list view architecturally the same as the thumbnail view, just sans thumbnails. Customers will now enjoy close buttons and the menus open on hover (in Beta one had to click to open them).

Fig 1.

List View of running windows appears on hover and supports close

2. Control Panel Jump List

Right-clicking on the Control Panel icon on the taskbar in Beta revealed a noticeably sparse Jump List. A few people such as Britney told us “Should most recently used items be displayed in the Jump List of the CPL when pinned to the taskbar? Something should be shown and nothing is there right now”. In RC the Control Panel Jump List offers quick access to recently used items.

Fig 2.

The Control Panel Jump List now surfaces recently used items

2. PowerShell Jump List

By default PowerShell in Beta launched a streamlined console. Customers could load optional modules via distinct shortcuts in the Start Menu. We heard from you that this was a confusing experience. Additionally, PowerShell did not surface a way to launch related tasks such as the Integrated Scripting Environment (ISE) from within their console experience. PowerShell now has a robust Jump List that affords a method to load modules, launch the ISE and open documentation.

3. Remote Desktop Jump List

Rajeev made us smile with his comment, “Being able to add my Remote Desktop shortcut to the taskbar—good. Saving settings and showing them in the Recent items section—awesome. Being able to pin the connections in the Jump List, so they always appear—priceless!” Well, Rajeev and others who shared this request, you will be enjoy this functionality in RC.

4. Applying taskbar settings

Have you ever customized the taskbar, only to find your changes were not saved across sessions? Has the taskbar ever inexplicably moved on you after you log in? For a variety of reasons, previous versions of Windows saved taskbar settings only after Explorer exited at the end of a session. However, if the OS is not shutdown properly these settings did not persist. Based on the bugs we saw from Beta, we decided to change our architecture and write these settings within 30 seconds (providing enough time to batch a group of changes) during the session. This means settings will now be more reliable.

Touch

5. Multi-touch zoom

One of the pieces of feedback we heard from the Beta was that customers enjoy the new multi-touch zoom feature, but wish it was supported in Windows Explorer. In response to this feedback we have added support for the zoom gesture in Windows Explorer. Using the zoom gesture you can switch between view modes in Explorer such as zooming from Small Icons to Extra Large icons.

Windows Explorer and Libraries

6. Invert Selection

In an effort to make improvements to performance, network bandwidth and memory footprint for various scenarios (e.g. libraries, search and search federation), we rearchitected the implementation of the view code in Windows Explorer. As part of this we did not to port “Invert Selection” since this rarely used feature is pretty complex to implement in the context of virtualized lists. Despite the small percentage of usage we’ve recorded, those who missed it have been pretty vocal :-) On one of the blog posts, GGreig summarized what we heard from several of you—“Invert Selection; that's a useful - sometimes absolutely invaluable - little piece of functionality, and I definitely don't want to see it go…Please reinstate Invert Selection.” Given the feedback from enthusiasts, we added back the functionality for RC.

7. Going up?

We’ve heard feedback, especially from those on this blog, that in Windows 7 moving up in the folder hierarchy often requires multiple clicks since longer folder names in the address bar often bump the parent folder into the overflow dropdown.

For RC, we’ve improved the overflow algorithm so that the parent folder’s button will appear in the address bar at all times and therefore going ‘up’ will always be a single click away in a predictable location. When there isn’t enough room to display the parent folder’s full name, it will appear truncated instead of going into the overflow. If space is especially tight, then the current folder’s name may appear truncated too, but in all cases the parent folder’s button will remain as a click target in the address bar.

In addition to making the address bar an even better tool for navigating ‘up’ in Explorer, this change also makes it easier to tell where your are as you navigate around since you can now see at least part of the parent folder’s name. It also avoids introducing any more redundant buttons to the Explorer frame and hence taking away any more screen space from being able to see your address. Also, it goes without saying that if you navigate into a folder, you can still use the back button to go back up. And the keyboard shortcut is also available.

Fig 3.

In Beta, a parent folder would collapse into an overflow dropdown

Fig 4.

In RC, parent folders always remain within single click access

8. Finding music by artist

We covered several of the improvements to arrangement views in the last post, but one we did not mention is that the “Artist” view in the Music Library now accounts for album artists and compilation albums. ShadowChaser summarized some feedback we heard from a number of customers in a comment: “The only concern I still have is with the ‘Artist’ view… it groups by ‘Contributing Artist’, not ‘Album Artist.’” Grouping only by contributing artist results in too many artists showing up and tracks from the same album getting split up in cases where customers didn’t expect. In RC, the “Artist” view in the Music Library groups together multiple tracks from an album by the common “Album Artist” property when it is available, groups tracks from compilation albums together into a “Various Artists” group and finally resorts to grouping by “Contributing Artist”. This reduces clutter when browsing music collection by artist, in addition to improving consistency with artist views in other applications and devices.

9. New folder is always available

We’ve gotten a lot of positive feedback during Beta about adding a top level “New folder” button in Explorer, freeing customers from digging into submenus. A common complaint we received, however, was that the button only appeared when nothing is selected. For RC, we’ve changed this so the “New folder” button will always appear, regardless of selection.

10. Right-click in Windows Explorer

For RC we’ve changed the behavior when right-clicking items in the view to address concerns customers were reporting with the Beta. We heard feedback that it was too hard to find space and get to the view’s background context menu for items such as New and Paste. Previously if one right-clicked over any portion of an item she would get the item’s context menu. We now show the view’s context menu when one clicks on any large white space, including the space between a files name and its properties.

11. Content view for search results

For RC we’ve adjusted the behavior when right-clicking items in the view to address concerns customers were reporting with the Beta. We heard feedback that it was too hard to find space

Content view is the new view mode we’ve added to Windows Explorer for Windows 7. It’s especially useful for search results where it surfaces the most relevant properties for each kind of file (e.g. documents, email, pictures and music) as well as a contextual “snippets” of the file content where the search term match occurred. There are a few changes here in the RC build. One thing we heard feedback on is that customers want to know exactly which properties were being shown for each item, so all properties now appear with labels. The text layout and colors have been updated in response to feedback to make each item even easier to parse and to avoid confusion with the colors used for encrypted or compressed files. We heard loud and clear that many found snippets very useful and wanted to see more of them, so in the RC we’ve allowed longer snippets and we’re using them in more places. In response to feedback we heard from customers when resizing their Explorer window or toggling the preview pane, we’ve made the transitions smoother as additional columns of information about each item are revealed when you make the view larger.

12. Intelligent re-indexing after application installation

In RC the Windows Search service now keeps the index up-to-date whenever support for new file types are introduced to the system. We know that in the past customers have sometimes had difficulties searching for files on their computer after new file handlers are installed. (File handlers govern how content and metadata is made searchable and are typically installed with applications such as Microsoft Office or updates such as the Microsoft Filter Pack).

In Win7 Beta (and previous versions of Windows), customers were required to rebuild their index whenever a new file handler was installed to ensure that any existing files were indexed with the newest functionality. Few customers knew to do this and it was an unnecessarily time consuming operation. Windows Search is more efficient in RC by automatically re-indexing the specific files affected by new file handlers. Rest assured that when one installs support for a certain kind of file, she can search for those files without doing any additional work.

Performance

13. Trimming sound schemes to help performance

We know our customers care about performance. We discovered that by just trimming the shutdown and logoff WAV files, we could save up to 400 ms. Every little bit counts.

Device Stage

14. Baseline Device Stage experience

Device Stage continues to enjoy positive reviews. For example, we saw this post on on a blog: “I have to be honest this works very well, it worked with my MP3 player in showing how much charge it had and other details as well is able to display the manual and offer me everything I needed to do with it effortlessly, including having the correct icon and image of the product.” However, we occasionally hear “too bad , my N70 aint supported either :-( …hopefully they are gonna support a ton more device by the time windows 7 get released”.

We took feedback like this to the devices makers and they too would like more integration given the interest from our customers. Several manufacturers are implementing custom experiences, but a large number have also opted to support their older devices in what we call the “baseline” Device Stage experience.

This UX works exactly like full Device Stage; the device image appears on the taskbar whenever it is connected and tasks are exposed in the Jump List. On first connect, the shell Window containing all of the built-in tasks appears automatically and is always just one click away from the desktop icon or device image in the Devices and Printers folder. When the device maker implements a custom Device Stage experience for a device, it gets posted on the Web and the baseline experience gets upgraded when the device is later reconnected. The core functionality is the same, but all of the branding, imaging and vendor-specific tasks are now available automatically in the same convenient UI.

Fig 5.

Baseline Device Stage experience for a mobile phone

15. Devices and Printers enhancement

PC and laptop makers such as Lenovo, were very interested in doing more than just showing the machine’s icon in Devices and Printers. They told us they wanted to leverage Device Stage to help them better customize the experience for our mutual customers. In RC double-clicking on the PC icon now offers a Device Stage UX. Like the other Device Stage devices, Device Stage for PC will be enabled when the PC maker has chosen to participate with their system.

Fig 6.

Device Stage experience for a PC

Devices and Printers

16. Unified experience for removing devices

One of the tasks customers perform in Devices & Printers is removing devices that are no longer in use. We received feedback that the remove action varied across different device classes. For example, removing a printer only removed the print queue and for Bluetooth devices it only removed the pairing of the device to the PC. We have changed this action to always completely uninstall the device across all device classes – which is the action that most customers expect.

17. Hardware properties

We know enthusiasts use the Device Manager’s property page to check the status of a device. We heard feedback that this wasn’t convenient and so we now also surface the property page directly from the Devices and Printers experience. Simply right-click on the device and one has one less reason to visit Device Manager.

18. Improved eject experience

The Safely Remove hardware functionality enables customers to make sure that their device is ready for removal. During the Windows 7 Beta, customers still had the Safely Remove Hardware functionality available on the taskbar as well as an Eject option on the context menus of applicable devices in Devices and Printers. Based on feedback, we have integrated these two separate pieces of functionality in RC and have changed its name from “Safely Remove” to “Eject”. The tool Notification Area icon still appears, but its context menu now has the option to open Devices and Printers. Also, we have simplified the options by eliminating the drop-down submenu and made the semantics for eject functionality more consistent across the different kinds of media. For example, ejecting an optical drive now ejects the media instead of the drive and ejecting a USB flash drive ejects the entire device instead of an individual volume.

19. USB device reliability on resume

We got feedback from a number of customers that their USB devices (e.g. keyboards, mice and drives) stopped working after a suspend/resume cycle. We worked with a number of customers to get traces and isolated the causes to address them post-beta builds. The work around in Beta was to unplug and replug the device to get it functional again—easy for external devices but not possible for internal devices. This workaround will not be needed on RC builds.

20. FireWire camera support

Some customers informed us they were unable to connected their 1394 HDV camera and stream its contents to their Beta machine. With the help of customers, we were able to identify a fault with our core 1394 stack and we’ve validated the scenario works in RC. This is another good example of the combination of telemetry and more “manual” follow up on the part of our test team.

Device Installation

21. Add Legacy Hardware functionality restored

The Add Legacy Hardware action was provided in Device Manager on past Windows releases to install non-Plug and Play devices. We removed this functionality for Windows 7 with the belief that this was rarely used. Aaron blogged, “You might have noticed that the old 'Add Legacy Hardware' option seems to be missing. I tend to use this quite a bit whenever I need to add in a Loopback adapter or some piece of hardware that is not quite installing correctly.” As a result, this functionality has been restored to Device Manager for RC to help add non-Plug and Play devices.

22. Increased responsiveness of Add Printer Wizard

There are some situations with legacy network printers in which Plug and Play cannot automatically identify the appropriate driver even when it’s available on Windows Update. For these situations, the Add Printer wizard allows customers to download a list of all the printer drivers available on Windows Update so they can manually select the driver for the specific printer being installed. The process of retrieving the list can take a few minutes and we received beta feedback that many people felt their machine was hung since there was nothing in the UI to let them know that it could take a few minutes. We have made some UI changes to indicate that process of retrieval can take some time. Additionally, we have also improved the overall performance of retrieving the list from Windows Update.

System

23. Partition size reduction

In Windows Vista, configuring features such as Windows Recovery Environment and Bit Locker required significant customer interaction. Also, a significant amount of drive space was reserved. The Windows 7 System partition enables features to be configured to work “out of the box” so very little customer interaction is needed to configure and utilize them. Based on feedback and telemetry data received through the beta, it became clear that we could cut the drive size in half (from 200M to 100M).

24. Reserved System Partition naming

The system partition is created automatically by Setup when installing on a machine with no existing partitions. During the Beta the existence of this partition on default installs confused many people and feedback indicated that a label telling them that this is space reserved for the system would be helpful when browsing disk configurations, and further help prevent it’s accidental deletion by enthusiasts. We will now label is “System Reserved”.

25. Dual Boot partition drive letter assignment

For a dual boot configuration for the Beta, the other Windows OS wouldn’t get a drive letter and therefore wouldn’t show up in explorer. We heard overwhelmingly from Beta customers that the lack of a drive letter was confusing and even caused some to believe that their secondary OS was lost. Assigning the drive letter makes it visible in explorer and aids in navigation across OS installations.

26. Pagefile reduction

Through extensive use of Beta telemetry data, we have determined we can slim down the Windows disk footprint further by reducing the default page file size to be 100% of the available main memory. It used to be “Memory + 300MB” so on a 1GB RAM system there was an extra third allocated that is no longer required. The pagefile on some occasions will increase in size if required, but we just pre-allocate less.

Network

27. Improved driver support

Based on telemetry data received from the beta, we identified networking drivers that were not available inbox. We worked with ecosystem partners to achieve increased inbox driver coverage across wireless and wired with significant coverage for some of the new ATOM-based laptops.

We hope you enjoyed yet another sneak peek into what’s coming in RC.

Some Changes Since Beta for the RC

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

We’ve been quite busy for the past two months or so working through all the feedback we’ve received on Windows 7. It should be no surprise but the Release Candidate for Windows 7 will have quite a few changes, many under the hood so to speak but also many visible. Some have asked if the featureset is "frozen" then what will we change--we change a lot of things in the beta based on feedback and we try to do so in a systematic manner with the focus on the goals for the release. The goal of having a fully functional Beta was to make sure we received reliable feedback and not a lot of "hey this doesn't work at all" sorts of reports. This has allowed us to really focus on delivering a refined RC where the changes we made are all the reflection of feedback we have received.

Building on the previous post that looked at the broad view of feedback, we want to start posting on the feedback and the engineering actions we’ve taken in responding to the feedback. We won’t be able to cover all the changes (as we’re still busy making them), but for today we wanted to start with a sampling of some of the more visible changes. We’re still on the same path working towards the release candidate and of course we know everyone is anxious for the next phase of our path to RTM. In the meantime, our full time machines are still running the Beta build.

Today’s post is from Chaitanya, who has previously posted on some of the core user interface work. --Steven

This blog post talks about a few of the improvements that will be in our Release Candidate (RC) based upon customer feedback. There are many under the hood changes (bug fixes, compatibility fixes, performance improvements, and improvements) across the entire dev team that we just don’t have room to discuss here, but we thought you’d enjoy a taste of some changes made by three of our feature teams: Core User Experience, Find & Organize and Devices & Media. The comments in this article come from a variety of verbatim sources, with identifying information withheld.

Desktop Experience

1. Windows Flip (ALT + TAB) with Aero Peek

We’ve received overwhelmingly positive feedback about Aero Peek and how it helps customers switch windows with increased confidence. Daniel wrote to tell us “I’m wondering why Peek was never implemented for the ALT + TAB window. The thumbnails look/behave the same way as the taskbar thumbnails when you hover the mouse over them. It seems logical that they would exhibit the peek behavior, too”. We decided to make this change since we heard many requests for it. One can still quickly flip between and cycle through running windows using the ALT+TAB keys, but when more window information is needed Aero Peek will appear. This is triggered by a time delay as you pause while keyboarding through running windows.

Fig 1.

Aero Peek triggered from Windows Flip (ALT+TAB)

2. Windows Logo + <#> keyboard shortcut

Enthusiasts often ask us for more keyboard shortcuts to simplify their common tasks. Efficiency is key. We’ve answered with a very powerful new keyboard shortcut for the taskbar that may just alienate mice everywhere. Pressing Windows Logo + <#> (where <#> corresponds to an item’s order in Quick Launch) in Vista would simply launch the item. As part of our unification of Quick Launch with the taskband in Windows 7, we now beef up the shortcut so it can both launch and switch. For example, if IE wasn’t running in Fig 1 then Windows Logo + 2 will launch the program (as it did in Vista). If IE is running with a single window, the same shortcut will now switch to the program. The magic really begins when IE is running with several windows or tabs—holding down the Windows Logo and tapping the 2 key repeatedly will actually cycle through the open IE items off the taskbar (with Aero Peek, of course). Letting go simply switches to the corresponding window. Think of this as per-program ALT +TAB shortcut for the first 10 items on the taskbar. If you need a new instance for IE, simply use SHIFT + Windows Logo + <#>. A program’s Jump List may also be accessed via ALT+ Windows Logo + <#>. Finally, you can even flip back to the last active window of a program by using CTRL+ Windows Logo + <#> (this also works by holding CTRL with a mouse click on a taskbar button). Keyboard aficionados rejoice!

3. Needy State

“Needy window” is the internal term we use for a window that requires your attention. Since the ‘90s, the taskbar has always provided some type of visualization to alert the customer to this state such as by flashing the button. A careful balance must be struck between providing information and not irritating the customer. With the new taskbar, we received feedback that Outlook reminders or a Messenger chat sometimes went unnoticed because needy windows were too subtle. For example, Mudassir opened a bug to say “The flashing is not obvious enough to get user's attention. Sometime I don't even notice it. It flashes for a little bit and then stops. If I am away the icon flashes and stops before I come back. The icon is not noticeable.” We’ve made three changes that should address the issue. First, we changed the flashing animation curve to make it more noticeable (from a sine to a sawtooth wave). Second, we used a bolder orange color. Finally, we wanted to double the number of flashes which is currently set to three. As a nod to Windows 7, we decided to go with seven flashes instead.

4. Taskbar “Open With”

Quick Launch always supported the ability to drop a file onto a pinned program and have it open with that program. The new taskbar on the other hand, always treats a drop as a pin command. Drop a program and the program is pinned. Drop a file and the file will be pinned under its respective program’s Jump List and that program automatically gets pinned to the taskbar. It was important for us to keep drag/drop consistent. We believe that for most cases people will open files through the desktop by just double-clicking them or from the Jump List and the default program will open. However, there are some scenarios when a customer wants to open a certain file type with another program. We heard this feedback and decided to revive “Open With” drag/drop on the taskbar with a keyboard modifier. One can hold down SHIFT and drop the file on the desired program.

5. Taskbar scaling

We’ve reclaimed lots of space on the taskbar by unifying launching/switching, by collapsing open windows and by cleaning the notification area. Still, some have asked for even more room to pin the programs they use regularly. We’ve made a change to squeeze in 24-39% more icons before the taskbar scrolls; depending upon your resolution, icon size and assuming the default notification area. Table 1 illustrates the new button capacity before the taskbar begins to scroll as well as the capacity growth since Beta. We believe customers will find more than enough room to pin their common programs.

Table 1.

Maximum taskbar button capacity before scrolling

Resolution	Large Icons	Small Icons	% Increase from Beta (large/small icons)
800x600	10	15	25% / 36%
1024x768	15	22	25% / 38%
1280x1024	20	29	25% / 32%
1600x1200	26	39	24% / 39%

6. Anchoring taskbar thumbnails

Hovering or clicking on a taskbar button surfaces all the running windows for that program. Upon seeing a set of open thumbnails, Kozlow asked “How do I know which application has opened the thumbnails group?” In other words, the thumbnails didn’t appear visually connected to the taskbar. We made a visual update that now keeps the color hot-track effect on when the mouse is over a thumbnail. In fig 2 you can see that IE retains its blue Color Hot-track visual even though the mouse is over a thumbnail.

Fig 2.

Color Hot-track stays active when the mouse hovers over taskbar thumbnails

7. Newly installed programs

“Customer in control” is so strong a mantra for Windows 7 we don’t even allow programs to pin themselves to the taskbar when they are installed. This is a task expressly reserved for the customer. We’ve gotten some requests to make this goal a bit easier so now when a program is installed, it is automatically and temporarily surfaced at the bottom of the Start Menu. The customer can easily discover this new addition, launch it directly and optionally drag it to the taskbar for convenient access in the future.

8. Jump List length

Jump Lists are proving to be a valuable tool to quickly jump to commonly access files, folders, links and tasks. Steve filed a bug in which he said “The whole point of the jump list is to make it easier to jump to your favorite locations. However, it doesn't save me time having to scan through a long list of frequent locations.” In other words, sometimes it’s hard to parse an item when the list gets too long. Our telemetry data informs us that in most cases customers are clicking on the first 10 items. Therefore, we’ve updated Jump Lists so that only a maximum of 10 items may be automatically suggested (this doesn’t apply to tasks or pinned items). Don’t worry—there’s even a setting for enthusiasts to customize the length of the list.

9. Increased pinning flexibility with Jump List

For organizational, scaling and identification purposes, the taskbar is designed to hold files, folders and links in a program’s Jump List. Items can only be pinned to the Jump List of programs registered to handle that file type. Based on feedback we’ve received we now allow one to pin items to a Jump List belonging to a program that isn’t registered to handle that file type. Better yet, pinning the item in most cases will create a new registration so that launching it from the Jump List will always open the file with that specific program. For example, one can pin an .HTML file to Notepad’s Jump List and when clicked on from the menu, the file will always open in Notepad even though IE by default handles the file type.

10. Desktop icon and gadget view options

Windows 7 makes gadgets far easier to manage, view and access by building them directly into the desktop. David’s feedback matches what others were telling us: “In Vista, I was able to hide desktop icons while my gadgets were still visible and available. I liked this feature in Vista, especially with all the icons that are constantly dropped on the desktop by app installers. I don't want to see the icons, but I still want to see my gadgets.” In Beta it was impossible to separate desktop icons from gadgets under the View setting available by right-clicking on the desktop. We made a change to afford independent control to each so that one can opt to hide just her gadgets or just her desktop icons.

Touch

11. Aero Peek for touch

We’re excited about Peek and we further refined its functionality. Our touch customers enjoy the benefits of direct manipulation, but inform us they feel left out of some of new functionality that’s available for the mouse and keyboard. We’ve made two improvements that spreads the love. First, the taskbar’s thumbnails now support a touch gesture so one can drag her finger across the UI and trigger Aero Peek. Also, the Show Desktop button is improved so a press-and-hold will allow the customer to peek at the desktop. A regular tap in both these scenarios still to commits the switch.

12. Multi-touch touch keyboard

A funny thing happens when one uses touch to interact with a software keyboard for the first time. The natural instinct is to press multiple buttons simultaneously like they do with a real keyboard. It’s quite reasonable to try to use SHIFT + <letter> to capitalize, for example. RC ushers in multi-touch support for the Touch Keyboard so that customers enjoy a more realistic experience.

13. Multi-touch right-click

People who are rely on touch give us mixed feelings towards tap and hold to bring up a context menu. This approach works, but it also involves a slight delay. We now have a fast new multi-touch gesture for right-click. Simply touch an item with one finger and use another finger to tap and summon a context menu.

14. Drag/Drop and selection

In Beta there was no discoverable way to select text in a website that scrolled both horizontally and vertically. Customers are now able to drag/drop and select items with touch, even inside scrolling pages. The new behavior is optimized for the two most common actions by touch customers—scrolling up and down and dragging left to right.

Networking

15. Internet access feedback

The new network experience from the taskbar’s notification area makes it much easier to find and connect to networks. People seem to also really like the wireless signal strength that is available at a glance. In our effort to simplify the experience we removed indications for some advanced scenarios. Based upon feedback, we’ve decided to introduce a new overlay icon which now reveals when there is a local connection without internet access.

Control Panel

16. User Account Control

If you’ve been following this blog, then you already know about a recent design change we’ve made that will prompt for any modification made to the UAC Control Panel. For more information, please refer to the earlier post on UAC Feedback and Follow-Up.

17. Locking a machine without a screensaver

It isn’t uncommon for IT administrators to want their corporate machines to auto-lock after a certain amount of time. In Beta, enabling this functionality required a screensaver to be set. We’ve since made a change to allow this functionality even when no screensaver is specified.

18. Faster access to High Performance power plan

Clicking on the battery flout from the taskbar notification area offers two different power plans: Balanced and Power saver. Windows 7 laptops are configured by default to use the Balanced plan since this setting best balances a good experience while promoting more environmentally friendly power use. However, some customers tell us they want to be able to quickly toggle between Balanced and High Performance (yet another power plan). We’ve taken a change to now show the latter in the flyout menu when it is enabled under the Power Options Control Panel.

19. Custom theme improvements

We’ve always known customers love personalizing their Windows experience. At the center of this expression of individuality are ingredients such as the desktop background, glass color, sounds and screensavers. In Windows 7 we’ve introduced themes that make it easy to enable a whole package of default combinations or for customers to save their own creations. However, during Beta we heard feedback along the lines of “I just changed my background or color and I see the change, but I thought it was saved when it really wasn’t”. We added text under each theme to not only aid in identification, but also to provide feedback on the state of a theme. The new “Unsaved Theme” text also ties better to the nearby “Save theme” command. These tweaks should make personalization a more predictable and enjoyable experience.

Windows Media Player

20. Improved Internet Radio playback

Internet radio playback continues to gain in popularity. We received feedback that sometimes playback of radio streams may be inconsistent depending on network conditions. It’s worth noting that our understanding of this issue was greatly helped by the broad scale of usage across so many customers and network topologies and our telemetry in the Beta. Windows Media Player has made changes to make streaming playback more reliable and resilient.

21. Improved playback support for video content from digital camcorders and cameras

Customers loved the increased range of formats natively supported by the Windows 7 Beta, but noticed areas where they wanted broader support. For example, one was unable to seek to a specific spot in the video in Windows Media Player or Windows Media Center for AVCHD content that was imported from a digital camcorder. We’ve addressed this. Also, while the support for video from some digital cameras worked great, we also got feedback about supporting a broader set of devices out of the box. We’ve since added support for Windows Media Player to natively support the .MOV files used to capture video for many common digital cameras.

22. Cleaner Now Playing view

Customers are sharing positive reviews of Media Player’s new light-weight Now Playing view. Still some have asked to make the experience even cleaner. We’ve responded with a visual update that is more lightweight and compact.

23. Filtering content that cannot be played

Media Player’s library view is designed to surface and showcase one’s content. However, in some cases items were displayed that couldn’t be played. For example, Apple’s lossless .M4A or .H263 MPEG-4 content would be shown in a library even though Media Player could not play them. In RC, this content will no longer appear in the library view so that there is better expectation of what is supported by the player.

24. Resume from sleep

Customers are used to resuming a CD or DVD after an interruption. With customers choosing new low-cost, smaller form-factor, machines without optical drives, an increasingly popular scenario is to have content played directly from the hard drive. In Beta, it was not possible to resume playback on such content after a laptop goes to sleep. Customers assume the experience should match that of physical media so we fixed the experience to meet this expectation.

25. Quieting Windows Media Player sync relationships

When Media Player is open and a portable media player or a USB drive is inserted, we trigger a dialog to determine whether a sync relationship should be created with the new device. Our original goal was to be proactive and help customers make a decision in context, but we received comments that this experience is jarring. As a result, we will no longer interrupt when the player is running. This is consistent with our “customer in control” goal of Windows 7 and we trust people can manually configure this should they wish to.

26. Easier access to advanced settings

What enthusiast doesn’t want to tweak her player settings? This was echoed by several comments so we’ve made it easier to access and adjust settings. The equalizer, play speed, SRS WOW and other options are now surfaced via the Now Playing context menu under Enhancements.

27. Jump List improvement

Media Player’s Jump List provides quick access to the content customers consume. The list becomes even more powerful and complete in the RC now that we also include items launched from Explorer.

Device Stage

28. Enriching the Device Stage ecosystem

Customers have been so positive about the new Device Stage experience, one of the biggest pieces of feedback we got was “Why aren’t even more of my devices supported?” We’ve taken that feedback to heart and then took the feedback to our IHV and OEM partners to get their support for more devices. Our hardware partners in turn asked us to make it easier to integrate with the Device Stage and we worked with them on improvements. Although Windows already supports tens of thousands of devices, customer feedback on the Beta introduces even more device support in RC via the new Device Stage experience.

Sound UX

29. Improving the headphone experience

Customers informed us that sometimes their audio streams did not properly move from the default speakers to their headphones. The fix required an update to the algorithm we use to detect new devices. In RC the transition works more reliably.

30. Increased audio reliability

In some cases people reported not having any audio device after installing Beta. The problem is that some audio hardware does not work out of the box with our inbox audio class driver. Amazingly there are over 26,000 custom audio drivers and while many are on Windows Update, many are still not. The Release Candidate tightens the Windows Logo test to better ensure clean install delivers baseline functionality for speakers and microphones. Furthermore, we will continue to populate Windows Update with frequently needed drivers.

Windows Explorer and Libraries

31. Improved header

It is great to see customers realize the convenience and power of libraries. Having files aggregated into one convenient view, without worrying where they are all physically located, simplifies many scenarios. The library header in Beta showed only a static string that reflected how many locations were represented as part of the library. We heard feedback that this wasn’t very clear and more importantly, customers preferred to have more information so that they could be better orientated themselves. The RC will introduce a new header that updates to reveal the subfolder as one browses a library. Furthermore, the “Arrange by” views are better expose in the upper right, in proximity of the other view and search controls.

32. Reduced confusion with drag/drop

The Release Candidate will remove the ability to drag/drop a folder into the Libraries node in the Explorer navigation pane. We know some liked this functionality to create a new library, but it also presented some serious design issues. For example, some were surprised to find a new library was created when their intent was to simply copy the folder. More seriously though, there were circumstances where people then deleted the original folder thinking it was already copied. Data loss is a grave concern of ours and we don’t want customers to suffer from such a mistake. Don’t worry though—one can still easily create a new library using the “New Library” or “Include in Library” commands in the Explorer command bar.

33. Reviving familiar entry points

Mando writes, “In Win7 the Win+E shortcut opens an explorer window but the path is “Libraries” instead (which isn’t where I want to go most of the time). Is there a way to configure the target folder of “Win+E” or is there an alternate shortcut that will get me to the “Computer” path like it did in Vista?” RC reverts the behavior and now the shortcut will launch the “Computer” Explorer. Also, we changed the link in Start Menu -> Username to match the Vista behavior.

34. FAT32 support

Local FAT32 hard disk drives were not support in libraries for Beta. RC libraries will now support non-removable FAT32 and NTFS hard disk drives thanks to the feedback we received.

35. Arrangement view enhancements

It’s been great to see people’s reaction to the arrangement views in libraries. Being able to browse using metadata certainly makes quick work of finding files. We’ve received many requests to further enhance the arrangement views in a variety of ways and we’ve made a number of changes in response to them. For starters, RC makes it easier to switch arrangement views—one can now do so directly from the view context menu, which is the familiar home of switching the view mode, sorting, and grouping. Second, the specific arrangement views themselves have been enhanced for RC. The “Month” and “Day” views in the Pictures library now group together both the pictures and videos taken on the same date, whereas previously the videos were split out into a separate group. The “Artist” and “Genre” views in the Music library now show the thumbnails for up to three unique albums per artist or genre instead of typically just one in Beta. The Videos library now features a Length view that lets customers split out the shorter clips from longer movies in their video collection. Finally, we’ve made it so that changing the grouping of the Folder view in a library is now remembered just like other arrangement view customization. People who prefer to see their files grouped a particular way no longer have to reset the grouping each time.

Performance

36. Improving performance through data

Feedback comes to us in many different forms. Typically it consists of comments customers share. However, some of the most valuable information actually comes to us automatically when people just use Windows. PerfTrack, for example, is a telemetry system that provides us with invaluable real-world performance data on over 500 different Windows scenarios. The exciting aspect of PerfTrack is that it represents what people are really experiencing “out in the wild”. Performance is a very important to both the engineering team as well as to our customers and we strive to continuously improve this area. The topic has been discussed in several posts on this blog.

Let’s look at just one example of a Windows scenario that was improved with the help of PerfTrack. The two graphs below show the performance of opening the Start Menu for both Beta and for a more recent version of Windows 7. Some caveats first—the sample sizes are different (after all Beta did go to a far wider audience) and these numbers shouldn’t be taken too literally since they really do just represent a snapshot. The different colors denote performance against the “interaction class”—the acceptable experience range defined by each feature team. In this case we want the Start Menu to appear within 50ms to 100ms. A trace capturing tool running on each machine lets us investigate and fix what may be impacting performance. The charts shows in Beta 85% of interactions were within the acceptable range (i.e. green or yellow, but not red). After examining the traces and making some optimizations, we find 92% of interactions are this range for a more recent build.

Fig 3.

Start Menu Open Times for Windows 7 Build 7000 (Beta)

Fig 4.

Start Menu Open Times for Windows 7 Build 7033

As is evident from this sample of changes, we’ve been very busy improving Windows 7 based upon what our customers are telling us in many forums.

- Chaitanya Sareen

Feedback and Engineering Windows 7

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

Just about every email we receive and every comment we get comes with feedback—something to change, something to do more of, something to do less of, and so on. As we’ve talked about in this blog, acting on each one in an affirmative manner is easier said than done. What we can say for certain, is that we are listening to each and every comment, blog post, news story, MS Connect report, Send Feedback item, and of course all the data and telemetry. This post kicks off the discussion of changes made to the product with an overview of the feedback process. We'll get into specific changes shortly and we'll continue to return to the theme of changes in the Release Candidate (RC) over the next weeks. Yesterday on the IE Blog, you saw that we'll be updating IE 8 on Windows 7, and there we also talked about the feedback process in general.

Feedback about Windows 7 of course starts before we've written any code, and by the time we've got running code thousands of people outside of Microsoft have provided input and influenced the feature set and design of Windows 7. As we've seen, the input from even a small set of customers can often represent a wide variety of choices--often in alignment, but just as often in opposition. As we're developing the features for Windows 7 we work closely with PC makers, enterprise customers, and all types of customers across small business, education, enthusiasts, product reviewers and industry "thought leaders", and so on. We shape the overall "blueprint" of the release based on this wide variety of input. As we have design prototypes or code running, we have much more targeted and specific feedback by using tools such as usability tests, concept tests, benchmark studies, and other techniques to validate the implementation of this blueprint. Our goal with this level of feedback is for it to be representative of the broad set of Windows customers, even if we don't have a 1:1 interaction with each and every customer. Hopefully this post will offer some insights into this process overall--the tools and techniques, and the scope of feedback.

In the first few weeks of the Windows 7 beta we had over one million people install and use Windows 7. That's an astounding number for any beta test and while we know it has been fun for many folks, it has been a lot of work for us--but work that helps to raise the quality of Windows 7. When you use the beta you are automatically enrolled in our Customer Experience Improvement Program (anonymous feedback and telemetry, which is voluntary and opt-in in the RTM release). Just by using Windows 7 as a beta tester you are helping to improve the product--you are providing feedback that we are acting on in a systematic manner. Here is a sense of the scale of feedback we are talking about:

During a peak week in January we were receiving one Send Feedback report every 15 seconds for an entire week, and to date we’ve received well over 500,000 of these reports. That averages to over 500 reports for each and every developer to look through! And we're only through 6 weeks of using the Windows 7 beta, even though for many Windows 7 already seems like an old friend.
To date, with the wide usage of the Windows 7 Beta we have received a hundreds of Connect (the MSDN/Technet enrolled beta customers) bug reports and have fixes in the pipeline for the highest percentage of those reported bugs than in any previous Windows development cycle.
To date, we have fixes in the pipeline for nearly 2,000 bugs in Windows code (not in third party drivers or applications) that caused crashes or hangs. While many Beta customers have said they are very happy with the quality of Windows 7, we are working to make it even better by making sure we are fixing the issues experienced by such broad and significant usage.
To date, we have recorded over 10,000,000 device installations and over 75% of these were able to use drivers provided in box (that is no download necessary). The remaining devices were almost all served by downloading drivers from Windows Update and by direct links to the manufacturer's web site. We've recorded the usage of over 2.8M unique plug-and-play device identifiers.
On a personal note, I've received and answered almost 2,000 email messages from folks all around the world, just since this blog started in August. I really appreciate the discussion we're having and am doing my best to keep up with all the mail.

We have a variety of tools we draw on to help inform the decision making process. A key element that we have focused on quite a bit in Windows 7 is the role of data in making decisions. Everything we do is a judgment call as ultimately product development is about deciding what to get done from an infinite set of possibilities, but the role of data is essential and is something that has become far more routine and critical. It is important to be super clear—data is not a substitute for good judgment or an excuse to make a decision one way or another, but it most definitely informs the decision. This is especially true in an era where the data is not only a survey or focus group, but often includes a “sampling” of millions of people using Windows over the course of an extended time period.

A quick story from years ago working on Office, many years ago before the development of telemetry and the internet deciding what features to put in a release of Office could really be best described as a battle. The battle took place in conference rooms where people would basically debate until one or more parties gave up from fatigue (mental or otherwise)—essentially adrenaline-based product development. The last person standing, the one with the most endurance, or the one who pulled an all-nighter to write the code pretty much determined how features ended up or what features ended up in a product. Sort of like turning feature design over to a Survivor-like process. I’m sure many of you are familiar with this sort of process. The challenges with this approach are numerous, but inevitably features do not hold together well (in terms of scenarios or architecture), the product lacks coherency, and most importantly unless you happen to have a good match between the “winner” and the target customers, features will often miss the mark.

In the early 1990’s we started instrumenting Word and learning about how people actually used the software (this was before the internet so this was a special version of the product we solicited volunteers to run and then we would collect the data via lots of floppies). We would compile data and learn about which features people used and how much people used them. We learned things such as how much more people used tables than we thought, but for things very different than tables. We learned that a very significant amount of time the first suggestion in the spelling dictionary was the right correction (hence autocorrect). We learned that no one ever read the tip of the day (“Don’t run with scissors”). This data enabled us to make real decisions about what to fix, the impact of changes, and then when looked at the goals (the resulting documents) what direction to take word processing.

Fast forward to the development of Windows 7 and we’re focused on using data to help inform decisions we make. This data takes many forms and helps in many ways. I know a lot of folks have questions about the data – is it representative, how does it help fix things people should be using but don’t, what about doing new things, and so on. Data is an important element of making decisions, but not a substitute for clear product goals, meaningful customer engagement, and working across the ecosystem to bring Windows 7 to customers.

Let’s talk a bit about “bugs”. Up front it is worth making sure we’re on the same page when we use the much overloaded term bug. For us a bug is any time the software does something that someone one wasn’t expecting it to do. A bug can be a cosmetic issue, a consistency issue, a crash, a hang, a failure to succeed, a confusing user experience, a compatibility issue, a missing feature, or any one of dozens of different ways that the software can behave in a way that isn’t expected. A bug for us is not an emotional term, but just shorthand for an entry in our database representing feedback on the product. Bugs can be reported by a human or by the various forms of telemetry built into Windows 7. This broad definition allows us to track and catalog everything experienced in the product and do so in a uniform manner.

Briefly, it is worth considering a few types of data that help to inform decisions as some examples.

Customer Experience Improvement Program. The CEIP covers the full set of data collected on your PC that is provided to Microsoft in an anonymous, private, and opt-in manner. During the beta, as we state, this is defaulted on. In the retail product of course this is optional. During the course of the beta we are seeing the data about usage of new features, where people are customizing the product, what commands are being used, and in general how is Windows 7 being used. You’ve seen us talk about some of this data from Windows Vista that informed the features of Windows 7, such as the display resolution being used or the number of accounts on a machine. There are many data points measured across the product. In fact, an important part of the development cycle is to make sure that new features are well instrumented to inform us of usage during beta and down the road.
Telemetry. While related to CEIP in the programmatic sense, we look at telemetry in a slightly different manner and you’ve seen this at work in how we talk about system performance or about the diversity of devices such as our discussion of high DPI support. Throughout the course of the beta we are able to see how boot time evolves or which devices are successfully installed or not. Important elements of telemetry that inform which bugs we fix are how frequently we are seeing a crash or a hang. We can identify software causing a higher level of issues and the right team or ISV can know to work on the issue. The telemetry really helps us focus on the benefit of the change—fixing a bug that represents thousands of customers, a widely used device, or broadly used third party software has a much bigger impact than a bug that only a few people, lower volume device, or less used software product might address. With this data we can more precisely evaluate benefit of changes.
Scenario based tests. During the course of developing a feature we can take our designs and prototypes (code, paper, or bitmaps) and create a structured study of how customers would interpret and value a feature/scenario. For example, early in the planning of Windows 7 we created a full working prototype of the taskbar enhancements. With this prototype we can study different types of customers (skill levels, familiarity with different versions of Windows, competitive product customers, IT pro or end-user) and how they react to well-defined series of “tasks”. This allows a much more detailed study of the feature, as one example. As with all tests, these are not a substitute for good judgment in broader context but a key element to inform decisions.
Benchmarking studies. As we transitioned to the pre-beta we started to have real code across the whole product so we began validation of Windows 7 with real code in real world scenarios. We call these studies benchmarking because often we are benchmarking the new product against a baseline of the previous version(s) of Windows. We might do a study where we see how long it takes to share a printer in the home and then compare that time to complete/success rate with a Windows 7 test using HomeGroup. We might compare setting up a wireless network with and without WPA. We have many of these types of benchmarks and work to make sure that we understand both the progress we’ve made and where we might need to improve documentation, tutorials, or other forms of assistance.

This type of feedback all represents structured feedback in that the data is collected based on a systematic study and usually has a hypothesis associated with it. We also have the unstructured feedback which represents the vast array of bug reports, comments, questions, and points of view expressed in blogs, newsgroups, and the Send Feedback button—these are unstructured because these are not collected in a systematic manner, but aggressively collected by any and all means. A special form of this input is the bug reporting done through the Connect program—the technical beta—which represents bug reports, feature suggestions, and comments from this set of participants.

The Windows 7 beta represents a new level of feedback in this regard in terms of the overall volume as we talked about above. If you go back and consider the size of the development team and the time it would take to just read the reports you can imagine just digesting (categorizing, understanding, flagging) issues let alone responding to them is a massive undertaking (about 40 Send Feedback reports per developer during that one week, though as you can imagine they are not evenly distributed across teams).

The challenge of how to incorporate all the feedback at this stage in the cycle is significant. It is emotional for us at Microsoft and the source of both considerable pride and also some consternation. We often say “no matter what happens, someone always said it would.” By that we mean, on any given issue you can be assured that all sides will be represented by passionate and informed views of how to resolve it, often in direct opposition to each other plus every view in the middle. That means for the vast majority of issues there is no right or wrong in an absolute sense, only a good decision within the context of a given situation. We see this quite a bit in the debates about how features should work—multiple solutions proposed and debate takes place in comments on a blog (people even do whole blogs about how things should work). But ultimately on the Windows development team we have to make a call as we’re seeing a lot of people are looking forward to us finishing Windows 7, which means we need to stop changing the product and ship it. We might not always make the right call and we’ll admit if we don’t make the right call, even if we find changing the behavior is not possible.

Making these decisions is the job of program management (PM). PMs don’t lock themselves in their offices and issue opinions, but more realistically they gather all the facts, data, points of view, and work to synthesize the best approach for a given situation. Program management’s role is making sure all the voices are heard, including beta testers, development, testing, sales, marketing, design, customer support, other teams, ISVs, IHVs, and on and on. Their role is to synthesize and represent these points of view systematically.

There are many factors that go into understanding a given choice:

What is it supposed to do? At the highest level, the first question to ask is about how is something supposed to work. Sometimes things are totally broken. We see this with many many beta issues around crashes and hangs for example. But there’s not a lot of debate over these since if it crashes in any meaningful frequency (based on telemetry) it should be fixed. We know if it crashes for you then it is a “must fix” but we are looking across the whole base of customers and understanding the frequency of a crash and also whether the code is in Windows, a driver from a hardware maker, or software from a third party—each of those has a different potential resolution path to consider. When it comes to user interaction there’s two elements of “supposed to do”. First, there’s the overall scenario goal and then there’s the feedback of how different people with different experiences (opinions) of what it should do. As an example, when we talked about HomeGroup and the password/passphrase there was a bunch of feedback over how this should work (an area we will be tweaking based in part on this feedback). We of course have specifications and prototypes, but we also have a fluidity to our development process such that we do not have 100% fidelity before we have the product working (akin to architectural blueprints that leave tons of decisions to be made by the general contractor or decided while construction is taking place). There are also always areas in the beta where the feature is complete but we are already on a path to “polish” the experience.
How big is the benefit? So say we decide something is supposed to behave differently. Will it be twice as good? Will it be 5% better? Will anyone notice? This is always a great discussion point. Of course people who advocate for a change always are convinced that the change will prevent the feature from being “brain dead” or “if you don’t change this then the feature is dead”. We see this a lot with areas around “discoverability” for example—people want to put something front and center as a way of fixing something. We also see many suggestions along the lines of “make it configurable”. Both of these have benefits in the near term of course, but both also add complexity down the road in terms of configurations, legacy user interface, and so on. Often it is important to look at the benefit in a broader context such as how frequently something will be executed by a given person or what percentage of customers will ultimately take advantage of the improvement. It is not uncommon internally to see folks extrapolate instantly to “everyone does this”!
How big is the change? Early in the product cycle we are making lots of changes to the code—adding new code, rearchitecting, and moving things around a lot. We don’t do so willy nilly of course but the reality is that early in the cycle there is time for us to manage through the process of substantially changed code and the associated regressions that will happen. We write specifications and have clear views of features (scenario plans, prototypes, and so on) because we know that as the project progresses the cost of making big changes of course goes up. The cost increases because there is less time, but also because big change late in the cycle to a large system is not prudent engineering. So as we consider changes we also have to consider how big a change is in order to understand the impact across the system. Sometimes change can be big in terms of lines of code, and lots of code is always risky. But more often the change is not the number of lines, but the number of places the code is connected—so while the change sounds like a simple “if” statement it is often more complex than that. Over the years, many have talked about componentization and other systems engineering ways to reduce the impact of change and of course Windows is very much a layered system. The reality is that even in a well layered system, it is unlikely one can change things at the bottom and expect no assumptions of behavior to carry forth through subsequent upper layers. This “defensiveness” is an attitude we have consistently throughout our development process because of the responsibility we feel to maintain compatibility, stability, performance, and reliability.
How costly is the change relative to the benefit? Change means something is different. So any time we change something it means people need to react. Often we are deliberate in change and we see this in user interface, driver models, and so on. When new are deliberate people can prepare and we can provide tools to help with a transition. We’ve seen a lot of comments about new features that react to the cost of change. Many times this commentary is independent of the benefit and just focuses on the change itself. This type of dialog makes it clear that change itself is not always good. With many bug reports we hear “this has been in Windows for 3 versions and must be fixed in Windows 7”. Over many releases of Windows we have learned that behaviors in the system, particularly in APIs, message order and semantics, or interfaces might not be ideal, but changing them introduces more complexity, incompatibilities, and problems for people than the benefit of the change. Some view these decisions as “holding us back” but more often than not it would be a break from the past one day only to create a new past to break from the next. The existing behavior, whether it is an API or a user interface, defines a contract we have and part of building a release is making sure we have a well understood cost/benefit view, knowing that as with any aspect of the system different people will have different views of this “equation”.
In the context of the whole release, how important is this issue? There is the reality that all decisions need to be made in the context of the broader goals of the release. Each release stands for a set of core scenarios and principles that define the release. By definition it means that each release some things will change more than others and some things might not change at all. Or said another way, some parts of the system will be actively worked on towards a set of goals while we keep other parts of the system more or less “stable” release over release. It means that things you might want to see changed might not change, just because that is an area of the product we’re not mucking with during Windows 7. As we’ve talked about, for Windows 7 we put a lot of work into various elements of system performance. Aside from the obvious scenario planning and measurement, we also took very seriously areas of the system that needed to change to move us forward. Likewise, areas of the system where the performance gain would not be significant enough to warrant change do not change that much. We carry this forward through the whole cycle as we receive data and telemetry.
How does the change impact security, reliability, performance, compatibility, localizability, accessibility, programmability, manageability, customizability, and so on? The list of “abilities” that it takes to deliver windows is rather significant. Members of our development team receive ongoing training and information on delivering on all of these abilities so we do a great job across the product. In addition, for many of these abilities we have members of the team dedicated full time to delivering on them and making sure across the product we do a good job. Balancing any change or input against all of these abilities is itself a significant undertaking and an important part of the research. Often we see input that is very focused on one ability which goes counter to another—it is easy to make a change to provide customization for example, but then this change must also be customizable for administrators, end-users, and PC makers. Such complexity is inherent in the very different scenarios for usage, deployment, and management of PCs. The biggest area folks see us considering this type of impact is when it comes to changing behavior that “has been in the product forever”. Sometimes an arbitrary decision made a while back is best left as is in order to maintain the characteristics of the subsystem. We know that replacing one old choice with a new implementation just resets the clock on things that folks would like to see be different—because needs change, perspectives change, and people change.

These are just a few of the factors that go into considering a product change. As you can see, this is not something that we take lightly and a lot goes into each and every change. We consider all the inputs we have and consider all the data we can gather. In some ways it is easy to freeze thinking about the decisions we must make to release Windows 7—if you think too hard about a decision because you might start to worry about a billion people relying on something and it gets very tricky. So we use data to keep ourselves objective and to keep the decision process informed and repeatable. We are always humbled by the responsibility we have.

While writing this post, I received a “bug report” email with the explicit statement “is Microsoft going to side step this issue despite the magnitude of the problem” along with the inevitable “Microsoft never listens to feedback”. Receiving mail like this is tough—we’re in the doghouse before we even start. The sender has decided that this report is symbolic of Microsoft’s inability or lack of desire to incorporate critical feedback and to fix must fix bugs during development. Microsoft is too focused on shipping to do the right thing. I feel like I’m stuck because the only answer being looked for is the fix and anything less is a problem or further proof of our failure. And in the back of my mind is the reality that this is just one person with one issue I just happen to be talking to in email. There over a couple of million people using the beta and if each one, or for that matter just one out of 10, have some unique change, bug fix, or must do work item we would have literally years of work just to make our way through that list. And if you think about the numbers and consider that we might easily get 1,000,000 submitted new “work items” for a product cycle, even if we do 100,000 of them it means we have 900,000 folks who feel we don’t listen compared to the 100,000 folks who feel listened to. Perhaps that puts the challenge in context.

With this post we tried to look at some of the ways we think about the feedback we’re getting and how we evaluate feedback in the course of developing Windows 7. No area is more complex than balancing the needs (and desires) of such a large and diverse population—end-users, developers, IT professionals, hardware makers, PC manufacturers, silicon partners, software vendors, PC enthusiasts, sysadmins, and so on. A key reason we augment our approach with data and studies that deliberately select for representative groups of “users” is that it is important to avoid “tyranny of the majority” or “rule by the crowd”. In a sense, the lesson we learned from adrenaline -based development was that being systematic, representative, and as scientific as possible in the use of data.

The work of acting on feedback responsibly and managing the development of Windows through all phases of the process is something we are very sincere about. Internally we’ve talked a lot about being a learning organization and how we’re always learning how to do a better job, improve the work we do, and in the process work to make Windows even better. We take this approach as individuals and how we view building Windows. We know we will continue to have tough choices to make as everyone who builds products understands and what you have is our commitment to continue to use all the tools available to make sure we are building the best Windows 7 we can build.

--Steven