Engineering Windows 7

Welcome to our blog dedicated to the engineering of Microsoft Windows 7

  • Engineering Windows 7

    Welcome to Engineering Windows 7

    • 347 Comments

    Welcome to our first post on a new blog from Microsoft—the Engineering Windows 7 blog, or E7 for short. E7 is hosted by the two senior engineering managers for the Windows 7 product, Jon DeVaan and Steven Sinofsky. Jon and Steven, along with members of the engineering team will post, comment, and participate in this blog.

    Beginning with this post together we are going to start looking forward towards the “Windows 7” project. We know there are tons of questions about the specifics of the project and strong desire to know what’s in store for the next major release of Windows. Believe us, we are just as excited to start talking about the release. Over the past 18 months since Windows Vista’s broad availability, the team has been hard at work creating the next Windows product.

    The audience of enthusiasts, bloggers, and those that are the most passionate about Windows represent the folks we are dedicating this blog to. With this blog we’re opening up a two-way discussion about how we are making Windows 7. Windows has all the challenges of every large scale software project—picking features, designing them, developing them, and delivering them with high quality. Windows has an added challenge of doing so for an extraordinarily diverse set of customers. As a team and as individuals on the team we continue to be humbled by this responsibility.

    We strongly believe that success for Windows 7 includes an open and honest, and two-way, discussion about how we balance all of these interests and deliver software on the scale of Windows. We promise and will deliver such a dialog with this blog.

    Planning a product like Windows involves systematic learning from customers of all types. In terms of planning the release we’ve been working with a wide variety of customers and partners (PC makers, hardware developers, enterprise customers, developers, and more) since the start of the project. We also continue our broad consumer learning through telemetry (Customer Experience Improvement Program), usability studies, and more. One area this blog will soon explore is all the different ways we learn from customers and the marketplace that inform the release.

    We have two significant events for developers and the overall ecosystem around Windows this fall. The Professional Developers Conference (PDC) on October 27 and the Windows Hardware Engineering Conference (WinHEC) the following week both represent the first venues where we will provide in-depth technical information about Windows 7. This blog will provide context over the next 2+ months with regular posts about the behind the scenes development of the release and continue through the release of the product.

    In leading up to this blog we have seen a lot of discussion in blogs about what Microsoft might be trying to accomplish by maintaining a little bit more control over the communication around Windows 7 (some might say that this is a significant understatement). We, as a team, definitely learned some lessons about “disclosure” and how we can all too easily get ahead of ourselves in talking about features before our understanding of them is solid. Our intent with Windows 7 and the pre-release communication is to make sure that we have a reasonable degree of confidence in what we talk about when we do talk. Again, top of mind for us is the responsibility we feel to make sure we are not stressing priorities, churning resource allocations, or causing strategic confusion among the tens of thousands of partners and customers who care deeply and have much invested in the evolution of Windows.

    Related to disclosure is the idea of how we make sure not to set expectations around the release that end up disappointing you—features that don’t make it, claims that don’t stick, or support we don’t provide. Starting from the first days of developing Windows 7, we have committed as a team to “promise and deliver”. That’s our goal—share with you what we’re going to get done, why we’re doing it, and deliver it with high quality and on time.

    We’re excited about this blog. As active bloggers on Microsoft’s intranet we are both looking forward to turning our attention and blogging energies towards the community outside Microsoft. We know the ins and outs of blogging and expect to have fun, provide great information, and also make a few mistakes. We know we’ll misspeak or what we say will be heard differently than we intended. We’re not worried. All we ask is that we have a dialog based on mutual respect and the shared goal of making a great release of Windows 7.

    Our intent is to post “regularly”. We’ll watch the comments and we will definitely participate both in comments and potentially in follow-up posts as required. We will make sure that members of the Windows 7 development team represent themselves as such as well. While we want to keep the dialog out in the open, please feel free to use email to steven.sinofsky@microsoft.com should you wish to. In particular, email is a good way to suggest topics we might have a chance to discuss on the blog.

    With that, we conclude our welcome post and ask you to stay tuned and join us in this dialog about the engineering of Windows 7.

    Steven and Jon

    Please note the availability of this blog in several other languages via the links on the nav pane. These posts are also created by members of our development team and we welcome dialog on these sites as well. We will continue to expand the list in other languages based on feedback.

     

  • Engineering Windows 7

    Some Changes Since Beta for the RC

    • 304 Comments

    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)

    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

    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)

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

    Fig 4.

    Start Menu Open Times for Windows 7 Build 7033

    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

  • Engineering Windows 7

    Windows 7 Battery Notification Messages

    • 303 Comments

    Over the past week we have seen a little bit of blogosphere activity regarding Windows 7 and batteries, specifically the new Windows 7 message “Considering replacing your battery”. Since this is related to the engineering of Windows 7 we’re going to use this blog to provide an update to people. As we have talked about many times, we have a relentless focus on the quality of Windows 7 and we take seriously any reports we receive that indicate a potential problem that could result in a significant failure of the OS. In a previous post we talked about the steps we take when we receive a bug report, in particular when we start to see several reports that appear to be the same. For the past week or so we have been diligently working through these steps and more to see if there is anything in Windows 7 we need to address regarding this issue. At this time we have no reason to believe there is any issue related to Windows 7 in this context.

    Several press articles this past week have drawn attention to blog and forum postings by users claiming Windows 7 is warning them to “consider replacing your battery” in systems which appeared to be operating satisfactorily before upgrading to Windows 7.  These articles described posts in the support forums indicating that Windows 7 is not just warning users of failing batteries – as we designed Windows 7 to do this – but also implying Windows 7 is falsely reporting this situation or even worse, causing these batteries to fail.  To the very best of the collective ecosystem knowledge, Windows 7 is correctly warning batteries that are in fact failing and Windows 7 is neither incorrectly reporting on battery status nor in any way whatsoever causing batteries to reach this state. In every case we have been able to identify the battery being reported on was in fact in need of recommended replacement.

    Using all the tools at our disposal including contacting customers reporting this issue on forums, customer service communications, partnerships with our PC makers, and of course the telemetry in Windows 7, we have been monitoring reports and discussions regarding this new feature, trying to separate reports of the designed behavior from those that might indicate an issue with Windows 7.  In the latter cases we are trying to understand the scope of applicability and obtain hardware on which to reproduce a faulty behavior.   To date all such steps indicate that we do have customers seeing reports of battery health issues and in all cases we have investigated Windows 7 has simply accurately detected a failing battery.   Before I go into our status on this particular issue, we should review the details behind this new feature.

    One of the most obvious components of PC battery life (the runtime you get on battery power) is the battery itself. PC batteries inherently degrade in their ability to hold a charge and provide power (as is the case for all rechargeable batteries). The cause of this is complex and includes irreversible changes in battery chemistry, and increased internal resistance among other things and those in turn are dependent on the design and manufacturing of the battery. This degradation translates into less battery life for the user over the life of the battery in the PC.  Ultimately, batteries must be replaced to restore an acceptable battery life.  A quick check of mainstream laptops will show that batteries usually have a warranty of 12 months, which is about the length of time when statistically we expect to see noticeable degradation (meaning that you start to notice the need to charge more frequently). Those of us that have owned the same laptop (or mobile phone, or music player, or anything else with rechargeable batteries) for a couple of years and taken it through regular charge cycles have no doubt “felt” the decline in battery life though we might have attributed to any number of factors since we did not have any information available to us otherwise.

    Windows 7 makes use of a feature of modern laptop batteries which have circuitry and  firmware that can report to Windows the overall health of the battery. This is reported in absolute terms as Watt-hours (W-hr) power capacity. Windows 7 then does a simple calculation to determine a percentage of degradation from the original design capacity. In Windows 7 we set a threshold of 60% degradation (that is the battery is performing at 40% of its designed capacity) and in reading this Windows 7 reports the status to you.  At this point, for example, a battery that originally delivered 5 hours of charge now delivers, on average, approximately 2 hours of charge.  The Windows 7 the notification is a battery meter icon and notification with a message “Consider replacing your battery”.  This notification is new to Windows 7 and not available in Windows Vista or Windows XP.

    Consider replacing your battery - Windows 7 notification

    PC batteries expose information about battery capacity and health through the system firmware (or BIOS).  There is a detailed specification for the firmware interface (ACPI), but at the most basic level, the hardware platform and firmware provide a number of read-only fields that describe the battery and its status.  The firmware provides information on the battery including manufacturer, serial number, design capacity and last full charge capacity.  The last two pieces of information—design capacity and last full charge capacity—are the information Windows 7 uses to determine how much the battery has naturally degraded.   This information is read-only and there is no way for Windows 7 or any other OS to write, set or configure battery status information.  In fact all of the battery actions of charging and discharging are completely controlled by the battery hardware.  Windows only reports the battery information it reads from the system firmware. Some reports erroneously claimed Windows was modifying this information, which is definitely not possible.

    As mentioned, every single indication we have regarding the reports we’ve seen are simply Windows 7 reporting the state of the battery using this new feature and we’re simply seeing batteries that are not performing above the designated threshold. Below we’ll talk about the data we have to support this point of view. It should stand to reason that some customers would be surprised to see this warning after upgrading a PC that was previously operating fine. Essentially the battery was degrading but it was not evident to the customer until Windows 7 made this information available. We recognize that this has the appearance of Windows 7 “causing” the change in performance, but in reality all Windows 7 did was report what was already the case.

    The following data points contributed to our understanding of the reports we are seeing. Please keep in mind that all the telemetry we see is opt-in, anonymous, and respects our privacy policy.

    • We have seen no reproducible reports of this notification on new hardware or newly purchased PCs. While we’ve seen the reports of new PCs receiving this notification, in all cases we have established that the battery was in a degraded state.
    • Our OEM partners have utilized their telemetry (call center, support forums, etc.) and have let us know that they are seeing no activity beyond what they expect. It is worth noting that PC manufacturers work through battery issues with customers and have a clear view of what is to be expected both in general and with respect to specific models, timelines, and batteries.
    • We’ve gone through all the major online support and self-help forums and when appropriate have worked to follow up with any reports of this notification being presented in error. Through this we have identified no reproducible cases where the battery or PC was new and have only learned of batteries that were degraded in capacity.
    • In our telemetry from RTM code customers, only a very small percentage of users are receiving the “Consider replacing your battery” notification, and as expected, we are seeing systems older than ~1.5 years.  We’re seeing relatively fewer notifications compared to pre-release software as the average age of the system decreases.
    • Microsoft has received 12 customer service incidents in addition to pulling 8 additional incidents from various forums. To date (for a total of 20 incidents), none of these have shown anything other than degraded batteries. 
    • Microsoft has been using the technet community moderators to assist in further contacting customers reporting on this notification and we’ve assigned additional customer service personnel to be ready. However, of the 30 or so contacts we have received we have not learned of any new facts or conditions with respect to this notice.
    • During pre-release testing of Windows 7 we saw almost precisely this same experience with customers in terms of the display of the notification. In fact, in looking at the hardware distribution of pre-release testing we saw an ever so slightly higher number of systems receiving this notice. This follows from the fact that a large set of customers are buying Windows 7 with new PCs or using the upgrade provided with a recent Windows Vista PC.
    • When looking at the telemetry reports for the machines that have reported displaying this notification we have seen nothing in additional reliability data that indicates any other system anomalies.
    • While the information regarding battery status is provided read-only to the operating system through ACPI, we performed a thorough code-review and verified that there exists no code that is capable of modifying battery status information.

    This data would confirm our point of view that we are seeing nothing more than the normal course of battery degradation over time. The transparency provided in this new Windows 7 feature produced a notice that previously was not available to customers and did so shortly after upgrade. This is the root cause of the urgency with which we’ve seen postings, but does not change the reality of the condition of the battery. We have no confirmed cases of new machines with the as-purchased batteries.

    As we always say with regards to any reports on the quality of Windows 7, we are going to continue to be diligent and use all the tools at our disposal to get to the bottom of a report that has the potential to require a code change we would distribute to customers. We are as certain as we can be that we have addressed the root cause and concerns of this report, but we will continue to monitor the situation. In particular, we will continue to have focused communication with our OEM partners as they monitor their customers and PCs over time.

    Finally, if you believe you are receiving this error and your battery is new or believed to be in great shape we would encourage you to report this to us or your original PC maker. You are welcome to send me mail through the contact form on this page, use the TechNet forum, the Microsoft Answers forum, or visit support.microsoft.com where you can get additional information about how to contact Microsoft assisted support in your region.

    Thanks,

    Steven

  • Engineering Windows 7

    Delivering a quality upgrade experience

    • 294 Comments

    This is a little bit of a tricky post to write because we’re going to be asking everyone using our Windows 7 Beta to help us out, but doing so is going to take a little time and require a bit of a commitment to helping test the next milestone. This has been a remarkably valuable and beneficial testing cycle for Windows as we have had a tremendous amount of very rigorous testing and usage. We’ve had millions of people install and use the Beta since January and as we’ve talked about, the feedback and telemetry have been of tremendous value as we finalize the product. The effort of Beta testers has contributed immensely to our ability to deliver a high-quality product to hundreds of millions of customers. We continue to follow the plan we have previously outlined and this post is no announcement of any news or change in plans. Since we know many people are running the Beta we want to provide a heads up regarding the behavior of the Release Candidate (RC) as it pertains to upgrades. Of course we are working hard on the RC and following the schedule we have set out for ourselves.

    A big part of the beta process is making sure we get as much “real world” coverage of scenarios and experiences as possible and monitor the telemetry of those experience overall. One of the most challenging areas to engineer is the process of upgrading one release of Windows to another. When you think about it, it is the one place where at one time we need to run a ton of code to basically “know” everything about a system before performing the upgrade. During the development of Windows 7 we routinely test hundreds of original OEM images from Windows Vista and upgrade them and then run automated tests validating the upgrade’s success. We also test thousands of applications and many thousands of devices as they too move through the upgrade process.

    Many of you installed the Windows 7 beta on a PC running Vista. We received that telemetry and acted on it accordingly. We believe we’ve continued to improve the upgrade experience throughout the release. Similarly, based on our telemetry most of you did clean installations onto new drive partitions. Through this telemetry we learned about the device ecosystem and what drivers were available or missing. We also learned about PC-specific functions that required installing a driver / application (from XP or Vista) to enable support for buttons, connectors, or other hardware components. Together we get great coverage of the setup experience.

    We’ve also learned that many of you (millions) are running Windows 7 Beta full time. You’re anxious for a refresh. You’ve installed all your applications. You’ve configured and customized the system. You would love to get the RC and quickly upgrade to it from Beta. The RC, however, is about getting breadth coverage to validate the product in real-world scenarios. As a result, we want to encourage you to revert to a Vista image and upgrade or to do a clean install, rather than upgrade the existing Beta.  We know that means reinstalling, recustomizing, reconfiguring, and so on.  That is a real pain.  The reality is that upgrading from one pre-release build to another is not a scenario we want to focus on because it is not something real-world customers will experience. During development we introduce changes in the product (under the hood) that aren’t always compatible with what we call “build-to-build” upgrade.  The supported upgrade scenario is from Windows Vista to Windows 7. Before you go jump to the comment section, we want to say we are going to provide a mechanism for you to use if you absolutely require this upgrade.  As an extended member of the development team and a participant in the Beta program that has helped us so much, we want to ask that you experience real-world setup and provide us real-world telemetry.

    If you do follow the steps below, you might run across some oddities after upgrade. We experience these internally at Microsoft occasionally but we don’t always track them down and fix them because they take time away from bugs that would not only manifest themselves during this one-time pre-release operation. From time to time we’ve noticed on a few blogs that people are using builds that we have not officially released and complained of “instabilities” after upgrade. Nearly all of these have been these build-to-build issues. We’ve seen people talk about how a messenger client stopped working, a printer or device “disappears”, or start menu shortcuts are duplicated. These are often harmless and worst case often involves reinstalling the software or device.

    We’re just trying to be deterministic and engineer the product for the real world. Speaking of the real world, many have asked about upgrading from Windows XP. There's no change here to the plan as has been discussed on many forums.  We realized at the start of this project that the “upgrade” from XP would not be an experience we think would yield the best results. There are simply too many changes in how PCs have been configured (applets, hardware support, driver model, etc.) that having all of that support carry forth to Windows 7 would not be nearly as high quality as a clean install. This is something many of you know and already practice. We do provide support for moving files and settings and will prompt at setup time, but applications will need to be reinstalled. We know that for a set of customers this tradeoff seems less than perfect, but we think the upfront time is well worth it.

    So when you try to upgrade a pre-RC build you will find that you’re not able to and setup will tell you and you can then exit gracefully. You can install as a clean installation and use the Windows Easy Transfer feature as well (run this from your current installation of course) if you wish to move your accounts, settings, files, and more. To bypass the version check, the instructions below will use a mechanism that is available for enterprise customers (so we are also testing this as well). It is not a simple command line switch. We didn’t make it multi-step on purpose but wanted to stick to using proven, documented and tested mechanisms.

    These instructions will be brief. Since everyone reading is a well-versed and experienced beta tester you know ALWAYS BACK UP YOUR MACHINE before running any OS installation and NEVER TEST AN OS ON YOUR ONLY COPY OF ANY DATA. Testing a pre-release product means just that—it is testing and it is pre-release. Even though this is a Release Candidate, we are still testing the product. We have very high confidence but even if an error happens once in 1,000,000 we want to make sure everyone is taking the precautions normal for a pre-release product.

    One other related caution is INSTALL ONLY OFFICIALLY RELEASED BUILDS FROM MICROSOFT. It will always be tempting to get the build with the “mod” already done but you really never know what else has been done to the build. There’s a thrill in getting the latest, we know, but that also comes with risks that can’t even be quantified. For the RC we will work to release a hash or some other way to validate the build, but the best way is to always download directly from Microsoft.

    Here’s what you can do to bypass the check for pre-release upgrade IF YOU REALLY REALLY NEED TO:

    1. Download the ISO as you did previously and burn the ISO to a DVD.
    2. Copy the whole image to a storage location you wish to run the upgrade from (a bootable flash drive or a directory on any partition on the machine running the pre-release build).
    3. Browse to the sources directory.
    4. Open the file cversion.ini in a text editor like Notepad.
    5. Modify the MinClient build number to a value lower than the down-level build. For example, change 7100 to 7000 (pictured below).
    6. Save the file in place with the same name.
    7. Run setup like you would normally from this modified copy of the image and the version check will be bypassed.

    clip_image002

    These same steps will be required as we transition from the RC milestone to the RTM milestone.

    Again, we know many people (including tens of thousands at Microsoft) are relying on the pre-release builds of Windows 7 for mission critical and daily work, making this step less than convenient. We’re working hard to provide the highest quality release we can and so we’d like to make sure for this final phase of testing we’re supporting the most real world scenarios possible, which incremental build to build upgrades are not. At the same time everyone on the beta has been so great we wanted to make sure we at least offered an opportunity to make your own expert and informed choice about how to handle the upgrade.

    We’re always humbled by the excitement around the releases and by the support and enthusiasm from those that choose to run our pre-releases. We’re incredibly appreciative of the time and effort you put into doing so. In return we hope we are providing you with a great release to work with at each stage of the evolution of the product. Our next stop is the RC…see you there!

    THANK YOU!

    --Windows 7 Team

    PS: At Step 1 above many of you are probably thinking, “hey why don’t you just let me mount the ISO and skip the plastic disc”. We’ve heard this feedback and we deserve the feedback. We don’t have this feature in Windows 7 and we should have. So please don’t fill the comments with this request. There are several third party tools for mounting and if you’ve got a Vista image there’s a good chance your PC came with those tools on it.

  • Engineering Windows 7

    A few more changes from Beta to RC…

    • 237 Comments

    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

    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

    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

    beta parent folder

    Fig 4.

    In RC, parent folders always remain within single click access

    RC parent folder

    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

    Baseline device stage experience

    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

    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.

  • Engineering Windows 7

    The Windows 7 Taskbar

    • 202 Comments

    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.

    Windows 1.01

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

    Windows 7 taskbar

    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.

    Windows 7 Taskbar Thumbnails

    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.

    Windows 7 Aero Peek

    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.

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

    Windows 7 Thumbnail Toolbar

    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.

    Windows 7 Notification Overflow

    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.

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

    Windows 7 Color Hot-track

    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

  • Engineering Windows 7

    UAC Feedback and Follow-Up

    • 198 Comments

    When we started the “E7” blog we were both excited and also a bit uneasy. The excitement is obvious. The unease is because at some point we knew we would mess up. We weren’t sure if we would mess up because we were blogging about a poorly designed feature or mess up because we were blogging poorly about a well-designed feature. To some it appears as though with the topic of UAC we’ve managed to do both. Our dialog is at that point where many do not feel listened to and also many feel various viewpoints are not well-informed. That’s not the dialog we set out to have and we’re going to do our best to improve.

    This post is an attempt to get both the blog right and the feature right. We don’t like where we are in terms of how folks are feeling and we don’t feel good – Windows 7 is too much fun and folks are having too much fun for us to be having the dialog we’re having. We hope this post allows us to get back to having fun!

    To start we’ll just show representative comments from the spectrum of feedback. We’ll then talk about the changes we’re making and also make sure we’re all on the same page regarding how we move forward. In terms of comments we’ve heard the following:

    @sroussey says:

    You have 95% of the people out there think you got it wrong, even if they are the ones that got it wrong. The problem is that they are the one's that buy and recommend your product. So do you give them a false sense of increased security by implementing the change (not unlike security by obscurity) and making them happy, or do you just fortify the real security boundaries?

    And @Thack says:

    Jon,

    Thanks for sharing your thoughts.  I understand your points.

    Now, I want add my voice to the call for one very simple change:

    Treat the UAC prompting level as a special case, such that ANY change to it, whether from the user or a program, generates a UAC prompt, regardless of the type of account the user has, and regardless of the current prompting level.

    That is all we are asking.  No other changes.  Leave the default level as it is, and keep UAC as it is.  We're just talking about the very specific case of CHANGES to the UAC prompting level.

    It will NOT be a big nuisance - most people only ever change the UAC level once (if at all).

    Despite your assurances, I REALLY WANT TO KNOW if anything tries to alter the UAC prompting level. 

    The fact that nobody has yet demonstrated how the putative malware can get into your machine is NO argument.  Somebody WILL get past those other boundaries eventually.

    Even if you aren't convinced by my argument, then the PR argument must be a no-brainer for Microsoft.

    PLEASE, Jon, it's just a small change that will gain a LOT of user confidence and a LOT of good PR.

    Thack

    With this feedback and a lot more we are going to deliver two changes to the Release Candidate that we’ll all see. First, the UAC control panel will run in a high integrity process, which requires elevation. That was already in the works before this discussion and doing this prevents all the mechanics around SendKeys and the like from working. Second, changing the level of the UAC will also prompt for confirmation.

    @mdaria510 says:

    Sometimes, inconsistency with your own ideals is a good thing. Make an exception, if only to put people's fears to rest.

    That sums up where we are heading. The first change was a bug fix and we actually have a couple of others similar to that—this is a beta still, even if many of us are running it full time. The second change is due directly to the feedback we’re seeing. This “inconsistency” in the model is exactly the path we’re taking. The way we‘re going to think about this that the UAC setting is something like a password, and to change your password you need to enter your old password.

    The feedback is that UAC is special, because it can be used to disable silently future warnings if that change is not elevated and so to change the UAC setting an elevation will be required.  To the points in the comments, we also don’t want to create a sense or expectation of security that is not there—you should still not download code and run it unless you trust the source. HTML, EXE, VBS, BAT, CMD and more are all code and all have the potential to alter the environment (user settings, user files) running as a standard user or an administrator. We’re focused on helping people make sure that code doesn’t get on the machine without consent and many third party tools can help more as well. We want people to be comfortable with the new UAC control and the new default setting, so we’ll make the changes outlined above as the feedback has been clear.

    While we’re discussing this we want to make sure we’re all on the same page going forward in terms of how we will evaluate the security of Windows 7. Aside from the UAC setting, the discussion of the vulnerability aspects of the Windows 7 Beta  have each started with getting code on the machine, which the mechanisms of Windows have prevented in the cases shown. We have also heard of security concerns that involve multiple steps to demonstrate a potential exploit. It is important to look at the first step—if the first step is “first get code running on the machine” then nothing after that is material, whether it is changing settings or anything else.  We will treat very seriously the ability to get code on a machine and run without consent. As Jon’s post highlighted briefly, the work in Windows 7 is about the increased protections in place to secure your PC from acquiring and running code without your consent, and of course we continue to make sure Windows code is secure from both tampering or circumventing the protections in the system.

    We want to reiterate the security of the system overall. Windows 7 is SD3+C and is designed to be more secure that Vista—that’s our priority. None of us want to have Windows 7 be perceived as being less secure than Vista in any way, because our design point is to make sure it is more secure that Windows Vista, by default.

    We said we thought we were bound to make a mistake in the process of designing and blogging about Windows 7. We want to continue the dialog and hopefully everyone recognizes that engineering, perhaps especially engineering Windows 7, is sometimes going to be a lively discussion with a broad spectrum of viewpoints expressed. We don’t want the discussion to stop being so lively or the viewpoints to stop being expressed, but we do want the chance to learn and to be honest about what we learned and hope for the same in return. This blog has almost been like building an extra product for us, and we’re having a fantastic experience. Let’s all get back to work and to the dialog about Engineering Windows 7. And of course most importantly, we will continue to hear all points of view and share our point of view and work together to deliver a Windows 7 product that we can all feel good about.

    --Jon and Steven

  • Engineering Windows 7

    User Account Control

    • 188 Comments

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

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

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

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

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

    The Why of UAC

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

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

    Percentage of machines (server excluded) with one or more user accounts from January 2008 to June 2008.  75% of machines have one account.

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

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

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

    What we have learned so far

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

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

    Impact on the software ecosystem

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

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

    Number of unique applications and tasks creating UAC prompts.  Shows a significant decline.

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

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

    Percentage of sessions with prompts over time. 

    Figure 3. Percentage of sessions with prompts over time.

    Impact on Windows

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

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

    Number of Microsoft prompters in the top 50 over time.

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

    Impact on Customers

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

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

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

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

    Percentage of prompts over time per prompt type.

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

    Percentage of UAC prompts allowed over time.

    Figure 6. Percentage of UAC prompts allowed over time.

    Looking ahead…

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

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

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

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

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

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

    Ben Fathi

  • Engineering Windows 7

    Boot Performance

    • 173 Comments

    Ed. Note: This is our first post from a senior member of the development team. Allow me to introduce Michael Fortin who is one of Microsoft’s Distinguished Engineers and leads the Fundamentals feature team that is in our Core Operating System group. Michael leads performance and reliability efforts across the Windows platform.  --Steven  (PS: Be sure to visit www.microsoft.com/ie and try out the beta 2 release of Internet Explorer 8).

    For Windows 7, we have a dedicated team focused on startup performance, but in reality the effort extends across the entire Windows division and beyond. Our many hardware and software partners are working closely with us and can rightly be considered an extension to the team.

    Startup can be one of three experiences; boot, resume from sleep, or resume from hibernate. Although resume from sleep is the default, and often 2 to 5 seconds based on common hardware and standard software loads, this post is primarily about boot as that experience has been commented on frequently. For Windows 7, a top goal is to significantly increase the number of systems that experience very good boot times. In the lab, a very good system is one that boots in under 15 seconds.

    For a PC to boot fast a number of tasks need to be performed efficiently and with a high degree of parallelism.

    • Files must be read into memory.
    • System services need to be initialized.
    • Devices need to be identified and started.
    • The user’s credentials need to be authenticated for login.
    • The desktop needs to be constructed and displayed.
    • Startup applications need to be launched.

    Because systems and configurations differ, boot times can vary significantly. This is verified by many lab results, but can also be seen in independent analysis, such as that conducted by Ed Bott. Sample data from Ed’s population of systems found that only 35% of boots took less than 30 seconds to give control to the user. Though Ed’s data is from a small population, his data is nicely in line with what we’re observing. Windows Vista SP1 data (below) also indicates that roughly 35% of systems boot in 30 seconds or less, 75% of systems boot in 50 seconds or less. The Vista SP1 data is real world telemetry data. It comes to us from the very large number of systems (millions) where users have chosen to send anonymous data to Microsoft via the Customer Experience Improvement Program.

    Histogram distribution of boot times for Vista SP1 as reported through the Microsoft Customer Experience Improvement Program data.  Paragraph above provides summary of the data presented.

    From our perspective, too few systems consistently boot fast enough and we have to do much better. Obviously the systems that are greater than 60 seconds have something we need to dramatically improve—whether these are devices, networking, or software issues. As you can see there are some systems experiencing very long boot times. One of the things we see in the PC space is this variability of performance—variability arises from the variety of choices, and also the variety of quality of components of any given PC experience. There are also some system maintenance tasks that can contribute to long boot times. If a user opts to install a large software update, the actual updating of the system may occur during the next boot. Our metrics will capture these and unfortunately they can take minutes to complete. Regardless of the cause, a big part of the work we need to do as members of the PC ecosystem is address long boot times.

    In both Ed’s sample and our telemetry data, boot time is meant to reflect when a machine is ready and responsive for the user. It includes logging in to the system and getting to a usable desktop. It is not a perfect metric, but one that does capture the vast majority of issues. On Windows 7 and Vista systems, the metric is captured automatically and stored in the system event log. Ed’s article covers this in depth.

    We realize there are other perceptions that users deem as reflecting boot time, such as when the disk stops, when their apps are fully responsive, or when the start menu and desktop can be used. Also, “Post Boot” time (when applications in the Startup group run and some delayed services execute), the period before Windows boot is initiated, and BIOS time can be significant. In our efforts, we’ve not lost sight of what users consider being representative of boot.

    Before discussing some of our Windows 7 efforts, we’d like to point out there is considerable engagement with our partners underway. In scanning dozens of systems, we’ve found plenty of opportunity for improvement and have made changes. Illustrating that, please consider the following data taken from a real system. As the system arrived to us, the off-the-shelf configuration had a ~45 second boot time. Performing a clean install of Vista SP1 on the same system produced a consistent ~23 second boot time. Of course, being a clean install, there were many fewer processes, services and a slightly different set of drivers (mostly the versions were different). However, we were able to take the off-the-shelf configuration and optimize it to produce a consistent boot time of ~21 seconds, ~2 seconds faster than the clean install because some driver/BIOS changes could be made in the optimized configuration.

    For this same system, it is worth noting the resume from sleep time is approximately 2 seconds, achieving a nearly instant on experience. We do encourage users to choose sleep as an alternative to boot.

    As an example Windows 7 effort, we are working very hard on system services. We aim to dramatically reduce them in number, as well as reduce their CPU, disk and memory demands. Our perspective on this is simple; if a service is not absolutely required, it shouldn’t be starting and a trigger should exist to handle rare conditions so that the service operates only then.

    Of course, services exist to complete user experiences, even rare ones. Consider the case where a new keyboard, mouse or tablet HW is added to the system while it was off. If this new HW isn’t detected and drivers installed to make the HW work during startup, then the user may not be able to enter their credentials and log into the machine. For a given user, this may be a very rare or never encountered event. For a population of 100s of millions of users, this can happen frequently enough to warrant having mechanisms to support it. In Windows 7, we will support this scenario and many others with fewer auto start services because more comprehensive service trigger mechanisms have been created.

    As noted above, device and driver initialization can be a significant contributor as well. In Windows 7, we’ve focused very hard on increasing parallelism of driver initialization. This increased parallelism decreases the likelihood that a few slower devices/drivers will impact the overall boot time.

    In terms of reading files from the disk, Windows 7 has improvements in the “prefetching” logic and mechanisms. Prefetching was introduced way back in Windows XP. Since today’s disks have differing performance characteristics, the scheduling logic has undergone some changes to keep pace and stay efficient. As an example, we are evaluating the prefetcher on today’s solid state storage devices, going so far as to question if is required at all. Ultimately, analysis and performance metrics captured on an individual system will dynamically determine the extent to which we utilize the prefetcher.

    There are improved diagnostic experiences in Windows 7 as well. We aim to quickly identify specific issues on individual systems, and provide help to assist in resolving the issues. We believe this is an appropriate way to inform users about some problems, such as having too many startup applications or the presence of lengthy domain-oriented logon scripts. As many users know, having too many startup applications is often the cause of long boot times. Few users, however, are familiar with implications of having problematic boot or logon scripts. In Windows XP, Vista and in Windows 7, the default behavior for Windows is to log the user into the desktop without waiting for potentially lengthy networking initialization or scripts to run. In corporate environments, however, it is possible for IT organizations to change the default and configure client systems to contact servers across the network. Unfortunately, when configuring clients to run scripts, domain administrators typically do so in a synchronous and blocking fashion. As a result, boot and logon can take minutes if networking timeouts or server authentication issues exist. Additionally, those scripts can run very expensive programs that consume CPU, disk and memory resources.

    In addition to working on Windows 7 specific features and services, we are sharing tools, tests and data with our partners. The tools are available to enthusiasts as well. The tools we use internally to detect and correct boot issues are freely available today here as a part of the Windows Performance Toolkit. While not appropriate for most users, the tools are proving to be very helpful for some.

    One of the topics we want to talk about in the future which we know has been written about a great deal and is the subject of many comments, is the role that additional software beyond the initial Windows installation plays in overall system performance. The sheer breadth and depth of software for Windows means that some software will not have the high quality one would hope, while the vast majority is quite good. Microsoft must continue to provide the tools for developers to write high performance software and the tools for end-users to identify the software on their system that might contribute to performance that isn’t meeting expectations. Windows itself must also continue to improve the defensive tactics it uses to isolate and inform the end-user about software that might contribute to poor performance.

    Another potential future topic pertains to configuration changes a user can make on their own system. Many recommended changes aren’t helpful at all. For instance, we’ve found the vast majority of “registry tweak” recommendations to be bogus. Here’s one of my favorites. If you perform a Live search for “Enable Superfetch on XP”, you’ll get a large set of results. I can assure you, on Windows XP there is no Superfetch functionality and no value in setting the registry key noted on these sites. As with that myth, there are many recommendations pertaining to CPU scheduling, memory management and other configuration changes that aren’t helpful to system performance.

    Startup is one topic on performance. As described in the previous post we want to continue the discussion around this topic. What are some of the elements you’d like to discuss more?

    Michael Fortin

  • Engineering Windows 7

    The Windows 7 Team

    • 164 Comments

    Thanks to everyone who provided comments and sent me mail. I definitely appreciate the discussion we have kicked off. There’s also a ton of energy in our hallways as this blog started. It seems like a good thing to do to start off is sort of an introduction to the Windows development team. This post provides an overview of the team that is represented by this blog.

    Before diving into the main topic, let’s talk a bit more about what to expect from this blog. First a few words on the comments and emails I’ve received. I’ve received a ton—most of the weekend was spent reading emails and comments. There are definitely some themes. I would say by and large the reception has been very warm and we definitely appreciate that. The most frequent request was to discuss Windows performance and/or just “make Windows faster”. There’s a lot to this topic so we expect to talk about this quite a bit over the next months. There are many specific requests—often representing all possible sides of an issue such as some folks saying “please get rid of (or don’t do) <x>” and then other folks saying “whatever you do it is really important to keep (or do) <x>”. A big part of this blog for me personally is having the discussion about the multiple facets of any given issue. Even something that sounds as binary as performance proves to have many subtle elements. For example, some folks suggested that the best thing for boot performance is to not start anything until idle time and others suggested that the delay loading feels like it slows them down and still others have suggested that the best approach is to provide a startup manager that pushes everyone to choose what to start up. All of these have merit worth discussing and also demonstrate the subtlety and complexity of even the most straight forward request.

    Second, much to the surprise of both Jon and I a number of folks questioned the “authenticity” of the post. A few even suggested that the posts are being “ghost written” or that this blog is some sort of ploy. I am typing this directly in Windows Live Writer and hitting publish. This blog is the real deal—typos, mistakes, and all. There’s no intermediary or vetting of the posts. We have folks on the team who will be contributing, but we’re not having any posts written by anyone other than who signs it. We will us one user name for all the posts since that keeps the blog security and ownership clear, but posts will be signed by the person that hit publish. (If I participate in the comments I will use my msdn name, steven_sinofsky.)

    And third, what frequency should folks expect and when do we get to the “features of Windows 7”. When we wrote that we would post “regularly” we meant that we don’t have a schedule or calendar of posts and we don’t want to commit to an artificial frequency which generally seems inconsistent with blogging. We do expect to follow a pattern similar to what you have become familiar with on the IEBlog. FWIW, on my internal blog no one has yet accused me of not contributing enough. :-)

    As we said in the introductory post we think it will be good to talk about the engineering of Windows 7 (the “how”) and the first step is establishing who the engineers are that do the engineering before we dive into the product itself (the “why” and “what”).

    So let’s meet the team...

    It is pretty easy to think of the Windows team as one group or one entity, and then occasionally one specific person comes to represent the team—perhaps she gave a talk at a conference, wrote a book or article folks become familiar with, or maybe he has a blog. Within Microsoft, the Windows product is really a product of the whole company with people across all the development groups contributing in some form or another. The Windows engineering team “proper” is jointly managed by Jon and me. Jon manages the core operating system, which is, among many things, the kernel, device infrastructure, networking, and the engineering tools and system (all of which are both client and server). I am part of the Windows client experience team which develops, among many things, the shell and desktop, graphics, and media support. One other significant part of the Windows product is the Windows Media Center which is a key contribution managed along with all of Microsoft’s TV support (IPTV, extenders, etc.).

    There’s a lot to building an org structure for a large team, but the most important part is planning the work of the team. This planning is integral to realizing our goal of improving the overall consistency and “togetherness” for Windows 7. So rather than think of one big org, or two teams, we say that the Windows 7 engineering team is made up of about 25 different feature teams.

    A feature team represents those that own a specific part of Windows 7—the code, features, quality, and overall development. The feature teams represent the locus of work and coordination across the team. This also provides a much more manageable size—feature teams fit in meeting spaces, can go to movies, and so on. On average a feature team is about 40 developers, but there are a variety of team sizes. There are two parts to a feature team: what the team works on and who makes up a team.

    Windows 7’s feature teams sound a lot like parts of Windows with which you are familiar. Because of the platform elements of Windows we have many teams that have remained fairly constant over several releases, whereas some teams are brand new or represent relatively new areas composed of some new code and the code that formed the basis of the team. Some teams do lots of work for Server (such as the VM work) and some might have big deliverables outside of Windows 7 (such as Internet Explorer).

    In general a feature team encompasses ownership of combination of architectural components and scenarios across Windows. “Feature” is always a tricky word since some folks think of feature as one element in the user-interface and others think of the feature as a traditional architectural component (say TCP/IP). Our approach is to balance across scenarios and architecture such that we have the right level of end-to-end coverage and the right parts of the architecture. One thing we do try to avoid is separating the “plumbing” from the “user interface” so that teams do have end-to-end ownership of work (as an example of that, “Find and Organize” builds both the indexer and the user interface for search). Some of the main feature teams for Windows 7 include (alphabetically):

    • Applets and Gadgets
    • Assistance and Support Technologies
    • Core User Experience
    • Customer Engineering and Telemetry
    • Deployment and Component Platform
    • Desktop Graphics
    • Devices and Media
    • Devices and Storage
    • Documents and Printing
    • Engineering System and Tools
    • File System
    • Find and Organize
    • Fundamentals
    • Internet Explorer (including IE 8 down-level)
    • International
    • Kernel & VM
    • Media Center
    • Networking - Core
    • Networking - Enterprise
    • Networking - Wireless
    • Security
    • User Interface Platform
    • Windows App Platform

    I think most of these names are intuitive enough for the purposes of this post—as we post more the members of the team will identify which feature team they are on. This gives you an idea of the subsystems of Windows and how we break down a significant project into meaningful teams. Of course throughout the project we are coordinating and building features across teams. This is a matter of practice because you often want to engineer the code in one set of layers for efficiency and performance (say bottom up), but end-users might experience it across layers, and IT pros might want to manage a desktop from the top-down. I admit sometimes this is a little bit too much of an insider view as you can’t see where some interesting things “live”. For example, the tablet and inking functionality is in our User Interface Platform team along with speech recognition, multi-touch and accessibility. The reason for this is the architectural need to share the infrastructure for all mechanisms of “input” even if any one person might not cross all those layers. This way when we design the APIs for managing input, developers will see the benefits of all the modes of user interaction through one set of APIs.

    The other aspect of our feature teams is the exact composition. A feature team represents three core engineering disciplines of software development engineers (sde or dev), software development engineers in test (sdet or test, sorry but I haven’t written a job description externally), and program managers (pm). Having all three of these engineering disciplines is a unique aspect of Microsoft that has even caught the attention of some researchers. In my old blog I described dev and pm which I linked to above (I still owe a similar post on SDET!).

    The shortest version of these roles is dev is responsible for the architecture and code, pm is responsible for the feature set and specification, and test is responsible for validation and the ultimate advocate for the customer experience. Everyone is responsible for quality and performance, each bringing their perspective to the work. For any given feature, each of dev, test, and pm work as a team of peers (both literally and conceptually). This is a key “balance of power” in terms of how we work and makes sure that we take a balanced approach to developing Windows 7. Organizationally, we are structured such that devs work for devs, sdets work for sdets, and pm works for pm. That is we are organized by these “engineering functions”. This allows for two optimizations—the focus on expertise in both domain and discipline and also the ability to make sure we are not building the product in silos, but focused on the product as a whole.

    We talk about these three disciplines together because we create feature teams with n developers, n testers, and 1/2n program managers. This ratio is pretty constant across the team. On average a feature team is about 40 developers across the Windows 7 project.

    We also have core members of our engineering team that work across the entire product:

    • Content Development – the writers and editors that create the online assistance, web site, SDK documents, and deployment documents.
    • Product Planning – responsible for the customer research and learning that informs the selection of features. Product Planning also coordinates the work we do with partners across the ecosystem in terms of partnering through the design and development of the release.
    • Product Design – develops the overall interaction model, graphical language, and design language for Windows 7
    • Research and Usability – creates field and lab studies that show how existing products and proposed feature perform with customers

    Some have said that the Windows team is just too big and that it has reached a size that causes engineering problems. At the same time, I might point out that just looking at the comments there is a pretty significant demand for a broad set of features and changes to Windows. It takes a set of people to build Windows and it is a big project. The way that I look at this is that our job is to have the Windows team be the right size—that sounds cliché but I mean by that is that the team is neither too large nor too small, but is effectively managed so that the work of the team reflects the size of the team and you see the project as having the benefits we articulate. I’m reminded of a scene from Amadeus where the Emperor suggests that the Marriage of Figaro contains “too many notes” to which Mozart proclaims “there are just as many notes, Majesty, as are required, neither more nor less.” Upon the Emperor suggesting that Mozart remove a few notes, Mozart simply asks “which few did you have in mind?” Of course the people on the team represent the way we get feature requests implemented and develop end to end scenarios, so the challenge is to have the right team and the right structure to maximize the ability to get those done—neither too many nor too few.

    I promised myself no post would be longer than 4 pages and I am getting close. The comments are great and are helping us to shape future posts. I hope this post starts to develop some additional shared context.

    --Steven

  • Engineering Windows 7

    Media Streaming with Windows 7

    • 141 Comments

    We’ve blogged about a number of features related to home networking and media in Windows 7.  A scenario which brings all these together in a pretty cool way is Media Streaming.  This scenario allows you to use a Windows 7 PC as a hub for media sharing—where you can share media with other PCs and devices on your home network via streaming, and even stream this information securely over the internet.  Scott Manchester on the Devices & Media program management team coordinated this post, but as you will see it represents work across the Core User Experience, Media Center, Networking, and even Windows Live chose to take advantage of the new APIs in this scenario.  This is a pretty detailed post and there’s a lot to try out.  Those of you using the RC to test things out, you can always install on another PC and use it for the 30-day period without requiring a new PID key.  Have fun!  --Steven

    Windows 7 includes a number of exciting new media streaming features that enable you to enjoy your media collection on other PCs and devices in the home and while on the road from across the internet. We’ve created a networked media experience that is more friendly to use and simpler to set up. Now enjoying music, pictures, and video on your network connected PC or media device “just works” without concern for media formats, transports, or protocols.

    There are a growing number of Network Media Devices (NMDs) certified to interoperate using an open and widely embraced industry standard called the Digital Living Network Alliance (DLNA). Windows 7 implements this open standard, which means that sharing media between NMDs, Windows PCs, Windows Home Server, and Extenders for Windows Media Center (including Xbox 360) is easier and more natural. Supporting this standard also means that the myriad of NMDs such as electronic picture frames, network radios, televisions, and others are companions to Windows 7 PCs and may seamlessly participate in the whole-home media experience.

    Not Just for the Techie

    We made it much simpler to configure media streaming. Before Windows 7, media streaming features were focused on media enthusiasts. To improve the setup experience, media streaming has been integrated with the new HomeGroup feature so in a typical home network configuration, media streaming is enabled and works by default. There is also a new “Stream” menu prominently displayed in the Window Media Player user interface (see figure below) that exposes simple scenario-based configuration options. These options allow you to:

    1. Set up your home PC so you can access your media libraries while away from home
    2. Allow other Windows 7 PCs and devices to push media to your Player and control it
    3. Quickly authorize all home PCs and devices to access your media collection

    Each of these scenarios will be discussed throughout this post.

    Configuring the stream options in Windows Media Player

    HomeGroup introduces the concept of “shared libraries” for music, pictures, and video. As described in a previous blog post, these shared libraries are accessible from within the navigation pane of Windows Explorer and Windows Media Player, and from the “shared” view of each media category within Windows Media Center (see figures below). The scope of these libraries is the same from each of these views.

    Libraries shared between Media Player and Media Center

    Media Center

    Windows Explorer will automatically discover and provide access to shared media libraries on other HomeGroup PCs. In addition, Windows Media Player and Windows Media Center will automatically discover shared libraries from:

    1. Windows Media Player 11 and 12
    2. Windows Home Server
    3. All DLNA compliant media servers (e.g. network attached storage)

    Who Can Access My Shared Media Libraries?

    A HomeGroup is a secured set of Windows 7 PCs that can view and consume each other’s media seamlessly. Sharing is automatically set up among HomeGroup PCs and HomeGroup settings allow you to choose what types of media you would like to share; for example, you may choose to only share your music library and not your video or pictures.

    Changing homegroup settings

    In addition to all HomeGroup PCs being able to access your media, we made it easy to allow devices to access shared media libraries on Windows 7 PCs. This can be done conveniently from either HomeGroup settings or within Windows Media Player:

    Enable streaming.

    Allowing devices to share media from Media Player

    You can also choose to restrict which specific PCs or devices have access to your media by choosing “more streaming options…” from the Windows Media Player “Stream” menu.

    Restricting sharing to specific devices.

    Play To: Windows 7 as a Universal Remote Control for your Media Collection

    In addition to playing media streamed from other shared media libraries within Windows Media Player, Windows 7 can now send media to be played on other Windows 7 PCs and DLNA-certified digital media renderers. We call this feature “Play To.” With “Play To,” you can browse or search from within Windows Media Player or Windows Explorer to find your desired media, and then choose where you want it to be played. A versatile remote control window is presented for each “Play To” session, providing you with the ability to control the entire experience.

    Choosing the Play To device in Media Player

    Choosing the Play To device from Explorer

    It does not matter where media collections are stored. “Play To” is available for both local media libraries and for shared media libraries. If you would like to send media from one Windows 7 PC to another, choose “Allow remote control of my Player” from the Windows Media Player “Stream” menu on the receiving PC. This will cause Windows Media Player to be discovered in the “Play To” menu of other Windows 7 PCs on the same network.

    Allowing remove control of the player

    When media streaming is enabled on your Windows 7 PC, “Play To” will be available in Windows Media Player and Windows Explorer via the right click menu for media items. If Windows 7 has not discovered a “Play To” capable PC or device on the network, this context menu will not be available. DLNA provides guidelines to certify different device categories and roles. Not every DLNA-certified device supports the “Play To” feature. Look for DLNA-certified Digital Media Renderers (DMR), and for the best performance, look for DMR devices that carry the “Compatible with Windows 7” logo.

    Compatible with Windows 7 logo

    Once you’ve selected media items to play on another PC or device, a “Play To” remote control window will launch providing standard controls like play, pause, stop, skip forward and backward, seek forward and backward, volume, and mute. Not every device will support all of the control features and some media types may not support seek. Once the “Play To” remote control window is launched, you can reorder or delete items, add to the queue, or toggle repeat. It’s even possible to add new media items from Windows Media Player or Windows Explorer by dragging them into this window.

    Play To remote control window.

    There is no artificial limit to the number of “Play To” sessions you can launch. You may send pictures to a picture frame, video clips to a TV, and music to another Windows 7 laptop all at the same time. Furthermore, different types of media can be sent to a single destination, as shown in the example above.

    What About the Xbox 360 and Extenders for Windows Media Center?

    Xbox 360 has two ways to receive media streams from other Windows 7 PCs, which we refer to casually as “dashboard” mode and “extender” mode.

    In dashboard mode, Xbox 360 functions in the role of a simple media player. While it’s not officially a DLNA-certified device, you can use Xbox 360 to browse the shared media libraries from Windows 7 PCs (there is also support for this in Windows Media Player 11) and pull content from those libraries for playback within the dashboard.

    Using Xbox 360 for media playback

    Using Xbox 360 for media playback

    In extender mode, Xbox 360 (and other Extenders for Windows Media Center) is seen by Windows 7 PC’s on the network as both a Digital Media Player (DMP) and a Digital Media Renderer (DMR) device. Using the Extender for Windows Media Center on the Xbox 360, you can browse media libraries on other computers and pull that content for local playback, similar to the process of using Xbox 360 in dashboard mode. However, in extender mode Xbox 360 will also support “Play To” so that users of Windows 7 PC’s on the network can push content to it. All extenders, when associated with a Windows 7 PC, will be discovered in the “Play To” menu of other Windows 7 PCs.

    Internet Access to Home Media

    With Windows 7 we’ve also extended the media streaming experience outside the home and allow you to access your home media from anywhere in the world via the internet. We’ve made media streaming over the internet a natural extension of the experience within the home. For the experience to be seamless we needed to solve some significant technical challenges, such as:

    1. Discovery – Resolving the computer name at home to a routable IP address
    2. Privacy – Ensuring the home media is only accessible by authorized users
    3. Security – Encrypting browsing and streaming of media to prevent eavesdropping
    4. Reliability – Network connection speeds, media formats and bit rates, and router firewalls all create potential reliability issues for a seamless experience

    To overcome these technical hurdles, we designed a model that uses an Online ID Provider to help facilitate discovery, privacy, and security. The new Online ID Provider infrastructure in Windows 7 allows you to link your Online ID (e.g. you@live.com) with your Windows user account. This enables an authentication/authorization server to provide the necessary privacy to establish a protected link between two Windows 7 PCs (e.g. your laptop on the road and your PC at home). Internet access to home media is enabled from the “Stream” menu in Windows Media Player.

    Enabling internet access to home media.

    The setup process walks you through linking an online ID with your Windows user account, which must be performed on both the home PC and remote PC. The same online ID must be used on both PCs in order to establish the connection between them. In order for remote PCs to access the home media collection, the PC at home (acting as a server) must be on a “Home” network location. Remote PCs (acting as clients) can browse and receive content streamed from the home PC from any network location (Public, Work, or Home). The network location is chosen when first connecting to any network and can be changed later from the Network and Sharing Center.

    Specify the network to be a home network

    Reliability - Network Connection Requirements

    Streaming media over the internet from home works best with an “always on” broadband connection. Broadband uplink speeds vary from a modest 200Kbps to 10Mbps or more. Downlink connection speeds will also vary from crowded hotspots, hotel rooms, and wireless network connections in friends’ homes. Regardless of the uplink or downlink speeds, we wanted to ensure that even high bit rate content (e.g. high definition recorded TV) could be streamed with a good experience. The internet media streaming feature uses advanced bandwidth detection algorithms and end-to-end network heuristics to determine how to stream content that is at a higher bit rate than the smallest link in the network path.

    Another challenge with internet access to home media is creating a peer-to-peer connection between the remote client PC and the home PC serving the media. A typical home network will get a single unique IP address from an internet service provider, and this IP address is shared by all the devices and PCs in the home using Network Address Translation (NAT), a function of an Internet Gateway Device (IGD) or Wireless Router. This creates a challenge for a remote PC or device to make an unsolicited connection inside the home, both in terms of resolving the home’s unique IP address and traversing the NAT to communicate directly to a unique PC or device on the home network.

    Windows 7 employs some advanced NAT traversal technologies to establish the peer-to-peer connection and, with most IGDs, will allow a reliable connection to the home PC from any remote PC. For best results you should use a wireless router or IGD that has been certified by the Windows Logo program.

    Media Formats

    In Windows 7 we let you enjoy the media you want and don’t trouble you with the need to know about file types or codecs in most cases. (For more details, see Table 1 below). In addition to supporting local playback of new formats, we can also ensure that the content will play on devices that may not support the codec, bit rate, container, or format of that content. We accomplish this by using the new transcoding support in Windows 7.

    Let’s say for instance you have a DivX movie you want to watch on your new DLNA certified television which only supports WMV and MPEG2. Windows 7 will determine the capability of the TV (codec, bit rate, etc.) and dynamically convert the DivX video to a format the TV can play. The general rule of thumb is: if Windows Media Player can play the content on the PC then the content will almost always play back on the network connected device. Bandwidth estimation techniques are used for media streaming within the home and over the internet, which enables Windows 7 to transcode using the most optimal format and bit rate.

    Table of media format support.

     Table 1: New Decoders in Windows 7

    The format and bit rate chosen for transcoding, especially for video, is highly dependent on the CPU performance of the transcoding PC as identified by its Windows Experience Index:

    Windows Experience Index

    We also created a flexible model for silicon partners to provide hardware accelerators that automatically work with media streaming and other Windows 7 features. This new acceleration model allows hardware developers to build media foundation proxies for media format encoders and decoders that are fully implemented in their hardware (perhaps in a GPU or additional hardware device). With hardware supported encoding and decoding, Windows 7 can offload the computationally demanding transcoding to dedicated hardware as a background task without affecting the CPU performance of the PC.

    Digital Living Network Support in Windows 7

    The Digital Living Network Alliance (DLNA) is a consortium of more than 200 companies interested in specifying technologies for exchanging media in home networks. The DLNA architecture is based on the UPnP specification, but in addition, DLNA specifies transport protocols (based on HTTP and RTP) and sets of media formats.

    DLNA defines device roles (e.g. servers, players, renderers, etc.) and the protocols that these devices use to discover each other and communicate with each other (e.g. UPnP, HTTP, RTP, etc.). Windows 7 implements several of the DLNA device roles (see table 2 below) and it also implements the DLNA protocols required for communications and media exchange. With Windows 7, your PC will be able to interoperate with a broad variety of DLNA certified devices like TVs, stereo systems, cell phones, DVRs, game consoles, etc.

    DLNA acronym table

    Table 2: DLNA Device Profiles Supported by Windows 7

    Because Windows 7 implements several device roles, there are different ways in which you could choose to use a Windows 7 PC at home. The remainder of this section explains the different scenarios.

    Scenario 1: You store your music, video, and pictures on a Windows 7 PC. You’ve recently acquired a TV with a DLNA logo. Using the TV, you can browse the media library available on the Windows 7 PC. You can use the TV to watch the video and pictures, and listen to music stored on the PC. Figure 1 illustrates this scenario. In this case, the Windows 7 PC behaves as a DMS. Notice that this scenario was already available in Windows Vista and in Windows XP using Windows Media Player 11.

    Figure 1: The TV unit browses and plays content stored in a PC

    Figure 1: The TV unit browses and plays content stored in a PC

    Scenario 2: You have a Network Attached Storage (NAS) device where you store your music, video, and pictures. The NAS device implements a DMS. You open Windows Media Player on a Windows 7 PC. You can find the NAS device using Windows Media Player, and you can browse the media library available on the NAS device. You can watch the video or pictures, and listen to music stored on the NAS device. Figure 2 illustrates this scenario. In this case, the Windows 7 PC behaves as a DMP.

    Figure 2: A Windows 7 PC browses and plays content stored on a NAS device

    Figure 2: A Windows 7 PC browses and plays content stored on a NAS device

    Scenario 3: You have a cell phone that not only takes pictures but can push the pictures to a Windows 7 PC. You can show the pictures to your friends using the large-screen display of the PC without the need to physically transfer the files to the PC with a USB thumb drive, for example. Figure 3 illustrates this scenario. In this case, the cell phone acts as a DMS and a DMC and the Windows 7 PC behaves as a DMR.

    Figure 3: A cell phone pushes pictures for display on a Windows7 PC

    Figure 3: A cell phone pushes pictures for display on a Windows7 PC

    Scenario 4: You’ve acquired a stereo system with the DLNA logo. On his Windows 7 PC, you’ve accumulated a vast collection of music with thousands of songs. Because your collection is large, you prefer to search, organize, and select songs using the rich capabilities of the Windows Media Player. Once you select the songs, you simply push the songs to your stereo system using “Play To.” You also have a NAS device containing an additional collection of music and video. You can use the Windows 7 PC to browse the content on the NAS device and push it to the stereo system. Figure 4 illustrates this scenario. In this case, the Windows 7 PC behaves as a DMS and a DMC.

    Figure 4: A Windows 7 PC browses local content or shared content on the network. The PC then pushes the content for playback in a TV unit (DMR).

    Figure 4: A Windows 7 PC browses local content or shared content on the network. The PC then pushes the content for playback in a TV unit (DMR).

    There's definitely a lot to enjoy here.  Have fun!! 

    -- Scott, Tim and the Devices & Media team

  • Engineering Windows 7

    Support and Q&A for Solid-State Drives

    • 139 Comments

    There’s a lot of excitement around the potential for the widespread adoption of solid-state drives (SSD) for primary storage, particularly on laptops and also among many folks in the server world.  As with any new technology, as it is introduced we often need to revisit the assumptions baked into the overall system (OS, device support, applications) as a result of the performance characteristics of the technologies in use.  This post looks at the way we have tuned Windows 7 to the current generation of SSDs.  This is a rapidly moving area and we expect that there will continue to be ways we will tune Windows and we also expect the technology to continue to evolve, perhaps introducing new tradeoffs or challenging other underlying assumptions.  Michael Fortin authored this post with help from many folks across the storage and fundamentals teams.  --Steven

    Many of today’s Solid State Drives (SSDs) offer the promise of improved performance, more consistent responsiveness, increased battery life, superior ruggedness, quicker startup times, and noise and vibration reductions. With prices dropping precipitously, most analysts expect more and more PCs to be sold with SSDs in place of traditional rotating hard disk drives (HDDs).

    In Windows 7, we’ve focused a number of our engineering efforts with SSD operating characteristics in mind. As a result, Windows 7’s default behavior is to operate efficiently on SSDs without requiring any customer intervention. Before delving into how Windows 7’s behavior is automatically tuned to work efficiently on SSDs, a brief overview of SSD operating characteristics is warranted.

    Random Reads: A very good story for SSDs

    SSDs tend to be very fast for random reads. Most SSDs thoroughly trounce traditionally HDDs because the mechanical work required to position a rotating disk head isn’t required. As a result, the better SSDs can perform 4 KB random reads almost 100 times faster than the typical HDD (about 1/10th of a millisecond per read vs. roughly 10 milliseconds).

    Sequential Reads and Writes: Also Good

    Sequential read and write operations range between quite good to superb. Because flash chips can be configured in parallel and data spread across the chips, today’s better SSDs can read sequentially at rates greater than 200 MB/s, which is close to double the rate many 7200 RPM drives can deliver. For sequential writes, we see some devices greatly exceeding the rates of typical HDDs, and most SSDs doing fairly well in comparison. In today’s market, there are still considerable differences in sequential write rates between SSDs. Some greatly outperform the typical HDD, others lag by a bit, and a few are poor in comparison.

    Random Writes & Flushes: Your mileage will vary greatly

    The differences in sequential write rates are interesting to note, but for most users they won’t make for as notable a difference in overall performance as random writes.

    What’s a long time for a random write? Well, an average HDD can typically move 4 KB random writes to its spinning media in 7 to 15 milliseconds, which has proven to be largely unacceptable. As a result, most HDDs come with 4, 8 or more megabytes of internal memory and attempt to cache small random writes rather than wait the full 7 to 15 milliseconds. When they do cache a write, they return success to the OS even though the bytes haven’t been moved to the spinning media. We typically see these cached writes completing in a few hundred microseconds (so 10X, 20X or faster than actually writing to spinning media). In looking at millions of disk writes from thousands of telemetry traces, we observe 92% of 4 KB or smaller IOs taking less than 1 millisecond, 80% taking less than 600 microseconds, and an impressive 48% taking less than 200 microseconds. Caching works!

    On occasion, we’ll see HDDs struggle with bursts of random writes and flushes. Drives that cache too much for too long and then get caught with too much of a backlog of work to complete when a flush comes along, have proven to be problematic. These flushes and surrounding IOs can have considerably lengthened response times. We’ve seen some devices take a half second to a full second to complete individual IOs and take 10’s of seconds to return to a more consistently responsive state. For the user, this can be awful to endure as responsiveness drops to painful levels. Think of it, the response time for a single I/O can range from 200 microseconds up to a whopping 1,000,000 microseconds (1 second).

    When presented with realistic workloads, we see the worst of the SSDs producing very long IO times as well, as much as one half to one full second to complete individual random write and flush requests. This is abysmal for many workloads and can make the entire system feel choppy, unresponsive and sluggish.

    Random Writes & Flushes: Why is this so hard?

    For many, the notion that a purely electronic SSD can have more trouble with random writes than a traditional HDD seems hard to comprehend at first. After all, SSDs don’t need to seek and position a disk head above a track on a rotating disk, so why would random writes present such a daunting a challenge?

    The answer to this takes quite a bit of explaining, Anand’s article admirably covers many of the details. We highly encourage motivated folks to take the time to read it as well as this fine USENIX paper. In an attempt to avoid covering too much of the same material, we’ll just make a handful of points.

    • Most SSDs are comprised of flash cells (either SLC or MLC). It is possible to build SSDs out of DRAM. These can be extremely fast, but also very costly and power hungry. Since these are relatively rare, we’ll focus our discussion on the much more popular NAND flash based SSDs. Future SSDs may take advantage of other nonvolatile memory technologies than flash.
    • A flash cell is really a trap, a trap for electrons and electrons don’t like to be trapped. Consider this, if placing 100 electrons in a flash cell constitutes a bit value of 0, and fewer means the value is 1, then the controller logic may have to consider 80 to 120 as the acceptable range for a bit value of 0. A range is necessary because some electrons may escape the trap, others may fall into the trap when attempting to fill nearby cells, etc… As a result, some very sophisticated error correction logic is needed to insure data integrity.
    • Flash chips tend to be organized in complex arrangements, such as blocks, dies, planes and packages. The size, arrangement, parallelism, wear, interconnects and transfer speed characteristics of which can and do vary greatly.
    • Flash cells need to be erased before they can be written. You simply can’t trust that a flash cell has no residual electrons in it before use, so cells need to be erased before filling with electrons. Erasing is done on a large scale. You don’t erase a cell; rather you erase a large block of cells (like 128 KB worth). Erase times are typically long -- a millisecond or more.
    • Flash wears out. At some point, a flash cell simply stops working as a trap for electrons. If frequently updated data (e.g., a file system log file) was always stored in the same cells, those cells would wear out more quickly than cells containing read-mostly data. Wear leveling logic is employed by flash controller firmware to spread out writes across a device’s full set of cells. If done properly, most devices will last years under normal desktop/laptop workloads.
    • It takes some pretty clever device physicists and some solid engineering to trap electrons at high speed, to do so without errors, and to keep the devices from wearing out unevenly. Not all SSD manufacturers are as far along as others in figuring out how to do this well.

    Performance Degradation Over Time, Wear, and Trim

    As mentioned above, flash blocks and cells need to be erased before new bytes can be written to them. As a result, newly purchased devices (with all flash blocks pre-erased) can perform notably better at purchase time than after considerable use. While we’ve observed this performance degradation ourselves, we do not consider this to be a show stopper. In fact, except via benchmarking measurements, we don’t expect users to notice the drop during normal use.

    Of course, device manufactures and Microsoft want to maintain superior performance characteristics as best we can. One can easily imagine the better SSD manufacturers attempting to overcome the aging issues by pre-erasing blocks so the performance penalty is largely unrealized during normal use, or by maintaining a large enough spare area to store short bursts of writes. SSD drives designed for the enterprise may have as high as 50% of their space reserved in order to provide lengthy periods of high sustained write performance.

    In addition to the above, Microsoft and SSD manufacturers are adopting the Trim operation. In Windows 7, if an SSD reports it supports the Trim attribute of the ATA protocol’s Data Set Management command, the NTFS file system will request the ATA driver to issue the new operation to the device when files are deleted and it is safe to erase the SSD pages backing the files. With this information, an SSD can plan to erase the relevant blocks opportunistically (and lazily) in the hope that subsequent writes will not require a blocking erase operation since erased pages are available for reuse.

    As an added benefit, the Trim operation can help SSDs reduce wear by eliminating the need for many merge operations to occur. As an example, consider a single 128 KB SSD block that contained a 128 KB file. If the file is deleted and a Trim operation is requested, then the SSD can avoid having to mix bytes from the SSD block with any other bytes that are subsequently written to that block. This reduces wear.

    Windows 7 requests the Trim operation for more than just file delete operations. The Trim operation is fully integrated with partition- and volume-level commands like Format and Delete, with file system commands relating to truncate and compression, and with the System Restore (aka Volume Snapshot) feature.

    Windows 7 Optimizations and Default Behavior Summary

    As noted above, all of today’s SSDs have considerable work to do when presented with disk writes and disk flushes. Windows 7 tends to perform well on today’s SSDs, in part, because we made many engineering changes to reduce the frequency of writes and flushes. This benefits traditional HDDs as well, but is particularly helpful on today’s SSDs.

    Windows 7 will disable disk defragmentation on SSD system drives. Because SSDs perform extremely well on random read operations, defragmenting files isn’t helpful enough to warrant the added disk writing defragmentation produces. The FAQ section below has some additional details.

    Be default, Windows 7 will disable Superfetch, ReadyBoost, as well as boot and application launch prefetching on SSDs with good random read, random write and flush performance. These technologies were all designed to improve performance on traditional HDDs, where random read performance could easily be a major bottleneck. See the FAQ section for more details.

    Since SSDs tend to perform at their best when the operating system’s partitions are created with the SSD’s alignment needs in mind, all of the partition-creating tools in Windows 7 place newly created partitions with the appropriate alignment.

    Frequently Asked Questions

    Before addressing some frequently asked questions, we’d like to remind everyone that we believe the future of SSDs in mobile and desktop PCs (as well as enterprise servers) looks very bright to us. SSDs can deliver on the promise of improved performance, more consistent responsiveness, increased battery life, superior ruggedness, quicker startup times, and noise and vibration reductions. With prices steadily dropping and quality on the rise, we expect more and more PCs to be sold with SSDs in place of traditional rotating HDDs. With that in mind, we focused an appropriate amount of our engineering efforts towards insuring Windows 7 users have great experiences on SSDs.

    Will Windows 7 support Trim?

    Yes. See the above section for details.

    Will disk defragmentation be disabled by default on SSDs?

    Yes. The automatic scheduling of defragmentation will exclude partitions on devices that declare themselves as SSDs. Additionally, if the system disk has random read performance characteristics above the threshold of 8 MB/sec, then it too will be excluded. The threshold was determined by internal analysis.

    The random read threshold test was added to the final product to address the fact that few SSDs on the market today properly identify themselves as SSDs. 8 MB/sec is a relatively conservative rate. While none of our tested HDDs could approach 8 MB/sec, all of our tested SSDs exceeded that threshold. SSD performance ranged between 11 MB/sec and 130 MB/sec. Of the 182 HDDs tested, only 6 configurations managed to exceed 2 MB/sec on our random read test. The other 176 ranged between 0.8 MB/sec and 1.6 MB/sec.

    Will Superfetch be disabled on SSDs?

    Yes, for most systems with SSDs.

    If the system disk is an SSD, and the SSD performs adequately on random reads and doesn’t have glaring performance issues with random writes or flushes, then Superfetch, boot prefetching, application launch prefetching, ReadyBoost and ReadDrive will all be disabled.

    Initially, we had configured all of these features to be off on all SSDs, but we encountered sizable performance regressions on some systems. In root causing those regressions, we found that some first generation SSDs had severe enough random write and flush problems that ultimately lead to disk reads being blocked for long periods of time. With Superfetch and other prefetching re-enabled, performance on key scenarios was markedly improved.

    Is NTFS Compression of Files and Directories recommended on SSDs?

    Compressing files help save space, but the effort of compressing and decompressing requires extra CPU cycles and therefore power on mobile systems. That said, for infrequently modified directories and files, compression is a fine way to conserve valuable SSD space and can be a good tradeoff if space is truly a premium.

    We do not, however, recommend compressing files or directories that will be written to with great frequency. Your Documents directory and files are likely to be fine, but temporary internet directories or mail folder directories aren’t such a good idea because they get large number of file writes in bursts.

    Does the Windows Search Indexer operate differently on SSDs?

    No.

    Is Bitlocker’s encryption process optimized to work on SSDs?

    Yes, on NTFS. When Bitlocker is first configured on a partition, the entire partition is read, encrypted and written back out. As this is done, the NTFS file system will issue Trim commands to help the SSD optimize its behavior.

    We do encourage users concerned about their data privacy and protection to enable Bitlocker on their drives, including SSDs.

    Does Media Center do anything special when configured on SSDs?

    No. While SSDs do have advantages over traditional HDDs, SSDs are more costly per GB than their HDD counterparts. For most users, a HDD optimized for media recording is a better choice, as media recording and playback workloads are largely sequential in nature.

    Does Write Caching make sense on SSDs and does Windows 7 do anything special if an SSD supports write caching?

    Some SSD manufacturers including RAM in their devices for more than just their control logic; they are mimicking the behavior of traditional disks by caching writes, and possibly reads. For devices that do cache writes in volatile memory, Windows 7 expects flush commands and write-ordering to be preserved to at least the same degree as traditional rotating disks. Additionally, Windows 7 expects user settings that disable write caching to be honored by write caching SSDs just as they are on traditional disks.

    Do RAID configurations make sense with SSDs?

    Yes. The reliability and performance benefits one can obtain via HDD RAID configurations can be had with SSD RAID configurations.

    Should the pagefile be placed on SSDs?

    Yes. Most pagefile operations are small random reads or larger sequential writes, both of which are types of operations that SSDs handle well.

    In looking at telemetry data from thousands of traces and focusing on pagefile reads and writes, we find that

    • Pagefile.sys reads outnumber pagefile.sys writes by about 40 to 1,
    • Pagefile.sys read sizes are typically quite small, with 67% less than or equal to 4 KB, and 88% less than 16 KB.
    • Pagefile.sys writes are relatively large, with 62% greater than or equal to 128 KB and 45% being exactly 1 MB in size.

    In fact, given typical pagefile reference patterns and the favorable performance characteristics SSDs have on those patterns, there are few files better than the pagefile to place on an SSD.

    Are there any concerns regarding the Hibernate file and SSDs?

    No, hiberfile.sys is written to and read from sequentially and in large chunks, and thus can be placed on either HDDs or SSDs.

    What Windows Experience Index changes were made to address SSD performance characteristics?

    In Windows 7, there are new random read, random write and flush assessments. Better SSDs can score above 6.5 all the way to 7.9. To be included in that range, an SSD has to have outstanding random read rates and be resilient to flush and random write workloads.

    In the Beta timeframe of Windows 7, there was a capping of scores at 1.9, 2.9 or the like if a disk (SSD or HDD) didn’t perform adequately when confronted with our random write and flush assessments. Feedback on this was pretty consistent, with most feeling the level of capping to be excessive. As a result, we now simply restrict SSDs with performance issues from joining the newly added 6.0+ and 7.0+ ranges. SSDs that are not solid performers across all assessments effectively get scored in a manner similar to what they would have been in Windows Vista, gaining no Win7 boost for great random read performance.

  • Engineering Windows 7

    Windows Desktop Search

    • 138 Comments

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

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

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

    Why Index?

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

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

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

    Trade-Offs

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

    A Model Citizen

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

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

    Constantly Improving

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

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

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

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

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

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

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

    Chris McConnell

    Find and Organize

  • Engineering Windows 7

    User Interface: Managing Windows windows

    • 135 Comments

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

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

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

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

    Screenshot of Windows 2.0 Screenshot of Windows Vista
    From Windows 2.0 to Vista.

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

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

    Standard caption buttons or upper right corner of a window in Vista.

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

    Data on Real-World Usage 

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

    Typical number of visible windows (one window 60%, two windows 29%, three or more windows 11%.
    Windows Feedback Panel data

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

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

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

    Pie chart showing custom window color selection.  29% of sessions have a custom color of "glass".

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

    Worldwide LCD monitor shipments by form factor. Distribution of native monitor resolution 2005-20010 est.
    Resolution data suggests wide aspect-ratio monitors will become the norm.

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

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

    Multimonitor users rely less on the taskbar and more on window interactions to switch among windows.
    MSR research report

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

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

    Evolving the design

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

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

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

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

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

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

    - Dave

  • Engineering Windows 7

    Beta to RC Changes – Turning Windows Features On or Off

    • 133 Comments

    The theme of “choice and control” has been applied in many aspects of how we have designed Windows 7. We’ve certainly received lots of positive feedback about the theme and about the choices we’ve made in the design, and we’ve also received a few suggestions for how we might continue to implement this theme in the future. We’ve received feedback for features that should be even more customizable (such as Explorer or the logon screen) or features that should be added to Windows (such as a PDF format reader, security tools, or disk utilities). And we’ve received feedback that some users might prefer to run Windows without certain features. This post is about a point of choice and control in the Windows 7 control panel called “Windows Features” which is where you can choose to turn various features of Windows on or off. This continues our discussion of changes we have made based on feedback from the Beta as we progress to the Release Candidate. This post is by Jack Mayo who is the group program manager for our Documents and Printing team and also worked on Internet Explorer 8. --Steven

    “Turning Windows Features On or Off” has a long history in Windows, going back to the earliest days of the 32-bit code base. We’ve received a lot of suggestions about features that you would like to turn on or off using your own criteria for choice. For Windows 7 we’ve engineered a more significant list of features and worked to balance that list in light of the needs of the broad Windows platform as well. We want to provide choice while also making sure we do not compromise on compatibility by removing APIs provided for developers. We also want to strike the right balance for consumers in providing choice and balancing compatibility with applications and providing a consistent Windows experience.

    We know many have specific ideas of what constitutes a “feature” or a “program” in Windows and what constitutes an identifiable “part” of the operating system, and yet we also know different people can have different points of view, often strongly held. Some might take an end-user approach and identify a feature based on a window or start menu shortcut. Some might take an approach based on one perspective of architectural subsystems, such as storage or security. Some might take an approach based on what to some are alternate choices to some similar functionality. All of these are valid in some context, but would not result in consistently identifying “features” considering these varied points of view. As engineers we know that no software system can be decomposed into an arbitrary set of layers or parts and any decomposition is likely to change over time.

    We don’t want the discussion about this feature or these choices to digress into a philosophical discussion about the definition of an operating system, which is ultimately a challenging exercise (judging by the revision history on the community page), but we do want to improve a feature centered on helping to meet the feedback expressed by some over the summer when this blog started.

    In the Release Candidate for Windows 7 we have extended the control panel called “Windows Features” which is available from the standard “Programs and Features” control panel (we often call this ARP, for the original name of Add/Remove Programs). This location is unchanged from Vista and XP, though the wording has been clarified. In Windows 7 if you bring up the Windows Features control panel by clicking on “Turn Windows Features on or off” (or just typing “Windows features” in the start menu) you will see the following in the Release Candidate (by default the hierarchy is not fully expanded, but in this screen shot I’ve expanded some elements for additional information):

    Windows Features control panel

    For those familiar with the Vista version or the Beta version of this dialog you will notice the list has grown. Let’s talk about what we’ve added and briefly how it works.

    If a feature is deselected, it is not available for use.  This means the files (binaries and data) are not loaded by the operating system (for security-conscious customers) and not available to users on the computer. These same files are staged so that the features can easily be added back to the running OS without additional media. This staging is important feedback we have received from customers who definitely do not like to dig up the installation DVD.

    For any of the features listed you can change the state to enable it or disable it. The Vista and Windows 7 beta control panel lists a wide range of features. Some are targeted towards Developers working on a client workstation (IIS, MSMQ, etc.), others are utilities for network administrators and enthusiasts (RSM, SNMP, Telnet, etc.), and some are features customers have asked us to make optional (Games, Fax and Scan, Tablet PC components).

    In Windows 7 we are expanding the number of features you have control over in this regard, giving customers more control, flexibility and choice in managing the features available in this version of Windows.  In addition to the features that were already available to turn on or off in Windows Vista, we’ve added the following features to the list in Windows 7:

    • Windows Media Player
    • Windows Media Center
    • Windows DVD Maker
    • Internet Explorer 8
    • Windows Search
    • Handwriting Recognition (through the Tablet PC Components option)
    • Windows Gadget Platform
    • Fax and Scan
    • XPS Viewer and Services (including the Virtual Print Driver)

    It is worth describing the details of “remove” since this too is a place where there are engineering and customer decisions to be made. We’ve already seen one decision which is to make sure we keep the features staged for future use so that a DVD is not required. A second decision is that we also continue to support the APIs available for features where these APIs are necessary to the functionality of Windows or where there are APIs that are used by developers that can be viewed as independent of the component. As many of you know these are often referred to as “dependencies” and with Windows the dependencies can run both internal to Windows and external for ISVs.

    It should be no surprise, but when we develop new features in Windows we tend to use the underlying infrastructure and associated APIs rather than duplicate code which would create extra working set, slow performance, and increase the surface area that needs to be secured, etc. We all know code reuse is a good engineering practice. As a platform, Windows tends to emphasize the creation of APIs for many systems, even when those subsystems are viewed as part of a larger system. When we have APIs that are used, we faced the choice of breaking software that just expected those APIs to be there or to continue to support the API. When we continued to support the API our approach was to remove a feature by making sure that an end-user could not invoke the feature via traditional end-user mechanisms. These are often difficult decisions as we work to balance the expectations of developers, the shared desire to deliver a robust release of Windows 7, and to maintain the goals set out by the feature “Turn Windows Features On or Off”. Because there are so many combinations of dependencies just represented in this list, selecting some options might provide you with some explanation as to the challenges in selecting a combination (for example Windows Media Player and Windows Media Center share a lot of code so turning one off might introduce a pretty complex situation for the average end-user).

    Finally, we know some have suggested that this set of choices be a “setup option”. Some operating systems do provide this type of setup experience. As we balanced feedback, the vast majority of feedback we have received was to streamline setup and to reduce the amount of potential complexity in getting a PC running. We chose to focus this feature on the post-setup experience for Windows 7.

    --Jack

  • Engineering Windows 7

    User Interface: Starting, Launching, and Switching

    • 131 Comments

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

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

    Taskbar Basics

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

    Image of Windows taskbar pointing out names of various regions.

    Fig. 1: Windows Taskbar Anatomy

    Taskband: The faithful window switcher

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

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

    The Start Menu: the Windows launch pad

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

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

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

    Quick Launch: Launching at your fingertips

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

    clip_image004

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

    Desktop Toolbars (aka Deskbands): Gadgets for your taskbar

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

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

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

    Notification Area: The whisperer

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

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

    Show Me the Data

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

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

    Histogram indicating peak number of open windows in sessions.

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

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

    Image of Taskbar properties dialog indicating percentage of sessions where a particular option is customized.

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

    LOCATION

    SESSION PERCENT

    Bottom (default)

    98.4%

    Top

    1.02%

    Left

    0.36%

    Right

    0.21%

    Fig. 5: Where do people put their taskbar?

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

    STATE

    SESSION PERCENT

    Toolbar enabled

    10%

    Toolbar enabled and visible

    3%

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

    Evolving the Taskbar

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

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

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

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

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

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

    - Chaitanya

  • Engineering Windows 7

    Continuing our discussion on performance

    • 129 Comments

    We've talked some about performance in this blog and recently many folks have been blogging and writing about the topic as well. We thought it would be a good time to offer some more behind the scenes views on how we have been working on and thinking about performance because it such an interesting topic for the folks reading this blog. Of course I've been using some pretty low-powered machines lately so performance is top of mind for me as well. But for fun I am writing this on my early holiday present--my new home machine is a 64-bit all-in-one desktop machine with a quad core CPU, discrete graphics, 8GB of memory, and hardware RAID all running a pretty new build of Windows 7 upgraded as soon as I finished the out of box experience. Michael Fortin and I authored this post. --Steven

    Our beta isn’t even out the door yet and many are already dusting off their benchmarks and giving them a whirl. As a reminder, we are encouraging folks to hold on benchmarking our pre-production builds. Yet we’ve come to expect it will happen, and we realize it will lead many to conclude one thing or another, and at the same time we appreciate those of you who take the time to remind folks of the pre-ship status of the code. Nevertheless we’re happy that many are seeing good results thus far. We're not yet as happy as we believe we will be when we finish the product as we continue to work on all the fundamental capabilities of Windows 7 as well as all the new features folks are excited about.

    Writing about performance in this blog is nearly as tricky as measuring it. As we've seen directional statements are taken further than we might intend and at the same time there are seemingly infinite ways to measure performance and just as many ways to perceive the same data. Ultimately, performance is something each individual feels is right--whether than means adequate or stellar might vary scenario to scenario, individual to individual. Some of the mail we've received has been clear about performance:

    • Boot-very very fast in all applications ( open-load applications) especially so many simultaneously!!!!! Hence, massive multicore ( quad-octa core cpu) , gpgpu for all!!!!!!!!!!!!
    • This is right time to do this properly, the users want speed, we'll give them speed.
    • i want to be able to run windows 7 extremely fast and still look good graphically on a asus aspire one netbook with these specs-1.5 ghz intel atom processor (single core) 1gb of ram
    • I hope that in addition to improvements in the gui and heart (I hope massive multicore + 64-bit + Directx 11 ..extreme performance, etc) for windows 7, modified the feature Flip 3d In Windows 7!!!!! Try to make a Flip 3D feature, really efficient and sensible in windows 7.
    • With regard to the performance thing, could you look at ways to reduce the penalty of having a lot of fonts installed.
    • From performance, boot up, explorer speed and UI experience , I hope the next version of windows delivers something new and innovating. I was playing with the new UI on the HP TouchPC and I have to say they did a great 1.0 job on the touch interface controls.
    • I do keep my fingers crossed for Windows 7 to be dramatically better in its performance than Windows Vista.
    • The biggest feature I see a lot of people wanting is performance.

    You can also see through some of these quotes that performance means something different to different people. As user-interface folks know, perceived performance and actual performance can often be different things. I [Steven] remember when I was writing a portion of the Windows UI for Visual C++ and when I benchmarked against Borland C++ at the time, we were definitely faster (measured by seconds). However the reviews consistently mentioned Borland as being faster and providing feedback in the form of counts of lines compiled flying by. So I coded up a line count display that flashed a lot of numbers at you while compiling (literally flashy so it looked like it couldn't keep up). In clock times it actually consumed a non-zero amount of time so we got "slower" but the reviewers then started giving us credit for being faster. So in this case slower actually got faster.

    There's another story from the past that is the flip side of this which is the scrolling speed in Microsoft Word for DOS (and also Excel for Windows--same dynamic). BillG always pushed hard on visible performance in the "early" days and scrolling speed was one of those things that never seemed to be fast enough. Well clever folks worked hard on the problem and subsequently made scrolling too fast--literally to the point that we had to slow it down so you didn't always end up going from page 1 to the end of the document just because you hold down the page down key. It is great to be fast, but sometimes there is "too much speed".

    We have seen the feedback about what to turn off or adjust for better performance. In many ways what we're seeing are folks hoping to find the things that cause the performance to be less than they would like. I had an email conversation with someone recently trying to pinpoint the performance issues on a new laptop. Just by talking through it became clear the laptop was pretty "clean" (~40 processes, half the 1GB of RAM free, <5% CPU at idle, etc.) and after a few back and forths it became clear it was the internet connection (dial-up) that was actually the biggest bottleneck in the system. Many encourage us to turn off animations, graphics, or even color as there is a belief that these can be the root of performance. We've talked about the registry, disk space utilization, and even color depth as topics where folks see these as potential performance issues.

    It is important to consider that performance is inherently a time/space tradeoff (computer science sense, not science fiction sense), and on laptops there is the added dimension of power consumption (or CPU utilization). Given infinite memory, of course many algorithms would be very different than the ones we use. In finite memory, performance is impacted greatly by the overall working set of a scenario. So in many cases when we talk about performance we are just as much talking about reducing the amount of memory consumed as we are talking about the clock time. Some parts of the OS are much more tunable in terms of the memory they use, which then improves the overall performance of the system (because there is less paging). Other parts of the system are much more about the number of instructions executed (because perhaps every operation goes through that code path). We work a great deal on both!

    The reality of measuring and improving performance is one where we are focused at several "levels" in Windows 7: micro-benchmarks, specific scenarios, system tuning. Each of these plays a critical role in how we are engineering Windows 7 and while any single one can be measured it is not the case that one can easily conclude the performance of the system from a measurement.

    Micro-benchmarks. Micro-benchmarks are the sort of tests that stress a specific subsystem at extreme levels. Often these are areas of the code that are hard to see the performance of during usage as they go by very fast or account for a small percentage of time during overall execution. So tests are designed to stress part of the system. Many parts of the system are subjected to micro-benchmarking such as the file system, networking, memory management, 2D and 3D graphics, etc. A good example here is the work we do to enable fast file copying. There is a lot of low level code that accounts for a (very significant) number of conditions when copying files around, and that code is most directly executed through XCOPY in a command window (or an API). Of course the majority of copy operations take place through the explorer and along with that comes a progress indicator, cancellable operation, counting up bytes to copy, etc. All of those have some cost with the benefit as well. The goal of micro-benchmarks is to enable us to best understand the best possible case and then compare it to the most usable case. Advanced folks always have access to the command line for more power, control, and flexibility. It is tempting to measure the performance of the system by looking at improvements in micro-benchmarks, but time and time again this proves to be inadequate as routine usage covers a much broader code path and time is spent in many places. For Internet Explorer 8 we did a blog post on performance that went into this type issue relative to script performance. At the other end of the spectrum we definitely understand the performance of micro-benchmarks on some subsystems will be, and should be, carefully measured --the performance of directx graphics is an area that gamers rely on for example. It is worth noting that many micro-benchmarks also depend heavily on a combination of Windows OS, hardware, and specific drivers.

    Specific scenarios. Most people experience the performance of a PC through high level actions such as booting, standby/resume, launching common applications. These are topics we have covered in previous posts to some degree. In Engineering Windows 7, each team has focused on a set of specific scenarios that are ones we wanted to make better. This type of the work should be demonstrable without any elaborate setup or additional tools. This work often involves tuning the code path for the number of instructions executed, looking at the data allocated for the common case, or understanding all the OS APIs called (for example registry lookups). One example that comes to mind is the work that we have going on to reduce the time to reinsert a USB device. This is particularly noticeable for UFD (USB flash drives) or memory cards. Windows of course allows the whole subsystem to be plumbed by unique drivers for a specific card reader or UFD, even if most of the time they are the same we still have to account for the variety in the ecosystem. At the start of the project we looked at a full profile of the code executed when inserting a UFD and worked this scenario end-to-end. Then systematically each of the "hot spots" was worked through. Another example along these lines was playback of DVD movies which involves not only the storage subsystem but the graphics subsystem as well. The neat thing about this scenario is that you also want to optimize for the CPU utilization (which you might not even notice while playing back the movie) as that dictates the power consumption.

    System tuning. A significant amount of performance work falls under the umbrella of system tuning. To ascertain what work we do in this area we routinely look at the overall performance of the system relative to the same tests on previous builds and previous releases of Windows. We're looking for things that we can do to remove operations that take a lot of time/space/power or things that have "grown" in one of those dimensions. We have build-to-build testing we do to make sure we do not regress and of course every developer is responsible for making sure their area improves as well. We left no stone unturned in terms of investigating opportunities to improve. One of the areas many will notice immediately when looking at the pre-beta or beta of Windows 7 is the memory usage (as measured by task manager, itself a measurement that can be misunderstood) of the desktop window manager. For Windows 7, a substantial amount of architectural work went into reducing the amount of memory consumed by the subsystem. We did this work while also maintaining compatibility with the Windows Vista drivers. We did similar work on the desktop search engine where we reduced not just the memory footprint, but the I/O footprint as well. One the most complex areas to work on was the improvements in the taskbar and start menu. These improvements involved substantial work on critical sections ("blocking" areas of the code), registry I/O, as well as overall code paths. The goal of this work is to make sure these UI elements are always available and feel snappy.

    It is worth noting that there are broad based measures of performance as well that drive the user interface of a selection of applications. These too have their place--they are best used to compare different underlying hardware or drivers with the same version of Windows. The reason for this is that automation itself is often version dependent and because automation happens in a less than natural manner, there can be a tendency to measure these variances rather than any actual perceptible performance changes. The classic example is the code path for drawing a menu drop down--adding some instructions that might make the menu more accessible or more appealing would be impossible to perceive by a human, but an automated system that drives the menu at super human speed would see a change in "performance". In this type of situation the effect of a micro-benchmark is magnified in a manner inconsistent with actual usage patterns. This is just a word of caution on how to consider such measurements.

    Given this focus across different types of measurement it is important to understand that the overall goal we have for Windows 7 is for you to experience a system that is as good as you expect it to be. The perception of performance is just as important as specific benchmarks and so we have to look to a broad set of tools as above to make sure we are operating with a complete picture of performance.

    In addition to these broad strategies there are some specific tools we've put in place. One of these tools, PerfTrack, takes the role of data to the next level with regard to performance and so will play a significant role in the beta. In addition, it is worth reminding folks about the broad set of efforts that go into engineering for performance:

    • We’ve been building out and maintaining a series of runs that measure thousands of little and big things. We’ve been running these before developer check-ins and maintaining performance and responsiveness at a level above which all that self-host our builds will find acceptable. These gates have kept the performance and responsiveness of our daily builds at a high enough level that thousands have found it possible to run their main systems on Windows 7 for extended periods of time, doing their normal daily work.
    • We’ve been driving down footprint, reducing our service costs, improving the efficiency of key code paths, refactoring locks to improve scalability, reducing hangs, improving our I/O efficiency and much more. These are scenario driven based on real world execution paths we know from our telemetry to be common.
    • We’ve been partnering closely with the top OEMs, ISVs and IHVs. Our tools have been made public, we’ve held numerous training sessions, and we’ve been focusing heavily on shipping systems in an effort to insure customers get great performing systems out of the box, with great battery life too.
    • Within the Windows dev team, we’ve placed a simple trace capturing tool on everyone’s desktop. This desktop tool allows each person to run 24x7 with performance tracing enabled. If anything seems slow or sluggish, they can immediately save the last minute-or-so of activity and send it for automated analysis. Additionally, a team of people visually inspect the traces for new issues or issues not yet decipherable by our automation. The traces are incredibly rich and allow us to get to the root of top issues most of the time.
    • For all Pre-Beta, Beta and RTM users, we’ve developed a new form of instrumentation and have used it to instrument over 500 locations in the operating system and inbox applications. This new instrumentation is simple in concept, but revolutionary in result. The tool is called PerfTrack, and it has helped confirm our belief that the client benchmarks aren’t too informative about real user responsiveness issues.

    Perftrack is a very flexible, low overhead, dynamically configurable telemetry system. For key scenarios throughout Windows 7, there exist “Start” and “Stop” events that bracket the scenario. Scenarios can be pretty much anything; including common things like opening a file, browsing to a web page, opening the control panel, searching for a document, or booting the computer. Again, there are over 500 instrumented scenarios in Windows 7 for Beta.

    Obviously, the time between the Stop and Start events is meant to represent the responsiveness of the scenario and clearly we’re using our telemetry infrastructure to send these metrics back to us for analysis. Perftrack’s uniqueness comes not just from what it measure but from the ability to go beyond just observing the occurrence of problematic response times. Perftrack allows us to “dial up” requests for more information, in the form of traces.

    Let’s consider the distribution below and, for fun, let's pretend the scenario is opening XYZ. For this scenario, the feature team chose to set some goals for responsiveness. With their chosen goals, green depicts times they considered acceptable, yellow represents times they deemed marginal, and red denotes the poor times. The times are in milliseconds and shown along the X axis. The Hit Count is shown on the Y axis.

    Graph measuring responsiveness goals and real world data.

    As can be seen, there are many instances where this scenario took more than 5 seconds to complete. With this kind of a distribution, the performance team would recommend that we “dial up” a request for 100+ traces from systems that have experienced a lengthy open in the past. In our “dialed up” request, we would set a “threshold” time that we thought was interesting. Additionally, we we may opt to filter on machines with a certain amount of RAM, a certain class of processor, the presence of specific driver, or any number of other things. Clients meeting the criteria would then, upon hitting the “Start” event, configure and enable tracing quickly and potentially send back to us if the “Stop” event occurred after our specified “threshold” of time.

    As you might imagine, a good deal of engineering work went into making this end to end telemetry and feedback system work. Teams all across the Windows division have contributed to make this system a reality and I can assure you we’ll never approach performance the same now that we have these capabilities.

    As a result of focusing on traces and fixing the very real issue revealed by them, we’ve seen significant improvements in actual responsiveness and have received numerous accolades on Windows 7. Additionally, I’d like to point out that these traces have served to further confirm what we’ve long believed t be the case.

    This post provides an overview of the ways we have thought about performance with some specifics about how we measure it throughout the engineering of Windows 7. We believe that throughout the beta we will continue to have great telemetry to help make sure we are achieving our goals and that people perceive Windows 7 to perform well relative to their expectations.

    We know many folks will continue to use stop watches, micro-benchmarks, or to drive automated tests. These each have their place in your own analysis and also in our engineering. We thought given all the interest we would talk more about how we measure things and how we're engineering the product.

    --Steven and Michael

  • Engineering Windows 7

    Our Next Engineering Milestone

    • 129 Comments

    Many posts start with a thank you and I want to start this post with an extra special thank you on behalf of the entire Windows team for all the installs and usage we are seeing of the Windows 7 Beta. We’ve had millions of installations of Windows 7 from which we are receiving telemetry, which is simply incredible. And from those who click on the “Send Feedback” button we are receiving detailed bug reports and of course many suggestions. There is simply no way we could move from Beta through Final Release of Windows 7 without this type of breadth coverage and engagement from you in the development cycle. There’s been such an incredible response, with many folks even blogging about how they have moved to using Windows 7 Beta on all their machines and have been super happy. The question we get most often is “if the Beta expires in August what will I do—I don’t want to return to my old [sic] operating system.” For a Beta release, that is quite a complement and we’re very appreciative of such a kind response.

    This post is about the path from where we are today, Beta, to our RTM (Release To Manufacturing), building on the discussion of this topic that started at the PDC. This post is in no way an announcement of a ship date, change in plans, or change in our previously described process, but rather it provides additional detail and a forward looking view of the path to RTM and General Availability. The motivation for this, in addition to the high level of interest in Windows 7, is that we’re now seeing how releasing Windows is not something that Microsoft does “solo”, but rather is something that we do as one part of the overall PC ecosystem. Obviously we have a big responsibility to do our part, one we take very seriously of course. The last stages of a Windows release are a partnership across the entire ecosystem working to make sure that the incredible variety of choices you have for PCs, software, and peripherals work together to bring you a complete and satisfying Windows 7 experience.

    The next milestone for the development of Windows 7 is the Release Candidate or “RC”. Historically the Release Candidate has signaled “we’re pretty close and we want people to start testing the release, especially because all the features are done.” As we have said before, with Windows 7 we chose a slightly different approach which we were clear up front about and are all now experiencing together and out in the open. The Pre-Beta from the PDC was a release where we said it was substantially API complete and even for the areas that were not in the release we detailed the APIs and experience in the sessions at the PDC. At that time we announced that the Beta test in early 2009 would be both API and feature complete, widely available, and would be the only Beta test. We continued this dialog with our hardware partners at WinHEC. We also said that many ecosystem partners including PC makers, software vendors, hardware makers will, as has been the case, continue to receive interim builds on a regular basis. This is where we stand today. We’ve released the feature complete Beta and have made it available broadly around the world (though we know folks have requested even more languages). As a development team we’re doing just what many of you do, which is choosing to run the Beta full time on many PCs at home and work (personally I have at least 9 different machines running it full time) and we’re running it on many thousands of individual’s machines inside Microsoft, and thousands of machines in our labs as well.

    All the folks running the Beta are actively contributing to fixing it. We’re getting performance telemetry, application compatibility data, usage information, and details on device requirements among other areas. This data is very structured and very actionable. We have very high-bandwidth relationships with partners and good tools to help each other to deliver a great experience. One thing you might be seeing is that hardware and software vendors might be trying out updated drivers / software enhanced for Windows 7. For example, many of the anti-virus vendors already have released compatibility packs or updates that are automatically applied to your running installation. You might notice, for example, that many GPU chipsets are being recognized and Windows 7 downloads the updated WDDM 1.1 drivers. While the Windows Vista drivers work as expected, the new 1.1 drivers provide enhanced performance and a reduced memory footprint, which can make a big difference on 1GB shared memory machines. You might insert a device and receive a recently updated version of a driver as I did for a Logitech QuickCam. Another example some of you might have seen is that the Beta requires a an updated version of Skype software currently in testing. When you go to install the old version you get an error message and then the problem and solutions user interface kicks in and you are redirected to the Beta site. This type of error handling is deployed in real time as we learn more and as the ecosystem builds out support. It is only because of our partnerships across the ecosystem that such efforts are possible, even during the Beta.

    Of course, it is worth reiterating that our design point is that devices and software that work on Windows Vista and are still supported by the manufacturer will work on Windows 7 with the same software. There are classes of software and devices that are Windows-version specific for a variety of reasons, as we have talked about, and we continue to work together to deliver great solutions for Windows 7. The ability to provide people the vast array of choices and the openness of the Windows platform make all of this a massive undertaking. We continue to work to improve this while also making sure we provide the opportunities for choice and differentiation that are critical to the health and variety of the overall ecosystem. This data and the work we’re doing together with partners is the critical work going on now to reach the Release Candidate phase.

    We’re also looking carefully at all the quality metrics we gather during the Beta. We investigate crashes, hangs, app compat issues, and also real-world performance of key scenarios. A very significant portion of our effort from Beta to RC is focused on exclusively on quality and performance. We want to fix bugs experienced by customers in real usage as well as our broad base of test suites and automation. A key part of this work is to fix the bugs that people really encounter and we do so by focusing our efforts on the data we receive to drive the ordering and priority of which bugs to fix. As Internet Explorer has moved to Release Candidate, we’ve seen this at work and also read about it on IE Blog.

    Of course the other work we’re doing is refining the final product based on all the real-world usage and feedback. We’ve received a lot of verbatim feedback regarding the user experience—whether that is default settings, keyboard shortcuts, or desired options to name a few things. Needless to say just working through, structuring, and “tallying” this feedback is a massive undertaking and we have folks dedicated to doing just that. At the peak we were receiving one “Send Feedback” note every 15 seconds! As we’ve talked about in this blog, we receive a lot of feedback where we must weigh the opinions we receive because we hear from all sides of an issue—that’s to be expected and really the core design challenge. We also receive feedback where we thought something was straight forward or would work fine, but in practice needed some tuning and refinement. Over the next weeks we’ll be blogging about some of these specific changes to the product. These changes are part of the process and part of the time we have scheduled between Beta and RC.

    So right now, every day we are researching issues, resolving them, and making sure those resolutions did not cause regressions (in performance, behavior, compatibility, or reliability). The path to Release Candidate is all about getting the product to a known and shippable state both from an internal and external (Beta usage and partner ecosystem readiness) standpoint.

    We will then provide the Release Candidate as a refresh for the Beta. We expect, based on our experience with the Beta, a broad set of folks to be pretty interested in trying it out.

    With the RC, this process of feedback based on telemetry then repeats itself. However at this milestone we will be very selective about what changes we make between the Release Candidate and the final product, and very clear in communicating them. We will act on the most critical issues. The point of the Release Candidate is to make sure everyone is ready for the release and that there is time between the Release Candidate and our release to PC makers and manufacturing to validate all the work that has gone on since the pre-Beta. Again, we expect very few changes to the code. We often “joke” that this is the point of lowest productivity for the development team because we all come to work focused on the product but we write almost no code. That’s the way it has to be—the ship is on the launch pad and all the tools are put away in the toolbox to be used only in case of the most critical issues.

    As stated up front, this is a partnership and the main thing going on during this phase of the project is really about ecosystem readiness. PC makers, software vendors, hardware makers all have their own lead times. The time to prepare new products, new configurations, software updates, and all the collateral that goes with that means that Windows 7 cannot hit the streets (so to speak) until everyone has time to be ready together. Think of all those web sites, download pages, how-to articles, training materials, and peripheral packages that need to be created—this takes time and knowing that the Release Candidate is the final code that we’re all testing out in the open is reassuring for the ecosystem. Our goal is that by being deliberate, predictable, and reliable, the full PC experience is available to customers.

    We also continue to build out our compatibility lists, starting with logo products, so that our http://www.microsoft.com/windows/compatibility site is a good resource for people starting with availability. All of these come together with the PC makers creating complete “images” of Windows 7 PCs, including the full software, hardware, and driver loads. This is sort of a rehearsal for the next steps.

    At that point the product is ready for release and that’s just what we will do. We might even follow that up with a bit of a celebration!

    There’s one extra step which is what we call General Availability or GA. This step is really the time it takes literally to “fill the channel” with Windows PCs that are pre-loaded with Windows 7 and stock the stores (online or in-person) with software. We know many folks would like us to make the RTM software available right away for download, but this release will follow our more established pattern. GA also allows us time to complete the localization and ready Windows for a truly worldwide delivery in a relatively small window of time, a smaller window for Windows 7 than any previous release. It is worth noting that the Release Candidate will continue to function long enough so no one should worry and everyone should feel free to keep running the Release Candidate.

    So to summarize briefly:

    • Pre-Beta – This release at the PDC introduced the developer community to Windows 7 and represents the platform complete release and disclosure of the features.
    • Beta – This release provided a couple of million folks the opportunity to use feature complete Windows 7 while also providing the telemetry and feedback necessary for us to validate the quality, reliability, compatibility, and experience of Windows 7. As we said, we are working with our partners across the ecosystem to make sure that testing and validation and development of Windows 7-based products begins to enter final phases as we move through the Beta.
    • Release Candidate (RC) – This release will be Windows 7 as we intend to ship it. We will continue to listen to feedback and telemetry with the focus on addressing only the most critical issues that arise. We will be very clear in communicating any changes that have a visible impact on the product. This release allows the whole ecosystem to reach a known state together and make sure that we are all ready together for the Release to Manufacturing. Once we get to RC, the whole ecosystem is in “dress rehearsal” mode for the next steps.
    • Release to Manufacturing (RTM) – This release is the final Windows 7 as we intend to make available to PC makers and for retail and volume license products.
    • General Availability (GA) – This is a business milestone and represents when you can buy Windows 7 pre-installed on PCs or as full packaged product.

    The obvious question is that we know the Pre-Beta was October 28, 2008, and the Beta was January 7th, so when is the Release Candidate and RTM? The answer is forthcoming. We are currently evaluating the feedback and telemetry and working to develop a robust schedule that gets us the right level of quality in a predictable manner. Believe me, we know many people want to know more specifics. We’re on a good path and we’re making progress. We are taking a quality-based approach to completing the product and won’t be driven by imposed deadlines. We have internal metrics and milestones and our partners continue to get builds routinely so even when we reach RC, we are doing so together as partners. And it relies, rather significantly, on all of you testing the Beta and our partners who are helping us get to the finish line together.

    Shipping Windows, as we hoped this shows, is really an industry-wide partnership. As we talked about in our first post, we’re promising to deliver the best release of Windows we possibly can and that’s our goal. Together, and with a little bit more patience, we’ll achieve that goal.

    We continue to be humbled by the response to Windows 7 and are heads down on delivering a product that continues to meet your needs and the needs of our whole industry.

    --Steven on behalf of the Windows 7 team

  • Engineering Windows 7

    Reflecting on a few recent threads…

    • 126 Comments

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

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

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

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

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

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

    Profile-based Setup

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

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

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

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

    Out of Box Experience - “OOBE”

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

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

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

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

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

    Windows Features

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

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

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

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

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

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

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

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

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

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

    --Steven

  • Engineering Windows 7

    Follow-up: Managing Windows windows

    • 121 Comments

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

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

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

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

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

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

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

    Put the windows where I want them

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

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

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

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

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

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

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

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

    Open at the right size

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

    @magicalclick suggested a solution:

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

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

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

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

    –steven

    Finding the right window

    The word being used is “Expose”:

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

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

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

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

    Dragging files

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

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

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

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

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

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

    - Dave

  • Engineering Windows 7

    Windows 7 -- Approach to System Performance

    • 113 Comments

    Many folks have commented and written email about the topic of performance of Windows. The dialog has been wide ranging—folks consistently want performance to improve (of course). As with many topics we will discuss, performance, as absolute and measurable as it might seem, also has a lot of subtlety. There are many elements and many tradeoffs involved in achieving performance that meets everyone’s expectations. We know that even meeting expectations, folks will want even more out of their Windows PCs (and that’s expected). We’ve re-dedicated ourselves to work in this area in Windows 7 (and IE 8). This is a major initiative across each of our feature teams as well as the primary mission of one of our feature teams (Fundamentals). For this post, I just wanted to frame the discussion as we dig into the topic of performance in subsequent posts.  Folks might find this post on IE8 performance relevant along with the beta 2 release of IE 8. 

    Performance is made up of many different elements. We could be talking about response time to a specific request. It might mean how much RAM is “typical” or what CPU customers need. We could be talking about the clock time to launch a program. It could mean boot or standby/resume. It could mean watching CPU activity or disk I/O activity (or lack disk activity). It could mean battery life. It might even mean something as mundane as typical disk footprint after installation. All of these are measures of performance. All of these are systematically tracked during the course of development. We track performance by running a known set of scenarios (there are thousands of these) and developers can run specific scenarios based on exercising more depth or breadth. The following represent some (this is just a partial list) of the metrics we are tracking and while developing Windows 7:

    • Memory usage – How much memory a given scenario allocates during a run. As you know, there is a classic tradeoff in time v. space in computer science and we’re not exempt. We see this tradeoff quite a bit in caches where you can use more memory (or disk space) in order to improve performance or to avoid re-computing something.
    • CPU utilization – Clearly, modern microprocessors offer enormous processing power and with the advent of multiple cores we see the opportunity for more parallelism than ever before. Of course these resources are not free so we measure the CPU utilization across benchmark runs as well. In general, the goal should be to keep the CPU utilization low as that improves multi-user scenarios as well as reduces power consumption.
    • Disk I/O – While hard drives have improved substantially in performance we still must do everything we can do minimize the amount that Windows itself does in terms of reading and writing to disk (including paging of course). This is an area receiving special attention for Windows 7 with the advent of solid state storage devices that have dramatically different “characteristics”.
    • Boot, Shutdown, Standby/Resume – All of these are the source of a great deal of focus for Windows 7. We recognize these can never be fast enough. For these topics the collaboration with the PC manufacturers and hardware makers plays a vital role in making sure that the times we see in a lab (or the performance you might see in a “clean install”) are reflected when you buy a new PC.
    • Base system – We do a great deal to measure and tune the base system. By this we mean the resource utilization of the base system before additional software is loaded. This system forms the “platform” that defines what all developers can count on and defines the system requirements for a reasonable experience. A common request here is to kick something out of the base system and then use it “on demand”. This tradeoff is one we work on quite a bit, but we want to be careful to avoid the situation where the vast majority of customers face the “on demand” loading of something which might reduce perceived performance of common scenarios.
    • Disk footprint – While not directly related to runtime performance, many folks see the footprint of the OS as indicative of the perceived performance. We have some specific goals around this metric and will dive into the details soon as well. We’ll also take some time to explain \Windows\WinSxS as it is often the subject of much discussion on technet and msdn! Here rather than runtime tradeoffs we see convenience tradeoffs for things like on disk device drivers, assistance content, optional Windows components, as well as diagnostics and logging information.

    We have criteria that we apply at the end of our milestones and before we go to beta and we won’t ship without broadly meeting these criteria. Sometimes these criteria are micro-benchmarks (page faults, processor utilization, working set, gamer frame rates) and other times they are more scenario based and measure time to complete a task (clock time, mouse clicks). We do these measurements on a variety of hardware platforms (32-bit or 64-bit; 1, 2, 4GB of RAM; 5400 to 7200 RPM or solid-state disks; a variety of processors, etc.) Because of the inherent tradeoffs in some architectural approaches, we often introduce conditional code that depends on the type of hardware on which Windows is running.

    On the one hand, performance should be straight forward—use less, do less, have less. As long as you have less of everything performance should improve. At the extreme that is certainly the case. But as we have seen from the comments, one person’s must-have is another person’s must-not-have. We see this a lot with what some on have called “eye candy”—we get many requests to make the base user interface “more fun” with animations and graphics (“like those found on competing products”) while at the same time some say “get rid of graphics and go back to Windows 2000”. Windows is enormously flexible and provides many ways to tune the experience. We heard lots on this forum about providing specific versions of Windows customized for different audiences, while we also heard quite a bit about the need to reduce the number of versions of Windows. However, there are limits to what we can provide and at the same time provide a reliable “platform” that customers and developers can count on and is robust and manageable for a broad set of customers. But of course within a known context (within your home or within a business running a known set of software) it will always be possible to take advantage of the customization and management tools Windows has to offer to tune the experience. The ability to have choice and control what goes on in your PC is of paramount importance to us and you will see us continue to focus on these attributes with Windows 7.

    By far the biggest challenge in delivering a great PC experience relative to performance is that customers keep using their PCs to do more and more things and rightfully expect to do these things on the PC they own by just adding more and more software. While it is definitely the case that Windows itself adds functionality, we work hard to pick features that we believe benefit the broadest set of customers. At the same time, a big part of Windows 7 will be to continue to support choice and control over what takes place in Windows with respect to the software that is provided, what the default handlers are for file types and protocols, and providing a platform that makes it easy for end-users to personalize their computing experience.

    Finally, it is worth considering real world versus idealized settings. In order to develop Windows we run our benchmarks in a lab setting that allows us to track specifically the code we add and the impact that has. We also work closely with the PC Manufacturers and assist them in benchmarking their systems as they leave the factory. And for true real-world performance, the Microsoft Customer Experience Improvement Program provides us (anonymous, private, opt-in) data on how machines are really doing. We will refer to this data quite a bit over the next months as it forms a basis for us to talk about how things are really working, rather than using anecdotes or less reliable forms of information.

    In our next post we will look at startup and boot performance, and given the interest we will certainly have more to say about the topic of performance.

    --Steven

  • Engineering Windows 7

    Action Center

    • 112 Comments

    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.

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

    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.

    Notification click-through rate - August through September, 2008

    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.

    Which software accounts for notifications - August through September, 2008

    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.

    Action Center notification area icon and fly-out menu

    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.

    Action Center Control Panel with a few messages queued up

    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

  • Engineering Windows 7

    Back from the PDC…next up, WinHEC

    • 108 Comments

    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

  • Engineering Windows 7

    Measuring the scale of a release

    • 108 Comments

    Thanks for all the feedback that we have been getting. That much of it is positive is certainly appreciated. I’ve been answering mails as best I can and along with members of the team we’ve been having the discussion in the comments. Everyone has done a great job sharing their views on specifics, wishes, and requests. I love getting these mails and reading the comments. It is fantastic. I just want to make sure folks know I can’t answer each one! What we are going to do is look to the emails and comments as a way of suggesting posts we should write.  The team overall appreciate the warm reception from all those that have joined us--we know we have lots of energetic discussions ahead of us and we're genuinely happy to start.

    With this post, I am hoping to continue the dialog on the way we think “inside the Win7 team” so to speak—in a sense this is about expanding the team a bit and bringing you into some more of the discussions we have about planning a release. This conversation about major or minor releases is very much like the one I have with my boss as we start planning :-)

    When we started planning the release, the first thing some might think we have to decide is if Windows 7 (client) would be a “major release” or not. I put that in quotes because it turns out this isn’t really something you decide nor is it something with a single answer. The magnitude of a release is as much about your perspective on the features as it is about the features themselves. One could even ask if being declared a major release is a compliment or not. As engineers planning a product we decide up front the percentage of our development team will that work on the release and the extent of our schedule—with the result in hand customers each decide for themselves if the release is “major”, though of course we like to have an opinion. On the server blog we talked about the schedule and we shared our opinion of the scale of the releases of Windows 7 client and server.

    Our goal is about building an awesome release of Windows 7.

    Across all customers, there is always a view that a major release is one that has features that are really the ones for me. A minor release is one that doesn’t have anything for me. It should then be pretty easy to plan a major release—just make sure it exactly the right features for everyone (and given the focus on performance, it can’t have any extra features, even if other people want them)! As engineers we all know such a design process is really impossible, especially because more often than not any two customers can be found to want exactly opposite features. In fact as I type this I received sequential emails one saying “[N]obody cares about touch screen nonsense” and the other saying “[Win7 needs] more advanced/robust ‘touch’ features”. When you just get unstructured and unsolicited input you see these opposites quite a bit. I’m sure folks are noticing this on the blog comments as well.

    Let’s explore the spectrum of release magnitude across a couple of (but not all) different types of customers: end-users, developers, partners, IT professionals, and influentials.

    End-users are generally the most straight-forward in terms of deciding how big a release is going to be. For an end-user a release is a big deal if they want to go out and buy an upgrade or buy a new PC. We could call that a major release. Seems simple enough and a major release is good for everyone. On the other hand, one could also imagine that a release is really cool and people want to buy it, but they also want to use their existing PC and the release requires more memory, updated drivers that might not be available, or maybe some specific hardware to be fully realized. Then it seems that a major release goes from a positive to a bit of an under-taking and thus loses some of its luster. Of course we all know that what folks really want is all the things they want that runs on the hardware they want—then that is a great product to get (whether it is major or not).

    Developers look at a release through a different lens. Obviously for developers a release is a major one if there are new APIs and capabilities to take advantage of in their software—again straight-forward enough. It could also be the case that a previous release had a lot of new APIs and folks are just getting familiar with using them and so what they really want is to round out the APIs and maybe improve performance. So one might suspect that the first release is a major release and the second type is a minor release. But if you look at the history of software products, it is often these “minor” releases that themselves become the major releases – Windows 3.1, Office 4.2, or even Windows XP SP2. In each of these cases, the target for developers became the “minor” release but in the eyes of the market that was the “major” release. The reason developers want to use new APIs is to differentiate their products or focus their energies on domain expertise they bring to the table, not just call new APIs for the sake of calling them. In that sense, a release might be a major one if it just happens to free up enough time for an ISV that they bet on the new APIs because they can focus on some things that are a major deal to them.

    Partners represent the broad set of folks who create PCs, hardware, and the infrastructure we think of as the ecosystem that Windows is part of. Partners tend to think about a major release in terms of the opportunity it creates and thus a major release might be one with a lot of change and thus it affords the opportunity to provide new hardware and infrastructure to customers. On the other hand, incompatibilities with the past might be viewed in a less than positive light if it means a partner needs to stop moving forward and revisit past work to bring it up to the required compatibility with a new release of Windows. If they choose, for any number of reasons, not to do that work then the release might be viewed as a minor one because of the lack of ecosystem support. So again we see that a big change can be viewed through the lens of a major or a minor release.

    IT professionals are often characterized as conservative by nature and thus take a conservative view of change. Due to the business focused nature of the role, the evaluation of any software product is going to take place in the context of a return on investment. So for an IT professional a major release would be one that delivers significant business value. This business value could be defined as a major investment in deployment and management of the software for example. Yet for end-users or developers, these very same features might not even be interesting let alone worthy of being a major or minor release.

    Influentials are all the folks who are in the business of providing advice, analysis, and viewpoints on the software we make. These folks often look at releases through the metric of “change”. Big changes equal major release. A big change can be a “re-architecture” as we saw in the transition from Windows 9x to Windows 2000—even though these products looked the same there was tons of change to talk about under the hood. So for reviewers and analysts it was definitely a major release. Big changes can also be big changes in the user-interface because that drives lots of discussion and it is easy to show all the change. Yet for each of these, this definition of major can also be viewed as a less than positive attribute. Re-architecture means potential incompatibilities. New user-interface can mean learning and moving from the familiar.

    We’ve seen a lot of comments and I have gotten a lot of email talking about re-architecting Windows as a symbol of a major release. We’ve also gotten a lot of feedback about how a major release is one that breaks with supporting the past. If I could generalize, folks are usually implying that if we do things like that then a number of other major benefits will follow—re-architecting leads to better performance, breaking with the past leads to using less memory. It is always tricky to debate those points because we are comparing a known state to a state where we fix all the things we know to fix, but we don’t yet know what we might introduce, break, or otherwise not fix. So rather than define a major release relative to the implementation, I think it makes sense define the success of the release relative to the benefits of whatever implementation is chosen.  We will definitely continue to pick up on this part of the discussion--there's a lot of dialog to have.

    The key is always a balance. We can have big changes for all customers if we prepare all the necessary folks to work through the change. We can have small changes have a big impact if they are the right changes at the right time, and those will get recorded over time as a major release.

    We’ve talked about the timing and the way we structure the team, so you have a sense for the “inputs” into the project. If we listened well and focused our efforts correctly, then each type of customers will find things that make the product worthwhile. And if we do our job at effectively communicating the product, then even the things that could be “problems” are seen in the broader context of an ecosystem where everyone collectively benefits when a few people benefit significantly.

    From our perspective, we dedicated our full engineering team and a significant schedule to building the Windows 7 client OS. That makes it a major undertaking by any definition. We intend for Windows 7 to be an awesome release.

    I hope this helped to see that perspective is everything when it comes to deciding how big a release is for each type of customer.

    --Steven

  • Engineering Windows 7

    Feedback and Engineering Windows 7

    • 105 Comments

    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

Page 1 of 3 (67 items) 123